It is an interesting problem. I think it's pretty much a lost cause to try
and make stable URLs for dynamic icons in general - feature data, styles,
and external resources like icon graphics are all things that might change
between the time that a .KML file is saved and the time that it is viewed.
I think that we should (via documentation and UI) encourage users to think
of .KML as a "realtime" viewable format, useful for things like regionated
KML, and KMZ as a better option for saving and viewing later or
distributing as a static file (since it can embed the images easily.)
I've spent a little time trying out some ideas outside of GeoServer:
https://github.com/dwins/icon-service (I'l see if I can stand up a demo
later.) The approach that I've been taking is to define the icon service
as operating on styles alone (not addressing individual rules), and the
client making the request includes feature attributes as needed. So an
icon url might look like:
http://localhost:9090/st/poi_dynamic?cat=1
If the style references a property named 'cat.' Then I just create a
feature with a point geometry at (0,0) and the attributes from the query
string, remove Symbolizers other than PointSymbolizer from the style, and
render it in a bbox of [-1:1,-1:1].
This approach seems to work well so far, but I haven't pushed it very hard
yet.
--
David Winslow
OpenGeo - http://opengeo.org/
On Thu, Jan 17, 2013 at 5:55 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Wed, Jan 16, 2013 at 6:05 PM, David Winslow <dwins...@opengeo.org>wrote:
>
>> Hi all (mostly Andrea though),
>>
>> I've been asked to look into making some KML improvements, so it seems
>> that Andrea and I should coordinate a bit to avoid potential clobbering.
>> I'm still just in the planning phase and probably won't be making KML
>> changes in GeoServer soon (in the next few weeks.)
>>
>
> The KML refactor will probably happen in a separate module as Justin
> suggested, and it's not going to start
> right away either, need to formulate a plan that everybody is happy with
> before start to work on it.
> This week is hectic enough with the impending feature freeze for 2.3.x,
> hopefully the discussion will
> resume next week.
>
>
>>
>> The improvements I'm talking about would relate to giving more faithful
>> representations of PointSymbolizers in KML generated by GeoServer.
>> Currently GeoServer discards most aspects of Marks (only fill and opacity
>> are preserved) and does not always ensure that URLs included in KML will
>> represent resources that are accessible to remote clients. Additionally,
>> GeoServer encodes an SLD style with multiple PointSymbolizers into a KML
>> Style with multiple IconStyles, which is invalid. (Google Earth will render
>> these, but discards all but the last IconStyle.)
>>
>> Anyway, to resolve these issues I'm thinking about adding facilities to
>> GeoServer for rendering individual icons for use in KML - both as a REST
>> service for actual KML files and also as embedded files in KMZ. The
>> KMLVectorTransformer would need to be modified to leverage these utilities
>> as well. So I'm interested to try and formulate a plan that allows these
>> new features to be developed without impeding or being impeded by the
>> refactor.
>>
>
> Hum, I don't see the two actually colliding too much as long as these
> utilities are well incapsulated,
> something taking a feature and a point symbolizer and returning back a
> BufferedImage, then
> it's up to the the KML code to just call them when dealing with a point
> symbolizer which is
> not already an external reference to a web accessible resource.
>
> This restful symbol service you're talking about is what I was envisoning
> myself as well for
> the task (something that was discussed in the past as well), I'm wondering
> what you
> are going to do for symbolizers that are depending on feature attributes,
> and also on how
> the symbol definition is moved around?
>
> Generically speaking, in order to draw an icon you need the feature, with
> its attributes,
> and the set of symbolizers that make up the symbol: a rule can contain
> many, and to build
> complex symbols it's not uncommon to end up using more than one, see for
> example
> the POI style for a trivial example.
>
> Now, the KML generated can be downloaded, to keep it stable it would be
> great if
> the URL referring back to the server contained the full definition of what
> needs to be
> done... however the SLD can be very large (multiple symbolizers) and might
> not fit
> into a normal URL. Also the size of the feature attributes can be
> completely unpredictable
> (what if one of the attributes is a large text? unlikely, but not
> impossible).
> An option could be to compress the data and base64 encode it, but it would
> get you
> only so far.
>
> Another option is instead to refer to the SLD and the feature, something
> like:
> &rule=poi/0/0&layer=poi&featureid=poi.1
>
> Where:
> * poi/0/0: the first rule in the first feature type style in the poi style
> * layer: the layer where the feature is coming from
> * featureid: the id of the feature
>
> This is compact, but has drawbacks too:
> * not stable over time, the layer can go, the feature can disappear
> * assumes the feature does have a stable identifier, but read only layers
> can
> also lack a primary key
>
> Hmm... interesting problem :-)
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
