I can a semi-colon increases robustness.
On the other hand, there is a case to be made to stay closer to an existing
geo format. The "Well-known texthttp://en.wikipedia.org/wiki/Well-known_text"
format is something my client likes to stay close too and I think that's a
valid point too. This text format uses space-separated coordinates to form
a geopoint like JavaRosa (though without altitude and accuracy) and
separates multiple geopoints with a comma.
The validation on the client for the decimal character would be
straightforward.
ยทยทยท
On Tue, Mar 11, 2014 at 7:24 PM, Christopher Robert wrote:Agreed that semi-colons seem safer. We've had to change exports to have
configurable delimiters because of CSV format differences across regions,
and I can easily imagine comma issues cropping up here too.Best,
Chris
On Tue, Mar 11, 2014 at 8:49 PM, Mitch Sundt mitchellsundt@gmail.comwrote:
I want to change geoline and geoshape to produce a semicolon-separated
list of geopoint values. Colons, slashes (/) and vertical bars(|) would be
other possible delimiters.e.g.: for geoline
30.2 33.2 67.0 3.0*; *33.2 20.2 7.0 22.0
My concern is that a bad implementation may emit localized
representations for the decimal values that contain commas. This may
especially occur if someone is performing data entry of these values
themselves.Semicolons have no meanings within decimal values, so they are a safer
delimiter.Thoughts?
On Tue, Feb 18, 2014 at 10:28 AM, mberg@ona.io wrote:
We (Ona) are on for supporting the required additions to pyxform.
On Thursday, February 13, 2014 11:13:50 PM UTC+6, Martijn van de Rijdt wrote:
This approach sounds excellent to me! Thanks a lot Mitch.
I can't speak for Ona/SEL, but they have indicated that they are on
board with this, so the tweaks to XLSForm for these datatypes should not be
a problem.Great community!
On Wednesday, February 12, 2014 4:30:35 PM UTC-7, Mitch wrote:
I think we can make an incremental effort, though that may blow up in
our faces....The key things to change are Javarosa and XLSForm. If they recognizes
these types, then Validate will, and ODK Collect and ODK Aggregate would
treat them as strings and everything will potentially work.I will make the change to Javarosa to add "geoline" and "geoshape"
I personally don't want to make the change to XLSForm. Perhaps you
can Martijn? Or have someone do it? I would hope it would be a 2-line
change to a case statement. Note that there is a FormHub, CTOSurvey and UW
version of XLSForm; I'm mainly interested in the change to the UW version.This fits well timing-wise with the Javarosa changes I am folding in
from CTOSurvey.I agree with Chris that it doesn't make sense to extend functionality
within Aggregate or Collect until there is significant demand.A few people have requested this feature, but none have stepped up to
make a change and contribute it back.Fortunately, the code in ODK Collect and ODK Aggregate is written such
that any new types will be mapped into string treatment.i.e., ODK Collect's WidgetFactory would map the unknown type to a
String widget.i.e., ODK Aggregate's FormParserForJavaRosa would map the unknown type
to a String storage fieldWhat I don't know is how fragile the Javarosa code is. This would rely
on it allowing a StringData object to be stored in a GeolineData or
GeoshapeData tree element. I don't know if the code is able to handle that
(it looks like it could).Going forward, the Activity used for the 'placement-map' appearance of
the geopoint could be the starting point for the two needed widgets in
Collect.
Mitch
On Wed, Feb 12, 2014 at 12:20 PM, Martijn van de Rijdt < mar...@enketo.org> wrote:
Thanks Chris,
In this case, it would be better to do it right, right away because
there isn't a great incremental approach from the hack to the proper
solution, so worth a (long) shot - less technical debt.On Wed, Feb 12, 2014 at 1:10 PM, Christopher Robert < cro...@surveycto.com> wrote:
Martijn,
This sounds great!
Unfortunately, we have not had any requests for this among our
clients, so we wouldn't be in a position to prioritize contributions. Also,
to be honest, we would naturally take the approach of implementing
minimally -- particularly until there was sufficient demand and clear
benefit to a more maximal implementation. Thus, the "start as a string
appearance" approach makes a lot of sense to me. It's just not clear that
the maximal vs. minimal implementation maximizes social value. (Sorry, I'm
an economist. But I think that the young Agile types might also agree with
the less-than-all-in approach.)Best,
Chris
P.S. Maybe this message will provoke an outcry from our clients who
have been waiting for such features. If so, we'll react accordingly!On Wed, Feb 12, 2014 at 2:36 PM, Martijn van de Rijdt < mar...@enketo.org> wrote:
Hi ODK/Nafundi/SurveyCTO/Formhub/Ona/Commcare/Other devs,
A sponsor is paying for two hot features in Enketo: the development of
geoshape and geoline widgets. This company wants to use Enketo with a
server that is not based on Aggregate, Formhub or CommCare and is fine with
using type="string" and appearance="geoshape"/appearance="geoline".... This
would obviously be a hack and not use the appearance attribute for what it
is meant for, nor would it have proper server-side datatype validation of
submissions.... but it would work for my client and would also work with
the current XLSForm, Validate, Aggregate, SurveyCTO and Formhub if Enketo
is used as a client (It would simply show up as a text field in Collect).This message is an attempt at doing this properly by instead using new
datatypes (no new appearances) if there is interest and time/funding from
some of you.I propose to introduce new XForm datatypes "geoshape" and "geoline"
with a format that is a comma-separated list of the current geopoint
datatype (of space-separated coordinates, altitude and accuracy):geoshape: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3 lng3
alt3 acc3, lat1 lng1 alt1 acc1" (final geopoint is equal to first)
geoline: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3 lng3 alt3
acc3"It would then be up to the server or data analysis tool whether to
transform this into a more useful format such as GeoJSON.Doing this would require:
ODK Validate supportXLSForm supportODK Aggregate++ support Formhub++ supportODK Collect++
support (or show 'not supported yet' warning)I know other groups have worked on similar widgets for Collect. If any
of these can be accepted (or made acceptable) in the main branches of ODK
Validate, ODK Aggregate, ODK Collect, they would be great to use as a
starting point.Any comments, interest, ability to work on this?
Martijn
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/AfVgKcpE6Jk/unsubscribe
.To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.For more options, visit https://groups.google.com/groups/opt_out.
--
Did you know that Enketo Smart Paper has now become the #1 tool for
data collection? Don't fall behind. Use it!Enketo | LinkedIn | GitHub | Twitter
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.For more options, visit https://groups.google.com/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/AfVgKcpE6Jk/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!
Enketo https://enketo.org |
LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo