[Geoserver-users] Storing styiling properties as a JSON map

GeoServer GeoServer User
1

Hi,

I have the necessity of storing several styling properties for different types of entities. That entities are identified by a type and a subtype. The first approach was using a different column for every styling property (color, stroke, label, etc ...). Some entities needs all the styling
properties and others just some of them (the number of styling properties needed is related with the entity type and subtype).

With this approach I have a lot of "noise" in my data model introduced by the styling properties. Beside, if a new type or subtype of entity needs another styling property a new column must be added. Some workarounds exists,
but they don't really solve the original problem (and sometimes they introduce other problems).

After spend some time thinking about this problem I come to this solution.
I store all the styling properties as a JSON map, i.e. in String that match this pattern '{"Color":"#FF0000", "Size":10.0}'. With this approach I can store all the styling properties in a single column in a flexible way. To make this properties available in SLDs I implement a new filter function to access the JSON map values. For example to access the 'Size' value:

(...)
<ogc:Function name='mapper'>
<ogc:PropertyName>json_map_properties</ogc:PropertyName>
     <ogc:Literal>Size</ogc:Literal>
     <ogc:Literal>5.0</ogc:Literal>
</ogc:Function>
(...)

The first parameter points to the JSON map. The second parameter is the name
of the property we want access (the map key). The third parameter is optional and contains the default value.

Does someone have a better approach to this problem ?

(If someone is interested I can contribute the code I write to GeoServer.)

Best regards,

Nuno Oliveira

2

On Tue, Aug 20, 2013 at 12:18 PM, Nuno Oliveira <
nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

I have the necessity of storing several styling properties for different
types of entities. That entities are identified by a type and a subtype.
The first approach was using a different column for every styling
property (color, stroke, label, etc ...). Some entities needs all the
styling
properties and others just some of them (the number of styling
properties needed is related with the entity type and subtype).

With this approach I have a lot of "noise" in my data model introduced
by the styling properties. Beside, if a new type or subtype of entity
needs another styling property a new column must be added. Some
workarounds exists,
but they don't really solve the original problem (and sometimes they
introduce other problems).

After spend some time thinking about this problem I come to this solution.
I store all the styling properties as a JSON map, i.e. in String that
match this pattern '{"Color":"#FF0000", "Size":10.0}'. With this
approach I can store all the styling properties in a single column in a
flexible way. To make this properties available in SLDs I implement a
new filter function to access the JSON map values. For example to access
the 'Size' value:

(...)
<ogc:Function name='mapper'>
<ogc:PropertyName>json_map_properties</ogc:PropertyName>
     <ogc:Literal>Size</ogc:Literal>
     <ogc:Literal>5.0</ogc:Literal>
</ogc:Function>
(...)

The first parameter points to the JSON map. The second parameter is the
name
of the property we want access (the map key). The third parameter is
optional and contains the default value.

Does someone have a better approach to this problem ?

Hmm... I can think of other approaches, but they would all be more
complicated
and require changes to GeoServer.
This one seems fine to me.

(If someone is interested I can contribute the code I write to GeoServer.)

I guess it could be a useful addition. Since you'd be contributing new
files, you'd
have to sign either the GeoServer or the GeoTools contribution agreement
for us to accept the contribution.

Jody, is the new contributor agreement available anywhere?

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

An alternative to defining a JSON-based syntax, you could also use a GeoServer-CSS style string. The advantage to this approach is that the CSS spec has already done the work of defining “flat” property names for the hierarchically-based SLD properties.

http://docs.geoserver.org/stable/en/user/community/css/properties.html

And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…

···

On Tue, Aug 20, 2013 at 3:18 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

I have the necessity of storing several styling properties for different
types of entities. That entities are identified by a type and a subtype.
The first approach was using a different column for every styling
property (color, stroke, label, etc …). Some entities needs all the
styling
properties and others just some of them (the number of styling
properties needed is related with the entity type and subtype).

With this approach I have a lot of “noise” in my data model introduced
by the styling properties. Beside, if a new type or subtype of entity
needs another styling property a new column must be added. Some
workarounds exists,
but they don’t really solve the original problem (and sometimes they
introduce other problems).

