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