Opened 20 years ago
Last modified 20 years ago
#723 assigned defect
three reprojection bugs
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | GDAL Support | Version: | 4.2 |
Severity: | normal | Keywords: | |
Cc: |
Description
There are three bugs that show up when using an orthographic projection (other projections are affected too) in WMS-client mode with a source in geographic projection: 1. If the projection is valid along the borders, but contains the north pole, the source bounding box will not be correct. In these cases the whole grid needs to be sampled in order to determine the source bounds. Perhaps this should be a processing parameter option? 2. If there are invalid points on a particular scanline, the whole scanline fails. The problem is that pj_transform returns a failure and the whole scanline is discarded by mapserver. It seems like pj_transform should transform valid points and set invalid ones to HUGE_VAL, but this is not the case. Maybe this is a bug in proj4... the manpage doesn't really say what the behavior should be in this case. 3. If the destination image contains the -180/180 border, there will be a stripe of invalid data there. The pixels that are near 180 degrees longitude will correspond to points in the source image that are up to 0.5 pixels past the right-hand edge of the image. It seems to me that somewhere in GDALGetGeoTransform there is a 0.5 that is inappropriately added. A quick fix is to allow a one-pixel margin of error in msSimpleRasterResampler. Attached to this message is an example map file and perl script that will demonstrate the problems. The zoomed-in image will have a blank area near the north pole and the zoomed-out image will only draw the center third: the top and bottom will be blank. There is also a quick-hack patch that shows a workaround for these problems. As a side note, it would be nice to have an option that causes a higher-res source image to be downloaded in order to avoid the oversampling effect that sometimes happens (the demo script included with this message produces a noticably pixelated image). - Dan Stahlke
Attachments (3)
Change History (6)
by , 20 years ago
Attachment: | cascade.map added |
---|
comment:1 by , 20 years ago
Dan, A couple notes: o There is a PROCESSING option called LOAD_FULL_RES_IMAGE that will force the whole source image to be loaded avoiding many of the extents issues. Of course this is only usable if the whole image isn't too large to load. o There is also a LOAD_FULL_RES_IMAGE option which forces whatever area is identified to be loaded at full resolution instead of the computed resolution. This can be quite valuable in cases where the guessed resolution is way off, but once again has memory use issues with some large images. o There is some work in recent version of PROJ.4 in pj_transform() that attempts to have pj_transform() attempt all points for any error believed to be "transient". This work was done in late January of this year and is in PROJ 4.4.8. Any change you are using an older version?
comment:2 by , 20 years ago
The given example uses both the LOAD_WHOLE_IMAGE and the LOAD_FULL_RES_IMAGE options. The problem is that neither of these has any effect until after the image has been downloaded from the remote server. There is one part of the code where the extents and resolution are determined for downloading the image from the remote WMS server, and another part of the code that computes this info again before rendering the map. The LOAD_* processing options only affect the second part (post-download) of the computation. There is no option that I can see that affects the first part (pre-download) of the bounds computation. LOAD_WHOLE_IMAGE and LOAD_FULL_RES_IMAGE, as they are currently implemented, should be on by default when in WMS client mode. The reason is that since the desired extents and resolution have already been computed before downloading the image, there is no need to re-compute. Whatever was downloaded should be used in full. As for proj4, I was using 4.4.7. I'll try an upgrade.
comment:3 by , 20 years ago
Status: | new → assigned |
---|
No action on this required for the 4.4. release. I would note this is related to Wiki topic: http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?WorldMappingIssues
Note:
See TracTickets
for help on using tickets.
mapfile demonstrating problem.