Doing geometry transformations in SLD

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Doing geometry transformations in SLD

aaime
Hi all,
I'm writing this mail to explore the possibility of extending
our current SLD support for symbolizer geometry.
With the current SLD 1.0 (and even with SE 1.1) we're stuck
with just telling the symbolizer which geometry attribute to
use, as the <sld:geometry> element is hard coded to be a
PropertyName.

This is lame, things would be much more flexible if that
was an Expression instead.
Coupled with filter functions that we already have today
and a handful of new ones we could get:
- on the fly geometry generation, such as buffering
   points and lines to draw buffer areas on the fly
- on the fly slice and dice, such as drawing only a portion
   of a line with a certain color, or making sure the
   geometry is sliced against the bouding box before
   rendering it into a vector format (I'm thinking PDF,
   using the Graphics object provided by iText)
- drop shadow effect, which could be achieved by just
   offsetting the geometry and drawing it with a darker
   color
- draw a line vertexes (typical selection style) by
   turning the line into a multipoint on the fly

Add the ability to define you own geometry manipulation
functions and the possibilities are endless.
Unfortunately there is a significant drawback: everything
in the current api is stuck to geometryName <=> String.

Soo... how could we add such support without breaking things
too much? One thing that comes to mind is to have a new
element, <GeometryEx> that is declared as an Expression.
This could be added to the existing symbolizer
classes/interfaces without much breakage, and extending
the parser to handle that as well.

The xml would look like:

<PointSymbolizer>
   <GeometryEx>
     <Function name="extractVertex">
       <ogc:PropertyName>myLineStringGeom</ogc:PropertyName>
     </Function>
   </GeometryEx>
   ...
</PointSymbolizer>

What do you think?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: Doing geometry transformations in SLD

jody.garnett
Andrea can I ask if this is a problem with the SLD parser; or a problem with the data structures? I tried to carefully make the geometry operations reduce their values to two expressions; the String based PropertyName accessors are still there; but have warnings that they only work with the expression used is a PropertyName.

