Geoshape (polygon) and geoline widget: request for comments & collaboration

Development
1

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:

  1. ODK Validate support
  2. XLSForm support
  3. ODK Aggregate++ support
  4. Formhub++ support
  5. ODK 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

2

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 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:

  1. ODK Validate support
  2. XLSForm support
  3. ODK Aggregate++ support
  4. Formhub++ support
  5. ODK 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.

3

Dear developers,

I am not a technical expert but I am working in sustainable land use in development countries. I am using ODK for our small holder projects to collect field data in an efficient manner. In my work field we work with areas (polygons); many of the field data is related to an area unit rather than to a single point. Hence, a polygon option in ODK and connecting attribute data to these polygons would be ideal for my work. I am sure that many my colleagues working in land use, forestry etc. are waiting for such an extension. ODK is already perfect with the geopoint option, but when you could also create polygons I am sure ODK will be used by many others in by area. Is it clear if this option will be build in? And in case the plan is there: When could this be expected? Look forward to any feedback on this. Thanks!

Again, ODK is really great: I thank all the developers who have been building this great tool and made it open source

··· On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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
4

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 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 martijn@enketo.orgwrote:

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:

  1. ODK Validate support
  2. XLSForm support
  3. ODK Aggregate++ support
  4. Formhub++ support
  5. ODK 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 https://enketo.org |
LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo

5

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 field

What 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 martijn@enketo.orgwrote:

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 <crobert@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 <martijn@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:

  1. ODK Validate support
  2. XLSForm support
  3. ODK Aggregate++ support
  4. Formhub++ support
  5. ODK 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 https://enketo.org | LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo

--
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

6

Hi,

A dedicated polygon (geoshape) widget will be built-in to Enketohttps://enketo.organd is planned to become available next month. Read more details
here: https://github.com/MartijnR/enketo-core/issues/89.

Cheers,
Martijn

··· On Saturday, March 15, 2014 8:49:09 AM UTC-6, 4est...@gmail.com wrote: > > Dear developers, > > I am not a technical expert but I am working in sustainable land use in > development countries. I am using ODK for our small holder projects to > collect field data in an efficient manner. In my work field we work with > areas (polygons); many of the field data is related to an area unit rather > than to a single point. Hence, a polygon option in ODK and connecting > attribute data to these polygons would be ideal for my work. I am sure that > many my colleagues working in land use, forestry etc. are waiting for such > an extension. ODK is already perfect with the geopoint option, but when you > could also create polygons I am sure ODK will be used by many others in by > area. Is it clear if this option will be build in? And in case the plan is > there: When could this be expected? Look forward to any feedback on this. > Thanks! > > Again, ODK is really great: I thank all the developers who have been > building this great tool and made it open source > > > > On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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 >
7

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 field > > *What 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: >>>> >>>> 1. ODK Validate support >>>> 2. XLSForm support >>>> 3. ODK Aggregate++ support >>>> 4. Formhub++ support >>>> 5. ODK 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 >
8

An early preview for those interested. Feedback welcome (especially on UX).
http://goo.gl/z1yCdo

··· On Sunday, March 16, 2014 12:29:12 PM UTC-6, Martijn van de Rijdt wrote: > > Hi, > > A dedicated polygon (geoshape) widget will be built-in to Enketoand is planned to become available next month. Read more details here: > https://github.com/MartijnR/enketo-core/issues/89. > > Cheers, > Martijn > > On Saturday, March 15, 2014 8:49:09 AM UTC-6, 4est...@gmail.com wrote: >> >> Dear developers, >> >> I am not a technical expert but I am working in sustainable land use in >> development countries. I am using ODK for our small holder projects to >> collect field data in an efficient manner. In my work field we work with >> areas (polygons); many of the field data is related to an area unit rather >> than to a single point. Hence, a polygon option in ODK and connecting >> attribute data to these polygons would be ideal for my work. I am sure that >> many my colleagues working in land use, forestry etc. are waiting for such >> an extension. ODK is already perfect with the geopoint option, but when you >> could also create polygons I am sure ODK will be used by many others in by >> area. Is it clear if this option will be build in? And in case the plan is >> there: When could this be expected? Look forward to any feedback on this. >> Thanks! >> >> Again, ODK is really great: I thank all the developers who have been >> building this great tool and made it open source >> >> >> >> On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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 >> >
9

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 field > > > What 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 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 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 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 support > > > > XLSForm 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
10

