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

[Mitch_S]

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

[martijnr]

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:

Enketo

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

[crobert]

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.

[Mitch_S]

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

[Eddy_Rellum]

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

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

[martijnr]

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

[crobert]

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

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.

[yanokwa]

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.

[Mitch_S]

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

[yanokwa]

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

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.

[yanokwa]

The prompts will be typed, right?. So why not a blank string for a
geo* that has never been captured?

Then geoline is 2 or more geopoints separated by semi-colon. Geoshape
is 3 or more points separated by semi-colon. Note that the first point
doesn't have to equal the last in geoshape to make it valid.

I guess I don't understand why you'd need the not-yet-captured state.

···

On Wed, Mar 12, 2014 at 4:21 PM, Mitch Sundt wrote: > 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 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 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 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, 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 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 >> >>>> >> >>>> -- >> >>>> 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 > > -- > 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.

[martijnr]

Hi Ed,

Up to now, implementing your tool for testing seems quite 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

No, it won't be technical at all once the new datatypes (geoshape and
geotrace) have been added to XLSForm (and once the next ODK Aggregate
version is released, I believe). A company called Ona has committed to do
the XLSForm work. After that implementing it is the same as any other type
of question (type=text, type=geoshape, type=integer, etc).

However, note that Enketo and ODK Collect are 2 different applications that
do more or less the same. It will initially only work in Enketo (as Yaw
mentioned implementing this in ODK Collect means hiring someone (like the
good folks at Nafundi) or developing it yourself.)

Cheers,
Martijn

···

On Monday, April 14, 2014 5:59:38 PM UTC-6, Yaw Anokwa wrote: > > 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 <cro...@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, <4est...@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...:-) > >> > >> 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. >

[Mitch_S]

Should anyone ever implement a geoline widget, you might want to save the
first point, then later save the 2nd point.

This would be, e.g., in the Savepoint XML file.

···

On Wed, Mar 12, 2014 at 4:50 PM, Yaw Anokwa wrote:

The prompts will be typed, right?. So why not a blank string for a
geo* that has never been captured?

Then geoline is 2 or more geopoints separated by semi-colon. Geoshape
is 3 or more points separated by semi-colon. Note that the first point
doesn't have to equal the last in geoshape to make it valid.

I guess I don't understand why you'd need the not-yet-captured state.

On Wed, Mar 12, 2014 at 4:21 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

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 yanokwa@nafundi.com 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

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

[Eddy_Rellum]

Dear Yaw and Martijn,

Thanks for this explanation. Very clear and good to hear that one can help
building the tool. Pretty logical of course with open source, but now the
process is a bit more clear. I will certainly look for ways how our
organisation can contribute to the development of the ODK functionality.

Kind regards,

Ed

···

On Tuesday, April 15, 2014 3:02:54 AM UTC+2, Martijn van de Rijdt wrote: > > Hi Ed, > > Up to now, implementing your tool for testing seems quite 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 >> > > No, it won't be technical at all once the new datatypes (geoshape and > geotrace) have been added to XLSForm (and once the next ODK Aggregate > version is released, I believe). A company called Ona has committed to do > the XLSForm work. After that implementing it is the same as any other type > of question (type=text, type=geoshape, type=integer, etc). > > However, note that Enketo and ODK Collect are 2 different applications > that do more or less the same. It will initially only work in Enketo (as > Yaw mentioned implementing this in ODK Collect means hiring someone (like > the good folks at Nafundi) or developing it yourself.) > > Cheers, > Martijn > > > On Monday, April 14, 2014 5:59:38 PM UTC-6, Yaw Anokwa wrote: >> >> 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 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, <4est...@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...:-) >> >> >> >> 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. >> >

[yanokwa]

Both the use case and the format makes sense to me.

···

On Wed, Mar 12, 2014 at 5:17 PM, Mitch Sundt wrote: > Should anyone ever implement a geoline widget, you might want to save the > first point, then later save the 2nd point. > > This would be, e.g., in the Savepoint XML file. > > > > > On Wed, Mar 12, 2014 at 4:50 PM, Yaw Anokwa wrote: >> >> The prompts will be typed, right?. So why not a blank string for a >> geo* that has never been captured? >> >> Then geoline is 2 or more geopoints separated by semi-colon. Geoshape >> is 3 or more points separated by semi-colon. Note that the first point >> doesn't have to equal the last in geoshape to make it valid. >> >> I guess I don't understand why you'd need the not-yet-captured state. >> >> On Wed, Mar 12, 2014 at 4:21 PM, Mitch Sundt wrote: >> > 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 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 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 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, 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 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 >> >> >>>> >> >> >>>> -- >> >> >>>> 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 >> > >> > -- >> > 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 > > -- > 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.

[Trung]

Dear Mitch,

I wrote to you yesterday saying that our team at Real-Time Analytics in Vietnam has committed to writing widgets for taking polygon and polyline. We are happy to contribute the code to the team. I said we needed a week to get it done but likely we will finalize it faster.

Please let me know.
Best,
Trung.

···

On Tuesday, April 15, 2014 2:51:15 PM UTC+7, Eddy Rellum wrote: > Dear Yaw and Martijn, > > > Thanks for this explanation. Very clear and good to hear that one can help building the tool. Pretty logical of course with open source, but now the process is a bit more clear. I will certainly look for ways how our organisation can contribute to the development of the ODK functionality. > > > Kind regards, > > > Ed > > On Tuesday, April 15, 2014 3:02:54 AM UTC+2, Martijn van de Rijdt wrote: > Hi Ed, > > > Up to now, implementing your tool for testing seems quite 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 > > > > No, it won't be technical at all once the new datatypes (geoshape and geotrace) have been added to XLSForm (and once the next ODK Aggregate version is released, I believe). A company called Ona has committed to do the XLSForm work. After that implementing it is the same as any other type of question (type=text, type=geoshape, type=integer, etc). > > > However, note that Enketo and ODK Collect are 2 different applications that do more or less the same. It will initially only work in Enketo (as Yaw mentioned implementing this in ODK Collect means hiring someone (like the good folks at Nafundi) or developing it yourself.) > > > Cheers, > Martijn > > > On Monday, April 14, 2014 5:59:38 PM UTC-6, Yaw Anokwa wrote: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 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, <4est...@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...:-) > > >> > > >> 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.

[martijnr]

Sounds good to approach un-captured states like that. Some things to
clarify though:

1. For geoshapes, the difference between a polygon and polyline, affects
   the validation. It doesn't seem quite right to me any more to use an
   appearance to determine which datatype validation to use. For that reason,
   I'd vote to make the geoline datatype a N-element list of geopoints. Mitch,
   your argument about have a very simple 2-point geoline widget (in another
   discussion thread) makes sense and maybe this could be the default
   behaviour of a geoline widget. However, if the underlying datatype allows N
   points, we could use appearance=multipoint to capture polylines in a more
   complex widget. For all versions of the geoline widget we could use the
   same validation (minimum of 2 points, no gaps)

2. Can we stick with the comma separator?

···

On Thu, Mar 13, 2014 at 8:09 AM, Yaw Anokwa wrote:

Both the use case and the format makes sense to me.

On Wed, Mar 12, 2014 at 5:17 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

Should anyone ever implement a geoline widget, you might want to save the
first point, then later save the 2nd point.

This would be, e.g., in the Savepoint XML file.

On Wed, Mar 12, 2014 at 4:50 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

The prompts will be typed, right?. So why not a blank string for a
geo* that has never been captured?

Then geoline is 2 or more geopoints separated by semi-colon. Geoshape
is 3 or more points separated by semi-colon. Note that the first point
doesn't have to equal the last in geoshape to make it valid.

I guess I don't understand why you'd need the not-yet-captured state.

On Wed, Mar 12, 2014 at 4:21 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

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 yanokwa@nafundi.com 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

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

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

[Syed_Muhammad_Qadeer]

Dear Trung,

Any progress on this. Capturing polygons and polyline is really much needed requirement. It will ease geo-data collection.

Thanks

···

On Friday, April 18, 2014 6:30:55 AM UTC+5, Trung Dang Le wrote: > Dear Mitch, > > > > I wrote to you yesterday saying that our team at Real-Time Analytics in Vietnam has committed to writing widgets for taking polygon and polyline. We are happy to contribute the code to the team. I said we needed a week to get it done but likely we will finalize it faster. > > > > Please let me know. > > Best, > > Trung. > > > > On Tuesday, April 15, 2014 2:51:15 PM UTC+7, Eddy Rellum wrote: > > > Dear Yaw and Martijn, > > > > > > > > > Thanks for this explanation. Very clear and good to hear that one can help building the tool. Pretty logical of course with open source, but now the process is a bit more clear. I will certainly look for ways how our organisation can contribute to the development of the ODK functionality. > > > > > > > > > Kind regards, > > > > > > > > > Ed > > > > > > On Tuesday, April 15, 2014 3:02:54 AM UTC+2, Martijn van de Rijdt wrote: > > > Hi Ed, > > > > > > > > > Up to now, implementing your tool for testing seems quite 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 > > > > > > > > > > > > No, it won't be technical at all once the new datatypes (geoshape and geotrace) have been added to XLSForm (and once the next ODK Aggregate version is released, I believe). A company called Ona has committed to do the XLSForm work. After that implementing it is the same as any other type of question (type=text, type=geoshape, type=integer, etc). > > > > > > > > > However, note that Enketo and ODK Collect are 2 different applications that do more or less the same. It will initially only work in Enketo (as Yaw mentioned implementing this in ODK Collect means hiring someone (like the good folks at Nafundi) or developing it yourself.) > > > > > > > > > Cheers, > > > Martijn > > > > > > > > > On Monday, April 14, 2014 5:59:38 PM UTC-6, Yaw Anokwa wrote: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 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, <4est...@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...:-) > > > > > > >> > > > > > > >> 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.

