Opened 15 years ago
Closed 15 years ago
#2844 closed defect (fixed)
msProjectRect return value not checked
| Reported by: | pramsey | Owned by: | pramsey |
|---|---|---|---|
| Priority: | normal | Milestone: | 5.6 release |
| Component: | MapServer C Library | Version: | unspecified |
| Severity: | normal | Keywords: | projections |
| Cc: | warmerdam |
Description
Right now, in mapdraw.c and mapraster.c, when msProjectRect is called to move the draw rectangle into the source projection, the success of the operation is assumed. However, for data sources in incompatible planar projections, far from the draw rectangle, the projection operation will fail completely: no good points will be returned.
Right now the behavior is to fall back to basically make a rectangle in the source projection that covers everything (-180,-90 180 90) for latlong, (-22000000,-11000000 22000000,11000000) for planar. For data sources like huge tileindexed raster layers, this is... painful indeed. Instead of no-op on a layer which is basically guaranteed to not be in the output, we check the complete contents.
Attachments (1)
Change History (4)
comment:1 by , 15 years ago
| Cc: | added |
|---|---|
| Keywords: | projections added |
by , 15 years ago
| Attachment: | msprojectrect1.patch added |
|---|
comment:2 by , 15 years ago
comment:3 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
The solution suggested in my previous comment was in fact implemented, I am closing this ticket.
It might be better to move the solution to this problem up a level, and at the start of a layer draw, pull both the source and destination rectangles into lonlat, and compare them for intersection there. That would be guaranteed to work and more aesthetically pleasing than assuming that a dest->source projection failure implies either 100% coverage (current assumption) or 0% coverage (my patch assumption).