search

google-code-export / marinemap

Automatically exported from code.google.com/p/marinemap
Other
1 stars 2 forks source link

KML generation framework #444

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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:
{{{
<Folder id="{%= instance.uid %}">
    <name>{%= instance.name %}</name>
    {% include_children instance %}
</Folder>
}}}

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

Original issue reported on code.google.com by underbluewaters on 11 Nov 2010 at 11:34

GoogleCodeExporter commented 9 years ago 
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.

Original comment by perrygeo...@gmail.com on 23 Nov 2010 at 8:10

GoogleCodeExporter commented 9 years ago 
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.

Original comment by perrygeo...@gmail.com on 24 Nov 2010 at 3:37

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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...

Original comment by underbluewaters on 29 Nov 2010 at 5:55

GoogleCodeExporter commented 9 years ago 
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.

Original comment by perrygeo...@gmail.com on 25 Jan 2011 at 5:53

GoogleCodeExporter commented 9 years ago 
* 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.

Original comment by perrygeo...@gmail.com on 11 Feb 2011 at 12:16

GoogleCodeExporter commented 9 years ago 
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.

Original comment by perrygeo...@gmail.com on 14 Feb 2011 at 8:33

GoogleCodeExporter commented 9 years ago 
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.

Original comment by perrygeo...@gmail.com on 14 Feb 2011 at 9:36

GoogleCodeExporter commented 9 years ago 
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.

Original comment by perrygeo...@gmail.com on 16 Feb 2011 at 3:53