[Mitch_S]

50%

• replacing "geoline" with "geotrace" -- a polyline. A simple geoline then
  uses an appearance="line" attribute for whatever widget captures geotraces.

• keeping the semicolon separator. Comma makes assumptions about
  internationalization and formatting of the values.

···

On Thu, Mar 13, 2014 at 8:09 AM, Martijn van de Rijdt wrote:

Sounds good to approach un-captured states like that. Some things to
clarify though:

1. For geoshapes, the difference between a polygon and polyline, affects
   the validation. It doesn't seem quite right to me any more to use an
   appearance to determine which datatype validation to use. For that reason,
   I'd vote to make the geoline datatype a N-element list of geopoints. Mitch,
   your argument about have a very simple 2-point geoline widget (in another
   discussion thread) makes sense and maybe this could be the default
   behaviour of a geoline widget. However, if the underlying datatype allows N
   points, we could use appearance=multipoint to capture polylines in a more
   complex widget. For all versions of the geoline widget we could use the
   same validation (minimum of 2 points, no gaps)

2. Can we stick with the comma separator?

On Thu, Mar 13, 2014 at 8:09 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Both the use case and the format makes sense to me.

On Wed, Mar 12, 2014 at 5:17 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

Should anyone ever implement a geoline widget, you might want to save
the
first point, then later save the 2nd point.

This would be, e.g., in the Savepoint XML file.

On Wed, Mar 12, 2014 at 4:50 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

The prompts will be typed, right?. So why not a blank string for a
geo* that has never been captured?

Then geoline is 2 or more geopoints separated by semi-colon. Geoshape
is 3 or more points separated by semi-colon. Note that the first point
doesn't have to equal the last in geoshape to make it valid.

I guess I don't understand why you'd need the not-yet-captured state.

On Wed, Mar 12, 2014 at 4:21 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

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 yanokwa@nafundi.com 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

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

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

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

[Trung]

Hi all,
I'm happy to announce that folks at RT Lab (RTA) has built a version of ODK
collect that is able to capture geoline and geoshape. We have tested and
everything seems fine but it would be great that the community tests it and
gives us feedback. Once everything is alright, we will contribute the codes
to the Core team so that it can be integrated in the official ODK Collect.

Please download the ODK Collect version
here: https://www.dropbox.com/s/6y7v2stelqlqjk0/ODK%20Collect.apk
Some forms we use to test the functionality:

• https://www.dropbox.com/s/nqchljexxgfcro4/FA%20-%20NAM%20-%20SAMPLE_GEO_POINT.xml
• https://www.dropbox.com/s/tvsqrvk5gx0bbbd/ODK%20-%20geo.xml

Thanks,
Trung.

···

On Tuesday, May 20, 2014 12:05:31 PM UTC+7, planne...@gmail.com wrote: > > Dear Trung, > > Any progress on this. Capturing polygons and polyline is really much > needed requirement. It will ease geo-data collection. > > Thanks > > On Friday, April 18, 2014 6:30:55 AM UTC+5, Trung Dang Le wrote: > > Dear Mitch, > > > > > > > > I wrote to you yesterday saying that our team at Real-Time Analytics in > Vietnam has committed to writing widgets for taking polygon and polyline. > We are happy to contribute the code to the team. I said we needed a week to > get it done but likely we will finalize it faster. > > > > > > > > Please let me know. > > > > Best, > > > > Trung. > > > > > > > > On Tuesday, April 15, 2014 2:51:15 PM UTC+7, Eddy Rellum wrote: > > > > > Dear Yaw and Martijn, > > > > > > > > > > > > > > > Thanks for this explanation. Very clear and good to hear that one can > help building the tool. Pretty logical of course with open source, but now > the process is a bit more clear. I will certainly look for ways how our > organisation can contribute to the development of the ODK functionality. > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > Ed > > > > > > > > > > On Tuesday, April 15, 2014 3:02:54 AM UTC+2, Martijn van de Rijdt wrote: > > > > > Hi Ed, > > > > > > > > > > > > > > > Up to now, implementing your tool for testing seems quite 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 > > > > > > > > > > > > > > > > > > > > No, it won't be technical at all once the new datatypes (geoshape and > geotrace) have been added to XLSForm (and once the next ODK Aggregate > version is released, I believe). A company called Ona has committed to do > the XLSForm work. After that implementing it is the same as any other type > of question (type=text, type=geoshape, type=integer, etc). > > > > > > > > > > > > > > > However, note that Enketo and ODK Collect are 2 different applications > that do more or less the same. It will initially only work in Enketo (as > Yaw mentioned implementing this in ODK Collect means hiring someone (like > the good folks at Nafundi) or developing it yourself.) > > > > > > > > > > > > > > > Cheers, > > > > > Martijn > > > > > > > > > > > > > > > On Monday, April 14, 2014 5:59:38 PM UTC-6, Yaw Anokwa wrote: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 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, <4est...@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...:-) > > > > > > > > > > >> > > > > > > > > > > >> 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. > >