[Geoserver-devel] Unit of measure support is in

GeoServer GeoServer Developer
1

Hi,
I've finally been able to commit the unit of measure support
Milton developed on GeoTools trunk (that makes it available
for GeoServer trunk too, of course).

If you're interested in the topic please test :slight_smile:

Oh, if you need a reminder of what UOM support does,
there is a quick example here:
http://osgeo-org.1803224.n2.nabble.com/Surprise-surprise-uom-support-about-to-land-td4803450.html#a4803450

But in short, it allows one to specify the unit of measure
of stroke widths, icons sizes and the like in meters
or feet instead of just pixels.

Along with Michael improved classfication functions this
brings us closer to having all the bits to supports SE/SLD 1.1
(the biggest missing item right now is a parser/encoder)

Cheers
Andrea

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

2

On 05/17/2010 11:19 AM, Andrea Aime wrote:

Hi,
I've finally been able to commit the unit of measure support
Milton developed on GeoTools trunk (that makes it available
for GeoServer trunk too, of course).

If you're interested in the topic please test :slight_smile:

Oh, if you need a reminder of what UOM support does,
there is a quick example here:
http://osgeo-org.1803224.n2.nabble.com/Surprise-surprise-uom-support-about-to-land-td4803450.html#a4803450

But in short, it allows one to specify the unit of measure
of stroke widths, icons sizes and the like in meters
or feet instead of just pixels.

Along with Michael improved classfication functions this
brings us closer to having all the bits to supports SE/SLD 1.1
(the biggest missing item right now is a parser/encoder)

Cheers
Andrea

This is a really cool feature, so I'm pretty excited about ripping it off for GeoServer CSS :slight_smile: However, when I looked at the spec I was really surprised to see that UOM is an attribute of the symbolizer instead of the parameter (a Symbolizer isn't a measurement!!) I also saw this little tidbit:

It is also possible to use pixel values inside a Symbolizer that uses a uom: px
has to be appended to the corresponding values in this case (e.g. 5px stands for 5 pixel).

By my reading, the UomRescalingVisitor doesn't handle this option. (And it seems like fully supporting this via a visitor will be a problem; with weird enough filter functions in a parameter the "px" suffix might appear and disappear for different features in the same symbolizer.)

In either case, I won't be able to faithfully represent styles like this one (hopefully pretty rare, but quite naturally encoded in CSS):

* {
    stroke-width: 2m;
    stroke-dashoffset: 2ft;
}

but it would be nice to at least be able to mix in pixel values with real-world measures. Anyone care to point out how I misread the visitor code? I'm crossing my fingers.

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

3

David Winslow ha scritto:

This is a really cool feature, so I'm pretty excited about ripping it off for GeoServer CSS :slight_smile: However, when I looked at the spec I was really surprised to see that UOM is an attribute of the symbolizer instead of the parameter (a Symbolizer isn't a measurement!!)

Yeah, it means every measure inside the symbolizer will be in, say,
meters. The CSS ability to specify each bit in a different UOM
has yet to come (not sure if it ever will actually).

I also saw this little tidbit:

It is also possible to use pixel values inside a Symbolizer that uses a uom: px
has to be appended to the corresponding values in this case (e.g. 5px stands for 5 pixel).

Oh? I did not know about this one. But yeah, found it:

"It is also possible to use pixel values inside a Symbolizer that uses a uom: px has to be appended to the corresponding values in this case (e.g. 5px stands for 5 pixel)."

By my reading, the UomRescalingVisitor doesn't handle this option. (And it seems like fully supporting this via a visitor will be a problem; with weird enough filter functions in a parameter the "px" suffix might appear and disappear for different features in the same symbolizer.)

In either case, I won't be able to faithfully represent styles like this one (hopefully pretty rare, but quite naturally encoded in CSS):

* {
   stroke-width: 2m;
   stroke-dashoffset: 2ft;
}

but it would be nice to at least be able to mix in pixel values with real-world measures. Anyone care to point out how I misread the visitor code? I'm crossing my fingers.

You did not misread the code, it has been designed to support just the
uom at the symbolizer level.
In GeoTools we lack the very support for representing an uom attached
to each stroke width, size and whatnot, so adding support for what
you're saying might require major changes around in the code...

Cheers
Andrea

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

4

