[Geoserver-devel] KML Dynamic Icons

GeoServer GeoServer Developer
1

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

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

2

On Wed, Jan 16, 2013 at 6:05 PM, David Winslow <dwinslow@anonymised.com> 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 :slight_smile:

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

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.

···

On Thu, Jan 17, 2013 at 5:55 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Jan 16, 2013 at 6:05 PM, David Winslow <dwinslow@anonymised.com> 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 :slight_smile:

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

4

On Thu, Jan 17, 2013 at 10:38 AM, David Winslow <dwinslow@anonymised.com>wrote:

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

This approach makes a lot of sense. Indeed we already have a mode=download
I think for KML, but might make sense to just return KMZ with the embedded
icons for that. Or to just not offer it and document that KMZ is the
download format. In GeoNode we already do have the distinction, between
'view in google earth' and 'download kml'.

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.

Ah, interesting. I like that approach a lot. I imagine some things may
break it in the future, but it goes further and is more elegant than
anything I was thinking of.

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

On Thu, Jan 17, 2013 at 5:55 AM, Andrea Aime <andrea.aime@anonymised.com
> wrote:

On Wed, Jan 16, 2013 at 6:05 PM, David Winslow <dwinslow@anonymised.com>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 :slight_smile:

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

5

I see, makes sense. Of course, you’re not going to bring a Scala dependency into GeoServer core, are you?

Cheers
Andrea

···

This approach makes a lot of sense. Indeed we already have a mode=download I think for KML, but might make sense to just return KMZ with the embedded icons for that. Or to just not offer it and document that KMZ is the download format. In GeoNode we already do have the distinction, between ‘view in google earth’ and ‘download kml’.

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

6

No, Scala makes it easy to mess with XML templates (eg: https://github.com/dwins/icon-service/blob/master/src/main/scala/KMLService.scala#L46-L51 ) but it’s not a good fit for GeoServer core.

···

On Thu, Jan 17, 2013 at 11:05 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Jan 17, 2013 at 4:56 PM, Chris Holmes <cholmes@anonymised.com> wrote:

I see, makes sense. Of course, you’re not going to bring a Scala dependency into GeoServer core, are you?

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

This approach makes a lot of sense. Indeed we already have a mode=download I think for KML, but might make sense to just return KMZ with the embedded icons for that. Or to just not offer it and document that KMZ is the download format. In GeoNode we already do have the distinction, between ‘view in google earth’ and ‘download kml’.

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

7

On Thu, Jan 17, 2013 at 11:05 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

On Thu, Jan 17, 2013 at 4:56 PM, Chris Holmes <cholmes@anonymised.com> wrote:

This approach makes a lot of sense. Indeed we already have a
mode=download I think for KML, but might make sense to just return KMZ with
the embedded icons for that. Or to just not offer it and document that KMZ
is the download format. In GeoNode we already do have the distinction,
between 'view in google earth' and 'download kml'.

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

I see, makes sense. Of course, you're not going to bring a Scala
dependency into GeoServer core, are you?

Out of curiosity, why is this so bad? I mean it complies to pure java
bytecode, could just be thought of an additional library, like the xml
stuff we do. It'll interoperate on any platform, which to me was the big
downside in bringing in other languages.

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

-------------------------------------------------------