Manipulator to `densify` polygons

[perrygeo]

One of the primary reasons we get weird problems with large polygons going below the surface is that GE only knows to place the vertices of the linear ring on the surface of the earth (not the edges or the plane between them) So the plane/edges end up dipping below the earth's surface due to curvature and terrain. The solution, aside from inventing some novel approach to 3D rendering, is to create more vertices.

Two options:

• writing a manipulator that takes a geometry and adds more vertices to some tolerance specified in settings. The KML rendering simplifies though which might nullify the benefits.
• adding an additional step to the KML rendering; currently we simplify but we could simplify and/or densify based on the characteristics of the line.

The downside to both approaches is that the geometries in the KML will get slightly larger. In the first option, so would the geometry_final stored in the database.

There are algorithms to do this (arcgis and grass have them). Postgis doesn't have it yet but it's coming in 2.1 (http://trac.osgeo.org/postgis/ticket/1019). That leaves us in bind since we either need to roll our own or wait for postgis 2.1 and require it.

[twelch]

Hmm, have you come across any published algorithms?

[springmeyer]

convert to lines and then use http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples/densify.py ?

[perrygeo]

Good find! I was looking at the JTS source which is pretty similar. The only concern about a pure python route would be performance. Right now we just pull kml representations right from postgis. To do the python route, we'd need to pull it out as WKT, convert to an ogr geom, densify with python then convert to kml. So a postgis function would be ideal but we could do it in python - we'd need to profile it on some test cases to see if it was a big deal or not.

[perrygeo]

Paul Ramsey's recent post and the older one referenced from the last paragraph got me thinking about some pitfalls to this approach ... when we densify lines we are assuming a knowledge of the position of the edge between two vertices (like GE does with polygon per Paul's post). If we assume the edge is a straight line in cartesian space, that edge may end up looking strange when we add verticies in the native srid. Curved edges between lines will be different from the polygon that was originally drawn. I've yet to demo this but the examples in Paul's posts should be enough to highlight the potential problems.

Maybe we just project to 4326 before densifying (seems to be how GE handles polygons internally)