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)
Change History (21)
by , 15 years ago
comment:1 by , 15 years ago
One zip archive was too large for trck so I attached most files separately.
comment:3 by , 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 , 15 years ago
Output from test.map (mapserver 5.4-rc1 and GDAL 1.6.0)
comment:4 by , 15 years ago
Component: | MapServer C Library → GDAL Support |
---|---|
Owner: | changed from | to
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 , 15 years ago
Cc: | added; removed |
---|
by , 15 years ago
Attachment: | test_no_gdal.png added |
---|
Test without GDAL using native PNG (MapServer 5.4)
comment:6 by , 15 years ago
Status: | new → assigned |
---|
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 , 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 , 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 , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I concur, closing as corrected.
mapfile