Storing styiling properties as a JSON map

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

Storing styiling properties as a JSON map

Nuno Oliveira
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing styiling properties as a JSON map

geowolf
On Tue, Aug 20, 2013 at 12:18 PM, Nuno Oliveira <[hidden email]> 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


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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing styiling properties as a JSON map

Martin Davis-3
In reply to this post by Nuno Oliveira
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.


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 <[hidden email]> 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 ?

(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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing styiling properties as a JSON map

pmgmendes
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 <[hidden email]> 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.


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 <[hidden email]> 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 ?

(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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing styiling properties as a JSON map

geowolf
On Wed, Aug 21, 2013 at 12:23 PM, Pedro Mendes <[hidden email]> 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):

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


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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing styiling properties as a JSON map

David Winslow-5
In reply to this post by pmgmendes
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.

--
David Winslow


On Wed, Aug 21, 2013 at 6:23 AM, Pedro Mendes <[hidden email]> 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 <[hidden email]> 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.


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 <[hidden email]> 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 ?

(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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing styiling properties as a JSON map

Martin Davis-3
In reply to this post by pmgmendes
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 <[hidden email]> 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 <[hidden email]> 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.


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 <[hidden email]> 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 ?

(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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing styiling properties as a JSON map

pmgmendes
"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 <[hidden email]> 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?



On Wed, Aug 21, 2013 at 3:23 AM, Pedro Mendes <[hidden email]> 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 <[hidden email]> 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.


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 <[hidden email]> 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 ?

(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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing styiling properties as a JSON map

Nuno Oliveira
In reply to this post by geowolf
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




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users