[Geoserver-devel] Fixing CSS inability to handle units

GeoServer GeoServer Developer
1

Hi,
the CSS documentation says that it’s possible to specify units along with a measure:
http://docs.geoserver.org/latest/en/user/extensions/css/values.html#numbers

However, in practice the translator ignores them and as a result it’s impossible to create
a CSS style that works in real world units.

I believe the reason for this is that CSS allows for mixing unit of measure in more than one
way, whilst SLD has a fixed and single unit for a given symbolizer… and this makes
a direct translation impossible.

Point in case:

  • {
    label: [name];
    font-size: 50m;
    label-offset: 10px 0px;
    }

How do you turn the above into a uniform set of units? You can’t, because the translation
between pixels and meters can only be done once the output project and map scale is
determined, so only when GetMap is being executed.

So, it seems the only way forward is to keep the value un-translated until rendering time.
Which I believe is doable by some creative use of filter functions.

First, the current map pixel per meter value can be put into the env function, just like we are already
putting some of the GetMap request attributes. Let’s call it “gt_pixels_per_meter”.
And then we can apply a filter function around each value whose unit is not in pixels, e.g.:

50 [http://www.opengeospatial.org/se/units/metre](http://www.opengeospatial.org/se/units/metre)

The uom filter function knows internally that it has to go and look for the gt_pixels_per_meter env variable to
perform the translation to pixels for the current request.

This would allow for a translation, and as a side effect, it would make it possible for
SLD users to mix units in their style sheets too.

What do you think?

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

2

I made some comments about this on the GeoTools list when when the unit-of-measure support arrived in GeoTools:

http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/10196

If it is possible to mix px and real-world units then we should be able to perform the conversion without requiring new filter functions - just convert all real-world measures to the same unit by multiplying with the appropriate conversion factor and leave px measures in pixel space (so the output style would only have two units - pixels and, say, meters.) Of course this breaks down if we want to support degrees as a length, but AFAIK all the non-pixel measures that SLD supports are linear.

The filter function could definitely work if the ‘px’ suffix is not going to be supported in GeoTools.

···

On Thu, Aug 22, 2013 at 5:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
the CSS documentation says that it’s possible to specify units along with a measure:
http://docs.geoserver.org/latest/en/user/extensions/css/values.html#numbers

However, in practice the translator ignores them and as a result it’s impossible to create
a CSS style that works in real world units.

I believe the reason for this is that CSS allows for mixing unit of measure in more than one
way, whilst SLD has a fixed and single unit for a given symbolizer… and this makes
a direct translation impossible.

Point in case:

  • {
    label: [name];
    font-size: 50m;
    label-offset: 10px 0px;
    }

How do you turn the above into a uniform set of units? You can’t, because the translation
between pixels and meters can only be done once the output project and map scale is
determined, so only when GetMap is being executed.

So, it seems the only way forward is to keep the value un-translated until rendering time.
Which I believe is doable by some creative use of filter functions.

First, the current map pixel per meter value can be put into the env function, just like we are already
putting some of the GetMap request attributes. Let’s call it “gt_pixels_per_meter”.
And then we can apply a filter function around each value whose unit is not in pixels, e.g.:

50 [http://www.opengeospatial.org/se/units/metre](http://www.opengeospatial.org/se/units/metre)

The uom filter function knows internally that it has to go and look for the gt_pixels_per_meter env variable to
perform the translation to pixels for the current request.

This would allow for a translation, and as a side effect, it would make it possible for
SLD users to mix units in their style sheets too.

What do you think?

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

Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Thu, Aug 22, 2013 at 3:22 PM, David Winslow <dwinslow@anonymised.com> wrote:

I made some comments about this on the GeoTools list when when the
unit-of-measure support arrived in GeoTools:

http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/10196

If it is possible to mix px and real-world units then we should be able to
perform the conversion without requiring new filter functions - just
convert all real-world measures to the same unit by multiplying with the
appropriate conversion factor and leave px measures in pixel space (so the
output style would only have two units - pixels and, say, meters.) Of
course this breaks down if we want to support degrees as a length, but
AFAIK all the non-pixel measures that SLD supports are linear.

No, it's not possible to do mixed units (as in, pixels and meters).
We could do a conversion of feet to meters statically, but not sure that
would buy us any advantage.

And as said above, it's not possible to convert between px and meters until
you have a request, with a specific target scale.
That's why I suggest to introduce the filter function, it will be evaluated
during the request and it has access to the target scale.

The filter function could definitely work if the 'px' suffix is not going
to be supported in GeoTools.

The suffixes make no sense in SLD, but filter functions do: the SLD is
still valid.
I guess you were suggesting we just leave the suffixes even in the SLD,
like <Size>10m</Size>?
That would make a mess, all code handling styles would have to be modified
accordingly.

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

I was referring to this paragraph from the SE 1.1.0 specification (in the intro to Section 11):

Pixel is interpreted as a paper unit, referring to the size of the map, while metre, foot and
other similar units are “ground” units referring to the actual size of real-world objects. All
values set inside this Symbolizer shall use this unit for drawing the corresponding
elements. 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).

You’re right that this wouldn’t fit well into SLD 1.0 documents because of backward compatibility, but it would be reasonable to generate styles using SE 1.1.0 if that is a better fit for CSS.

···

On Thu, Aug 22, 2013 at 9:31 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Aug 22, 2013 at 3:22 PM, David Winslow <dwinslow@anonymised.com> wrote:

I made some comments about this on the GeoTools list when when the unit-of-measure support arrived in GeoTools:

http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/10196

If it is possible to mix px and real-world units then we should be able to perform the conversion without requiring new filter functions - just convert all real-world measures to the same unit by multiplying with the appropriate conversion factor and leave px measures in pixel space (so the output style would only have two units - pixels and, say, meters.) Of course this breaks down if we want to support degrees as a length, but AFAIK all the non-pixel measures that SLD supports are linear.

No, it’s not possible to do mixed units (as in, pixels and meters).
We could do a conversion of feet to meters statically, but not sure that would buy us any advantage.

And as said above, it’s not possible to convert between px and meters until you have a request, with a specific target scale.
That’s why I suggest to introduce the filter function, it will be evaluated during the request and it has access to the target scale.

The filter function could definitely work if the ‘px’ suffix is not going to be supported in GeoTools.

The suffixes make no sense in SLD, but filter functions do: the SLD is still valid.
I guess you were suggesting we just leave the suffixes even in the SLD, like 10m?
That would make a mess, all code handling styles would have to be modified accordingly.

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

5

On Thu, Aug 22, 2013 at 3:31 PM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

The filter function could definitely work if the 'px' suffix is not going
to be supported in GeoTools.

The suffixes make no sense in SLD, but filter functions do: the SLD is
still valid.
I guess you were suggesting we just leave the suffixes even in the SLD,
like <Size>10m</Size>?
That would make a mess, all code handling styles would have to be modified
accordingly.

To be more specific, the issue is that calling
font.getSize().evaluate(feature, Double.class)
must always result in a number, but if we leave the suffixes, we would
actually be able
to do the conversion only during rendering, and rendering it's not the only
case,
there are also style transformations, e.g., one could write a static style
simplifier that
removes calls to the env function, in the spirit of the
simplifyingFilterVisitor

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

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

6

On Thu, Aug 22, 2013 at 3:43 PM, David Winslow <dwinslow@anonymised.com> wrote:

I was referring to this paragraph from the SE 1.1.0 specification (in the
intro to Section 11):

Pixel is interpreted as a paper unit, referring to the size of the map,

while metre, foot and
other similar units are “ground” units referring to the actual size of
real-world objects. All
values set inside this Symbolizer shall use this unit for drawing the
corresponding
elements. 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).

You're right that this wouldn't fit well into SLD 1.0 documents because of
backward compatibility, but it would be reasonable to generate styles using
SE 1.1.0 if that is a better fit for CSS.

Ah, was not aware of that.
Sigh, still, as said, it makes things complicated because SLD is not really
used only
in "standard" map rendering, see my other mail.
Also, there is no difference in memory between SLD 1.0 and SLD 1.1, the
difficulties
I see are not in parsing, they are in programmatic style handling, however
past parsing
we cannot tell if the style was 1.0 or 1.1 and imho, the client code should
not really forced
to know either.

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

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