This makes sense to me. It seems there's consensus and it's also easier for us to start by omitting invalid data. I'll update the TSC roadmap issue.
I've just pushed a PR with a working version of the new GeoJSON export type for Briefcase. If you want to try it, you can use this JAR file: https://github.com/opendatakit/briefcase/files/2499280/briefcase-geojson.jar.zip
Any feedback will be very valuable! You can write it directly to the PR: https://github.com/opendatakit/briefcase/pull/669
Export polygon from Aggregate
I tried the tool and it seems to work perfect! You saved me! Many thanks for your great work!
That's great to hear, @Eddy_Rellum! Thanks!
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.
Awesome! Thanks for the feedback
@ggalmazor I just had a late minute idea and I'm curious if it's easy to add. If it is, great, if not, we can/should punt for later.
We generally have accuracy and altitude in the data, right? That data is very useful for filtering bad data in downstream tools. Is it possible to add both as keys? Something like https://github.com/geojson/geojson-spec/issues/4#issuecomment-75226021 is what I had in mind.
I see some complications:
- Adding that would involve using the custom library we talked about to have the
accuracyForeign 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.)
Thanks for the explanation, @ggalmazor. Let's table the accuracy addition until we get the current implementation shipped and someone complains.
Heads up! We've just released Briefcase v1.13 with a shiny new GeoJSON export option! Spread the word!
I would like to access GeoJSON from aggregate in my python program.
Can anybody explain how to do that?
It's hard to give specific instructions because your question is somewhat general.
You can get a GeoJSON file from your submissions using Briefcase. You have information about this here: https://docs.opendatakit.org/briefcase-using/#export-forms-to-csv
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.
@ggalmazor. Thanks for your response.
I need API to download the GeoJSON file from aggregate.
I think this makes my requirement clear.
Currently, there is no API for that in Aggregate.
The only way you can get a GeoJSON using ODK is with Briefcase.
5 posts were split to a new topic: Null geometry when exporting GeoJSON from Briefcase