Dear Martijn,

I looked at the early preview and it looks existing! In your mail you are referring to Enketo which is partly a paid service. Will this tool (geoshape/geoline) also become available as opensource (ODK collect and ODK aggregate)? If so, can you indicate when this will be available? I am busy setting up a large fieldwork campaign for sustainable agriculture projects with small holder farmers in Afrika and South America for which this tool would be very valuable. Would be good to know if I can implement these features (polygons and polylines) in my ODK forms and aggregate service.

FYI: The link between Enketo and ODK is not yet entirely clear to me that is also why I am asking. Thanks for the feedback!

Kind regards,

Ed

··· On Monday, March 24, 2014 10:40:42 PM UTC+1, Martijn van de Rijdt wrote: > An early preview for those interested. Feedback welcome (especially on UX). http://goo.gl/z1yCdo > > On Sunday, March 16, 2014 12:29:12 PM UTC-6, Martijn van de Rijdt wrote: > Hi, > > > A dedicated polygon (geoshape) widget will be built-in to Enketo and is planned to become available next month. Read more details here: https://github.com/MartijnR/enketo-core/issues/89. > > > Cheers, > Martijn > > On Saturday, March 15, 2014 8:49:09 AM UTC-6, 4est...@gmail.com wrote:Dear developers, > > > > I am not a technical expert but I am working in sustainable land use in development countries. I am using ODK for our small holder projects to collect field data in an efficient manner. In my work field we work with areas (polygons); many of the field data is related to an area unit rather than to a single point. Hence, a polygon option in ODK and connecting attribute data to these polygons would be ideal for my work. I am sure that many my colleagues working in land use, forestry etc. are waiting for such an extension. ODK is already perfect with the geopoint option, but when you could also create polygons I am sure ODK will be used by many others in by area. Is it clear if this option will be build in? And in case the plan is there: When could this be expected? Look forward to any feedback on this. Thanks! > > > > Again, ODK is really great: I thank all the developers who have been building this great tool and made it open source > > > > > > > > On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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
11

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, 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 field

What 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 support

XLSForm 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

12

Hi Ed,

Thanks!

This feature is now finished and deployed but we're waiting for support in
the servers (Aggregate, Formhub, Ona, SurveyCTO) and form builder (XLSForm)
before it can actually be used.

Latest version is here:

Yes, enketo.org is available as a paid service (with a free level) or for
free on formhub.org. The code for this widget is here:
https://github.com/MartijnR/enketo-core/tree/master/src/widget/geo.

Cheers,
Martijn

··· On Tue, Apr 8, 2014 at 5:10 AM, <4estsense@gmail.com> wrote:

Dear Martijn,

I looked at the early preview and it looks existing! In your mail you are
referring to Enketo which is partly a paid service. Will this tool
(geoshape/geoline) also become available as opensource (ODK collect and ODK
aggregate)? If so, can you indicate when this will be available? I am busy
setting up a large fieldwork campaign for sustainable agriculture projects
with small holder farmers in Afrika and South America for which this tool
would be very valuable. Would be good to know if I can implement these
features (polygons and polylines) in my ODK forms and aggregate service.

FYI: The link between Enketo and ODK is not yet entirely clear to me that
is also why I am asking. Thanks for the feedback!

Kind regards,

Ed

On Monday, March 24, 2014 10:40:42 PM UTC+1, Martijn van de Rijdt wrote:

An early preview for those interested. Feedback welcome (especially on
UX). http://goo.gl/z1yCdo

On Sunday, March 16, 2014 12:29:12 PM UTC-6, Martijn van de Rijdt wrote:
Hi,

A dedicated polygon (geoshape) widget will be built-in to Enketo and is
planned to become available next month. Read more details here:
https://github.com/MartijnR/enketo-core/issues/89.

Cheers,
Martijn

On Saturday, March 15, 2014 8:49:09 AM UTC-6, 4est...@gmail.comwrote:Dear developers,

