Hi Flo, On May 25, 2011, at 3:00 AM, Flo Ledermann wrote:
> Hi all, > > I want to use mapnik for rendering whole world images with different > projections. I know this is not what mapnik is mostly used for... but I > guess it should work nevertheless. It should, yes. Thanks for getting in touch on this. > > I was experiencing some truncation of polygons towards the borders in > non-rectangular projections (like for example Robinson > projection) in Mapnik 0.7.0 By this do you mean the seemingly straight lines along the dateline on the right? I think reason that the left edge looks properly curved is that the shapefile has a high density of vertexes on the left side of the ocean polygons. The remaining edges (including the right side) lack vertexes, so when reprojected they continue to look straight. There is a sample script the gdal project provides to add vertexes that you might try: http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples/densify.py > , so I put my hopes in building from trunk as > I saw there was some clipping-related work going on there recently. Right. If you were hitting a problem then trunk should provide more options to fix it. But yes, the defaults in trunk now are a bit more brittle (but also more performant and flexible) until you provide the right options. > Much > to my surprise *it got much worse* in the trunk version, truncating > polygons heavily on both sides of the globe. Yes, this is because the move to clipping by the map extent means that you have one place (the map srs/bounds) to fix/handle out of bounds issues, but left unhandled very small bbox queries may be sent to the layer datasources which leads to very reduced features. I realize that you did not expect to have to "fix" them when upgrading and that this regression may be annoying, but I feel like it is an improvement both for reprojected and non-reprojected cases. And there are three solutions to quickly fix: 1) As you noticed you can set the map.maximum_extent. But this extent must be in the bounds of the map srs. So, in your case you need to do: robinson_bounds = _get_projected_bounds(output_projection, bounds=bounds) mmap.maximum_extent = robinson_bounds mmap.zoom_to_box(robinson_bounds) 2) Still, there is an even easier solution (which I need to document on the wiki better). It is that you can request that proj4 do sane things when out of bounds coordinates are passed and properly wrap them. Do do this add the: +over parameter to your proj4 string. This should fix things even without the use of maximum_extent. This proj4 parameter has no known harm so I recommend *always* using it. The cool thing is that it also can be a valid modifier if the proj4 srs is created via an epsg code. So both this: +proj=robin +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs +over and this: +init=esri:54030 +over are valid robinson definitions that both contain +over and will behave the way you expect. 3) The third option is to apply this patch: http://trac.mapnik.org/ticket/751. But, I do not wish to use this, at least for the mainline rendering in feature_style_processor.hpp, because it can slow down multithreaded servers slightly. Can you tell top performance is on my mind? So, I would recommend #2, and then the mapnik2 image should render just like mapnik 0.7.x (but a bit faster if it were being rendered under high load). Dane _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
