Opened 16 years ago

Last modified 16 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:


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) (615 bytes) - added by fwarmerdam 16 years ago.
mapfile demonstrating problem. (734 bytes) - added by fwarmerdam 16 years ago.
Perl mapscript script to demonstrate problem?
quickfix.diff (3.3 KB) - added by fwarmerdam 16 years ago.
One potential solution

Download all attachments as: .zip

Change History (6)

Changed 16 years ago by fwarmerdam

Attachment: added

mapfile demonstrating problem.

Changed 16 years ago by fwarmerdam

Attachment: added

Perl mapscript script to demonstrate problem?

Changed 16 years ago by fwarmerdam

Attachment: quickfix.diff added

One potential solution

comment:1 Changed 16 years ago by fwarmerdam


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 Changed 16 years ago by dstahlke@…

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 Changed 16 years ago by fwarmerdam

Status: newassigned
No action on this required for the 4.4. release. 

I would note this is related to Wiki topic:

Note: See TracTickets for help on using tickets.