Image gets corrupted near left or right edge when rendering a -180 to 180 longitude raster in EPSG:3857 Web Mercator projection.
Data to reproduce:
I have a working ogcserver with this issue, and I can PM a url.
what is a bounding box that triggers the issue?
In example this one:
Got it from ogcserver logged request:
GET /?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&BBOX=15111499.456594,-3775246.650710,19994525.807835,4348070.064023&SRS=EPSG:3857&WIDTH=414&HEIGHT=689&LAYERS=sfc&STYLES=&FORMAT=image/png&DPI=72&TRANSPARENT=TRUE HTTP/1.0
Okay, one thing to realize is that reprojection is likely being forced because OGCServer is setting the map srs to +init=EPSG:3857 on the fly. So, let's remove OGCServer for the moment.
What do you get if you install nik2img.py and run:
nik2img.py sfc9.xml issue_1550.png -e 15111499.456594 -3775246.650710 19994525.807835 4348070.064
023 -d 414 689
Running the above command I get a message:
display: unable to open X server `' @ display.c/DisplayImageCommand/420.
thats fine, it is just failing to auto-open the image in your default viewer. Can you post the image?
So if it's ogcserver-specific, how come there is the same issue in MapProxy?
And is there a workaround?
now try adding +init=epsg:3857 for the map srs value. Then re-run the nik2img.py command. (also make sure to get the right dimensions to match your wms request). Do you then see the same problem?
Did that. I have a clear render identical to the first one made with nik2img - no errors.
Hrm, curious. I would have assumed that setting +init=epsg:3857 would break things. Even though that is essentially the same projection as the longform proj4 string it would still trigger the raster reprojection code and could lead to this issue.
So, not sure what is happening. Are you positive that your OGCServer is configured with the exact same XML you have posted here?
One thing you could try would be to go into the OGCServer code and find the in-memory map object and print it to stderr with mapnik.save_map_to_string(m) and see if something is different about the map that OGCServer knows about.
I've double checked the xml, that I'm serving - I'm positive on that.
The only way nik2img breaks is when I set
srs="+init=epsg:3857 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +over +no_defs"
for a layer tag also.
When +init=epsg:3857 is added only to a Map srs - everything's ok.
How can I run ogcserver in a debug mode to enter python commands while executed?
no, do not append +init=epsg:3857 to the srs value, do: srs="+init=epsg:3857"
Dane, thanks a lot - I guess that nailed it. I'm not sure yet, but I don't get corrupt edges anymore when serving with ogcserver. I have to test it further with different bboxes for nik2img and mapproxy conf.
Hmm so where's the catch? It consideres +init=epsg:3857 and +proj=merc.... as different projections?
yes, +init=epsg:3857 and +proj=merc.... are not equivalent strings, and so this code path (https://github.com/mapnik/mapnik/blob/master/src/agg/process_raster_symbolizer.cpp#L92-101) will be followed. If this is happening ( and I presume it will be happening based on the way ogcserver works) then we can isolate the bug to mapnik's raster reprojection. And then the workaround would be to hack (or fix) would be to fix either mapnik or ogcserver to try to prevent this code path from happening and prevent reprojection from happening - assuming that we do not seem the problem with the non-reprojected case.
@nlebedev - is this still a problem at all. Can you re-test all scenarios with latest mapnik master as there have been a few more raster alignment fixed landed?