Opened 23 years ago

Closed 23 years ago

#16 closed defect (fixed)

Quebec separated from Canada (!!!)

Reported by: dmorissette Owned by: warmerdam
Priority: high Milestone:
Component: WMS Server Version: 3.5
Severity: normal Keywords:
Cc: mcilhagga@…

Description

This is not a political post... but the above WMS URL does not seem consider 
Quebec to be part of Canada any more! :)

Actually, what happens is that with an image size of 300x300, Quebec and the 
Maritimes are gone, but if you change the size to 600x300 then all the provinces 
are fine.  Interesting!?!??!?!

Attachments (1)

mswms_gmap.gif (977 bytes ) - added by dmorissette 23 years ago.
Image produced by this bug's URL and showing the problem

Download all attachments as: .zip

Change History (6)

by dmorissette, 23 years ago

Attachment: mswms_gmap.gif added

Image produced by this bug's URL and showing the problem

comment:1 by jdoyon@…, 23 years ago

I just noticed this on my end as well (Daniel and I use the same data).

I'm not sure, my memory could be failing me, but I *think* this started 
happening when I updated my code from the CVS today, my previous MS3.5 was from 
a couple of weeks ago ... Maybe changes that occured in the mean time caused 
this ?

That's one possiblity, but I also noticed that they disappear only when 
reprojecting, and then, only certain projections.  If i do a very simple OGC 
call (?wmtver=1.0.0&request=map) with any size, the missing provinces are 
allways there. When I reproject using an OGC client using EPSG:4326, then 
Quebec and Maritimes are missing, BUT, if I reproject to EPSG:42101 (WSG 84 / 
LCC Canada), then the provinces show up fine ...

Hope this helps...

comment:2 by fwarmerdam, 23 years ago

Owner: changed from morissette@… to fwarmerdam

comment:3 by fwarmerdam, 23 years ago

Status: newassigned

comment:4 by fwarmerdam, 23 years ago

In maputil.c:msDrawLayer() (and presumably it's analogs) the following
call is done to transform the latlong region of the map into the projection
of the layer (LCC).  I think this transformation is operating very poorly
because the lat/long region is so unreasonable as input to the LCC reprojection.

  if((map->projection.numargs > 0) && (layer->projection.numargs > 0))
    msProjectRect(&map->projection, &layer->projection, &searchrect); // projec

(gdb) p map->extent
$19 = {minx = -179.40000000000001, miny = -179.40000000000001, 
  maxx = 179.40000000000001, maxy = 179.40000000000001}
(gdb) p searchrect
$20 = {minx = -2306170961.9598298, miny = -566618157.16840172, 
  maxx = 3.1311206780778273, maxy = 4642261.9173844298}
(gdb) 

Some shapes are failnng the subsequent test against searchrect, including 
Quebec, and Greenland.



On review of msProjectRect(), a good deal of effort is expended to 
compute a bounding rectangle that is likely to be OK.  A sampling
of points around the edge are used, not just the corners. 

However, it doesn't account for the fact that pj_transform() can fail
for illegal points, and so the bounds are not well computed.  All the top and
bottom edges have no useful effect (but are misconstrued as being small values
since the failure of pj_transform() is not detected).  The right side points
are projected to have large negative x values which is reasonable.  The
problem is that we don't do points through the center that can approach the
right edge in a valid region, getting a properly MAXX value. 

One possible solution is to to the current sampling all through the rect
not just along the edges but this will substantially increase the computational
cost.  Perhaps this would just kick in when a transform fails. 



comment:5 by fwarmerdam, 23 years ago

Resolution: fixed
Status: assignedclosed
I have fixed the bug by improving msProjectRect()'s ability in the face
of some points failing to reproject. 

msProjectPoint now returns MS_FAILURE if transform fails.
msProjectRect now deals with failure to reproject some points, and samples
through the middle of the rectangle if there are any failures.

Note: See TracTickets for help on using tickets.