-
Notifications
You must be signed in to change notification settings - Fork 229
UI hangs at mbtiles export when Source is non WGS84/web merc projection #1390
Comments
@andrewharvey generally speaking, all projections supported by proj4, should be supported by Mapbox Studio. When using shapefiles (for bigger data we recommend PostGIS) it really helps if you preprocess them before loading into Mapbox Studio. In particular, preprocess:
Here's a description on how to do it: #1200 (comment) I can replicate with Even just zooming or panning in Mapbox Studio source project crashes the whole application.
|
WGS84.shp was the one that works (so I could be sure it was the projection that was the issue). I didn't run into any crashes myself I could pan and zoom the Source. Yeah the workaround is to reproject, but this should probably be fixed within Mapbox Studio to either work correctly with data in this projection, or warn the user first that it's not supported/what the problem is. I forgot about shapeindex, thanks for the hint! (Hopefully when I include it in the shapefile ZIP uploaded to Mapbox for processing it's used) |
💯% agreed, we are working on it, but the problem is intermittent and we haven't been able to exactly pinpoint the real reason. |
The problem I described is repeatable and it seems from what I could determine that the reason is one line of code expects the coordinates to be in WGS84 but values are actually being provided in the native coordinate system, as I described. |
True, I've read your comment and appreciate your detective work, but the wrong coordinates really come from calling into proj4 via C++ in node-mapnik. For most of the cases proj4 is able to reproject, but for some unfortunately not, and then the original coordinates are returned. We were not yet able to pinpoint, what those some have in common and how to work around that, when calling into proj4 to do the reprojection. If you have any idea how to fix this properly in C++, a PR is more than welcome! |
I see, so in the ds.extent() call from ./lib/source.js you're saying these should be WGS84 rather than the same projection as the source SHP file? Just testing out mapnik with python here...
It seems the datasource is in NZMG and it's envelope() is reported in NZMG, and the reprojection happens when you set a different layer.srs. (again just my understanding from what I've read and tried out). Based on this within ./lib/source.js if we're getting the extent of the datasource why is it expected to be in WGS84, when it seems from the way the Mapnik API works it should be in NZMG (the projection of the datasource). Sorry if I've missed something, just trying to nail what's actually going on here. |
@andrewharvey @BergWerkGIS - thanks for the great, small testcase and the investigations. To confirm: @andrewharvey are you running Mapbox Studio My hunch is you are running from github as I can see that the bug you describe (not projecting source extents correctly into epsg:4326) likely happened in 823ffb9#diff-ae2e9ce210cf8e5e189658fb547ddc8a (which is still not in an official release). Before that change we were calling getCenterAndExtent from mapnik-omnivore here and via this require which correctly handled reprojecting the extent of a source into epsg:4326. |
latest from github
Oh yes, before you had getExtent(ds, l.srs) which must have gotten the extent of the datasource in the layer's projection, wonder why it was changed? |
capturing chat with @GretaCB - next actions:
|
@springmeyer Sure, it's public domain data. Thanks. |
FYI: I've noticed when adding the data in WGS84 and NZMG is doesn't align properly in Mapbox Studio. Manually adding |
Fix is merged to |
Reopening, not fully fixed until mapbox/mapnik-vector-tile#122 lands. |
@BergWerkGIS ticketed separately at #1395 |
Closing now. Thanks @andrewharvey @GretaCB @BergWerkGIS for all the testing and fixes! To recap:
|
In Mapbox Studio if I use a SHP file of a projection which isn't WGS84 / Web Mercator it seems to run into some issues exporting this Source to mbtiles prior to uploading to Mapbox.com. It may well be that using such a projection isn't supported but there are no warnings about this.
In fact the layer displays fine and I can even create styles from it without a problem.
I did some debugging and found that ./lib/source.js:311 was being reached as there wasn't any extent metadata present in the datasource. However, the ds.extent() as returned by the mapnik.Datasource object is [ 2035800, 5326900, 3016800, 6751400 ], which then becomes an issue down on line ./lib/source.js:323 where .min and .max between a projected coordinate system and a geographic coordinate system results in the extents becoming [ 2035800, 5326900, 180, 85.0511 ]. Which then seems to correctly throw an error that "bounds south value must be less than or equal to north" at ./lib/tilelive.js:245 but the user interface just sits there.
The two source files I used to test this are at http://tianjara.net/hosted/nzcoastline/
I'm not sure what fix you want to implement, but either way currently it just hangs at 0.0% when generating the mbtiles for upload.
The text was updated successfully, but these errors were encountered: