Projection and Datum

[thesteve0]

Would be nice to write the projection and datum to the GeoJSON file (EPSG code would be sufficient)

[calvinmetcalf]

I'd actually suggest by default re projecting to wgs84, 99% of geojson use cases are going to probably want that projection, you can specify the projection as the 3rd argument to the row cursor.

[feomike]

good idea on this one; will work it in at some point.

[calvinmetcalf]

so it now does automatically convert it to wgs84

[feomike]

this (autoproject if not in wgs 84) is in the code base that we merged in this week, right calvin?

[calvinmetcalf]

yes

[feomike]

sweet, nicely done. for some reason, i didn't pick that up.

[scw]

@calvinmetcalf has included some more thoughts about projection which are worth looking over. My preference is that we have a selector for projection, which defaults to WGS-84, but allows them to optionally retain the current projection when possible. GeoJSON isn't explicitly limited to geodesic coordinate spaces, and our tool should reflect this. If they're doing simple things like measuring area, or for example using @sgillies excellent Shapely to perform meaningful operations like buffering, they will likely want to operate on projected coordinates. I see why reprojecting to WGS-84 is useful in many cases, but don't think it should be the exclusive output format.

[maphew]

+1 @scw, default of wgs84, while allowing others (and always explicitly naming which it is).

[calvinmetcalf]

So a couple things:

• I chose wgs84 as it is neutral it works everywhere
• there are definitely times where projecting causes problems I think they are outweighed by the headaches that not projecting causes.
• the advantages of a crs disappear when you combine it with other data
• using a named crs pretty explicitly means this will not just work you'll have to consult a lookup db somewhere.
• spatialreference.org is the only lookup db I know of and it's not actively maintained
• the more buttons and knobs the higher the chance that someone chooses wrong
• all the (practical) advantages of a crs can be gained by the user projecting it themselves
• I don't see government organization putting out two versions of the data but even if they did would you download geojson in Alabama state plane feet over wgs84?

[calvinmetcalf]

Is it possible to get an auth number through arcpy?

We have only really been talking about projections for geojson data (horrible idea) but not projections for .sqlite data or csv/json wkt.

[scw]

I guess part of this discussion should be oriented around what the primary purpose of the tool is: is it to get data out in these formats in a simple to use form for consumption in environments which rely exclusively on geographic coordinates? Is data exchange the primary goal, or will folks also use these outputs as their data storage format? Some scoping will probably help identify the appropriate approach to moving the tools forward.

I think you're right to separate out the issues of CRS for GeoJSON: it is a specific subcase that should be handled separately. Because the specification mentions named lookups, it will be more tricky to implement and may fall out of scope. That said, I think it's preferable to handle the unlinked version elegantly, and at least provide a way to write out the correct EPSG code where possible. GDAL/OGR is perhaps our benchmark implementation of data translation, and it does this: defaults to WGS84, where it writes out urn:ogc:def:crs:OGC:1.3:CRS84, but otherwise does an EPSG lookup. To get EPSG codes from ArcGIS, see this question on GIS.SE.

For other data types beside GeoJSON, I think it's even more important to retain data fidelity (or at least provide a mechanism to do so). SQLite / SpatiaLite natively supports arbitrary projections, and it looks like the code already adds a value for WGS84 if needed, which I imagine could be extended. Similarly, OGR can write out WKT text into CSVs, and doesn't directly rely on the output stream being WGS84.

I think I hear you saying that the use case is an organization, say local government, using this tool to export the data to an interchange format that can be consumed by others easily. But I think it's also worth recognizing that their might be users who want to interoperate with others, and use these output formats as a data format for storage, and retain projection information could be useful to this latter group. In an ideal world, I'd probably want to see the hypothetical data provided in two formats: WGS84 and the native format, so that if I was doing analysis I could get the real geometries, at their native precision, and also an easy to use geographic version.

[calvinmetcalf]

I think highlighting interchange vs storage is key, putting in a selector that defaults to wgs84 but also has a no change and a custom selection might work especially if, like the geometry selector, it's ignored with formats that don't support it.

[calvinmetcalf]

I broke this out into its own tool