[Geoserver-devel] New Style Function - Storing styling properties as a JSON map

Nuno_Oliveira · August 29, 2013, 2:58pm

Hi,

After this discussion ( http://osgeo-org.1560.x6.nabble.com/Storing-styiling-properties-as-a-JSON-map-td5073329.html) on GeoServer users list (if you think this is a useful add) I would like to contribute the mapper function to GeoServer.

As already discussed, the goal of mapper function will be allowing the access of styling properties stored in a Map encoded as a JSON object. With this approach we can store all our styling properties in a single column (Feature property). Since their are not explicitly declared, the number and the type of styling properties is variable. The JSON object can be easily used in all architecture layers (javascript, java, scala, ruby, …).

As an example, lets consider this normal style:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:PropertyName>MARK</ogc:PropertyName>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:PropertyName>COLOR</ogc:PropertyName>
</CssParameter>
</Fill>

<Size>
<ogc:PropertyName>SIZE</ogc:PropertyName>
</Size>
</Graphic>
</PointSymbolizer>

Our Feature will need to have explicitly declared the properties “WELL_KNOWN_NAME”, “COLOR” and “ELEMENT_SIZE”.

Using the mapper function the style above will become:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>mark</ogc:Literal>
</ogc:Function>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>color</ogc:Literal>
</ogc:Function>
</CssParameter>
</Fill>

<Size>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>size</ogc:Literal>
</ogc:Function>
</Size>
</Graphic>
</PointSymbolizer>

The Feature property “JSON_STYLE” will contain all JSON styling properties and could look like this:

‘{“color”:“##081931”,“size”:10,“mark”:“square”,“label”:“simple point”}’

I have done a quick benchmarking (in attach) and there is no performance cost in having the style stored in a JSON object. However, if the JSON object is not a Feature property, i.e. if it is obtained in a static context (literal, env function , …) we cannot cache its value. Since the object is not associated with any feature the cost of putting the deserialized object in cache (i.e. using the object himself to produce a hascode) is more costly that just parsing the object. But (at the moment) I don’t see any use case where the JSON object isn’t associated with any Feature. Anyway the cost of parsing the object is not so high we are talking about more ~150ms for 10000 point with three styling properties.

I have been out of GeoServer Dev for some time, but we already sign the contributing agreement for contributing W3DS module.
Currently we are using this function as a GeoServer extension (plugin).

Best regards,

Nuno Oliveira

(attachments)

MapperFunctionBenchMarking.pdf (38.6 KB)

jive · September 1, 2013, 6:27am

So it looks like this may be a straight contribution to geotools, i.e. this is a normal function right?

function: mapper

argument 1: (String) JSON formatted map
argument 2: (String) KEY

So nothing really wrong with the function, I would prefer if you implemented a slightly different way in order to be obvious about the use of JSON.

Implement the function “get” with arguments Map<String,Object> and String
Implement the function “json” which parses a String into a map<String,Object> explicitly

-or-

Implement the function “get” as above
implement a type conversion from String to Map<String,Object>

So your example as CQL would be: get( json(JSON_STYLE),“colour”)

One final (slightly bad) idea is that the property name syntax does support xpath, so with the right property access you may be able to get by with just:

JSON_STYLE/color which would be better for all concerned.

Jody Garnett

On Friday, 30 August 2013 at 12:58 AM, Nuno Oliveira wrote:

Hi,

After this discussion ( http://osgeo-org.1560.x6.nabble.com/Storing-styiling-properties-as-a-JSON-map-td5073329.html) on GeoServer users list (if you think this is a useful add) I would like to contribute the mapper function to GeoServer.

As already discussed, the goal of mapper function will be allowing the access of styling properties stored in a Map encoded as a JSON object. With this approach we can store all our styling properties in a single column (Feature property). Since their are not explicitly declared, the number and the type of styling properties is variable. The JSON object can be easily used in all architecture layers (javascript, java, scala, ruby, …).

As an example, lets consider this normal style:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:PropertyName>MARK</ogc:PropertyName>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:PropertyName>COLOR</ogc:PropertyName>
</CssParameter>
</Fill>

<Size>
<ogc:PropertyName>SIZE</ogc:PropertyName>
</Size>
</Graphic>
</PointSymbolizer>

Our Feature will need to have explicitly declared the properties “WELL_KNOWN_NAME”, “COLOR” and “ELEMENT_SIZE”.

Using the mapper function the style above will become:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>mark</ogc:Literal>
</ogc:Function>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>color</ogc:Literal>
</ogc:Function>
</CssParameter>
</Fill>

<Size>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>size</ogc:Literal>
</ogc:Function>
</Size>
</Graphic>
</PointSymbolizer>

The Feature property “JSON_STYLE” will contain all JSON styling properties and could look like this:

‘{“color”:“##081931”,“size”:10,“mark”:“square”,“label”:“simple point”}’

I have done a quick benchmarking (in attach) and there is no performance cost in having the style stored in a JSON object. However, if the JSON object is not a Feature property, i.e. if it is obtained in a static context (literal, env function , …) we cannot cache its value. Since the object is not associated with any feature the cost of putting the deserialized object in cache (i.e. using the object himself to produce a hascode) is more costly that just parsing the object. But (at the moment) I don’t see any use case where the JSON object isn’t associated with any Feature. Anyway the cost of parsing the object is not so high we are talking about more ~150ms for 10000 point with three styling properties.

I have been out of GeoServer Dev for some time, but we already sign the contributing agreement for contributing W3DS module.
Currently we are using this function as a GeoServer extension (plugin).

Best regards,

Nuno Oliveira

Learn the latest–Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Attachments:

MapperFunctionBenchMarking.pdf

Nuno_Oliveira · September 2, 2013, 2:21pm

I suppose it is a normal function. Whats is the behavior of a normal function ? A third optional argument that can contain a default value is available. (Maybe I can use the fall-back value …) I agree. I like the two options, however due to performance issues the second option is not viable. The conversion from JSON String to Map<String, Object> is too costly, we need to use a cache mechanism. I don’t see a way of implementing an efficient cache system using only the JSON String without any extra attributes. Although, the first option seems fine to me. If the JSON String comes from a PropertyName (which is typical use case) the “json” function can use a cache mechanism based on the Feature. So I will implement the first option. Nice idea I will keep this in mind. I will work on this and when I have something I let you know. Thanks for the tips. Best regards, Nuno Oliveira

···

Hi,

On 09/01/2013 07:27 AM, Jody Garnett wrote:

So it looks like this may be a straight contribution to geotools, i.e. this is a normal function right?

function: mapper

argument 1: (String) JSON formatted map

argument 2: (String) KEY

So nothing really wrong with the function, I would prefer if you implemented a slightly different way in order to be obvious about the use of JSON.

Implement the function “get” with arguments Map<String,Object> and String

Implement the function “json” which parses a String into a map<String,Object> explicitly

-or-

Implement the function “get” as above

implement a type conversion from String to Map<String,Object>

So your example as CQL would be: get( json(JSON_STYLE),“colour”)

One final (slightly bad) idea is that the property name syntax does support xpath, so with the right property access you may be able to get by with just:

JSON_STYLE/color which would be better for all concerned.

–
Jody Garnett

On Friday, 30 August 2013 at 12:58 AM, Nuno Oliveira wrote:

Hi,

After this discussion ( http://osgeo-org.1560.x6.nabble.com/Storing-styiling-properties-as-a-JSON-map-td5073329.html) on GeoServer users list (if you think this is a useful add) I would like to contribute the mapper function to GeoServer.

As already discussed, the goal of mapper function will be allowing the access of styling properties stored in a Map encoded as a JSON object. With this approach we can store all our styling properties in a single column (Feature property). Since their are not explicitly declared, the number and the type of styling properties is variable. The JSON object can be easily used in all architecture layers (javascript, java, scala, ruby, …).

As an example, lets consider this normal style:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:PropertyName>MARK</ogc:PropertyName>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:PropertyName>COLOR</ogc:PropertyName>
</CssParameter>
</Fill>

<Size>
<ogc:PropertyName>SIZE</ogc:PropertyName>
</Size>
</Graphic>
</PointSymbolizer>

Our Feature will need to have explicitly declared the properties “WELL_KNOWN_NAME”, “COLOR” and “ELEMENT_SIZE”.

Using the mapper function the style above will become:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>mark</ogc:Literal>
</ogc:Function>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>color</ogc:Literal>
</ogc:Function>
</CssParameter>
</Fill>

<Size>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>size</ogc:Literal>
</ogc:Function>
</Size>
</Graphic>
</PointSymbolizer>

The Feature property “JSON_STYLE” will contain all JSON styling properties and could look like this:

‘{“color”:“##081931”,“size”:10,“mark”:“square”,“label”:“simple point”}’

I have done a quick benchmarking (in attach) and there is no performance cost in having the style stored in a JSON object. However, if the JSON object is not a Feature property, i.e. if it is obtained in a static context (literal, env function , …) we cannot cache its value. Since the object is not associated with any feature the cost of putting the deserialized object in cache (i.e. using the object himself to produce a hascode) is more costly that just parsing the object. But (at the moment) I don’t see any use case where the JSON object isn’t associated with any Feature. Anyway the cost of parsing the object is not so high we are talking about more ~150ms for 10000 point with three styling properties.

I have been out of GeoServer Dev for some time, but we already sign the contributing agreement for contributing W3DS module.
Currently we are using this function as a GeoServer extension (plugin).

Best regards,

Nuno Oliveira

Learn the latest–Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Attachments:

MapperFunctionBenchMarking.pdf

jive · September 2, 2013, 10:29pm

When implementing a type conversion you can cache as well (based on String hash probably) so if you do like the JSON_STYLE/color idea you can make it perform.

Note caching based on the feature may not always work:
a) Datastore can return the same feature object each time, just changing the contents and feature id
b) You may have more then one JSON blob in your feature, so caching based on feature_id+attribute_name is probably needed?

···

On Tue, Sep 3, 2013 at 12:21 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com634…> wrote:

Hi,

On 09/01/2013 07:27 AM, Jody Garnett wrote:

So it looks like this may be a straight contribution to geotools, i.e. this is a normal function right?

I suppose it is a normal function. Whats is the behavior of a normal function ?

function: mapper

argument 1: (String) JSON formatted map

argument 2: (String) KEY

A third optional argument that can contain a default value is available. (Maybe I can use the fall-back value …)

So nothing really wrong with the function, I would prefer if you implemented a slightly different way in order to be obvious about the use of JSON.

I agree.

Implement the function “get” with arguments Map<String,Object> and String

Implement the function “json” which parses a String into a map<String,Object> explicitly

-or-

Implement the function “get” as above

implement a type conversion from String to Map<String,Object>

I like the two options, however due to performance issues the second option is not viable. The conversion from JSON String to Map<String, Object>
is too costly, we need to use a cache mechanism. I don’t see a way of implementing an efficient cache system using only the JSON String without any extra attributes.

Although, the first option seems fine to me. If the JSON String comes from a PropertyName (which is typical use case) the “json” function can use a cache mechanism based on the Feature.

So I will implement the first option.

So your example as CQL would be: get( json(JSON_STYLE),“colour”)

One final (slightly bad) idea is that the property name syntax does support xpath, so with the right property access you may be able to get by with just:

JSON_STYLE/color which would be better for all concerned.

Nice idea I will keep this in mind.

–
Jody Garnett

I will work on this and when I have something I let you know.

Thanks for the tips.

Best regards,

Nuno Oliveira

On Friday, 30 August 2013 at 12:58 AM, Nuno Oliveira wrote:

Hi,

After this discussion ( http://osgeo-org.1560.x6.nabble.com/Storing-styiling-properties-as-a-JSON-map-td5073329.html) on GeoServer users list (if you think this is a useful add) I would like to contribute the mapper function to GeoServer.

As already discussed, the goal of mapper function will be allowing the access of styling properties stored in a Map encoded as a JSON object. With this approach we can store all our styling properties in a single column (Feature property). Since their are not explicitly declared, the number and the type of styling properties is variable. The JSON object can be easily used in all architecture layers (javascript, java, scala, ruby, …).

As an example, lets consider this normal style:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:PropertyName>MARK</ogc:PropertyName>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:PropertyName>COLOR</ogc:PropertyName>
</CssParameter>
</Fill>

<Size>
<ogc:PropertyName>SIZE</ogc:PropertyName>
</Size>
</Graphic>
</PointSymbolizer>

Our Feature will need to have explicitly declared the properties “WELL_KNOWN_NAME”, “COLOR” and “ELEMENT_SIZE”.

Using the mapper function the style above will become:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>mark</ogc:Literal>
</ogc:Function>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>color</ogc:Literal>
</ogc:Function>
</CssParameter>
</Fill>

<Size>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>size</ogc:Literal>
</ogc:Function>
</Size>
</Graphic>
</PointSymbolizer>

The Feature property “JSON_STYLE” will contain all JSON styling properties and could look like this:

‘{“color”:“##081931”,“size”:10,“mark”:“square”,“label”:“simple point”}’

I have done a quick benchmarking (in attach) and there is no performance cost in having the style stored in a JSON object. However, if the JSON object is not a Feature property, i.e. if it is obtained in a static context (literal, env function , …) we cannot cache its value. Since the object is not associated with any feature the cost of putting the deserialized object in cache (i.e. using the object himself to produce a hascode) is more costly that just parsing the object. But (at the moment) I don’t see any use case where the JSON object isn’t associated with any Feature. Anyway the cost of parsing the object is not so high we are talking about more ~150ms for 10000 point with three styling properties.

I have been out of GeoServer Dev for some time, but we already sign the contributing agreement for contributing W3DS module.
Currently we are using this function as a GeoServer extension (plugin).

Best regards,

Nuno Oliveira

Learn the latest–Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Attachments:

MapperFunctionBenchMarking.pdf

Nuno_Oliveira · September 3, 2013, 8:55am

The String hash code will be computed using the JSON String right ? The JSON String can by very long. The cost of computing the hash code plus the cost of comparing the string when collisions happened is heights than the cost of just parsing the JSON Object with Jackson (for base types). I make a test, rendering 10000 points caching the JSON String is about 300 miliseconds more costly that using normal styling and about 100 miliseconds more costly that using the JSON Style based properties mechanism without caching. However this may not be true if the values stored in the JSON map are complex like Geometries for example. But i think the most common use case is that the values will be base types, i.e. double, float, int, String, etc … Maybe a I lost something, if I could manage to cache the conversion between JSON and HashMap this will be the cleanest solution, but I don’t see who to do it. My code for selecting the key based on the Feature is: ### code ### Object key = object; if (object instanceof Feature) { Feature feature = (Feature) object; if (feature.getType().isIdentified()) { key = feature.getIdentifier(); } } ### code ### If a feature is identified, i.e. isIdentified() method returns true, is ID is never NULL and is different for every feature ? (Maybe I got it wrong but after reading some documentation this is the behavior I expect). If the isIdentified() returns false the feature will be used to compute the hash code, this is costly because the implemented hash code uses all Features attributes to compute the hash code including the JSON object. Yes, for every Feature ID I store a list of available JSON Blobs based on the property Name. But I suppose I can extend PropertyMapPair object to store a Map based on the feature_id+attribute it seams more efficient. This is my function to obtain or put in cache a new map (at this point it is guarantee that propertyName is not NULL and that the object (feature) is not NULL). ### code ### private Map<String, Object> getOrCreateCachedMap(List parameters, PropertyName propertyName, Object object) { Object key = object; if (object instanceof Feature) { Feature feature = (Feature) object; if (feature.getType().isIdentified()) { key = feature.getIdentifier(); } } List propertyMapPairs = (List) FunctionLocalContext.INSTANCE.getEntryValue(key); if (propertyMapPairs == null) { propertyMapPairs = new ArrayList(); FunctionLocalContext.INSTANCE.addEntry(key, propertyMapPairs); } for (PropertyMapPair propertyMapPair : propertyMapPairs) { if (propertyMapPair.propertyName.getPropertyName().equals(propertyName.getPropertyName())) { LOGGER.log(Level.FINE, “Map is in cache !”); return propertyMapPair.map; } } LOGGER.log(Level.FINE, “Map is not in cache !”); String jsonMap = getJsonMap(parameters, object); Map<String, Object> map = deserializeJsonMap(jsonMap); propertyMapPairs.add(new PropertyMapPair(propertyName, map)); return map; } ### code ### (I send as attach the current state of JsonMapDeserializer class). Best regards, Nuno Oliveira

(attachments)

JsonMapDeserializer.java (7.28 KB)

···

Hi,

On 09/02/2013 11:29 PM, Jody Garnett wrote:

When implementing a type conversion you can cache as well (based on String hash probably) so if you do like the JSON_STYLE/color idea you can make it perform.

Note caching based on the feature may not always work:
a) Datastore can return the same feature object each time, just changing the contents and feature id

b) You may have more then one JSON blob in your feature, so caching based on feature_id+attribute_name is probably needed?

On Tue, Sep 3, 2013 at 12:21 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

On 09/01/2013 07:27 AM, Jody Garnett wrote:

So it looks like this may be a straight contribution to geotools, i.e. this is a normal function right?

I suppose it is a normal function. Whats is the behavior of a normal function ?

function: mapper

argument 1: (String) JSON formatted map

argument 2: (String) KEY

A third optional argument that can contain a default value is available. (Maybe I can use the fall-back value …)

So nothing really wrong with the function, I would prefer if you implemented a slightly different way in order to be obvious about the use of JSON.

I agree.

Implement the function “get” with arguments Map<String,Object> and String

Implement the function “json” which parses a String into a map<String,Object> explicitly

-or-

Implement the function “get” as above

implement a type conversion from String to Map<String,Object>

I like the two options, however due to performance issues the second option is not viable. The conversion from JSON String to Map<String, Object>
is too costly, we need to use a cache mechanism. I don’t see a way of implementing an efficient cache system using only the JSON String without any extra attributes.

Although, the first option seems fine to me. If the JSON String comes from a PropertyName (which is typical use case) the “json” function can use a cache mechanism based on the Feature.

So I will implement the first option.

So your example as CQL would be: get( json(JSON_STYLE),“colour”)

One final (slightly bad) idea is that the property name syntax does support xpath, so with the right property access you may be able to get by with just:

JSON_STYLE/color which would be better for all concerned.

Nice idea I will keep this in mind.

–
Jody Garnett

I will work on this and when I have something I let you know.

Thanks for the tips.

Best regards,

Nuno Oliveira

On Friday, 30 August 2013 at 12:58 AM, Nuno Oliveira wrote:

Hi,

After this discussion ( http://osgeo-org.1560.x6.nabble.com/Storing-styiling-properties-as-a-JSON-map-td5073329.html) on GeoServer users list (if you think this is a useful add) I would like to contribute the mapper function to GeoServer.

As already discussed, the goal of mapper function will be allowing the access of styling properties stored in a Map encoded as a JSON object. With this approach we can store all our styling properties in a single column (Feature property). Since their are not explicitly declared, the number and the type of styling properties is variable. The JSON object can be easily used in all architecture layers (javascript, java, scala, ruby, …).

As an example, lets consider this normal style:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:PropertyName>MARK</ogc:PropertyName>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:PropertyName>COLOR</ogc:PropertyName>
</CssParameter>
</Fill>

<Size>
<ogc:PropertyName>SIZE</ogc:PropertyName>
</Size>
</Graphic>
</PointSymbolizer>

Our Feature will need to have explicitly declared the properties “WELL_KNOWN_NAME”, “COLOR” and “ELEMENT_SIZE”.

Using the mapper function the style above will become:

<PointSymbolizer>
<Graphic>

<WellKnownName>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>mark</ogc:Literal>
</ogc:Function>
</WellKnownName>
<Fill>
<CssParameter name=“fill”>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>color</ogc:Literal>
</ogc:Function>
</CssParameter>
</Fill>

<Size>
<ogc:Function name=“mapper”>
<ogc:PropertyName>JSON_STYLE</ogc:PropertyName>
<ogc:Literal>size</ogc:Literal>
</ogc:Function>
</Size>
</Graphic>
</PointSymbolizer>

The Feature property “JSON_STYLE” will contain all JSON styling properties and could look like this:

‘{“color”:“##081931”,“size”:10,“mark”:“square”,“label”:“simple point”}’

I have done a quick benchmarking (in attach) and there is no performance cost in having the style stored in a JSON object. However, if the JSON object is not a Feature property, i.e. if it is obtained in a static context (literal, env function , …) we cannot cache its value. Since the object is not associated with any feature the cost of putting the deserialized object in cache (i.e. using the object himself to produce a hascode) is more costly that just parsing the object. But (at the moment) I don’t see any use case where the JSON object isn’t associated with any Feature. Anyway the cost of parsing the object is not so high we are talking about more ~150ms for 10000 point with three styling properties.

I have been out of GeoServer Dev for some time, but we already sign the contributing agreement for contributing W3DS module.
Currently we are using this function as a GeoServer extension (plugin).

Best regards,

Nuno Oliveira

Learn the latest–Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Attachments:

MapperFunctionBenchMarking.pdf