Opened 15 years ago

Closed 15 years ago

#2976 closed defect (fixed)

raster and vector layers are not properly aligned

Reported by: bartw Owned by: warmerdam
Priority: normal Milestone: 5.6 release
Component: GDAL Support Version: 5.2
Severity: blocker Keywords:
Cc: sdlime

Description

I attached zip archive with:

ras.png, ras.wld - raster layer
vec.* - vector layer
map.map - mapserver map file
qgis_project - qgis project file

Those png images shows output from QGIS and MapServer:
mapserv*.png - mapserver output
qgis.png - qgis output

QGIS renders points from vector layer in center of black pixels from raster. This is correct. Both those layers were generated from the same data. Unfortunately there is a bug in mapserver because layers are shifted. It seams not be raster scaling bug because misalignment is constant all over the map. Shift offset might change when extent or output image size changes(I commented out other "size" in mapfile that demonstraes this). It happens with jpeg, png and agg(png) output(possibly all others). I tested it with mapserver 5.0.3 and 5.2.1 on ubuntu and windows. I used dist packages on Ubuntu(8.10 and 9.04) and ms4w 2.3.1 packages on windows.

Attachments (12)

map.map (538 bytes ) - added by bartw 15 years ago.
mapfile
mapserv1.png (7.9 KB ) - added by bartw 15 years ago.
mapserver output 1
mapserv2.png (6.4 KB ) - added by bartw 15 years ago.
mapserver output 2
qgis.png (7.0 KB ) - added by bartw 15 years ago.
qgis output
qgis_project.qgs (8.6 KB ) - added by bartw 15 years ago.
qgis project file
qgis_project.2.qgs (8.6 KB ) - added by bartw 15 years ago.
qgis project file
ras.png (176.5 KB ) - added by bartw 15 years ago.
raster png
ras.wld (104 bytes ) - added by bartw 15 years ago.
raster worldfile
vec.tar.bz2 (195.8 KB ) - added by bartw 15 years ago.
vector layer
test.map (898 bytes ) - added by sdlime 15 years ago.
Test mapfile with vector features placed at corners.
test.png (7.6 KB ) - added by sdlime 15 years ago.
Output from test.map (mapserver 5.4-rc1 and GDAL 1.6.0)
test_no_gdal.png (7.2 KB ) - added by sdlime 15 years ago.
Test without GDAL using native PNG (MapServer 5.4)

Download all attachments as: .zip

Change History (21)

by bartw, 15 years ago

Attachment: map.map added

mapfile

by bartw, 15 years ago

Attachment: mapserv1.png added

mapserver output 1

by bartw, 15 years ago

Attachment: mapserv2.png added

mapserver output 2

by bartw, 15 years ago

Attachment: qgis.png added

qgis output

by bartw, 15 years ago

Attachment: qgis_project.qgs added

qgis project file

by bartw, 15 years ago

Attachment: qgis_project.2.qgs added

qgis project file

by bartw, 15 years ago

Attachment: ras.png added

raster png

by bartw, 15 years ago

Attachment: ras.wld added

raster worldfile

by bartw, 15 years ago

Attachment: vec.tar.bz2 added

vector layer

comment:1 by bartw, 15 years ago

One zip archive was too large for trck so I attached most files separately.

comment:2 by sdlime, 15 years ago

Cc: warmerdam added

How'd you generate the MapServer images? WMS, CGI or ?

Steve

comment:3 by sdlime, 15 years ago

I can recreate the output Bart sees with 5.4. If I set the extent to what MapServer computes based on Bart's original mapfile (so no aspect ratio adjustment will be necessary) we get:

EXTENT -9.6092 35 -2.3908 39

I can draw inline features in the corners of the image to confirm they are being placed as expected. The points show up exactly where they should, right at the corners. If there were a systematic offset of vector features I'd expect these to be offset as well. I'll attach a sample image and mapfile. I drew the points as single pixels so look for red at the corners. Leads me to believe it's a raster problem, but I could be wrong of course.

Steve

by sdlime, 15 years ago

Attachment: test.map added

Test mapfile with vector features placed at corners.

by sdlime, 15 years ago

Attachment: test.png added

Output from test.map (mapserver 5.4-rc1 and GDAL 1.6.0)

comment:4 by sdlime, 15 years ago

Component: MapServer C LibraryGDAL Support
Owner: changed from sdlime to warmerdam

If I compile MapServer without GDAL support and use the old built-in PNG renderer the offset goes away. Most likely a GDAL issue so I'll reassign. Wonder if this could be a precision problem? I don't see any apparent systematic offset in apps I'm running but those are almost all in UTM coordinate system. Perhaps since this example is lat/lon significant digits are being truncated or rounded which magnifies the problem here? Just guessing.

Steve

comment:5 by sdlime, 15 years ago

Cc: sdlime added; warmerdam removed

by sdlime, 15 years ago

Attachment: test_no_gdal.png added

Test without GDAL using native PNG (MapServer 5.4)

comment:6 by warmerdam, 15 years ago

Status: newassigned

I have confirmed the problem, and also found that adding PROCESSING "RESAMPLE=NEAREST" to the raster layer resolves the issue. I suspect this is an issue with the fact that mapdrawgdal does not support subpixel resolution but the offsets should then be less than a whole pixel. I'll dig deeper.

comment:7 by warmerdam, 15 years ago

I have made a change in trunk (r8897) changing how the rounding is done when selecting a source window. The old logic was such that the conversion to integer values could result in an up to 1 pixel error in the selection of the region from the source file. With the adjustment the error is limited to a half pixel (round instead of truncate). However, when using the high performance raster logic and supersampling the placement can still be quite bad depending on the window selected and the amount of oversampling being done.

I am hesitant to back port this to old releases though it is certainly possible.

comment:8 by sdlime, 15 years ago

Milestone: 5.6.0 release

Frank, any reason not to close this? I'm assigning to the 5.6 milestone since that's what trunk will become.

Steve

comment:9 by warmerdam, 15 years ago

Resolution: fixed
Status: assignedclosed

I concur, closing as corrected.

Note: See TracTickets for help on using tickets.