Opened 17 years ago
Closed 17 years ago
#1957 closed defect (invalid)
mapserver doesn't render thick lines on the edges properly
Reported by: | Owned by: | sdlime | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | WMS Server | Version: | 4.8 |
Severity: | major | Keywords: | |
Cc: |
Description
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
Change History (14)
comment:2 by , 17 years ago
Cc: | added |
---|---|
Component: | WMS Server → MapServer C Library |
Owner: | changed from | to
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.
comment:3 by , 17 years ago
Component: | MapServer C Library → WMS Server |
---|
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 :)
comment:4 by , 17 years ago
Cc: | added |
---|
comment:5 by , 17 years ago
Status: | new → assigned |
---|
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
comment:6 by , 17 years ago
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
comment:7 by , 17 years ago
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.
comment:8 by , 17 years ago
blocked: | → 1956 |
---|
comment:9 by , 17 years ago
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
comment:10 by , 17 years ago
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
comment:11 by , 17 years ago
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
comment:12 by , 17 years ago
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
comment:14 by , 17 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
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
Note:
See TracTickets
for help on using tickets.