[Qgis-developer] Displacement and SLD's

Giuseppe Sucameli brush.tyler at gmail.com
Wed May 8 08:30:52 PDT 2013


Hi Andrea,

On Wed, May 8, 2013 at 12:57 PM, Andrea Aime
<andrea.aime at geo-solutions.it>wrote:

> On Wed, May 8, 2013 at 12:33 PM, Giuseppe Sucameli <brush.tyler at gmail.com>wrote:
>
>> IMHO the displacement shouldn't be used in that way, as empty space
>> between graphics, though the SE1.1 specs doesn't define a proper tag to do
>> that... In fact the Graphic->Displacement tag is already used in other
>> contexts with the meaning of "distance in pixels from the hot-spot", not as
>> space around the graphic symbol neither as offset between neighbour
>> graphics.
>>
>
> Right, but at the same time, the SE does not say how to use it in
> GraphicFill, so one is free to interpret.
>

Not at all, it says:

""" The GraphicFill element both indicates that a stipple-fill repeated
graphic will be used and specifies the fill graphic. [...] A “graphic” can
be defined very informally as “a little picture”. The appearance of the
graphic is defined with the embedded Graphic element, which is discussed in
Subclause 11.3.2. """

so the meaning of Graphic elements is supposed to be the same for both
GraphicFill and GraphicStroke.

For example, GeoServer does not need SE 1.1 gap and InitialGap in graphic
> strokes because it uses the dasharray for that, another thing that is
> already in the SLD 1.0 spec and that had no proper definition of usage in
> combination with graphicstroke (moreover, it's more flexible than the
> simple gap syntax, one can create irregular symbol along lines, something
> like two circle, space, one circle, space, repeat).
>

It's surely more flexible, but I've few inventiveness. For me a dash is a
dash, so those dash-something elements should be used to render dashes, not
graphic strokes. From my side I would draw both a graphic stroke and a dash
line, BTW the XML schema allows to put GraphicStroke and SvgParameters
toghether without explain how it must behave.


>
>
>> I would define 2 new tags as GraphicFill tag's children, like it's
>> already done in the GraphicStroke tag.
>> GraphicStroke has Gap and InitialGap, we should use the same approach.
>>
>
> Extending SLD is a minefield, what happens if OGC releases a corrigendum
> that adds the same tags, but with a slightly different semantic?
>

The same that would happen if OGC defines what dasharray/dashoffset
elements must be used for.
I agree with you extending SLD should be avoided, additions to GraphicFill
tag could happen soon:
""" Additional parameters for the GraphicFill may be provided in the future
to provide more control the exact style of filling. """


> The way we handle extensions in GeoServer is to use a VendorOptions tag,
> which can accomodate key/value pairs,
>

We do the same in QGIS, and even the tag name it's the same! ;)


>  in this case we could have something like:
>
> <PolygonSymbolizer>
>    ...
>   <VendorOption key="gapAbove">10</VendorOption>
>
   <VendorOption key="gapBelow">5</VendorOption>
>   <VendorOption key="gapRight">5</VendorOption>
>   <VendorOption key="gapLeft">15</VendorOption>
> </PolygonSymbolizer>
>

s/key/name/

We already have a <VendorOption name="distance">20,15</VendorOption> that
handle the distance between graphics in fill, but we are open to a shared
naming convention, as far as possible.

Cheers.


>
> Cheers
> Andrea
>
> --
> ==
> GeoServer training in Milan, 6th & 7th June 2013!  Visit
> http://geoserver.geo-solutions.it for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>



-- 
Giuseppe Sucameli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130508/3c29f116/attachment-0001.html>


More information about the Qgis-developer mailing list