rendering differences between 5.4.2 and 5.6.0

[milovanderlinden]

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

[milovanderlinden]

tbonfort handed me a patch (see attachment); it corrects the outline/halo for labels (lowest two images on the webpage) But other differences remain: - different dashes on the highway - different render for the A58 tunnel) - labels within the urban-areas (grey) still have no halo

[milovanderlinden]

added recipients and assigned ticket to tbonfort

[tbonfort]

label outlines reverted in r9398

[tbonfort]

alan, daniel,

can we also revert the scalefactor applied on the symbol pattern for now (the one acting on dashed lines)

[dmorissette]

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...

[dmorissette]

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?

[aboudreault]

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?

[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?

[aboudreault]

I've modified the resolution factor variable name since it isn't related to the scale: r9433.

[sdlime]

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

[dmorissette]

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?

[sdlime]

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

[milovanderlinden]

I will test this with my openstreetmap mapfile on monday (oct 12) thanks for the great work on trying to fix this!

[tamas]

I've just fixed an issue in r9437 introduced with r9432. Could anyone look into this by considering the possible consequences? Is this a desired option to call msGetLabelSize with img=NULL?

See mapgraticule.c 1100 for an example.

Tamas

[milovanderlinden]

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.

[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

[milovanderlinden]

compare-screenshot differences in number of layers

[milovanderlinden]

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.

[aboudreault]

Reopening the ticket since the implementation for GD and others drivers is not done yet.

[tbonfort]

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,

[milovanderlinden]

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

[milovanderlinden]

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.

[milovanderlinden]

(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

[aboudreault]

milovanderlinden, May you update the mapserv to run the lastest trunk again please.

[milovanderlinden]

Compiled r9453, excelent result! label positioning now looks exactly matches between the two versions!  http://dogomaps.net/compare.html

[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.
• 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.

[tbonfort]

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

[aboudreault]

I committed the resolution scaling for svg, swf, pdf and imagemap drivers in r9472.

[dmorissette]

Alan, is this done? Can we close?

[aboudreault]

All issues have been fixed.