Skip to content

Corrupted image on raster edges near -180 or 180 longitude #1550

Open
nextstopsun opened this Issue Oct 29, 2012 · 14 comments

2 participants

@nextstopsun

Image gets corrupted near left or right edge when rendering a -180 to 180 longitude raster in EPSG:3857 Web Mercator projection.

Mapnik config:
https://gist.github.com/3977161

Data to reproduce:
http://db.tt/spGl43uC

I have a working ogcserver with this issue, and I can PM a url.

@springmeyer
Mapnik member

what is a bounding box that triggers the issue?

@nextstopsun

In example this one:
15111499.456594,-3775246.650710,19994525.807835,4348070.064023

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

@springmeyer
Mapnik member

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

I get:

@nextstopsun

Installed nik2img.
Running the above command I get a message:

display: unable to open X server `' @ display.c/DisplayImageCommand/420.

@springmeyer
Mapnik member

thats fine, it is just failing to auto-open the image in your default viewer. Can you post the image?

@nextstopsun

Yep. http://db.tt/1MCjsQpW
All clear.
So if it's ogcserver-specific, how come there is the same issue in MapProxy?
And is there a workaround?

@springmeyer
Mapnik member

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?

@nextstopsun

Did that. I have a clear render identical to the first one made with nik2img - no errors.

@springmeyer
Mapnik member

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.

@nextstopsun

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?

@springmeyer
Mapnik member

no, do not append +init=epsg:3857 to the srs value, do: srs="+init=epsg:3857"

@nextstopsun

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?

@springmeyer
Mapnik member

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.

@nextstopsun nextstopsun referenced this issue in mapproxy/mapproxy Oct 30, 2012
Closed

Problem with mapnik rendered rasters #40

@springmeyer
Mapnik member

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.