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 <mtncl...@gmail.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...
>
>
> 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
>
>
------------------------------------------------------------------------------
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