This was one of the motivations for FilterFactory2 (http://geoapi.sourceforge.net/snapshot/javadoc/index.html). So you must be talking SLD / SE.

I would like to see if we can make that a choice; based on your examples I can only see the use of Function or PropertyName right now (are their any other useful possibilities?).

Jody

On Sun, Feb 15, 2009 at 1:34 AM, Andrea Aime <[hidden email]> wrote:
Hi all,
I'm writing this mail to explore the possibility of extending
our current SLD support for symbolizer geometry.
With the current SLD 1.0 (and even with SE 1.1) we're stuck
with just telling the symbolizer which geometry attribute to
use, as the <sld:geometry> element is hard coded to be a
PropertyName.

This is lame, things would be much more flexible if that
was an Expression instead.
Coupled with filter functions that we already have today
and a handful of new ones we could get:
- on the fly geometry generation, such as buffering
  points and lines to draw buffer areas on the fly
- on the fly slice and dice, such as drawing only a portion
  of a line with a certain color, or making sure the
  geometry is sliced against the bouding box before
  rendering it into a vector format (I'm thinking PDF,
  using the Graphics object provided by iText)
- drop shadow effect, which could be achieved by just
  offsetting the geometry and drawing it with a darker
  color
- draw a line vertexes (typical selection style) by
  turning the line into a multipoint on the fly

Add the ability to define you own geometry manipulation
functions and the possibilities are endless.
Unfortunately there is a significant drawback: everything
in the current api is stuck to geometryName <=> String.

Soo... how could we add such support without breaking things
too much? One thing that comes to mind is to have a new
element, <GeometryEx> that is declared as an Expression.
This could be added to the existing symbolizer
classes/interfaces without much breakage, and extending
the parser to handle that as well.

The xml would look like:

<PointSymbolizer>
  <GeometryEx>
    <Function name="extractVertex">
      <ogc:PropertyName>myLineStringGeom</ogc:PropertyName>
    </Function>
  </GeometryEx>
  ...
</PointSymbolizer>

What do you think?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: Doing geometry transformations in SLD

aaime
Jody Garnett ha scritto:
> Andrea can I ask if this is a problem with the SLD parser; or a problem
> with the data structures?

The data structures. Fixing the parser is a piece of cake.

> I tried to carefully make the geometry
> operations reduce their values to two expressions; the String based
> PropertyName accessors are still there; but have warnings that they only
> work with the expression used is a PropertyName.
>
> This was one of the motivations for FilterFactory2
> (http://geoapi.sourceforge.net/snapshot/javadoc/index.html). So you must
> be talking SLD / SE.

Sorry? That did not get into the symbolizer implementation, not even
on trunk, as far as I can see. When I wrote the mail my IDE was open
on 2.5.x, and I did not think about the SE effort, but looking at
the interfaces now, there are still just plain strings, even in
GeoApi:

org.opengis.style.Symbolizer (geoapi):
String getGeometryPropertyName();

Happily enough we're not stuck with GeoApi interfaces, as GeoTools
still has its own ones, and they are not deprecated, so it's still
possible to pull such a change without having to go through a
committee.

Thought I must say this is going to be confusing for the user as code
completion will always report two PointSymbolizer, just like now
we have two Filter and two Expression and so on.

> I would like to see if we can make that a choice; based on your examples
> I can only see the use of Function or PropertyName right now (are their
> any other useful possibilities?).

I don't understand what is the advantage of limiting the scope.
You have an expression, you do this:

Geometry g = geomExpression.evaluate(feature, Geometry.class);

and that's it, how it's being built up internally should not
matter, no?

Cheers
Andrea


--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: Doing geometry transformations in SLD

johann sorel
In reply to this post by aaime
Hi, (read bellow)

Andrea Aime a écrit :

> Hi all,
> I'm writing this mail to explore the possibility of extending
> our current SLD support for symbolizer geometry.
> With the current SLD 1.0 (and even with SE 1.1) we're stuck
> with just telling the symbolizer which geometry attribute to
> use, as the <sld:geometry> element is hard coded to be a
> PropertyName.
>
> This is lame, things would be much more flexible if that
> was an Expression instead.
> Coupled with filter functions that we already have today
> and a handful of new ones we could get:
>  
> - on the fly geometry generation, such as buffering
>    points and lines to draw buffer areas on the fly
>  
This is already in the SE definition for polygon symbolizer.
See Displacement property.
but not on points or lines.
> - on the fly slice and dice, such as drawing only a portion
>    of a line with a certain color, or making sure the
>    geometry is sliced against the bouding box before
>    rendering it into a vector format (I'm thinking PDF,
>    using the Graphics object provided by iText)
>  
This is a renderer issue, we should not make a rendering operation
in an expression, imagine how it would behave if your special expression
optimized for the streamingRenderer is used in another renderer, a glyph
factory  or even a 3D renderer ?
since style are generic and can be used by anything, they should not offer
the possibility to be tightly related to some special optimizations.
> - drop shadow effect, which could be achieved by just
>    offsetting the geometry and drawing it with a darker
>    color
>  
This is already in the SE definition for polygon symbolizer.
See Offset property.
but not on points.

> - draw a line vertexes (typical selection style) by
>    turning the line into a multipoint on the fly
>  
Shouldn't that be somewhere else ? this is relative to
user interaction, so it should be stored somewhere in the application
and given to the renderer as some kind of special feature list ?
> Add the ability to define you own geometry manipulation
> functions and the possibilities are endless.
> Unfortunately there is a significant drawback: everything
> in the current api is stuck to geometryName <=> String.
>  
I think the idea is not bad, but it's simple only for the streaming renderer
once again, since it's rebuild it's cache each time it doesn't matter
for it.

The problem is different when you work in statefull mode.
If the geometry becames an Expression, that means it can't be cached
since it may change because of whatever factor, attribut or variable in the
application (it could even change with time, impossible in statefull
mode to track
down a expression result change for each feature).


Here is another approach I propose :

- Keep close to the specification and dont change it.
The specification is perhaps not perfect but it's fair and square
and works for 98% of the use cases.
- For all other things (endless possibilities) make new symbolizer
implementations that the streaming renderer will be able to understand.

This way you just extend the specification (by providing a new symbolizer)
and you dont break anything.


johann


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: Doing geometry transformations in SLD

aaime
johann sorel ha scritto:

> Hi, (read bellow)
>
> Andrea Aime a écrit :
>> Hi all,
>> I'm writing this mail to explore the possibility of extending
>> our current SLD support for symbolizer geometry.
>> With the current SLD 1.0 (and even with SE 1.1) we're stuck
>> with just telling the symbolizer which geometry attribute to
>> use, as the <sld:geometry> element is hard coded to be a
>> PropertyName.
>>
>> This is lame, things would be much more flexible if that
>> was an Expression instead.
>> Coupled with filter functions that we already have today
>> and a handful of new ones we could get:
>>   - on the fly geometry generation, such as buffering
>>    points and lines to draw buffer areas on the fly
>>  
> This is already in the SE definition for polygon symbolizer.
> See Displacement property.
> but not on points or lines.

This is actually "perpendicularOffset" (SE spec, page 21), but yeah,
thanks for pointing this out.

>> - on the fly slice and dice, such as drawing only a portion
>>    of a line with a certain color, or making sure the
>>    geometry is sliced against the bouding box before
>>    rendering it into a vector format (I'm thinking PDF,
>>    using the Graphics object provided by iText)
>>  
> This is a renderer issue, we should not make a rendering operation
> in an expression, imagine how it would behave if your special expression
> optimized for the streamingRenderer is used in another renderer, a glyph
> factory  or even a 3D renderer ?
> since style are generic and can be used by anything, they should not offer
> the possibility to be tightly related to some special optimizations.

The PDF case is an optimization indeed, the "draw a portion
of a line from km 5 to km 10 a different color" pops up
from time to time on the GeoServer users mailing list and
it's no optimization. It's something that routing related renderers
are able to do, and SLD driven ones cannot.

>> - drop shadow effect, which could be achieved by just
>>    offsetting the geometry and drawing it with a darker
>>    color
>>  
> This is already in the SE definition for polygon symbolizer.
> See Offset property.
> but not on points.

This is actually displacement (SE spec, page 21), but I see your point.
Still, I'm looking for something more general.

>> - draw a line vertexes (typical selection style) by
>>    turning the line into a multipoint on the fly
>>  
> Shouldn't that be somewhere else ? this is relative to
> user interaction, so it should be stored somewhere in the application
> and given to the renderer as some kind of special feature list ?

That works for a stateful renderer, not for web based ones.
Plus, being able to draw the vertices is something has
popped up a few times on the geoserver user list already,
not something I'm making up. I also had to hand modify the
current renderer to support this a few times for debugging
purposes.

>> Add the ability to define you own geometry manipulation
>> functions and the possibilities are endless.
>> Unfortunately there is a significant drawback: everything
>> in the current api is stuck to geometryName <=> String.
>>  
> I think the idea is not bad, but it's simple only for the streaming
> renderer
> once again, since it's rebuild it's cache each time it doesn't matter
> for it.
>
> The problem is different when you work in statefull mode.
> If the geometry becames an Expression, that means it can't be cached
> since it may change because of whatever factor, attribut or variable in the
> application (it could even change with time, impossible in statefull
> mode to track
> down a expression result change for each feature).

Sorry I don't follow you. When you evaluate the property name
against a feature, don't you get a different geometry for each feature?
What's different in evaluating a function instead of getting the feature
geometry? You still get back one geometry per feature, and you can
still cache the result, functions are stateless as far as I know,
given the same inputs you'll get back the same output, so the
result seems to be cacheable.

>
> Here is another approach I propose :
>
> - Keep close to the specification and dont change it.
> The specification is perhaps not perfect but it's fair and square
> and works for 98% of the use cases.

Hum, my experience with the GeoServer users is that SLD covers
all the basics, but it's quite away from a professional usage.
Just see all the options we provide to control labelling on
a per symbolizer basis, or the dynamic symbolizers, which are quite
appreciated by most of the user base, or the common need to
draw road plates (symbol + number superimposed, and locked
togheter so that if the label is not drawn due to label
conflict resolution, neither is the symbol).

Sure SE is a neat improvement over SLD 1.0, uom support is
important, and the classification functions improve a lot the
readability of a style document, but there are still a number
of common things that you cannot do, and that non SLD based
softwares already provide.

Among the "big" maps made by GeoServer users that I looked at
recently, none used only the pure SLD abilities, some of the
current extensions was always used.

If you want another example, look at the DeeGree ability
to draw charts on top of a map. Guess what, they ended up
doing something very similar to the "dynamic symbolizers"
proposal, and they did so independently of us.

> - For all other things (endless possibilities) make new symbolizer
> implementations that the streaming renderer will be able to understand.

Sure, I could make a PointSymbolizerEx, LineSymbolizerEx, and so on,
that extend the base symbolizers. And then alter the parser to build
these extended classes. As long as you don't know what they have to
offer beyond the GeoApi abilities you simply don't use them.
If the user chose to use extended abilities the rendering will break
anyways.

But isn't already what's happening with the gt2 symbolizer interfaces?
They extend the GeoApi ones to provide extra functionality.
So, why not put this extension there too?
A GeoApi based renderer will just not see the extra methods, and
end up drawing the default geometry instead.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: Doing geometry transformations in SLD

jody.garnett
In reply to this post by aaime

Andrea can I ask if this is a problem with the SLD parser; or a problem with the data structures? 

The data structures. Fixing the parser is a piece of cake.

We have already taken the Filter definition in this direction; taking the style definition in this direction should be fine as well.

You will have some difficulties in recognizing the type of the final result; but that should not matter that much since the symbolizers do not care. Also if you are doing any transformations you may not be able to figure out the final layer bounds ... unless you want to get tricky:

Tricky #1: 
- make a polygon the size of the bounds
- call the transform (or whatever function like buffer) on the polygon
- convert that back to bounds

Tickey #2: 
- update the implementation of buffer, transform etc to work on geometry and referencedenvelope
 
This was one of the motivations for FilterFactory2 (http://geoapi.sourceforge.net/snapshot/javadoc/index.html). So you must be talking SLD / SE.

Sorry? That did not get into the symbolizer implementation, not even
on trunk, as far as I can see.

 

So we could add a method here:
- getGeometry(): Expression

And document getGeometryPropertyName() in the same manner as Filter; as something that is only valid when the expression is a PropertyExpression.

It would be a good test of how open geoapi is these days.

Thought I must say this is going to be confusing for the user as code
completion will always report two PointSymbolizer, just like now
we have two Filter and two Expression and so on.

Not a good long term plan; I like the way the geoapi style api is shaping up - I think we should use and modify it to suite our needs; or just remain method compatible. 

I don't understand what is the advantage of limiting the scope.

I thought it would be easier for you on the XSD side.
 
Cheers,
Jody

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel