[Geoserver-users] Visible shift between superimposed dashed lines

GeoServer GeoServer User
1

Hi,

We use two dashed strokes to represent roads under construction
The large gray dashed stroke is under a thiner white dashed stroke.
Dashes have same parameters (as shown by the left image).

In some cases (when the linestring starts out of the requested image),
we can see a shift between the gray and the white dashes (the gray
dash exceeds the white one and becomes visible at one of the dash
end (as shown by the right image)

Has anyone any tip to solve this problem ? (using a plain white line to
hide the artifact is not an option).

Thanks for the help,

Michaël

ATT00002.jpg

ATT00003.jpg

···

2

Hi Michaël,

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

ATT00003.jpg

ATT00002.jpg

···

Are the two line declarations within the same se:FeatureTypeStyle in the SLD file? In theory, if I understand it correctly, in this situation the same data should be rendered on the same pass, so I’d expect them to be identical. A bug in GeoServer perhaps?

Cheers,
Jonathan

On 23 October 2013 17:54, Michael Michaud <Michael.Michaud@anonymised.com> wrote:

Hi,

We use two dashed strokes to represent roads under construction
The large gray dashed stroke is under a thiner white dashed stroke.
Dashes have same parameters (as shown by the left image).

In some cases (when the linestring starts out of the requested image),
we can see a shift between the gray and the white dashes (the gray
dash exceeds the white one and becomes visible at one of the dash
end (as shown by the right image)

Has anyone any tip to solve this problem ? (using a plain white line to
hide the artifact is not an option).

Thanks for the help,

Michaël

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

3

On Wed, Oct 23, 2013 at 7:16 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Hi Michaël,

Are the two line declarations within the same <se:FeatureTypeStyle> in
the SLD file? In theory, if I understand it correctly, in this situation
the same data should be rendered on the same pass, so I'd expect them to be
identical. A bug in GeoServer perhaps?

A weird one too... afaik all we do is to call java2d to paint the very same
line with the dashed array...

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.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

-------------------------------------------------------

4

Hi,

Here after is the SLD generating these weird dash lines.
Just a suggestion :
The documentation explains that geoserver can take into account
the size and width of symbolisations (for fixed values) in order
to display features which geometry is out of the requested BBox
but which symbol may overlap it.
If the enveloppe the lines are clipped to depends on the line
symbol width, it explains quite well what we observe on our map.
In this case, using the maximum line width of a sld to compute
the buffer size could be of some help.

We tried to set a DefaultRenderingBuffer to prevent the buffer
size to vary but without success.

Michaël Michaud
IGN - INSTITUT NATIONAL DE L'INFORMATION
GEOGRAPHIQUE ET FORESTIERE (FRANCE)

<FeatureTypeStyle>

<Rule>

<Name>Route en construction.1</Name>

<ogc:Filter>

<ogc:And>

<ogc:PropertyIsEqualTo>

<ogc:PropertyName>symbolisation</ogc:PropertyName>

<ogc:Literal>Route en construction</ogc:Literal>

</ogc:PropertyIsEqualTo>

<ogc:PropertyIsEqualTo>

<ogc:Function name="env"><ogc:Literal>ROU_opacite</ogc:Literal><ogc:Literal>1.0</ogc:Literal></ogc:Function>

<ogc:Literal>1.0</ogc:Literal>

</ogc:PropertyIsEqualTo>

</ogc:And>

</ogc:Filter>

<MinScaleDenominator>0</MinScaleDenominator>

<MaxScaleDenominator>34000</MaxScaleDenominator>

<LineSymbolizer uom="http://www.opengeospatial.org/se/units/metre&quot;&gt;

<Stroke>

<CssParameter name="stroke"><ogc:Function name="env"><ogc:Literal>ROU_lisere_N</ogc:Literal><ogc:Literal>#808080</ogc:Literal></ogc:Function></CssParameter>

<CssParameter name="stroke-dasharray">75 30</CssParameter>

<CssParameter name="stroke-linejoin">round</CssParameter>

<CssParameter name="stroke-linecap">butt</CssParameter>

<CssParameter name="stroke-width">15</CssParameter>

</Stroke>

</LineSymbolizer>

</Rule>

</FeatureTypeStyle>

<FeatureTypeStyle>

<Rule>

<Name>Route en construction.2</Name>

<ogc:Filter>

<ogc:And>

<ogc:PropertyIsEqualTo>

<ogc:PropertyName>symbolisation</ogc:PropertyName>

<ogc:Literal>Route en construction</ogc:Literal>

</ogc:PropertyIsEqualTo>

<ogc:PropertyIsEqualTo>

<ogc:Function name="env"><ogc:Literal>ROU_opacite</ogc:Literal><ogc:Literal>1.0</ogc:Literal></ogc:Function>

<ogc:Literal>1.0</ogc:Literal>

</ogc:PropertyIsEqualTo>

</ogc:And>

</ogc:Filter>

<MinScaleDenominator>0</MinScaleDenominator>

<MaxScaleDenominator>34000</MaxScaleDenominator>

<LineSymbolizer uom="http://www.opengeospatial.org/se/units/metre&quot;&gt;

<Stroke>

<CssParameter name="stroke">#ffffff</CssParameter>

<CssParameter name="stroke-dasharray">75 30</CssParameter>

<CssParameter name="stroke-linejoin">miter</CssParameter>

<CssParameter name="stroke-linecap">butt</CssParameter>

<CssParameter name="stroke-width">10</CssParameter>

</Stroke>

</LineSymbolizer>

</Rule>

</FeatureTypeStyle>

________________________________

  De : Andrea Aime [mailto:andrea.aime@anonymised.com]
  Envoyé : mercredi 23 octobre 2013 19:24
  À : Jonathan Moules
  Cc : Michael Michaud; geoserver-users@lists.sourceforge.net
  Objet : Re: [Geoserver-users] Visible shift between superimposed dashed lines
  
  On Wed, Oct 23, 2013 at 7:16 PM, Jonathan Moules <jonathanmoules@anonymised.com.> wrote:
  
    Hi Michaël,

    Are the two line declarations within the same <se:FeatureTypeStyle> in the SLD file? In theory, if I understand it correctly, in this situation the same data should be rendered on the same pass, so I'd expect them to be identical. A bug in GeoServer perhaps?

  A weird one too... afaik all we do is to call java2d to paint the very same line with the dashed array...

  Cheers
  Andrea

  --
  
  ==
  Our support, Your Success! Visit http://opensdi.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

  -------------------------------------------------------

5

Hi Michael,
It seems my last email to you bounced (though it clearly got to the list).

Anyway, you might want to try removing the lines:

By using those, you’re asking GeoServer to draw the lines on separate rendering passes. In reality you want them done on the same pass.

Regards,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

On 24 October 2013 10:02, Michael Michaud <Michael.Michaud@anonymised.com> wrote:

Hi,

Here after is the SLD generating these weird dash lines.
Just a suggestion :
The documentation explains that geoserver can take into account
the size and width of symbolisations (for fixed values) in order
to display features which geometry is out of the requested BBox
but which symbol may overlap it.
If the enveloppe the lines are clipped to depends on the line
symbol width, it explains quite well what we observe on our map.
In this case, using the maximum line width of a sld to compute
the buffer size could be of some help.

We tried to set a DefaultRenderingBuffer to prevent the buffer
size to vary but without success.

Michaël Michaud
IGN - INSTITUT NATIONAL DE L’INFORMATION
GEOGRAPHIQUE ET FORESTIERE (FRANCE)

Route en construction.1

ogc:Filter

ogc:And

ogc:PropertyIsEqualTo

ogc:PropertyNamesymbolisation</ogc:PropertyName>

ogc:LiteralRoute en construction</ogc:Literal>

</ogc:PropertyIsEqualTo>

ogc:PropertyIsEqualTo

<ogc:Function name=“env”>ogc:LiteralROU_opacite</ogc:Literal>ogc:Literal1.0</ogc:Literal></ogc:Function>

ogc:Literal1.0</ogc:Literal>

</ogc:PropertyIsEqualTo>

</ogc:And>

</ogc:Filter>

0

34000

<ogc:Function name=“env”>ogc:LiteralROU_lisere_N</ogc:Literal>ogc:Literal#808080</ogc:Literal></ogc:Function>

75 30

round

butt

15

Route en construction.2

ogc:Filter

ogc:And

ogc:PropertyIsEqualTo

ogc:PropertyNamesymbolisation</ogc:PropertyName>

ogc:LiteralRoute en construction</ogc:Literal>

</ogc:PropertyIsEqualTo>

ogc:PropertyIsEqualTo

<ogc:Function name=“env”>ogc:LiteralROU_opacite</ogc:Literal>ogc:Literal1.0</ogc:Literal></ogc:Function>

ogc:Literal1.0</ogc:Literal>

</ogc:PropertyIsEqualTo>

</ogc:And>

</ogc:Filter>

0

34000

#ffffff

75 30

miter

butt

10

De : Andrea Aime [mailto:andrea.aime@anonymised.com]
Envoyé : mercredi 23 octobre 2013 19:24
À : Jonathan Moules
Cc : Michael Michaud; geoserver-users@lists.sourceforge.net
Objet : Re: [Geoserver-users] Visible shift between superimposed dashed lines

On Wed, Oct 23, 2013 at 7:16 PM, Jonathan Moules <jonathanmoules@anonymised.com> wrote:

Hi Michaël,

Are the two line declarations within the same se:FeatureTypeStyle in the SLD file? In theory, if I understand it correctly, in this situation the same data should be rendered on the same pass, so I’d expect them to be identical. A bug in GeoServer perhaps?

A weird one too… afaik all we do is to call java2d to paint the very same line with the dashed array…

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.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

6

Hi Jonathan,

It seems my last email to you bounced (though it clearly got to the list).

Anyway, you might want to try removing the lines:

Thanks for your answer,
We have just tried your suggestion, but it does not solve the problem.

By using those, you’re asking GeoServer to draw the lines on separate rendering passes. In reality you want them done on the same pass.

I want them to be drawn with consistent parameters, not really in the same pass.
Indeed, we generally want them to be drawn in two separate passes so that
crossroads look nice.

My guess is that the problem comes from the following code :

class StreamingRenderer
private void processSymbolizers(…) {
…
for (Symbolizer symbolizer : symbolizers) {
…
double size = RendererUtilities.getStyle2DSize(style) + 10;
env.expandBy(size);
…
}
…
}
}

Regards,

Michaël

···

On 24 October 2013 10:02, Michael Michaud <Michael.Michaud@anonymised.com> wrote:

Hi,

Here after is the SLD generating these weird dash lines.
Just a suggestion :
The documentation explains that geoserver can take into account
the size and width of symbolisations (for fixed values) in order
to display features which geometry is out of the requested BBox
but which symbol may overlap it.
If the enveloppe the lines are clipped to depends on the line
symbol width, it explains quite well what we observe on our map.
In this case, using the maximum line width of a sld to compute
the buffer size could be of some help.

We tried to set a DefaultRenderingBuffer to prevent the buffer
size to vary but without success.

Michaël Michaud
IGN - INSTITUT NATIONAL DE L’INFORMATION
GEOGRAPHIQUE ET FORESTIERE (FRANCE)

Route en construction.1

ogc:Filter

ogc:And

ogc:PropertyIsEqualTo

ogc:PropertyNamesymbolisation</ogc:PropertyName>

ogc:LiteralRoute en construction</ogc:Literal>

</ogc:PropertyIsEqualTo>

ogc:PropertyIsEqualTo

<ogc:Function name=“env”>ogc:LiteralROU_opacite</ogc:Literal>ogc:Literal1.0</ogc:Literal></ogc:Function>

ogc:Literal1.0</ogc:Literal>

</ogc:PropertyIsEqualTo>

</ogc:And>

</ogc:Filter>

0

34000

<ogc:Function name=“env”>ogc:LiteralROU_lisere_N</ogc:Literal>ogc:Literal#808080</ogc:Literal></ogc:Function>

75 30

round

butt

15

Route en construction.2

ogc:Filter

ogc:And

ogc:PropertyIsEqualTo

ogc:PropertyNamesymbolisation</ogc:PropertyName>

ogc:LiteralRoute en construction</ogc:Literal>

</ogc:PropertyIsEqualTo>

ogc:PropertyIsEqualTo

<ogc:Function name=“env”>ogc:LiteralROU_opacite</ogc:Literal>ogc:Literal1.0</ogc:Literal></ogc:Function>

ogc:Literal1.0</ogc:Literal>

</ogc:PropertyIsEqualTo>

</ogc:And>

</ogc:Filter>

0

34000

#ffffff

75 30

miter

butt

10

De : Andrea Aime [mailto:andrea.aime@anonymised.com]
Envoyé : mercredi 23 octobre 2013 19:24
À : Jonathan Moules
Cc : Michael Michaud; geoserver-users@lists.sourceforge.net
Objet : Re: [Geoserver-users] Visible shift between superimposed dashed lines

On Wed, Oct 23, 2013 at 7:16 PM, Jonathan Moules <jonathanmoules@anonymised.com.> wrote:

Hi Michaël,

Are the two line declarations within the same se:FeatureTypeStyle in the SLD file? In theory, if I understand it correctly, in this situation the same data should be rendered on the same pass, so I’d expect them to be identical. A bug in GeoServer perhaps?

A weird one too… afaik all we do is to call java2d to paint the very same line with the dashed array…

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.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

7

On Fri, Oct 25, 2013 at 2:21 PM, Michael Michaud <Michael.Michaud@anonymised.com>wrote:

**
Hi Jonathan,

It seems my last email to you bounced (though it clearly got to the
list).
Anyway, you might want to try removing the lines:

</FeatureTypeStyle>
<FeatureTypeStyle>

Thanks for your answer,
We have just tried your suggestion, but it does not solve the problem.

By using those, you're asking GeoServer to draw the lines on separate
rendering passes. In reality you want them done on the same pass.

I want them to be drawn with consistent parameters, not really in the same
pass.
Indeed, we generally want them to be drawn in two separate passes so that
crossroads look nice.

My guess is that the problem comes from the following code :

class StreamingRenderer
        private void processSymbolizers(...) {
                ...
                *for (Symbolizer symbolizer : symbolizers) {*
* ...*
* double size =
RendererUtilities.getStyle2DSize(style) + 10;*
* env.expandBy(size);*
* ...*
* }*
                *...*
        }
}

It's the code that expands the envelope based on how big the symbolizers to
be painted are.
You should be able to dodge it by adding &buffer=20 to your requests,
forcing the
envelope buffering to a fixed value.
See if that works

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.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

-------------------------------------------------------

8

Hi,

···

Can’t make it work with &buffer=20 :o(
(I can see some effects of &buffer on ponctual symbols, but not on linear symbols)

I did not go through all the code but I wonder if the &buffer parameter is
really used for “line clipping” (I have seen it used for “feature selection” only).

Regards,

Michaël

==
Our support, Your Success! Visit http://opensdi.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

9

On Fri, Oct 25, 2013 at 3:43 PM, Michael Michaud <Michael.Michaud@anonymised.com>wrote:

(I can see some effects of &buffer on ponctual symbols, but not on linear
symbols)

I did not go through all the code but I wonder if the &buffer parameter is
really used for "line clipping" (I have seen it used for "feature
selection" only).

I see, too bad. Can you open a bug report on jira.codehaus.org?
While don't have time to look into this one right now, but believe the
problem is indeed a bug

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.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

-------------------------------------------------------