After spend some time thinking about this problem I come to this solution.
I store all the styling properties as a JSON map, i.e. in String that
match this pattern ‘{“Color”:“#FF0000”, “Size”:10.0}’. With this
approach I can store all the styling properties in a single column in a
flexible way. To make this properties available in SLDs I implement a
new filter function to access the JSON map values. For example to access
the ‘Size’ value:

(…)
<ogc:Function name=‘mapper’>
ogc:PropertyNamejson_map_properties</ogc:PropertyName>
ogc:LiteralSize</ogc:Literal>
ogc:Literal5.0</ogc:Literal>
</ogc:Function>
(…)

The first parameter points to the JSON map. The second parameter is the
name
of the property we want access (the map key). The third parameter is
optional and contains the default value.

Does someone have a better approach to this problem ?

(If someone is interested I can contribute the code I write to GeoServer.)

Best regards,

Nuno Oliveira

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-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

4

Hi Martin,

I work and helping Nuno with this one.
We agree that makes sense using the GeoServer-CSS style string. But we still need some kind of representation that aggregates all the properties values in an single object. The JSON representation makes relatively easy the deserializing part (and serializing too, when the feature persistence occurs) so it was a natural choice.

We looked in the CSS module’s source code for the parsers but we can’t find where they are.

“And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…”
Yep, that would be interesting.

I think this function will be a nice addition to the Geoserver’s Filter Functions set.

best,
pedro mendes.

···

On Tue, Aug 20, 2013 at 7:01 PM, Martin Davis <mtnclimb@anonymised.com> wrote:

An alternative to defining a JSON-based syntax, you could also use a GeoServer-CSS style string. The advantage to this approach is that the CSS spec has already done the work of defining “flat” property names for the hierarchically-based SLD properties.

http://docs.geoserver.org/stable/en/user/community/css/properties.html

And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…

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-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Tue, Aug 20, 2013 at 3:18 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

I have the necessity of storing several styling properties for different
types of entities. That entities are identified by a type and a subtype.
The first approach was using a different column for every styling
property (color, stroke, label, etc …). Some entities needs all the
styling
properties and others just some of them (the number of styling
properties needed is related with the entity type and subtype).

With this approach I have a lot of “noise” in my data model introduced
by the styling properties. Beside, if a new type or subtype of entity
needs another styling property a new column must be added. Some
workarounds exists,
but they don’t really solve the original problem (and sometimes they
introduce other problems).

After spend some time thinking about this problem I come to this solution.
I store all the styling properties as a JSON map, i.e. in String that
match this pattern ‘{“Color”:“#FF0000”, “Size”:10.0}’. With this
approach I can store all the styling properties in a single column in a
flexible way. To make this properties available in SLDs I implement a
new filter function to access the JSON map values. For example to access
the ‘Size’ value:

(…)
<ogc:Function name=‘mapper’>
ogc:PropertyNamejson_map_properties</ogc:PropertyName>
ogc:LiteralSize</ogc:Literal>
ogc:Literal5.0</ogc:Literal>
</ogc:Function>
(…)

The first parameter points to the JSON map. The second parameter is the
name
of the property we want access (the map key). The third parameter is
optional and contains the default value.

Does someone have a better approach to this problem ?

(If someone is interested I can contribute the code I write to GeoServer.)

Best regards,

Nuno Oliveira

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-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

5

On Wed, Aug 21, 2013 at 12:23 PM, Pedro Mendes <p.m.g.mendes@anonymised.com>wrote:

Hi Martin,
I work and helping Nuno with this one.
We agree that makes sense using the GeoServer-CSS style string. But we
still need some kind of representation that aggregates all the properties
values in an single object. The JSON representation makes relatively easy
the deserializing part (and serializing too, when the feature persistence
occurs) so it was a natural choice.

We looked in the CSS module's source code for the parsers but we can't
find where they are.

The CSS parser is written in Scala and it's located here (geocss module):
https://github.com/dwins/geoscript.scala

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

The CSS module in GeoServer is just GeoServer integration (mostly Wicket components) for the CSS converter which is part of GeoScript Scala. You can see the sources for the converter, including the parser, on Github:

https://github.com/dwins/geoscript.scala/tree/master/geocss/src

It’s not really designed to support piecemeal conversion, but as a prototype you could try running the full conversion and then extracting Rules or Symbolizers from the generated SLD.

···

On Wed, Aug 21, 2013 at 6:23 AM, Pedro Mendes <p.m.g.mendes@anonymised.com> wrote:

Hi Martin,

I work and helping Nuno with this one.
We agree that makes sense using the GeoServer-CSS style string. But we still need some kind of representation that aggregates all the properties values in an single object. The JSON representation makes relatively easy the deserializing part (and serializing too, when the feature persistence occurs) so it was a natural choice.

We looked in the CSS module’s source code for the parsers but we can’t find where they are.

“And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…”

Yep, that would be interesting.

I think this function will be a nice addition to the Geoserver’s Filter Functions set.

best,
pedro mendes.

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-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Tue, Aug 20, 2013 at 7:01 PM, Martin Davis <mtnclimb@anonymised.com> wrote:

An alternative to defining a JSON-based syntax, you could also use a GeoServer-CSS style string. The advantage to this approach is that the CSS spec has already done the work of defining “flat” property names for the hierarchically-based SLD properties.

http://docs.geoserver.org/stable/en/user/community/css/properties.html

And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…

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-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Tue, Aug 20, 2013 at 3:18 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

I have the necessity of storing several styling properties for different
types of entities. That entities are identified by a type and a subtype.
The first approach was using a different column for every styling
property (color, stroke, label, etc …). Some entities needs all the
styling
properties and others just some of them (the number of styling
properties needed is related with the entity type and subtype).

With this approach I have a lot of “noise” in my data model introduced
by the styling properties. Beside, if a new type or subtype of entity
needs another styling property a new column must be added. Some
workarounds exists,
but they don’t really solve the original problem (and sometimes they
introduce other problems).

After spend some time thinking about this problem I come to this solution.
I store all the styling properties as a JSON map, i.e. in String that
match this pattern ‘{“Color”:“#FF0000”, “Size”:10.0}’. With this
approach I can store all the styling properties in a single column in a
flexible way. To make this properties available in SLDs I implement a
new filter function to access the JSON map values. For example to access
the ‘Size’ value:

(…)
<ogc:Function name=‘mapper’>
ogc:PropertyNamejson_map_properties</ogc:PropertyName>
ogc:LiteralSize</ogc:Literal>
ogc:Literal5.0</ogc:Literal>
</ogc:Function>
(…)

The first parameter points to the JSON map. The second parameter is the
name
of the property we want access (the map key). The third parameter is
optional and contains the default value.

Does someone have a better approach to this problem ?

(If someone is interested I can contribute the code I write to GeoServer.)

Best regards,

Nuno Oliveira

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-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

7

Yes, I can see it’s appealing to use an existing JSON parser.

And it shouldn’t be to hard to make a parser for simple syntax like:

fill: #4DFF4D; fill-opacity: 0.7;

But for more complex CSS syntax it would be harder to hand-code a parser - you’d want to create a parser using something like JavaCC, I think. Of course, given that your functions presumable pull out single constant values, you wouldn’t be able to make use of complex CSS anyway.

As a partial step, could you use the CSS property names in the JSON?

···

On Wed, Aug 21, 2013 at 3:23 AM, Pedro Mendes <p.m.g.mendes@anonymised.com> wrote:

Hi Martin,

I work and helping Nuno with this one.
We agree that makes sense using the GeoServer-CSS style string. But we still need some kind of representation that aggregates all the properties values in an single object. The JSON representation makes relatively easy the deserializing part (and serializing too, when the feature persistence occurs) so it was a natural choice.

We looked in the CSS module’s source code for the parsers but we can’t find where they are.

“And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…”

Yep, that would be interesting.

I think this function will be a nice addition to the Geoserver’s Filter Functions set.

best,
pedro mendes.

On Tue, Aug 20, 2013 at 7:01 PM, Martin Davis <mtnclimb@anonymised.com> wrote:

An alternative to defining a JSON-based syntax, you could also use a GeoServer-CSS style string. The advantage to this approach is that the CSS spec has already done the work of defining “flat” property names for the hierarchically-based SLD properties.

http://docs.geoserver.org/stable/en/user/community/css/properties.html

And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…

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-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Tue, Aug 20, 2013 at 3:18 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

I have the necessity of storing several styling properties for different
types of entities. That entities are identified by a type and a subtype.
The first approach was using a different column for every styling
property (color, stroke, label, etc …). Some entities needs all the
styling
properties and others just some of them (the number of styling
properties needed is related with the entity type and subtype).

With this approach I have a lot of “noise” in my data model introduced
by the styling properties. Beside, if a new type or subtype of entity
needs another styling property a new column must be added. Some
workarounds exists,
but they don’t really solve the original problem (and sometimes they
introduce other problems).

After spend some time thinking about this problem I come to this solution.
I store all the styling properties as a JSON map, i.e. in String that
match this pattern ‘{“Color”:“#FF0000”, “Size”:10.0}’. With this
approach I can store all the styling properties in a single column in a
flexible way. To make this properties available in SLDs I implement a
new filter function to access the JSON map values. For example to access
the ‘Size’ value:

(…)
<ogc:Function name=‘mapper’>
ogc:PropertyNamejson_map_properties</ogc:PropertyName>
ogc:LiteralSize</ogc:Literal>
ogc:Literal5.0</ogc:Literal>
</ogc:Function>
(…)

The first parameter points to the JSON map. The second parameter is the
name
of the property we want access (the map key). The third parameter is
optional and contains the default value.

Does someone have a better approach to this problem ?

(If someone is interested I can contribute the code I write to GeoServer.)

Best regards,

Nuno Oliveira

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-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

8

“Of course, given that your functions presumable pull out single constant values, you wouldn’t be able to make use of complex CSS anyway.”

That’s true. The style object contains simple key/value pairs that will be passed to the filter function.

“As a partial step, could you use the CSS property names in the JSON?”

We’re going to do that. I’ve checked the spec tables, and it seems that all the properties are covered.

For the moment, we’re keeping the JSON approach with the sole reason of having web clients manipulating the “style” attribute directly, and it makes a lot more easy for us, to just delegate the deserializing/serializering part to the Jackson processors.

···

On Wed, Aug 21, 2013 at 4:58 PM, Martin Davis <mtnclimb@anonymised.com> wrote:

Yes, I can see it’s appealing to use an existing JSON parser.

And it shouldn’t be to hard to make a parser for simple syntax like:

fill: #4DFF4D; fill-opacity: 0.7;

But for more complex CSS syntax it would be harder to hand-code a parser - you’d want to create a parser using something like JavaCC, I think. Of course, given that your functions presumable pull out single constant values, you wouldn’t be able to make use of complex CSS anyway.

As a partial step, could you use the CSS property names in the JSON?

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-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Wed, Aug 21, 2013 at 3:23 AM, Pedro Mendes <p.m.g.mendes@anonymised.com> wrote:

Hi Martin,

I work and helping Nuno with this one.
We agree that makes sense using the GeoServer-CSS style string. But we still need some kind of representation that aggregates all the properties values in an single object. The JSON representation makes relatively easy the deserializing part (and serializing too, when the feature persistence occurs) so it was a natural choice.

We looked in the CSS module’s source code for the parsers but we can’t find where they are.

“And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…”

Yep, that would be interesting.

I think this function will be a nice addition to the Geoserver’s Filter Functions set.

best,
pedro mendes.

On Tue, Aug 20, 2013 at 7:01 PM, Martin Davis <mtnclimb@anonymised.com> wrote:

An alternative to defining a JSON-based syntax, you could also use a GeoServer-CSS style string. The advantage to this approach is that the CSS spec has already done the work of defining “flat” property names for the hierarchically-based SLD properties.

http://docs.geoserver.org/stable/en/user/community/css/properties.html

And who knows, down the road there might be deeper support for persisting and parsing CSS styles in GeoServer…

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-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Tue, Aug 20, 2013 at 3:18 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

I have the necessity of storing several styling properties for different
types of entities. That entities are identified by a type and a subtype.
The first approach was using a different column for every styling
property (color, stroke, label, etc …). Some entities needs all the
styling
properties and others just some of them (the number of styling
properties needed is related with the entity type and subtype).

With this approach I have a lot of “noise” in my data model introduced
by the styling properties. Beside, if a new type or subtype of entity
needs another styling property a new column must be added. Some
workarounds exists,
but they don’t really solve the original problem (and sometimes they
introduce other problems).

After spend some time thinking about this problem I come to this solution.
I store all the styling properties as a JSON map, i.e. in String that
match this pattern ‘{“Color”:“#FF0000”, “Size”:10.0}’. With this
approach I can store all the styling properties in a single column in a
flexible way. To make this properties available in SLDs I implement a
new filter function to access the JSON map values. For example to access
the ‘Size’ value:

(…)
<ogc:Function name=‘mapper’>
ogc:PropertyNamejson_map_properties</ogc:PropertyName>
ogc:LiteralSize</ogc:Literal>
ogc:Literal5.0</ogc:Literal>
</ogc:Function>
(…)

The first parameter points to the JSON map. The second parameter is the
name
of the property we want access (the map key). The third parameter is
optional and contains the default value.

Does someone have a better approach to this problem ?

(If someone is interested I can contribute the code I write to GeoServer.)

Best regards,

Nuno Oliveira

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-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

9

Hi,

After doing some tests I come to this conclusion.

The goal of the mapper function is the possibility of accessing some styling properties
stored in a key<->value structure encoded as a JSON object. Keys are Strings and
values are Objects. Values are converted using GeoTools Converters, so they can be
of type geometry, string, double, float, etc ...

CSS is an interesting approach, although I think is a to "heavy" solution for this use case. Beside, as reference by Pedro the used format needs to be easily parsed by others layers of the architecture. JSON can be easily serialized/deserialized by java, scala, javascript, etc ... and is perfect for REST interfaces.

@Aime; I will make a post on geoserver-dev a technical description about the implementation.

Best regards,

Nuno Oliveira