I am not a technical expert but I am working in sustainable land use in
development countries. I am using ODK for our small holder projects to
collect field data in an efficient manner. In my work field we work with
areas (polygons); many of the field data is related to an area unit rather
than to a single point. Hence, a polygon option in ODK and connecting
attribute data to these polygons would be ideal for my work. I am sure that
many my colleagues working in land use, forestry etc. are waiting for such
an extension. ODK is already perfect with the geopoint option, but when you
could also create polygons I am sure ODK will be used by many others in by
area. Is it clear if this option will be build in? And in case the plan is
there: When could this be expected? Look forward to any feedback on this.
Thanks!

Again, ODK is really great: I thank all the developers who have been
building this great tool and made it open source

On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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 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

13

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 wrote:

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 field

What 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 support

XLSForm 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.

14

W.r.t. the core ODK tools, they will be able to accept forms that use these
data types, but they will present string fields to the user for data entry,
where the user has to manually enter the coordinate values.

Once people in the community write and contribute back a widget to capture
a geoshape and/or a geotrace we will fold those back into the ODK Collect
codebase.

On ODK Aggregate, we would probably continue to support these only as
string fields; there would probably be an upper limit to the total length
of those fields, too.

Mitch

··· On Tue, Apr 8, 2014 at 9:10 AM, Martijn van de Rijdt wrote:

Hi Ed,

Thanks!

This feature is now finished and deployed but we're waiting for support in
the servers (Aggregate, Formhub, Ona, SurveyCTO) and form builder (XLSForm)
before it can actually be used.

Latest version is here:
https://enketo.org/webform/preview?form=http://demo-forms.enketo.org/geo.xml

Yes, enketo.org is available as a paid service (with a free level) or for
free on formhub.org. The code for this widget is here:
https://github.com/MartijnR/enketo-core/tree/master/src/widget/geo.

Cheers,
Martijn

On Tue, Apr 8, 2014 at 5:10 AM, 4estsense@gmail.com wrote:

Dear Martijn,

I looked at the early preview and it looks existing! In your mail you are
referring to Enketo which is partly a paid service. Will this tool
(geoshape/geoline) also become available as opensource (ODK collect and ODK
aggregate)? If so, can you indicate when this will be available? I am busy
setting up a large fieldwork campaign for sustainable agriculture projects
with small holder farmers in Afrika and South America for which this tool
would be very valuable. Would be good to know if I can implement these
features (polygons and polylines) in my ODK forms and aggregate service.

FYI: The link between Enketo and ODK is not yet entirely clear to me that
is also why I am asking. Thanks for the feedback!

Kind regards,

Ed

On Monday, March 24, 2014 10:40:42 PM UTC+1, Martijn van de Rijdt wrote:

An early preview for those interested. Feedback welcome (especially on
UX). http://goo.gl/z1yCdo

On Sunday, March 16, 2014 12:29:12 PM UTC-6, Martijn van de Rijdt wrote:
Hi,

A dedicated polygon (geoshape) widget will be built-in to Enketo and is
planned to become available next month. Read more details here:
https://github.com/MartijnR/enketo-core/issues/89.

Cheers,
Martijn

On Saturday, March 15, 2014 8:49:09 AM UTC-6, 4est...@gmail.comwrote:Dear developers,

I am not a technical expert but I am working in sustainable land use in
development countries. I am using ODK for our small holder projects to
collect field data in an efficient manner. In my work field we work with
areas (polygons); many of the field data is related to an area unit rather
than to a single point. Hence, a polygon option in ODK and connecting
attribute data to these polygons would be ideal for my work. I am sure that
many my colleagues working in land use, forestry etc. are waiting for such
an extension. ODK is already perfect with the geopoint option, but when you
could also create polygons I am sure ODK will be used by many others in by
area. Is it clear if this option will be build in? And in case the plan is
there: When could this be expected? Look forward to any feedback on this.
Thanks!

Again, ODK is really great: I thank all the developers who have been
building this great tool and made it open source

On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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 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

--
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.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

15

Hi Martijn,

