Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Geotrace widget should only capture lines, not polygons #1028
Software and hardware versions
According to the specs, geotrace is for lines, and geoshape is for polygons. In ODK Collect, geotrace allows you to collect lines or polygons.
Steps to reproduce the problem
Create a form with a geotrace widget and launch in ODK Collect. Collect a geotrace in the widget and click the save button, which prompts you to "Save as polygon" or "save as polyline"
Geotrace should be used to collect lines only.
Geotrace and geoshape should both allow you to use your current position, a timed interval, OR a long press, to draw a vertex.
That is a very good point. We need to do some rethinking of geo activities in general as described in #507 and #508. Perhaps as part of #507 we should take a step back and make sure that we clearly define and document the role of each different widget. For example, @yanokwa a while back was mentioning that it might be good to have the possibility to specify the projection used.
The 3 existing data types (geopoint, geotrace, geoshape) match up well with the 3 geometry types (point, line, polygon). The names are a little confusing, but the documentation is consistent that geotrace=line and geoshape=polygon. This is also how Enketo implements it.
What would be ideal is if geopoint, geotrace, and geoshape all allowed you to either use your current position or use long press to manually collect a position. In many cases the user cannot stand in the location he/she wants to map. The geoshape widget works well for manually adding vertices, but it doesn't allow you to collect your current position or use a timed interval.
With a few enhancements to the geo activities, Collect can be a highly capable mapping platform for use with GIS! Let me know if you have thoughts about these changes.
As for specifying the projection, the raw GPS data should always be in WGS84 (unprojected), and re-projecting it is usually done as a post-processing step. Most applications use Web Mercator projection (WKID 3857) to display WGS84 data. http://spatialreference.org/ref/sr-org/7483/
I think the changes you propose are great, @geomapdev and thanks for the extra background on projections.
I'm not exactly sure where to go from here! On my personal wishlist for the geowidgets are:
I suspect all of these depend on #507 and #508, what do you think? @MukundAnanthu has started #507 and your ideas and feedback there would be much appreciated. I think it will be much easier to make consistent changes once redundancy between the different activities is captured.
I think it would also be good to file the different things we've been discussing as separate issues.
This was referenced
Jun 1, 2017
I think that it would be more clear and easy to undersand if each geowidget should create only one geometry type :
Considering the projection, the easiest is to store data in WGS84 (EPSG SRID number 4326) and let database users reproject data in their favorite projection.
I hope I did not pollute your discussion.