#411 closed defect (fixed)
Clipping issue wth ortho projection.
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | MapServer CGI | Version: | 4.0 |
Severity: | normal | Keywords: | |
Cc: | tylermitchell@… |
Description
When a latlong shapefile is projected using orthographical projection, mapserver does not handle the edge clipping correctly, projecting the points at 0,0 rather than hiding them. It looks like the problem in this case is with the polygons that are half visible and half invisible. The invisible vertices appear to be all substituted with (0,0) coordinates. http://www.scriptsupport.co.uk/images/mapserv.png http://www.scriptsupport.co.uk/images/mapserv2.png http://www.scriptsupport.co.uk/images/mapserv3.png http://www.scriptsupport.co.uk/downloads/mapserver.zip contains a zipfile with the world shapefile, the test1.map mapfile. the shp2img args I used were; shp2img -m ./test1/test1.map -o C:\test.png but that will obviously depend on your system.
Attachments (1)
Change History (7)
comment:2 by , 21 years ago
Status: | new → assigned |
---|
OK, lots of progress. The problem is that msProjectShape() in mapproject.c ignores whether or not each of the points in the shape project successfully. Points over the horizon were getting converted from lat/long to radians by pj_transform(), but then the actual reprojection failed so pj_transform() returned the radian value which was treated as projection coordinates (almost 0,0 since radian values are very small). But nothing "above" this in MapServer paid any attention to whether the reprojection succeeded, so the shapes would be plotted with some or all the vertices nearly at 0,0. Polygons completely over the horizon were drawns as a point at 0,0. Polygons partially over the horizon would just have some points approximately at 0,0 resulting in the ugly wedges seen in the sample image. I have modified msProjectLine() and msProjectShape() to return MS_FAILURE if any of the points fail to reproject. However, in msDrawShape() where msProjectShape() is called, it isn't so obvios what should be done. If I return MS_FAILURE then the whole layer drawing aborts and no shapes are drawn, but an error is generated. If I just stop drawing the shape, and return MS_SUCCESS then the map drawing works, *but* any polygons with even a few vertices over the horizon is dropped completely. I have attached a PNG of this result to show unsatisfactory it is. Now I wonder if there is any reasonable way to handle drawing of polygons that go over the horizon. I can't think of a way ... it's almost like we need to ask PROJ.4 to return a point "on the horizon" for such polygons. Another alternative might be to split big polygons into small chunks so that not much would be visibly lost on the horizon. Split polygons into 1degree by 1degree chunks for instance. I am interested in other thoughts. For now I am committing changes to mapproject.c to return MS_FAILURE from msProjectLine() and msProjectShape() if any point fails to project. In this situation the points of the line or shape will be indeterminate.
comment:3 by , 19 years ago
Cc: | added |
---|
comment:4 by , 19 years ago
I have modified msProjectShape() to remove unreprojectable lines. If no lines are left in the shape, then the shape is "nulled" using msFreeShape(). ... Still need to complete the main work items of RFC 5.
comment:5 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I have committed changes in CVS to split lines as they cross the horizon and to clip polygons. The specification is in RFC 5: http://ms.gis.umn.edu/development/rfc/ms-rfc-5 Note that contrary to the RFC, polygons rings are currently never split. A few other caveats are covered at: http://home.gdal.org/~warmeda/reproject/ The changes are in 4.7 only and are too complex to contemplate porting back to 4.6.x.
Note:
See TracTickets
for help on using tickets.