Crop again

[rclark]

A bunch of changes:

• gets rid of the callback pattern, because everything here is synchronous anyways. This means we drop all the try/catch statements and expect the caller to implement them as they see fit
• geometry.transformTo(SRS) cannot perform transformations between reference systems based on different datum -- for example this function can't transform data in a state-plane SRS using NAD83 to spehrical mercator which uses WGS84. So the PR switches to using geometry.transform(gdal.CoordinateTransformation) which supports datum transformations.
• re-implements cropping with caveats:
  • creates the world boundary in epsg:4326, then attempts to transform it into the file's native spatial reference
  • if this transformation fails, that likely means the world boundary is outside the bounds of the native SRS. In this case, no cropping is done. Otherwise, it crops with the same intersection logic that was there before.
• adds a test script to run reprojection on every shapefile in mapnik-test-data. This helps us cover a slightly broader range of scenarios than we were covering before.

Question: Cropping presents a scenario where a feature might fall entirely outside the bounds of the target SRS. In this case, we have to decide if we should drop the feature out of the output shapefile, or if we should keep the feature, but set its geometry to null. As written right now, this PR drops the feature out. Is this the right behavior?

cc @GretaCB @BergWerkGIS

[wilhelmberg]

As written right now, this PR drops the feature out. Is this the right behavior?

Yes, I dare say so. If the feature is out of the +/-85.xxx bounds it cannot reasonably be displayed with Web Mercator anyway. If anybody wants to display data close to or on the poles they have to look for other solutions.