[OpenLayers-Users] Large Vector Layer

[Scott Davis]

All good advice. Thanks for the response. (See inline comments below.)
-s

On Aug 21, 2007, at 9:56 AM, Tim Schaub wrote:
> Scott Davis wrote:
>> Bottom line: I need features from a datalayer that has 10k points. Is
>> WFS what you'd recommend at this point?
>
> A few things to keep in mind:
>
> With the current vector formats, you should think on the order of 100s
> of features client side (not thousands).
>
Agreed. The layer has 10k total points, but we don't turn it on until  
the user is zoomed in close enough to limit the damage to 100-150  
features.

var busstopWfs = new OpenLayers.Layer.WFS( "Bus Stop", "/public/ 
busstop/wfs", {typename: 'trimet:busstop'},
			  { isBaseLayer: false, maxResolution: 8, featureClass:  
OpenLayers.Feature.WFS.Busstop });

This might be stating the obvious, but it's worth commenting on  
publicly: WFS layers that have 10-20 features render almost  
immediately. The bus stop layer that has 100-200 features lags by 2-3  
seconds.

> You can use the maxFeatures parameter with WFS to limit the number of
> features requested.
>
Leaving bus stops off of our map might be perceived as a bug... (wink)

> You can use a combination of WMS and WFS - with min/max resolution on
> the layers - to limit requests for vector features.
>
Absolutely. When rendering the bus stops into the underlying WMS  
basemap, we pay zero performance penalties. (Thanks TileCache!)

The customer wants to hover over a bus stop to pop up add'l info,  
hence the need to move the features up from the WMS baselayer to a  
WFS Marker. Unfortunately, this gives us the 2-3 second lag in  
showing the bus stops. Also, dragging the map makes the Markers  
disappear and reappear again after another 2-3 second delay. We're  
actually toying with the idea of rendering the bus stop icon into the  
WMS baselayer to eliminate the flicker effect when dragging and the  
*appearance* of lag time. When the WFS layer catches up, it'll drop  
the identical icon invisibly over the identical spot on the map,  
giving us the hover capabilities. We're implementing this right now  
as we speak, but it looks like a promising compromise...

> You can use WMS with GetFeatureInfo to query feature attributes.
>
The problem with GetFeatureInfo requests on point data is the tiny,  
tiny target. We're dropping 20x20 pixel icons over the point.  
Requiring users to hit the bulls-eye each time isn't a viable  
solution, unfortunately. If either OpenLayers or GeoServer offered a  
buffer attribute on the GetFeatureInfo request, I'd use it in a  
heartbeat. (Hint, hint!) GFI requests on a Polygon are the bee's  
knees. Points, err, umm, not so much.

When I originally implemented this feature, it required a click on  
the map. Rather than doing a GetFeatureInfo, I rolled my own service  
to buffer the point and return the results. While it worked, there  
was the TCP/IP lag time (again, 2-3 seconds). The benefit of the WFS  
layer is that it pulls the data down locally, giving me instant pop ups.

I'm just laughing -- the click roundtrip was 2-3 seconds. The WFS fix  
now takes 2-3 seconds to render. I'm playing Whack-a-mole with that  
lag time, aren't I?

> There are two ways you take performance hits with vector features (or
> markers): parsing and rendering.
> [snip]
> So, without accounting for parsing, you can assume a client will  
> parse a
> feature (with attributes) in 5-10 ms.  You can see how waiting around
> 100 seconds just to parse 10,000 features is a show stopper.  Don't  
> even
> consider rendering them.

The 2-3 second lag we're seeing for ~150 WFS features  
(unscientifically calculated via the "gut feel" method) seems to be  
inline with your estimates.

>
> I'll work on getting the new GML format tested and into the trunk this
> week.

I'm really looking forward to both the GML format and the GeoJSON  
format work you're doing. GeoServer 1.6.head has GeoJSON output  
capabilities, but I haven't had a client that allows me to exercise  
it. Having both features in GeoServer and OpenLayers will allow us to  
do some evaluation between the two. I'm pretty sure that GeoJSON will  
win the race given its svelte footprint, but I'm looking forward to  
proving it in code.

Thanks again to everyone for the hard work they're putting into these  
great projects.

Cheers,
s