Opened 19 years ago
Last modified 19 years ago
#1444 assigned defect
Positioning bug with gdal support compiled in
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | GDAL Support | Version: | 4.6 |
Severity: | normal | Keywords: | |
Cc: |
Description
If i compile mapserver-4.6.0 with gdal support, positioning of a point (Postgis 0.9.2) over a raster layer (GeoTiff) produces different positions of that point if i pan the window rectangle in different directions (I have zoomed the raster layer very deep, so i can see the point in a pixel group) This is reproduceable with mapserver-4.0/4.25/4.4 with gdal-1.1.9/1.2.6/1.3.0 . My Platform is RedHat Enterprise Linux 3.0 (in real CentOS-3.5 wich is a free RHEL 3.0 with all updates) I can send a few hardcopy's which shows this error ! Wolfgang Brungert
Attachments (3)
Change History (5)
by , 19 years ago
Attachment: | hardcopy_mapserver_correct.png added |
---|
by , 19 years ago
Attachment: | hardcopy_mapserver_with_gdal1.png added |
---|
This is false (with gdal support compiled in)
by , 19 years ago
Attachment: | hardcopy_mapserver_with_gdal2.png added |
---|
This is also false, after a few mouse clicks to pan around (with gdal support compiled in)
comment:1 by , 19 years ago
attachments.description: | This is also false, after a few mouse clicks ton pan around (with gdal support compiled in) → This is also false, after a few mouse clicks to pan around (with gdal support compiled in) |
---|
comment:2 by , 19 years ago
Status: | new → assigned |
---|---|
Summary: | Positioning bug with gdal support compiled in → Positioning bug with gdal support compiled in |
By default MapServer's GDAL renderer stretches a particular pixel region from the file to a particular pixel region in the result raster. It does not attempt to address subpixel resolution issues. That means when you are zoomed in far past 1:1 raster resolution you will never see just part of a disk pixel. The pixels will always be evenly spread over the canvas even though this is clearly a misrepresentation. It is done this way since at normal resolutions it is essentially accurate and it is faster to do this sort of bit blitting. If you were able to force the layer to go through the resampler, you should see correct results. Possibly MapServer ought to force use of the resampling code when images are requested at much more than their native resolution. I can't really address this just now, but I will leave the bug open. Let me know if you need information on how to tweak things to use the resampler.
Note:
See TracTickets
for help on using tickets.
This is correct ! (without gdal support compiled in)