ByronCinNZ
commented
11 months ago This email explaining finding to Andrew -
So in this sample data the coordinate order is expressed in long/lat and the coordinate system is stated to be EPSG:4167 : "points": [ { "id": "BoundaryMarks", "type": "FeatureCollection", "featureType": "SurveyPoint", "features": [ { "id": "1725787", "type": "Feature", "featureType": "BoundaryMark", "time": null, "geometry": { "type": "Point", "coordinates": [ 174.7501603083, -36.9307359096 ] },
This would be correct because it is a geometry object in a GeoJSON file
But I would argue that this is not where we should place coordinates in the stated CRS. On EPSG.io, the description of 4267 says:
Coordinate system: Ellipsoidal 2D CS. Axes: latitude, longitude. Orientations: north, east. UoM: degree
So when we apply the conversion in PanCadastre it flips it again because it assumes these point values to be in the stated projection.
In my opinion, the geometry object should never be populated with anything but GeoJSON approved values in long/lat 4326. This leaves open the question of, “where do we point the surveyed values for points in their stated projection?” We need a separate element for survey point coordinate values because we otherwise would be required to overwrite these with the output from PanCadastre.
Could we use a topojson approach and create an array of point values in the original crs that we reference in a topology section under points? Or maybe populate a topology object for points with these surveyed values? This latter option would mean we have a a “coordinate” element option for topology that would hold these values.
Actually, as I think about it, maybe we should be using json-fg. The “place” object exist just for his purpose.
Flipped coordinate order on output has been observed in some cases. Investigate and make recommendations . In part this is a result of using GeoJSON as a data format and may be limited to this encoding.