Very glad to hear that this application becomes open source. As explained, I am an end-user, trying to dig into this technical XML en ODK stuff because it is very useful to me and my workfield. I am planning to try to find some financing so that the community can build in extra ODK functionality for support sustainable land use projects. I have clear ideas for what is needed within the sustainable land use community. As said before, one of the most important things here is that you can map an area automatically (by walking around a parcel, just as the tracking mode with GPS, taking a coordinate based on a time period or distance setting) and add attributes to that area. Up to now, implementing your tool for testing seems qiete technical and only accessible to programming experts that are acquintanced with Xforms. Am I correct? As an end-user I am only working with XLSForms, not within Xforms directly. So at the moment the matter remains too technical for me.

For both Mitch and you:

How could we start a traject for making this tool user friendly within ODK so that everyone who used ODK collect/ODK-build (XLSForms) and Aggregate could use this tool? Would additional financing speed things up or do I just have to be more pacient with ODK...? So how does this work if I find some financing for further development: Can I just apply to build this application within ODK (collect/build/aggregate)?

Good to discuss this so that I can take it into account. Thanks again for the feedback and look forward to see all this evolve...:slight_smile:

Kind regards,

Ed

··· On Tuesday, April 8, 2014 6:10:18 PM UTC+2, Martijn van de Rijdt wrote: > Hi Ed, > > > Thanks! > > > > This feature is now finished and deployed but we're waiting for support in the servers (Aggregate, Formhub, Ona, SurveyCTO) and form builder (XLSForm) before it can actually be used. > > > > Latest version is here: https://enketo.org/webform/preview?form=http://demo-forms.enketo.org/geo.xml > > > > Yes, enketo.org is available as a paid service (with a free level) or for free on formhub.org. The code for this widget is here: https://github.com/MartijnR/enketo-core/tree/master/src/widget/geo. > > > > Cheers, > Martijn > > > > > > On Tue, Apr 8, 2014 at 5:10 AM, <4est...@gmail.com> wrote: > > Dear Martijn, > > > > I looked at the early preview and it looks existing! In your mail you are referring to Enketo which is partly a paid service. Will this tool (geoshape/geoline) also become available as opensource (ODK collect and ODK aggregate)? If so, can you indicate when this will be available? I am busy setting up a large fieldwork campaign for sustainable agriculture projects with small holder farmers in Afrika and South America for which this tool would be very valuable. Would be good to know if I can implement these features (polygons and polylines) in my ODK forms and aggregate service. > > > > > FYI: The link between Enketo and ODK is not yet entirely clear to me that is also why I am asking. Thanks for the feedback! > > > > Kind regards, > > > > Ed > > > > > > > > On Monday, March 24, 2014 10:40:42 PM UTC+1, Martijn van de Rijdt wrote: > > > An early preview for those interested. Feedback welcome (especially on UX). http://goo.gl/z1yCdo > > > > > > On Sunday, March 16, 2014 12:29:12 PM UTC-6, Martijn van de Rijdt wrote: > > > Hi, > > > > > > > > > A dedicated polygon (geoshape) widget will be built-in to Enketo and is planned to become available next month. Read more details here: https://github.com/MartijnR/enketo-core/issues/89. > > > > > > > > > > Cheers, > > > Martijn > > > > > > On Saturday, March 15, 2014 8:49:09 AM UTC-6, 4est...@gmail.com wrote:Dear developers, > > > > > > > > > > > > I am not a technical expert but I am working in sustainable land use in development countries. I am using ODK for our small holder projects to collect field data in an efficient manner. In my work field we work with areas (polygons); many of the field data is related to an area unit rather than to a single point. Hence, a polygon option in ODK and connecting attribute data to these polygons would be ideal for my work. I am sure that many my colleagues working in land use, forestry etc. are waiting for such an extension. ODK is already perfect with the geopoint option, but when you could also create polygons I am sure ODK will be used by many others in by area. Is it clear if this option will be build in? And in case the plan is there: When could this be expected? Look forward to any feedback on this. Thanks! > > > > > > > > > > > > > Again, ODK is really great: I thank all the developers who have been building this great tool and made it open source > > > > > > > > > > > > > > > > > > > > > > > > On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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 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 | LinkedIn | GitHub | Twitter
16

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 field

What 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 support

XLSForm 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

17

I'll just mention this since it's somewhat related to this discussion: we
just added two new functions to SurveyCTO, for our upcoming 1.21 release:

distance-between(geopointfield1, geopointfield2): Returns the distance,
in meters, between two geopoint fields (as in the calculate expression
"distance-between(${start_gps}, ${end_gps})"). (Keep in mind that the
accuracy of the distance calculated will depend on the accuracy of the GPS
readings, so try to be sure to get accurate GPS readings.)

enclosed-area(repeatedgeopointfield): Returns the area enclosed, in
square-meters, within a series of repeated geopoint fields (as in the
calculate expression "enclosed-area(${gps_reading})", called outside a
repeat group that includes the gps_reading field). (Keep in mind that the
accuracy of the area calculated will depend on the accuracy of the GPS
readings, so try to be sure to get accurate GPS readings.)

For the latter function, it is a series of repeated geopoint fields rather
than a single geoshape; and for the former it is two individual geopoint
fields rather than a single geoline. We implemented these on the spur of
the moment to support an existing customer, and they seemed potentially
useful for other SurveyCTO customers as well.

As geoline and geoshape become supported throughout the toolset, we can
easily convert these functions to take those field types as parameters.

Best,

Chris

··· On Mon, Apr 14, 2014 at 7:24 AM, <4estsense@gmail.com> wrote:

Hi Martijn,

Very glad to hear that this application becomes open source. As explained,
I am an end-user, trying to dig into this technical XML en ODK stuff
because it is very useful to me and my workfield. I am planning to try to
find some financing so that the community can build in extra ODK
functionality for support sustainable land use projects. I have clear ideas
for what is needed within the sustainable land use community. As said
before, one of the most important things here is that you can map an area
automatically (by walking around a parcel, just as the tracking mode with
GPS, taking a coordinate based on a time period or distance setting) and
add attributes to that area. Up to now, implementing your tool for testing
seems qiete technical and only accessible to programming experts that are
acquintanced with Xforms. Am I correct? As an end-user I am only working
with XLSForms, not within Xforms directly. So at the moment the matter
remains too technical for me.

For both Mitch and you:

How could we start a traject for making this tool user friendly within ODK
so that everyone who used ODK collect/ODK-build (XLSForms) and Aggregate
could use this tool? Would additional financing speed things up or do I
just have to be more pacient with ODK...? So how does this work if I find
some financing for further development: Can I just apply to build this
application within ODK (collect/build/aggregate)?

Good to discuss this so that I can take it into account. Thanks again for
the feedback and look forward to see all this evolve...:slight_smile:

Kind regards,

Ed

On Tuesday, April 8, 2014 6:10:18 PM UTC+2, Martijn van de Rijdt wrote:

Hi Ed,

Thanks!

This feature is now finished and deployed but we're waiting for support
in the servers (Aggregate, Formhub, Ona, SurveyCTO) and form builder
(XLSForm) before it can actually be used.

Latest version is here:
https://enketo.org/webform/preview?form=http://demo-forms.enketo.org/geo.xml

Yes, enketo.org is available as a paid service (with a free level) or
for free on formhub.org. The code for this widget is here:
https://github.com/MartijnR/enketo-core/tree/master/src/widget/geo.

Cheers,
Martijn

On Tue, Apr 8, 2014 at 5:10 AM, 4est...@gmail.com wrote:

Dear Martijn,

I looked at the early preview and it looks existing! In your mail you
are referring to Enketo which is partly a paid service. Will this tool
(geoshape/geoline) also become available as opensource (ODK collect and ODK
aggregate)? If so, can you indicate when this will be available? I am busy
setting up a large fieldwork campaign for sustainable agriculture projects
with small holder farmers in Afrika and South America for which this tool
would be very valuable. Would be good to know if I can implement these
features (polygons and polylines) in my ODK forms and aggregate service.

FYI: The link between Enketo and ODK is not yet entirely clear to me
that is also why I am asking. Thanks for the feedback!

Kind regards,

Ed

On Monday, March 24, 2014 10:40:42 PM UTC+1, Martijn van de Rijdt wrote:

An early preview for those interested. Feedback welcome (especially on
UX). http://goo.gl/z1yCdo

On Sunday, March 16, 2014 12:29:12 PM UTC-6, Martijn van de Rijdt wrote:

Hi,

A dedicated polygon (geoshape) widget will be built-in to Enketo and
is planned to become available next month. Read more details here:
https://github.com/MartijnR/enketo-core/issues/89.

