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