[wip] Even more crop

[rclark]

So far what I've done here is to make it so that cropping only occurs if the original SRS is WGS84. This gets us out of traps where the original SRS doesn't have a cartesian "extent" that we can project [-180, -85.05113, 180, 85.05113] into (e.g. a lambert conformal conic projection). Apologies, I'm having trouble really articulating what this problem is...

I also added more tests to compare the outputs from node-wmshp against outputs from ogr2ogr. All the tests pass except for the one where the input is Antarctica in a polar stereoscopic projection. What this case represents is one where the source data falls outside the EPSG:3857 boundaries, but the source SRS is not WGS84. In this case we fail with:

Error: Full reprojection failed, but partial is possible if you define OGR_ENABLE_PARTIAL_REPROJECTION configuration option to TRUE

I did this to represent the consequence of only cropping when the source is WGS84. The next step is to determine how to handle this scenario.

cc @BergWerkGIS @GretaCB

[wilhelmberg]

I would suggest the following:

Either check what the most common uploaded coordinate systems are, that fail and prepare clipping for them. Or wait till one fails and then create the clipping procedure for it.

Clipping procedure meaning:

• reproject the WGS84 bbox to that other needed coordinate system
• use the reprojected bbox for clipping before reprojecting the data to WebMercator

Illustration how that bbox woud look like in different coordinate systems:

WGS84 BBOX (+-180/+-85) displayed in WGS84

bbox displayed in WebMercator

bbox displayed in Van der Grinten World 1:

WGS84 with more vertices along the borders in Van der Grinten:

[rclark]

Right, so you're suggesting a whitelist of reference systems that we're comfortable clipping. If we do this, do we set OGR_ENABLE_PARTIAL_REPROJECTION and allow shapefiles with non-whitelisted SRS to get through?

Clipping procedure meaning:

• reproject the WGS84 bbox to that other needed coordinate system
• use the reprojected bbox for clipping before reprojecting the data to WebMercator

This is what I was doing before, and what I found was that when reprojecting the WGS84 bbox into some other systems, I got bad results -- the example I was tinkering with was http://spatialreference.org/ref/esri/102004/. Do you have any good explanation of what the problem is I am encountering?

[rclark]

@BergWerkGIS this most recent commit:

• bounds.js takes the coordinates representing the world bbox in WGS84 and presents them in WKT
• index.js uses this WKT to create a gdal.Geometry
• that geometry is projected into the shapefile's SRS, the output is validated, and simplified with zero tolerance to remove any duplicate coords. If, after that step, the geometry is still invalid, we give up on clipping.
• individual features are clipped using this geometry

At this point all the tests pass which compare the node-wmshp output to an ogr2ogr output (same extent and feature count), except for the case of Antarctica in a stereoscopic projection. In this scenario, the clipping step completely eliminates the geometry, and the node-wmshp result has no features in it.

[rclark]

https://github.com/mapbox/node-wmshp/commit/4d54b4d4d945e2eb79eb5ff70c62f14ede83bff6 checks if the input geometry is valid (this antarctica case is not !!) and runs geom.simplify(0) on it. This gets me a step closer to passing the test -- the feature is no longer dropped out entirely. Instead the feature's envelope is a little bit off from what I got using ogr2ogr. Close!

[rclark]

The problem with reprojecting a cropped, stereoscopic representation of Antarctica is that it crosses the dateline. What is a single polygon originally actually needs to be split into a multipolygon after reprojection.

Not splitting the polygons means that we end up with a single self-intersecting polygon that looks kind of "inside-out" when rendered (arrows show the order of vertices)

My takeaway is that we've solved the cropping problem here, but in the meantime we've uncovered a dateline issue.

[wilhelmberg]

Hm, strange, for me the clipped and reprojected Antarctica looks like this:

ogr2ogr has the flag wrapdateline which splits geometries crossing the dateline meridian. Maybe node-gdal implements a similiar function.

[rclark]

I suspect you and I are clipping the polygon at different latitudes, which would explain why your example has lost the "tail" seen in the stereoscopic image.

I took stab at splitting along the dateline and, well... it is non-trivial

• you have to take a different approach for lines than you do for polygons
• reprojection of coordinates that were clipped at, and hence fall on or very near the dateline can result in rounding discrepancies where the majority of coordinates in a geometry are, say, +180 and then a single outlier ends up at -180.