Cheers,

Martijn

On Saturday, March 15, 2014 8:49:09 AM UTC-6, 4est...@gmail.comwrote:Dear developers,

I am not a technical expert but I am working in sustainable land use
in development countries. I am using ODK for our small holder projects to
collect field data in an efficient manner. In my work field we work with
areas (polygons); many of the field data is related to an area unit rather
than to a single point. Hence, a polygon option in ODK and connecting
attribute data to these polygons would be ideal for my work. I am sure that
many my colleagues working in land use, forestry etc. are waiting for such
an extension. ODK is already perfect with the geopoint option, but when you
could also create polygons I am sure ODK will be used by many others in by
area. Is it clear if this option will be build in? And in case the plan is
there: When could this be expected? Look forward to any feedback on this.
Thanks!

Again, ODK is really great: I thank all the developers who have been
building this great tool and made it open source

On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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 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 | 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/d/optout.

18

I'm with Martijn. I think semi-colon is fine, but if there is a way we
can get closer to the some standard format, we probably should.

One option might be http://www.georss.org/simple

Yaw

··· -- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Wed, Mar 12, 2014 at 10:04 AM, Martijn van de Rijdt martijn@enketo.org wrote:

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 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 crobert@surveycto.com 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.com wrote:

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 field

What 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 support

XLSForm 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 | 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/d/optout.

19

The other problem is how to distinguish a not-yet-captured value from a
captured value.

I am leaning toward "" as a not-yet-captured value, which makes the simple
format Yaw referenced would be bad for multi-point captures.

With "", this means string(.) yields:

"" - a geopoint that has never been captured
"3.0 2.2 22.0 4.0" -- a geopoint that has been captured

"; " - a geoline that has never been captured
"3.05 2.2 22.0 4.0;" -- a geoline with the start point captured
"; 3.10 2.2 22.0 4.0" -- a geoline with the end point captured

"" - a geoshape that has never been captured
"3.05 2.2 22.0 4.0; ; 3.10 2.2 22.0 4.0" -- a 3-point geoshape with the
middle point not captured, but the first and 3rd have been.

··· On Wed, Mar 12, 2014 at 10:15 AM, Yaw Anokwa wrote:

I'm with Martijn. I think semi-colon is fine, but if there is a way we
can get closer to the some standard format, we probably should.

One option might be http://www.georss.org/simple

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Wed, Mar 12, 2014 at 10:04 AM, Martijn van de Rijdt martijn@enketo.org wrote:

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 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 < crobert@surveycto.com> 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.com wrote:

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 field

What 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 support

XLSForm 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 | 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/d/optout.

--
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.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

20

Ed,

In general if you want something added to ODK you shouldn't wait for
the core team to do it. You should building (yourself or by funding a
developer) and the core team will most certainly merge it into the
core.

Yaw

··· -- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Mon, Apr 14, 2014 at 4:30 AM, Christopher Robert crobert@surveycto.com wrote:

I'll just mention this since it's somewhat related to this discussion: we
just added two new functions to SurveyCTO, for our upcoming 1.21 release:

distance-between(geopointfield1, geopointfield2): Returns the distance, in
meters, between two geopoint fields (as in the calculate expression
"distance-between(${start_gps}, ${end_gps})"). (Keep in mind that the
accuracy of the distance calculated will depend on the accuracy of the GPS
readings, so try to be sure to get accurate GPS readings.)

enclosed-area(repeatedgeopointfield): Returns the area enclosed, in
square-meters, within a series of repeated geopoint fields (as in the
calculate expression "enclosed-area(${gps_reading})", called outside a
repeat group that includes the gps_reading field). (Keep in mind that the
accuracy of the area calculated will depend on the accuracy of the GPS
readings, so try to be sure to get accurate GPS readings.)

For the latter function, it is a series of repeated geopoint fields rather
than a single geoshape; and for the former it is two individual geopoint
fields rather than a single geoline. We implemented these on the spur of the
moment to support an existing customer, and they seemed potentially useful
for other SurveyCTO customers as well.

As geoline and geoshape become supported throughout the toolset, we can
easily convert these functions to take those field types as parameters.

Best,

Chris

