mvt.PrepareGeometry (and mvt as whole) was written to be srid agnostic, but the follwing lines would fail in the edge case that the projection had axis oriented differently from the common web mercator and lat/longs, such as:
These types of coordinate systems are also refered to as Lo coordinate systems.
The following lines are relevant the mvt code:
https://github.com/go-spatial/geom/blob/f76f5a146183cad0c5d8653fd20e07c5db52b934/encoding/mvt/prepare.go#L66-L67
However, I think the change would need a new or re-designed types. One thing that comes to mind is tweaking the Extent elements to be left, top, right, bottom instead of min/maxX/Y. This would not require any changes under our current assumptions in tegola of only using epsg 3857 and 4326.
Here are some relevant links to discussions on this topic:
mvt.PrepareGeometry(and mvt as whole) was written to besridagnostic, but the follwing lines would fail in the edge case that the projection had axis oriented differently from the common web mercator and lat/longs, such as:epsg:2053epsg:22385These types of coordinate systems are also refered to as Lo coordinate systems.
The following lines are relevant the
mvtcode: https://github.com/go-spatial/geom/blob/f76f5a146183cad0c5d8653fd20e07c5db52b934/encoding/mvt/prepare.go#L66-L67 However, I think the change would need a new or re-designed types. One thing that comes to mind is tweaking theExtentelements to beleft,top,right,bottominstead ofmin/maxX/Y. This would not require any changes under our current assumptions in tegola of only using epsg 3857 and 4326.Here are some relevant links to discussions on this topic:
https://community.esri.com/thread/185667-why-is-the-projection-upside-down https://isis.astrogeology.usgs.gov/IsisSupport/index.php?topic=370.0 http://www.ngi.gov.za/index.php/technical-information/geodesy-and-gps/datum-s-and-coordinate-systems