GML, KML, GeoJSON - Speed rendering 3109 polygons?

Question

I am working with Geoserver, serving U.S. Lower 48 counties to openlayers (3109 polygons - lots more vertices). The counties are loaded into a postgis database. I am curious about developer experience when trying to push that quantity of vertices to the client.

What WFS format have you attained the best results with? Has additional tuning to Geoserver been used?

I realize that tiled WMS would be faster, but I want to allow for dynamic changes in a choropleth map using openLayers, ie. the user submits a form, a Python script is called, and new data bins are returned for openlayers to reload the map div. I also want to try this in full resolution form before reducing polygon complexity in openlayers.

score 4 · Answer 1 · answered Jan 28 '13 at 00:31

Maybe this triggers some new ideas: I've got an application running where users can edit a map with many elements.

Instead of sending all data as WFS, I use WMS maps, and when the user clicks, or draws a selection, I fetch the selected items as WFS.

After sending an update back to the server, I refresh the WMS layer.

There are some OpenLayers examples that demonstrate how you can do that. You'll probably have to tweak it a bit, but OpenLayers+GeoServer will work out the difficult part for you. The data is sent gzipped, so the original format is not even that important; it's not the bottleneck. Let OpenLayers and GeoServer figure out what format they use to exchange information.

This approach scales pretty well. Even people with slow connections and slow computers can use it to edit the map. Fetching hundreds of elements is very quick, and you probably won't need more than that at the same time to edit.

_{Finally.. off-topic, but as you intend to do client-side stuff with map data:
Keep in mind that IE7 and lower are going to be problematic if you want to draw polygons with OpenLayers. OpenLayers uses SVG for client-side drawing, and IE7 and lower don't have support built in. Those users will be required to download a crappy old plugin.
All other browsers are fine.}

IE8 will be almost as bad. OpenLayers has several renderers and for browsers that don't support Canvas or SVG is will resort to VML, which IE7 does support. The different renderers give better and worse performance in different places, e.g. rendering vs. mouse-over & click detection — tomfumb, Jan 28 '13 at 17:34

score 3 · Answer 2 · edited Apr 13 '17 at 12:34

3

GEOJSON is in my opinion, the best format, it is easy to read, easy to use in javascript and generally smaller in size then GML/KML. It can even contain info about style, see here.

It not a official standard, but it is supported on both leaflet and openlayers and on many gis-desktop apps like qgis.

edited Apr 13 '17 at 12:34

Community

1

answered Jan 28 '13 at 09:19

warrieka

3,479
17
18

score 3 · Answer 3 · answered Jan 28 '13 at 15:16

3

Why not use your python script to create a new SLD file and send that to the WMS server with your request.

There is an example here.

answered Jan 28 '13 at 15:16

Ian Turton

81,417
6
84
185

I have considered this, and will likely test this option for speed. This is not for development, but for research, so I want to give WFS a try. – Jay Laura Jan 28 '13 at 15:31

score 2 · Answer 4 · edited Apr 13 '17 at 12:33

Using GeoJSON is a good start to speed up your system but it may not be sufficient. You should consider building several versions of your data layer, one per zoom layer, and apply generalisation/simplification methods to each version. The client should request the relevant layer depending on the selected zoom level. That would ensure the level of detail of the data exchanged between the server and the client is suitable, and it would boost more significantly both the network transfer and the rendering. To go further, you could extend your system with vector tiling and spatial indexing as described in this document, but I am not sure openlayers and geoserver can handle it...yet!

For sure: Forget GML.

This is my fallback method when the full resolution WFS is too slow. I'm interested in problems of this size and want to be able to report both the full resolution speed and, if necessary, the reduced resolution speed. — Jay Laura, Jan 28 '13 at 15:32

score 2 · Answer 5 · edited Apr 13 '17 at 12:34

I've been down a similar road twice already and client-side rendering for anything more than a small number of points or really simple polygons just isn't a good idea. Once you've tied yourself to that architecture it's costly to back out and in any project you're likely to see either a change in requirements or an increase in data volume as various stakeholders / supervisors start to see what your system's capable of. The browser-based client-side rendering approach does not scale.

If you want dynamic rendering I second @iant's approach. I previously described a number of options for a different but related problem here. I've also used polygon generalisation to assist in client-side rendering and, while it definitely does help, it generates more difficult problems, like if you want to pull down the non-generalised polygon as your user zooms further in.

Even if you're working with a known platform - e.g. you know the hardware, browser version, and plugins of all clients - which is unlikely, you have no idea what kind of load those clients are under. This kind of approach requires that the browser can get a LOT of CPU time to keep the user experience fluid and anything else is going to annoy your users.

GML, KML, GeoJSON - Speed rendering 3109 polygons?

5 Answers5