On Mon, Apr 14, 2014 at 7:24 AM, 4estsense@gmail.com wrote:

Hi Martijn,

Very glad to hear that this application becomes open source. As explained,
I am an end-user, trying to dig into this technical XML en ODK stuff because
it is very useful to me and my workfield. I am planning to try to find some
financing so that the community can build in extra ODK functionality for
support sustainable land use projects. I have clear ideas for what is needed
within the sustainable land use community. As said before, one of the most
important things here is that you can map an area automatically (by walking
around a parcel, just as the tracking mode with GPS, taking a coordinate
based on a time period or distance setting) and add attributes to that area.
Up to now, implementing your tool for testing seems qiete technical and only
accessible to programming experts that are acquintanced with Xforms. Am I
correct? As an end-user I am only working with XLSForms, not within Xforms
directly. So at the moment the matter remains too technical for me.

For both Mitch and you:

How could we start a traject for making this tool user friendly within ODK
so that everyone who used ODK collect/ODK-build (XLSForms) and Aggregate
could use this tool? Would additional financing speed things up or do I just
have to be more pacient with ODK...? So how does this work if I find some
financing for further development: Can I just apply to build this
application within ODK (collect/build/aggregate)?

Good to discuss this so that I can take it into account. Thanks again for
the feedback and look forward to see all this evolve...:slight_smile:

Kind regards,

Ed

On Tuesday, April 8, 2014 6:10:18 PM UTC+2, Martijn van de Rijdt wrote:

Hi Ed,

Thanks!

This feature is now finished and deployed but we're waiting for support
in the servers (Aggregate, Formhub, Ona, SurveyCTO) and form builder
(XLSForm) before it can actually be used.

Latest version is here:
https://enketo.org/webform/preview?form=http://demo-forms.enketo.org/geo.xml

Yes, enketo.org is available as a paid service (with a free level) or
for free on formhub.org. The code for this widget is here:
https://github.com/MartijnR/enketo-core/tree/master/src/widget/geo.

Cheers,
Martijn

On Tue, Apr 8, 2014 at 5:10 AM, 4est...@gmail.com wrote:

Dear Martijn,

I looked at the early preview and it looks existing! In your mail you
are referring to Enketo which is partly a paid service. Will this tool
(geoshape/geoline) also become available as opensource (ODK collect and ODK
aggregate)? If so, can you indicate when this will be available? I am busy
setting up a large fieldwork campaign for sustainable agriculture projects
with small holder farmers in Afrika and South America for which this tool
would be very valuable. Would be good to know if I can implement these
features (polygons and polylines) in my ODK forms and aggregate service.

FYI: The link between Enketo and ODK is not yet entirely clear to me
that is also why I am asking. Thanks for the feedback!

Kind regards,

Ed

On Monday, March 24, 2014 10:40:42 PM UTC+1, Martijn van de Rijdt wrote:

An early preview for those interested. Feedback welcome (especially on
UX). http://goo.gl/z1yCdo

On Sunday, March 16, 2014 12:29:12 PM UTC-6, Martijn van de Rijdt wrote:

Hi,

A dedicated polygon (geoshape) widget will be built-in to Enketo and
is planned to become available next month. Read more details here:
https://github.com/MartijnR/enketo-core/issues/89.

Cheers,

Martijn

On Saturday, March 15, 2014 8:49:09 AM UTC-6, 4est...@gmail.com
wrote:Dear developers,

I am not a technical expert but I am working in sustainable land use
in development countries. I am using ODK for our small holder projects to
collect field data in an efficient manner. In my work field we work with
areas (polygons); many of the field data is related to an area unit rather
than to a single point. Hence, a polygon option in ODK and connecting
attribute data to these polygons would be ideal for my work. I am sure that
many my colleagues working in land use, forestry etc. are waiting for such
an extension. ODK is already perfect with the geopoint option, but when you
could also create polygons I am sure ODK will be used by many others in by
area. Is it clear if this option will be build in? And in case the plan is
there: When could this be expected? Look forward to any feedback on this.
Thanks!

Again, ODK is really great: I thank all the developers who have been
building this great tool and made it open source

On Wednesday, February 12, 2014 8:36:26 PM UTC+1, Martijn van de Rijdt 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 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 | 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/d/optout.

--
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.