[Geoserver-devel] Improving KML Icon support

GeoServer GeoServer Developer
1

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 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.)

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.
  • 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.)
  • Fix up the rest service so that it doesn’t require administrative authentication.

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.

–
David Winslow
OpenGeo - http://opengeo.org/

2

On Fri, Feb 22, 2013 at 7:48 PM, David Winslow <dwinslow@anonymised.com> 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

3

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.

···

On Sun, Feb 24, 2013 at 5:23 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Feb 22, 2013 at 7:48 PM, David Winslow <dwinslow@anonymised.com> 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