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