Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Empty rendering of carto js produced open-streets-dc xml #1473

Closed
rundel opened this Issue Sep 7, 2012 · 6 comments

Comments

Projects
None yet
2 participants
Contributor

rundel commented Sep 7, 2012

Not sure if this is more appropriate as a carto issue or mapnik issue.

If I generate an xml stylefile for open-streets-dc using an up to date install of carto js and attempt to render it using nik2img or my minimalistic C++ renderer I end up with a completely blank image as output. Rendering open-streets-dc works fine from within Tilemill.

This used to work without any additional worry about zoom level or bounding box when I was testing for compatibility between the carto implementations. Likely I am missing something simple.

nik2img verbose output is below:

Step: 1 // --> Nik2img starting...
Step: 2 // --> Format: png
Step: 3 // --> Loading mapfile...
Step: 4 // --> Loaded test.xml...
Step: 5 // --> Setting Map view...
Step: 6 // --> Zoom to extent of all layers: "Box2d(-30056262.51,-20037508.34,30056262.51,20037508.34)"
Step: 7 // --> Finished setting extents...
Loading map took...  0.1441 seconds
Step: 8 // --> SRS: +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over
Step: 9 // --> Map extent: Box2d(-30056262.51,-20037508.34,30056262.51,20037508.34)
Step: 10 // --> Map long/lat bbox: Box2d(-269.999999962,-85.0511287776,269.999999962,85.0511287776)
Step: 11 // --> Map center: Coord(0.0,0.0)
Step: 12 // --> Map long/lat center: Coord(0.0,0.0)
Step: 13 // --> Map scale denominator: 357812648.929
Step: 14 // --> Extent of all layers: Box2d(-8584936.07589,4691869.09667,-8561639.82286,4720949.89071)
Step: 15 // --> Long/lat extent of all layers: Box2d(-77.1197929016,38.7916365864,-76.9105191,38.9949616)
Step: 16 // --> Long/lat center of all layers: Coord(-77.0151560008,38.8932990932)
Step: 17 // --> Layers intersecting map: [dcgis-water, natural, highway-outline, highway, location, highway-label]
Step: 18 // --> At current scale of '100187.5417'...
Step: 19 // --> Layer 'dcgis-water' has 1 active rule(s) in styles: ['dcgis-water']
Active rules: ''
Step: 20 // --> Layer 'natural' has 2 active rule(s) in styles: ['natural']
Active rules: '', ''
Step: 21 // --> Layer 'highway-outline' is NOT visible
Step: 22 // --> Layer 'highway' is NOT visible
Step: 23 // --> Layer 'location' is NOT visible
Step: 24 // --> Layer 'highway-label' has 9 active rule(s) in styles: ['highway-label']
Active rules: '', '', '', '', '', '', '', '', ''
Step: 25 // --> Starting rendering...
Rendering image took...  1.0171 seconds
Step: 26 // --> Finished rendering map to... test.png
Total Nik2img run time: 1.5934 seconds
Contributor

rundel commented Sep 7, 2012

Does appear to be a bounding box / zoom level issue, since if I hard code the extent from step 14 I get a proper rendering. Any idea of what changed in mapnik or nik2img to cause this change in behavior?

Owner

springmeyer commented Sep 7, 2012

I can take a look. What what the exact commands you used?

Contributor

rundel commented Sep 7, 2012

nik2img.py -v test.xml test.png where test.xml is the output from carto.

Owner

springmeyer commented Sep 7, 2012

Okay, I see the problem. Carto recently started setting the maximum-extent of the map (mapbox/carto#43) simply as a way to reduce potential mercator clipping issues. It appears there is a bug in mapnik whereby when this is set it is used at the map extent somehow, instead of simply being used to limit the extent (if larger).

Owner

springmeyer commented Sep 7, 2012

ah, ha, its always been this way: 8998296#L3R363. So, yeah, the reason I thought that was a good idea is because some layers (if in non-mercator projections) can easily end up not being able to be projected into mercator and that is a case where setting the maximum-extent is valuable - to allow zoom_all to actually work again instead of resulting in an uninitialized box2d. But, this likely needs a better approach.

Owner

springmeyer commented Sep 7, 2012

thanks for this report! should be fixed in 0de2bea.

springmeyer pushed a commit that referenced this issue Sep 12, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment