On Fri, Feb 22, 2013 at 7:48 PM, David Winslow <[email protected]> wrote:
> Hi all,
>
> Just in time to coincide with Andrea's KML refactoring I've been putting
> some time into the dynamic KML icon support I discussed previously. I
> still haven't merged the refactoring into my branch, but for the sake of
> discussion I've put up my code here:
> https://github.com/dwins/geoserver/compare/kml-dynamic-icons . If you
> just want to use it, rebuild at least the restconfig and wms modules and
> request KML from GeoServer in vector mode. (The easiest way to do this, I
> think, is to use the layer preview to get a URL to a layer in a format with
> fewer format options and then just replace the format with 'kml'.)
>
The compare seems to be missing the class KMLIconFinder class
>
> The basic approach that it takes is to extract "dynamic" styling
> properties from a style and encode them into a URL (along with the style
> name, to retrieve the original static properties.) Then a REST service
> interprets those URLs to generate icons on demand. (Depending on how long
> things take I'd like to take measures to normalize properties - for example
> scaling opacity to a limited precision - in order to increase the
> likelihood of a caching web client like Google Earth reusing icons that are
> visually similar between different features.)
>
>
Seems like a reasonable approach. I have one doubt, as far as I can see
whatever point symbolizer is used it
will result in backlinks to the icon rest service, meaning the KML ends up
requiring the GeoServer that generated
it 100% of the time.
The current generation instead is self contained, if only marks and
external graphics with absolute URLs to
internet accessible icons are used.
Some might argue this is a regression, can we think of a icon mode that
mimics today's behavior, and tries
as hard as possible to keep things self contained instead?
Maybe the two modes can be alterenatives, something that should be made
easier if the style generation
is one of the various "kml decorators" that will be available in the
refactored kml code.
> The big gaps right now are:
> * I'm not sure how to get a style's identifier from within the
> KMLMapTransformer - AFAIK I just get the parsed Style. The existing code
> appears to use Style.getName to generate WMS links but I am 99% sure this
> is a bug. Even if .getName is correct, I would still need the workspace to
> fully identify a style when generating icon URLs. Alternatively to
> identifying styles I could encode static styling properties in URLs, but I
> am wary of making the icon service open-ended in this way.
>
Eh, indeed this is a problem, to get something stable it would be better to
use the style internal identifier
instead, which does not change with renames. Unfortunately the Style API
back in GeoTools has no
allowance for a metadata map where we could store such information.
Maybe we should change it?
> * KMZ icons should be embedded in the KMZ directory structure rather than
> referenced via URL. (I am thinking I will simply hash the same information
> that would have gone into the icon urls to generate probably-unique icon
> file names.)
>
Right, this is a good idea.
> * Fix up the rest service so that it doesn't require administrative
> authentication.
>
Yep, it may be nice if the REST services could have some sort of
declarative security, like the GUI,
where we have public pages, and pages that are meant to be administrator
eyes only.
However, this might pose compatibility issues with the current URL based
approach.
>
> Of course there's also still the small matter of dealing with the new kml
> module - I probably will not be able to investigate this today but it will
> be a priority for next week.
>
The current KML module on trunk is just a set of moved classes, the
refactor is still on the
drawing board, I'm trying to get a decent design on paper so that I can
move on and make
a prototype I can show the community.
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
-------------------------------------------------------
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
