Opened 15 years ago
Closed 14 years ago
#3157 closed defect (fixed)
rendering differences between 5.4.2 and 5.6.0
Reported by: | milovanderlinden | Owned by: | aboudreault |
---|---|---|---|
Priority: | normal | Milestone: | 5.6 release |
Component: | MapServer CGI | Version: | svn-trunk (development) |
Severity: | normal | Keywords: | |
Cc: | aboudreault, dmorissette, sdlime, tbonfort |
Description (last modified by )
Reproduce:
- compile mapserver 5.4.2
- compile mapserver-svn (trunk)
cp mapserv -? cgi-bin/mapserv-5.4.2 (5.4.2) cp mapserv -? cgi-bin/mapserv-svn (5.6.0-BETA2) cd cgi-bin/ cp mapserv-5.4.2 -> mapserv
- render wms map with qGIS -> export image
- cp mapserv-svn -> mapserv
- zoom out and back in in qGIS -> export image
Result:
- differences in rendering
Remarks:
- By simply overwriting the "mapserv" executable it is clear that the mapfile is not changed
I have created a web-page that shows differences (images are large, comparison images are side-by-side)
http://dogomaps.net/mapserver-5.4.2-5.6.0.html
Attachments (2)
Change History (35)
comment:1 by , 15 years ago
by , 15 years ago
Attachment: | tbonfort.patch added |
---|
comment:2 by , 15 years ago
Owner: | changed from | to
---|
comment:4 by , 15 years ago
Milestone: | → 5.6 release |
---|
comment:6 by , 15 years ago
alan, daniel,
can we also revert the scalefactor applied on the symbol pattern for now (the one acting on dashed lines)
comment:7 by , 15 years ago
Cc: | added; removed |
---|
comment:8 by , 15 years ago
Cc: | added |
---|
We completely overlooked the fact that using scalefactor with SIZEUNITS different from PIXEL could cause this kind of side-effect. If we revert the change for the symbol pattern, we should probably also do it for all other params that used to not be affected by the scaling factor before and were changed for RFC-55... but then that removes lots of value to this enhancement.
Here is the list from the RFC:
- offsets (line, point, polygon)
- pattern (line)
- gap (line)
- outlinewidth (labels)
- shadowsize, background-shadow-size (labels)
- buffer around labels (collision)
- minfeaturesize, mindistance (labels)
I wonder how much work it would be to properly handle these with a new defresolution/resolution arg to all functions? It's kind of late, but we may not have much choice, unless we make that a compile-time option...
comment:9 by , 15 years ago
I'm starting to think the compile-time option is the best way to go: default to the 5.4 behavior for all affected params, and with a compile-time option you let scalefactor affect all those params, with the understanding that you must use SIZEUNITS PIZEL with such a build.
Would that work or did I overlook something else?
comment:10 by , 15 years ago
Since all agg/pdf/svg draw functions have an imageObj in parameter, and that the resolution is already in the imageObj..... I think it would be ok to just add temporary "defresolution" property in it then we could easily compute the resolution scale factor in all those functions. But yes, for GD, we will need to add the parameter and modify the function calls (mostly in maprendering.c) because those functions use a gdImagePtr instead of an imageObj.. but having the res scale factor computable with the imageObj... it's too much effort. What's your thought?
follow-ups: 13 16 comment:11 by , 15 years ago
functions now use the scalefactor and the resolutionfactor, as some parameters must be scaled by "scalefactor", and others only by "resolutionfactor"
changes have only been applied to the AGG renderer.
revision: r9432
milo: can you test the current trunk version on your data and confirm?
comment:12 by , 15 years ago
I've modified the resolution factor variable name since it isn't related to the scale: r9433.
comment:13 by , 15 years ago
Replying to tbonfort:
functions now use the scalefactor and the resolutionfactor, as some parameters must be scaled by "scalefactor", and others only by "resolutionfactor"
changes have only been applied to the AGG renderer.
revision: r9432
milo: can you test the current trunk version on your data and confirm?
Do the same changes need to made in the GD code or wasn't that changed in the first place? -Steve
comment:14 by , 15 years ago
Yes, the GD code (and other drivers) were also changed and will need to have the changes reverted. We are making sure AGG has proper support for RFC-55, while coming back to 5.4 behavior for maps using SIZEUNITS != PIXELS and/or SCALEDENOM.
However, but for GD and all other except AGG we are not sure if we should revert everything back to the state of 5.4 (removing RFC55 support), or if we should attempt to make all of them work properly for RFC-55 at such a late time before the release.
It may be easier and more worthwhile to wait and invest time to fix this in the new rendering stuff in 6.0 than in the 5.6 code that is likely to go away anyway.
Do you have a preference?
comment:15 by , 15 years ago
My preference would be to fix things in 6.0 and revert 5.6 to 5.4 behavior assuming that's less work at this late date. I don't know that we want AGG and GD diverging significantly in their behavior at 5.6 though.
Steve
comment:16 by , 15 years ago
I will test this with my openstreetmap mapfile on monday (oct 12) thanks for the great work on trying to fix this!
comment:17 by , 15 years ago
comment:18 by , 15 years ago
Performed visual tests comparing 5.4.2 with r9442 and the rendering is now exactly the same for my openstreetmap mapfiles!
Excelent work. As far as I am concerned, this issue can be closed.
I intend to set up a openlayers test page where a dynamic comparison of the two versions side by side can be made. I will keep you posted.
comment:19 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
follow-up: 23 comment:20 by , 15 years ago
I have set up a nice little openlayers "Map compare" here: http://dogomaps.net/compare.html
You can use it to review in detail the rendering of a mapserver 5.4.2 and the r9442 svn version
by , 15 years ago
Attachment: | map_compare.png added |
---|
compare-screenshot differences in number of layers
comment:21 by , 15 years ago
I attached a screenshot that shows that the number of labels that are drawn is different and also the selection of what labels to show.
comment:22 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Reopening the ticket since the implementation for GD and others drivers is not done yet.
follow-up: 24 comment:23 by , 15 years ago
Replying to milovanderlinden:
I have set up a nice little openlayers "Map compare" here: http://dogomaps.net/compare.html
You can use it to review in detail the rendering of a mapserver 5.4.2 and the r9442 svn version
milo, could you update the mapserv on your test server to run the latest trunk, I hope the issue with the labels is now fixed.
thanks,
follow-up: 25 comment:24 by , 15 years ago
Replying to tbonfort: I updated to trunk, but the label placement and selecting what objects should show a label or not is not yet the same between the two versions. The new trunk is online at http://dogomaps.net/compare.html
comment:25 by , 15 years ago
Replying to milovanderlinden:
If I can find some time I will implement permalinks in the compare.html example so it will be easier to show where issues arise.
comment:26 by , 15 years ago
(Permalink implemented) See here: http://dogomaps.net/compare.html?zoom=8&lat=386539.36768&lon=52146.05713&layers=B it is clear that version 5.4.2 does the label placement different when zoomed in
comment:27 by , 15 years ago
milovanderlinden, May you update the mapserv to run the lastest trunk again please.
comment:28 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Compiled r9453, excelent result! label positioning now looks exactly matches between the two versions! http://dogomaps.net/compare.html
follow-up: 30 comment:29 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Reopening the ticket, the work is not done yet. I'll close it when everything is done.
I've committed in r9453: the new GD functions API, and in r9454: the resolution scaling in GD driver.
I let all OFFSET and GAP scaled by the scalefactor, as agg does.
tbonfort, may you take a look at these "possible modifications or problems":
- mapgd.c, line 1089 and 1767: not sure what to do with those lines.
- maplabel.c, line 1085: I want to be sure the change is ok for maxsize and minsize comparison.
- mapdraw.c, line 2344, 2367 and 2580): the backgroundshadowsizex and backgroundshadowsizey multiplied by the resolutionfactor are assigned to the style.offsetx/y variables. I think it shouldn't because the style.offsetx/y will be scaled (using scalefactor) in msDrawShadeSymbolGD and msDrawShadeSymbolAGG() functions.
comment:30 by , 15 years ago
Replying to aboudreault:
Reopening the ticket, the work is not done yet. I'll close it when everything is done.
I've committed in r9453: the new GD functions API, and in r9454: the resolution scaling in GD driver.
I let all OFFSET and GAP scaled by the scalefactor, as agg does.tbonfort, may you take a look at these "possible modifications or problems":
- mapgd.c, line 1089 and 1767: not sure what to do with those lines.
they are both ok, although the test should be ==-99 , not -90. Not sure why this is so, so leaving this as is for now
- maplabel.c, line 1085: I want to be sure the change is ok for maxsize and minsize comparison.
adapted in r9462
- mapdraw.c, line 2344, 2367 and 2580): the backgroundshadowsizex and backgroundshadowsizey multiplied by the resolutionfactor are assigned to the style.offsetx/y variables. I think it shouldn't because the style.offsetx/y will be scaled (using scalefactor) in msDrawShadeSymbolGD and msDrawShadeSymbolAGG() functions.
no, the current is correct, as msDrawShadeSymbol is called with a scalefactor=1 in those cases
comment:31 by , 15 years ago
I committed the resolution scaling for svg, swf, pdf and imagemap drivers in r9472.
comment:32 by , 14 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | reopened → new |
Alan, is this done? Can we close?
tbonfort handed me a patch (see attachment); it corrects the outline/halo for labels (lowest two images on the webpage) But other differences remain: