Andrea,
- the graphics are not referred to, but are embedded in the
representation instead.
I think this should be an option. By default the response should be a really simple string representation of the rules.
(see below)
What do you do with dynamic symbolizers that do have attributes in
the symbol path,
This is interesting case... mmm ... I think here the unique option will be resolving the url for each feature and serialize the list of obtained external graphic as a list of rules with the name initialized to the value of the resolved attribute.
For example:
<FeatureTypeStyle>
<Rule>
<Name>Flags</Name>
<Title>USA state flags</Title>
<PointSymbolizer>
<Graphic>
<ExternalGraphic>
<OnlineResource xlink:type="simple"
xlink:href="http://www.usautoparts.net/bmw/images/states/tn_$\{strToLowerCase\(STATE\_ABBR\)\}\.jpg" />
<Format>image/gif</Format>
</ExternalGraphic>
</Graphic>
</PointSymbolizer>
</Rule>
</FeatureTypeStyle>
will be resolved as:
<FeatureTypeStyle>
<Rule>
<Name>alaska</Name>
<Title>USA state flags</Title>
<PointSymbolizer>
<Graphic>
<ExternalGraphic>
<OnlineResource xlink:type="simple"
xlink:href="http://www.usautoparts.net/bmw/images/states/tn_alaska.jpg" />
<Format>image/gif</Format>
</ExternalGraphic>
</Graphic>
</PointSymbolizer>
</Rule>
\.\.\.
<Rule>
<Name>wyoming</Name>
<Title>USA state flags</Title>
<PointSymbolizer>
<Graphic>
<ExternalGraphic>
<OnlineResource xlink:type="simple"
xlink:href="http://www.usautoparts.net/bmw/images/states/tn_wyoming.jpg" />
<Format>image/gif</Format>
</ExternalGraphic>
</Graphic>
</PointSymbolizer>
</Rule>
</FeatureTypeStyle>
Then serialized as json.
If the OnlineResource is a relative path we have 2 ways to proceed:
- generate a base64 encoded string to encode and send the image.
- use getLegendGraphic with image output format to be able to serve images from the FileSystem (selecting them using the RULE parameter and probably the CQL_FIlter to select the feature by FeatureID f.e.). I think this (cql_filter) can be another good improvement if it is not supported.
SVG, or Mark objects, or graphic fills and graphic strokes?
As said the graphical objects can be: [default]
- serialized as is (json style representation) [I will provide this]
This will minimize the data transfer and the load on the target geoserver delegating render operation to the client library this make sense for standard Mark objects (ttf://, shape://, ...)
- rendered all graphic objects as embedded images into the response encoded as base64 string (json with graphic embedded). [resolve as embedded]
- provide links to external graphic using geoserver url(s):
F.e.:
http://localhost:80///geoserver/wms?REQUEST=GetLegendGraphic&VERSION=....&FORMAT=image/png&LAYER=layerName&RULE=RuleName&LEGEND_OPTIONS=forceLabels:off
NOTE: For dynamic symbolizers we need the cql_filter improvement
- only the active parts of the style at the specified scale at returned
Anything else?
Yes, there's another question regarding the outputFormat and the format parameter, currently the unique way to add as add on (without modify the current getLegendGraphic output format) is implementing another response handler and a new output format which may results in query like:
http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetLegendGraphic&layer=topp:states&styles=population2&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&width=780&height=330&srs=EPSG:4326&format=application/json&outputFormat=application/json
For a better integration of the getLegendGraphic I think we may define if we want to switch using different responseHandlers or continue working with outputFormats.
Carlo
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 87<<
054 Massarosa (LU)
Italy
phone: + 84 2313<<
fax: + 84 60272<<
mob: + 9 44549<<
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
%5C%7D%5C.jpg"){kind=link}