My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
CommonVectorBottlenecks  
A discussion of the common performance bottlenecks and annoyances encountered when displaying vectors as KML
Updated Jul 1, 2010 by perrygeo...@gmail.com

Points are too dense

Problem : too many points to differentiate at higher zoom levels.

Solution : point clustering .

http://wiki.osgeo.org/wiki/Point_Clustering

Features are too dense (but they have a useful attribute field)

Problem : At higher zoom levels, different categories of features become less relevant and tend to clutter up the view. For example, residential streets become a problem if you're trying to show them at the state level where you'd only want to show highways and interstates.

Solution : Scale dependent rendering by attribute field. At certain zoom levels, certain features will be turned off.

Features are too dense (but they differ in size)

Problem : Too many features and no real way to use an attribute field to identify which ones are relevant at a given zoom level.

Solution: Use a scale-dependent size threshold. At a given zoom level, only show features which are greater than a certain area (polygon) or length (lines).

Features are too complex

Problem: Features have too many vertices causing slow rendering.

Solution: Scale-dependent simplification. For lines or polygons, we can determine a reasonable simplification threshold for each zoom level and produce a regionated KML with network links to the various levels of simplification.

Features span a wide geographic area

Problem: A large number of features spread across a huge area. When zooming in, regardless of the scale-dependent measures we have taken, we'll still have to load the entire set of features even though only a few may be in our view field.

Solution: Split the features into 'tiles' in a manner similar to raster superoverlays.

??? How to handle large features which span the tile boundaries? Break them apart?

Vector data that is just too damn big

Problem: There are some datasets that are likely to be too large to display as vectors regardless of how we try to optimize them.

Solution: Render them to tiled rasters/superoverlays. Hopefully happy-kml-tool can use its styling language to hook into mapnik/mapserver or something in conjunction with tilecache to produce these tiles without having to write additional styling info.

Comment by project member underbluewaters, Jul 1, 2010

Vector data that is just too damn big:

I'm thinking this might be out of scope, but I'm glad it's identified here. There are existing tools that do a good job here, and we could make the transition to using mapnik easier by using the same syntax and properties when it makes sense. We should investigate how easy it might be to directly support outputting to mapnik but if it's difficult I'm not sure it's worth it. The upshot is that we could use superoverlays in combination with vectors for performance in some cases, but I've never seen a good example of this done.

Comment by project member underbluewaters, Jul 2, 2010

Can it be assumed that when employing these strategies you lose the ability to effectively drill down into the data via the tree (either Google Earth Desktop or kmltree)? I think we can make that assumption, since there would be folder after folder (or networklink) of data that is only there for style/performance purposes. It would be pretty unwieldy, but I think it would be okay if we just set these folders as "checkHideChildren" so they are treated as a black-box layer.

The reason I bring this up, is that I think it has implications for the syntax of the stylesheet language. I'd like to have the ability to specify folders, their names, icons, descriptions, etc. That would be hard if folders are being generated by an algorithm. I'd like to punt the issue of letting people specify, say, "folders that contain points clustered at x position in the tree should have blue icons while the top of the tree should have green icons." Obviously we'll need some styling support, but I think it will be much less flexible than for manually created folders. Right?

Comment by project member underbluewaters, Jul 2, 2010

More on raster data.

Chris showed me a good example of data that needed to be rasterized yesterday, and I was thinking that it would be nice to have a simplified, invisible polygon over that data so that it was clickable. We could do that sort of thing if this language supported raster data. I still think it might prove way too difficult though.

Comment by project member perrygeo...@gmail.com, Jul 2, 2010

On some level, KML forces you to choose between a nicely structured tree heirarchy and good performance. I dont see any way around that other than making it a "black-box" layer.

I think styling support for all of the above rendering strategies should be incorporated to the extent possible. Perhaps just as arguments passed into the rendering method.

As far as auto-generating folders, I think that would be a crucial piece of functionality. Lets say I had a dynamic database of point locations of bird sitings and I want a folder for each species; I shouldnt have to hardcode the species names. They should be dynamically generated based on the species in the dataset. Classifying and organizing data dynamically by attribute field should be a core piece of functionality IMO. It's what GIS does so well but is missing from GE and most KML tools.

I think being able to display any and all vector data in a reasonable way should be the goal of HKT. If it means rasterizing the data then fine, thats the "happy" way to treat that particular dataset.

Powered by Google Project Hosting