I'm new to ODK and I'm now analysing data collected with Geotrace.
Data look like this (one cell):
12.416629421784283 37.59671424251596 1993.8934136246776 6.0; 12.416479997387624 37.59675837626236 1993.6542834206723 4.0; 12.416379606381305 37.59675997386694 1993.3067534667914 4.0; 12.416353450984571 37.59687075454621 1992.9546061427736 4.0; 12.41635870
Truncated at 255 characters.
Is it somehow possible to get the full string (>255) when the length has not been specified in the xlsform?
Or will this mean that all collected data are incomplete because of this...?
Other question:
Does someone by any chance have an R script to calculate the area from geotrace output?
BTW, there is a fairly recent posting about geotrace truncation.
If the odk:length wasn't specified in the original form, then there is a good chance that the original data has been (silently) truncated when it was submitted and saved in Aggregate. If you have physical access to the actual Android device you might be able to recover the original submission XML (which may have the full string)...
Aside, you can also calculate the area of a geotrace from within your form, using a calculation with the area() function.
Hi @Suzanne, can we improve the documentation in some way? There is a warning at the bottom of the geotrace widget section that links to the documentation on aggregate field length, but perhaps the warning should be at the top? Or is geotrace mentioned somewhere else without the warning? I just want to know if there is a way that we can better help people avoid the problem you encountered. Thanks!
It may make sense to have something appear in form builders (eg Build, KoboToolbox, etc) explicitly warning the user, while they are actually creating the form, that geotrace/geoshape widgets will truncate their result unless odk:length is set! Having it clearly spelled out in the ODK online documentation is all well and good, but how many people actually read the documentation before, say, firing up KoboToolbox for the first time? [I certainly didnt! ]
Or better yet, in addition, have these form builders actually add this flag by default for these data types. A typical geopoint can take on the order of 25 characters, which means you are only going to be able to capture approx 10 points for a trace, or 9 for a shape (due to having to repeat the first geopoint). So I think there is a good argument that these two data types will normally require a longer string (eg 1250, or 50 points) to store them in typical usecases. @issa - do you think this would be reasonable to do for Build?
Dunno... I could see - for geotrace - that somebody could just turn it on and having it periodically capture their location to build up a track while they are walking/driving, possibly for an hour+. Maybe enough for 1000 points would cover 99% of usecases?
If you have physical access to the actual Android device you might be able to recover the original submission XML (which may have the full string)...
]