By my reading, the UomRescalingVisitor doesn't handle this option. (And
it seems like fully supporting this via a visitor will be a problem;
with weird enough filter functions in a parameter the "px" suffix might
appear and disappear for different features in the same symbolizer.)

In either case, I won't be able to faithfully represent styles like this
one (hopefully pretty rare, but quite naturally encoded in CSS):

* {
  stroke-width: 2m;
  stroke-dashoffset: 2ft;
}

but it would be nice to at least be able to mix in pixel values with
real-world measures. Anyone care to point out how I misread the visitor
code? I'm crossing my fingers.

You did not misread the code, it has been designed to support just the
uom at the symbolizer level.
In GeoTools we lack the very support for representing an uom attached
to each stroke width, size and whatnot, so adding support for what
you're saying might require major changes around in the code...

Let me think about that.

Could we actually use Measure<Distance> and define Converters for "1", 1, and "1px","1m",1km".

We would rely on the Symbolizer data structure storing things as a literal expression; and try and evaluate as a Measure.class rather then just an Integer.class or Double.class as is done now.

Jody

5

Jody Garnett ha scritto:

By my reading, the UomRescalingVisitor doesn't handle this
option. (And it seems like fully supporting this via a visitor
will be a problem; with weird enough filter functions in a
parameter the "px" suffix might appear and disappear for
different features in the same symbolizer.)

In either case, I won't be able to faithfully represent styles
like this one (hopefully pretty rare, but quite naturally encoded
in CSS):

* { stroke-width: 2m; stroke-dashoffset: 2ft; }

but it would be nice to at least be able to mix in pixel values
with real-world measures. Anyone care to point out how I misread
the visitor code? I'm crossing my fingers.

You did not misread the code, it has been designed to support just
the uom at the symbolizer level. In GeoTools we lack the very
support for representing an uom attached to each stroke width, size
and whatnot, so adding support for what you're saying might require
major changes around in the code...

Let me think about that.

Could we actually use Measure<Distance> and define Converters for
"1", 1, and "1px","1m",1km".

We would rely on the Symbolizer data structure storing things as a
literal expression; and try and evaluate as a Measure.class rather
then just an Integer.class or Double.class as is done now.

Eh, it might get tricky as we have two sources of uom specification,
the literal itself, but also the symbolizer one. I guess the local
one would win.

Anyone interested in cooking up a patch?

Cheers
Andrea

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

6

On 20/05/2010, at 4:57 PM, Andrea Aime wrote:

Eh, it might get tricky as we have two sources of uom specification,
the literal itself, but also the symbolizer one. I guess the local
one would win.

Anyone interested in cooking up a patch?

Pick me pick me! After all I failed at applying the screenmap patch :frowning:

I would actually like a bit of discussion first... We would still like to be fast at the default case of working with pixels, is there any way we can detect when we should check of a Measure.class? Or should we just try all the time.

Ideas:
- test if the literal is a Numeric prior to trying expr.evaulate( feature, Measure.class )
- test if the symbolizer already has a UOM setting; of so we should test for Measure.class

Any other ways we can short cut? Or is this a case of make it work first and then make it fast.

I am also a bit annoyed that we have to try for a Measure.class and not a Distance.class although I understand why (darn java generics being compile time only).

Jody

7

Jody Garnett ha scritto:

On 20/05/2010, at 4:57 PM, Andrea Aime wrote:

Eh, it might get tricky as we have two sources of uom
specification, the literal itself, but also the symbolizer one. I
guess the local one would win.

Anyone interested in cooking up a patch?

Pick me pick me! After all I failed at applying the screenmap patch
:frowning:

Don't feel bad about that, the patch went out of synch and would
not apply...

I would actually like a bit of discussion first... We would still
like to be fast at the default case of working with pixels, is there
any way we can detect when we should check of a Measure.class? Or
should we just try all the time.

Good question, I don't have much of an answer.
The current approach is to transform the SLD into pixels uom
before giving it to the SLDStyleFactory and more importantly
before doing the query over the data so that we know how much
to enlarge the query area to take into account big symbolizers.

With this idea that one can put the uom in the text + filter
functions that can add it dynamically boom, the above does not
work anymore. Quite honestly, I don't feel like restarting
everything from scratch though, tempted to just refuse to handle
the local uom on symbolizers that have the "px" pop up dynamically
using functions...

