Hi Andrea, thanks for the feedback.
I have updated the branch to include the KMLIconFinder class, so it should
be possible to download it and run it now.
Regarding backward compatibility concerns, I think that we should simply
caution users against using KML in a disconnected setting. I am working on
embedding dynamic icons into KMZ files, and when that is working we can
recommend KMZ as a superior format for disconnected use. Additionally, I
intend to detect publicly accessible external graphics and generate direct
links in that case, so the generated KML will be "standalone" in that case.
Otherwise, since KML's only method of including icons is via URL we cannot
support icons without depending on some web service.
--
David Winslow
OpenGeo - http://opengeo.org/
On Sun, Feb 24, 2013 at 5:23 AM, Andrea Aime
<[email protected]>wrote:
> 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
