KML generation framework

[perrygeo]

Needs to address two needs:

First, to provide a view that serializes all of the user's shapes into a kml document with a workspace tag at the top. Users/developers should be able to define a template under Feature.get_options().kml_template that represents each feature class. FeatureCollections will need to somehow be supported, possibly through a custom template tag, ie: {{{

{%= instance.name %} {% include_children instance %}

}}}

Secondly, this framework will need to provide another view of shared shapes with the same structure as the north-coast app, again using the kml templates specified by Feature.get_options().kml_template

Google Code Info: Issue #: 444 Author: underbluewaters Created On: 2010-11-11T23:34:51.000Z Closed On: 2011-02-16T15:53:45.000Z

[perrygeo]

Some notes on the kml geometries:

In the 1.X branches, MPAs have an additional queryset method add_kml() which allows the following:

m = Mpa.objects.get(pk=1).add_kml() m.kml

The force right-hand rule and reverse methods are now available through geodjango BUT they are only exposed at the queryset level, not the geometry/instance level. IOW there is no such thing as:

m.geometry_final.force_rhr() #FAILS

consequently, we can't get proper KML without going through a queryset but then we're still stuck with an unextruded feature:

m = Mpa.objects.force_rhr().reverse().get(pk=1) m.geometry_final.kml # Correct orientation but still not extruded.

IOW, every kml view would need to gather instance pks, make another query to force_rhr + reverse then do some post processing to manually extrude to 3D. This would be a major PITA - I'd suggest that the current way of having a custom queryset to add_kml is the cleanest and most robust method aside from modifying geodjango itself to support our use case at the GEOS geometry level.

Google Code Info: Author: perrygeo...@gmail.com Created On: 2010-11-23T20:10:53.000Z

[perrygeo]

Another approach which might make more sense:

Implement the forceRHR geometry manipulation in python code so that we don't have to rely on postgis queries. I'm not sure how this would perform on large geometries but I've got a demo working which should allow a direct kml property on every feature class.

Google Code Info: Author: perrygeo...@gmail.com Created On: 2010-11-24T15:37:55.000Z

[perrygeo]

Have you done any performance tests to compare doing these operations in the database vs in python for a bunch of features? They could be pretty close since postgis is just hitting GEOS in a lot of cases anyways. Not sure how the .replace() calls would compare to doing them in postgres though...

Google Code Info: Author: underbluewaters Created On: 2010-11-29T17:55:04.000Z

[perrygeo]

Geometry problems are taken care of. Major remaining tasks relate to templating KML so that a) potentially highly variable kml templates can be combined into a single document and b) recursive templating to handle nested feature collections.

Google Code Info: Author: perrygeo...@gmail.com Created On: 2011-01-25T17:53:52.000Z

[perrygeo]

• kml output has been fully refactored to support features and nested collections.
• sharing, public and user kmls supported

• templating (at least django-style extension templating) is not going to be a feasible way to style kml; rather we will use two feature properties to determine the kml representation of a feature instance:

  a .kml property .. returns a string with the Placemark (for features) or Folder (for collections) a .kml_style property.. returns a string with Style elements that can be refered to by URL. Only unique style strings will be included to reduce redundancy in multi-feature kml output.

The remaining items to deal with include:

• Testing
• Docs
• A way to validate kml on the fly (?) or at least ensure that bad kml returned from one feature doesn't screw up an entire document.
• A way to define the Icon url and its variants (open/closed/shared/etc)

The workspace doc and UI integration will obviously come next but that should be a seperate ticket.

Google Code Info: Author: perrygeo...@gmail.com Created On: 2011-02-11T00:16:50.000Z

[perrygeo]

Docs mostly done.

Revising down % complete as we need to fix public layer display when not signed in .. a little refactor of the kmlapp views needed.

Google Code Info: Author: perrygeo...@gmail.com Created On: 2011-02-14T20:33:23.000Z

[perrygeo]

And we're about 3/4 of the way there. The sharing permissions for anonymous users was fixed up so public layers work as expected. Tests to come.

Google Code Info: Author: perrygeo...@gmail.com Created On: 2011-02-14T21:36:13.000Z

[perrygeo]

Tests complete. I think the kml framework is robust enough to roll out. Of course if issues pop up later, we'll open more focused tickets to address the specifics.

Google Code Info: Author: perrygeo...@gmail.com Created On: 2011-02-16T15:53:45.000Z