Otherwise we have to scrap the rescaling visitor and rebuild the
uom -> px logic all in the SLDStyleFactory and also kiss goodbye
the ability to automatically figure out the rendering meta-buffer
when doing queries.

So... what about having the rescale style visitor look for px
at the end of an expression and handle that accordingly?
If it's a literal check it if ends with px, if it's an expression
check if it's a strConcat funcion and look if it has a "px"
literal at the end?

Cheers
Andrea

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

8

On 20/05/2010, at 5:32 PM, Andrea Aime wrote:

Jody Garnett ha scritto:

On 20/05/2010, at 4:57 PM, Andrea Aime wrote:

Eh, it might get tricky as we have two sources of uom
specification, the literal itself, but also the symbolizer one. I
guess the local one would win.
Anyone interested in cooking up a patch?

Pick me pick me! After all I failed at applying the screenmap patch
:frowning:

Don't feel bad about that, the patch went out of synch and would
not apply...

I would actually like a bit of discussion first... We would still
like to be fast at the default case of working with pixels, is there
any way we can detect when we should check of a Measure.class? Or
should we just try all the time.

Good question, I don't have much of an answer.
The current approach is to transform the SLD into pixels uom
before giving it to the SLDStyleFactory and more importantly
before doing the query over the data so that we know how much
to enlarge the query area to take into account big symbolizers.

Oh cool did not know that. Makes sense and I like that approach for performance.

With this idea that one can put the uom in the text + filter
functions that can add it dynamically boom, the above does not
work anymore. Quite honestly, I don't feel like restarting
everything from scratch though, tempted to just refuse to handle
the local uom on symbolizers that have the "px" pop up dynamically
using functions...

Agreed; not worth holding up the patch for. Wait until we have a real use etc.

Otherwise we have to scrap the rescaling visitor and rebuild the
uom -> px logic all in the SLDStyleFactory and also kiss goodbye
the ability to automatically figure out the rendering meta-buffer
when doing queries.

So... what about having the rescale style visitor look for px
at the end of an expression and handle that accordingly?
If it's a literal check it if ends with px, if it's an expression
check if it's a strConcat funcion and look if it has a "px"
literal at the end?

I think you mean have the rescale visitor look for "m", "km" etc and transform it into "px" measurements?
Oh wait you are trying to use "px" as a flag to tell the rescaling visitor to not apply its default transform .. yeah I get it.

So at the end of the day we want the rescaling visitor to do everything it can prior to letting the renderer at it.
Question. Can the rescale visitor inject a function expression around entries in order to accomplish a conversion?

Jody

9

Jody Garnett ha scritto:

Otherwise we have to scrap the rescaling visitor and rebuild the uom -> px logic all in the SLDStyleFactory and also kiss goodbye the ability to automatically figure out the rendering meta-buffer when doing queries.

So... what about having the rescale style visitor look for px at
the end of an expression and handle that accordingly? If it's a
literal check it if ends with px, if it's an expression check if
it's a strConcat funcion and look if it has a "px" literal at the
end?

I think you mean have the rescale visitor look for "m", "km" etc and
transform it into "px" measurements? Oh wait you are trying to use
"px" as a flag to tell the rescaling visitor to not apply its default
transform .. yeah I get it.

Well, if you want to make David super-happy you can also add support
for other uom specs so that we can support a more natural CSS style
where each item has its own uom.

So at the end of the day we want the rescaling visitor to do
everything it can prior to letting the renderer at it. Question. Can
the rescale visitor inject a function expression around entries in
order to accomplish a conversion?

Why a function expression? I'm usually a bit weary of using functions
as they don't translate down to sql, but for symbolizers that should
not be a problem

Cheers
Andrea

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

10

On 20/05/2010, at 6:42 PM, Andrea Aime wrote:

So at the end of the day we want the rescaling visitor to do
everything it can prior to letting the renderer at it. Question. Can
the rescale visitor inject a function expression around entries in
order to accomplish a conversion?

Why a function expression?

Or at least injecting an expression ,
Just going over options; if I see a concat( expr, "m" ) I would find it easer to replace that with the correct expr * M_SCALE_RATIO

I'm usually a bit weary of using functions as they don't translate down to sql, but for symbolizers that should not be a problem

Understood.

Jody