Agreed. My preference would be to skip exporting any data we've determined - by whatever means - to be 'bad'. This is a lot safer than trying to massage it to be 'less bad', and it will be less a show-stopper than aborting the entire export.
How best alert the user can probably be dealt with separately; at a minimum, the number of submissions after an export will be less than number before (ie the count in the DB), so at least there's a reliable indication that something is probably 'bad' somehwere...
Could you say something about your data, like how many features you've exported, where they all points, line strings, polygons, etc.? This will help us know what's tested and what's not so far
I exported a test polygon and it also included a point. So I used geopoint and geotrace. I even used geotrace with an extra long field of 15999 characters. Then I moved it to QGIS, and that reads the GEOJSON well. Then from QGIS to KML and into Google Earth. Works well. I will do some more testing later on. I want to verify if all polygon nodes (with fields more than 255 characters) are being exported well. I'll let you know.
Adding that would involve using the custom library we talked about to have the accuracy Foreign Member added to each point.
It's not clear how that would work on GEOTRACE and GEOSHAPE field types.
We could set the accuracy to an array of values
An older GeoJSON spec allowed for extra additional elements in the positions array (coordinates) but they recommend to avoid doing that in the current specs.
Even if we decided to ignore the recommendation and add an additional element with the accuracy, there's no guarantees that any GIS client would interpret it correctly since it's out of spec.
I've also searched the IETF workgroup mail archive in search for answers on why not supporting the accuracy of points:
There's an argument for making GeoJSON files as small as possible (no accuracy means smaller files)
It's hinted that there should be a relationship between accuracy and decimal places in coordinates, although I'm happy that didn't get to the RFC because it's kind of crazy.
Somewhat of an aside, but this is actually not an unusual convention in scientific measurement. Basically, its only meaningful to report as many decimal places as the accurary of your measurements imply. Or more formally:
...the number of significant figures should not exceed the maximum precision allowed by that sample size.
Which is a bit like saying, if you pace out a distance of 20m - where your stride is approx 1m - you shouldn't then report it as "65.617 feet" (20m = 65.6168') because by doing so you are rather mis-representing the implied accuracy of your original measurement to be within 0.2mm (0.0005 feet), which obviously its not.
Yeah, of course I generally agree, but on this context, it would produce all kind of crazy results.
GPS devices use error correction and interpolation all the time to deal with low accuracy situations (meaning that they can give a pretty good position and report bad accuracy nevertheless). I don't think tampering with the original coordinates is a good idea...
There's the issue about the grid's resolution, which is not linear (meters per degree). A .001 longitude difference doesn't represent the same on the North Pole and over the equator.
Also, using the accuracy to "snap" positions into their most reasonable (accurate) coordinates would introduce significant changes to the relative speed between pairs of points, which could be important to some applications that focus on movement rather than position (vessels on the sea, cars on the road, etc.)
I'm afraid I can't help you on how to read GeoJSON files in Python. I imagine there is a range of libraries that you could use for that but, in any case, I think that's kind of off-topic in this forum.
