search

MapServer / MapServer-import

3 stars 2 forks source link

mapserver doesn't render thick lines on the edges properly #1957

Open tbonfort opened 12 years ago

tbonfort commented 12 years ago

Reporter: steven.ottens@geodan.nl Date: 2006/11/03 - 16:47

When a LINE element, wider than 1, comes at the edge of a BBOX at an angle, the
line is drawn until the middleline hits the edge. This means that the outer
lines are not drawn until the edge.
See also the blog entry by Chris as referenced above.

This is a big issues on tiled implementations
tbonfort commented 12 years ago

Author: steven.ottens@geodan.nl Date: 2006/11/03 - 16:48

It could very well be related by Yukka's bug:
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1956
tbonfort commented 12 years ago

Author: fwarmerdam Date: 2006/11/03 - 16:52


Check the following for an example:
  http://crschmidt.net/blog/archives/154/mapserver-rendering-bug/

I think we need to extend rendering of lines out past the edge of the
image based on some geometry calculations with the symbol size and where
the symbol will be completely "off image". 

Hopefully this isn't too deep into GD!

Recatigorizing as core library and reassigning to Steve for consideration.
tbonfort commented 12 years ago

Author: pspencer@dmsolutions.ca Date: 2006/11/03 - 16:53

in ka-Map we solve this by rendering a larger image and clipping the center out.  The default buffer is now 
40 pixels in ka-Map, but it should be possible to automatically calculate the size of the buffer required 
from the largest symbol size or something like that :)
tbonfort commented 12 years ago

Author: sdlime Date: 2006/11/03 - 21:41

I think this is likely a clipping issue. I don't remember the size of the 
clipping buffer left outside the edge of the image but it's a fixed size and 
not computed. It should be possible to compute that size from the maxsize of 
all classes (and styles) as Paul suggests.

Steve
tbonfort commented 12 years ago

Author: sdlime Date: 2006/11/06 - 05:14

Anyone got a simple test case for this one? I think really thing this is a
clipping issue.

One problem with autosetting of the clipping buffer is that with auto-styling or
feature specific sizing (e.g. via attribute) you don't know what the max is. One
idea might be to figure out a way to explicitly set this value somehow (in
metadata?).

Steve
tbonfort commented 12 years ago

Author: steven.ottens@geodan.nl Date: 2006/11/06 - 09:40

The dutch edugis site uses mapserver and requests tiles, which amplifies the issue:
http://www.edugis.nl/mapbuilder_test/edugis/
It is not the maybe the simplest test case though, but I have full access to
that site so I can change stuff if needed.
tbonfort commented 12 years ago

Author: sdlime Date: 2006/11/08 - 07:52

Did some testing tonite and this looks to be a GD bug but I'll have to write a
test purely in GD to confirm. MapServer is clipping using computations based on
the first style in the requested class. It's almost always the largest since
it's rendered first. So that's not the problem here (although it's possible in
certain cases this might not be robust enough), certainly not with the example
Chris posted.

It looks like once GD hits a point not in the image it bails on rendering even
if the brush being used is large enough to still be affecting the image. Argh...

Steve
tbonfort commented 12 years ago

Author: sdlime Date: 2006/11/08 - 08:04

I can confirm GD doesn't handle points at the edge either (at least when drawing
an ellipse). Once that center point is outside the image bounds it doesn't
matter if a part of the ellipse is in the image, it won't draw it.

Steve
tbonfort commented 12 years ago

Author: steven.ottens@geodan.nl Date: 2006/11/08 - 15:37

Great work Steve, some basic testing in house did point to the same conclusion,
we suspect that GD's edge check in the line function is too rough, but haven't
done proper testing yet.
Now the question is who's the best man to solve this bug. We're willing to try
it, but out knowledge of GD/mapserver isn't too good.

Steven
tbonfort commented 12 years ago

Author: sdlime Date: 2006/11/08 - 17:20

I'm planning on digging in again tonite (got caught up in election coverage 
last night) with GD specific tests. I want to make sure I'm not doing something 
stupid elsewhere in MapServer.

I suspect the outcome will be another patch for GD. We're going to have to 
consider our own distribution...

Steve
tbonfort commented 12 years ago

Author: sdlime Date: 2006/11/13 - 06:53

Check out a recent message to mapserver-dev related to a fix...

Steve
tbonfort commented 12 years ago

Author: sdlime Date: 2006/11/29 - 07:02

Since this is a GD problem I'm marking as invalid and closing this out. Note
that using the CVS version of GD does fix this problem. I don't know if that is
a result of other patches or the perhaps the addition of Autodesk submitting
patches. At any rate try downloading and see what you think.

Steve