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.
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
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.
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 fieldWhat I don't know is how fragile the Javarosa code is. This would
rely
on it allowing a StringData object to be stored in a GeolineData
or
GeoshapeData tree element. I don't know if the code is able to
handle that
(it looks like it could).Going forward, the Activity used for the 'placement-map'
appearance
of
the geopoint could be the starting point for the two needed
widgets
in
Collect.
Mitch
On Wed, Feb 12, 2014 at 12:20 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Thanks Chris,
In this case, it would be better to do it right, right away
because
there isn't a great incremental approach from the hack to the
proper
solution, so worth a (long) shot - less technical debt.On Wed, Feb 12, 2014 at 1:10 PM, Christopher Robert cro...@surveycto.com wrote:
Martijn,
This sounds great!
Unfortunately, we have not had any requests for this among our
clients, so we wouldn't be in a position to prioritize
contributions. Also,
to be honest, we would naturally take the approach of
implementing
minimally
-- particularly until there was sufficient demand and clear
benefit
to a
more maximal implementation. Thus, the "start as a string
appearance"
approach makes a lot of sense to me. It's just not clear that the
maximal
vs. minimal implementation maximizes social value. (Sorry, I'm an
economist.
But I think that the young Agile types might also agree with the
less-than-all-in approach.)Best,
Chris
P.S. Maybe this message will provoke an outcry from our clients
who
have been waiting for such features. If so, we'll react
accordingly!On Wed, Feb 12, 2014 at 2:36 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK/Nafundi/SurveyCTO/Formhub/Ona/Commcare/Other devs,
A sponsor is paying for two hot features in Enketo: the
development
of
geoshape and geoline widgets. This company wants to use Enketo
with
a server
that is not based on Aggregate, Formhub or CommCare and is fine
with using
type="string" and appearance="geoshape"/appearance="geoline"....
This would
obviously be a hack and not use the appearance attribute for what
it is
meant for, nor would it have proper server-side datatype
validation
of
submissions.... but it would work for my client and would also
work
with the
current XLSForm, Validate, Aggregate, SurveyCTO and Formhub if
Enketo is
used as a client (It would simply show up as a text field in
Collect).This message is an attempt at doing this properly by instead
using
new
datatypes (no new appearances) if there is interest and
time/funding from
some of you.I propose to introduce new XForm datatypes "geoshape" and
"geoline"
with a format that is a comma-separated list of the current
geopoint
datatype (of space-separated coordinates, altitude and accuracy):geoshape: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3
lng3
alt3 acc3, lat1 lng1 alt1 acc1" (final geopoint is equal to
first)
geoline: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3 lng3
alt3
acc3"It would then be up to the server or data analysis tool whether
to
transform this into a more useful format such as GeoJSON.Doing this would require:
ODK Validate supportXLSForm supportODK Aggregate++ support Formhub++ supportODK
Collect++
support (or show 'not supported yet' warning)I know other groups have worked on similar widgets for Collect.
If
any
of these can be accepted (or made acceptable) in the main
branches
of ODK
Validate, ODK Aggregate, ODK Collect, they would be great to use
as
a
starting point.Any comments, interest, ability to work on this?
Martijn
--
You received this message because you are subscribed to the
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
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, visithttps://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
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
Both the use case and the format makes sense to me.
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.
Sounds good to approach un-captured states like that. Some things to
clarify though:
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)
Can we stick with the comma separator?
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 fieldWhat I don't know is how fragile the Javarosa code is. This
would
rely
on it allowing a StringData object to be stored in a
GeolineData
or
GeoshapeData tree element. I don't know if the code is able to
handle that
(it looks like it could).Going forward, the Activity used for the 'placement-map'
appearance
of
the geopoint could be the starting point for the two needed
widgets
in
Collect.
Mitch
On Wed, Feb 12, 2014 at 12:20 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Thanks Chris,
In this case, it would be better to do it right, right away
because
there isn't a great incremental approach from the hack to the
proper
solution, so worth a (long) shot - less technical debt.On Wed, Feb 12, 2014 at 1:10 PM, Christopher Robert cro...@surveycto.com wrote:
Martijn,
This sounds great!
Unfortunately, we have not had any requests for this among our
clients, so we wouldn't be in a position to prioritize
contributions. Also,
to be honest, we would naturally take the approach of
implementing
minimally
-- particularly until there was sufficient demand and clear
benefit
to a
more maximal implementation. Thus, the "start as a string
appearance"
approach makes a lot of sense to me. It's just not clear that
the
maximal
vs. minimal implementation maximizes social value. (Sorry, I'm
an
economist.
But I think that the young Agile types might also agree with
the
less-than-all-in approach.)Best,
Chris
P.S. Maybe this message will provoke an outcry from our
clients
who
have been waiting for such features. If so, we'll react
accordingly!On Wed, Feb 12, 2014 at 2:36 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK/Nafundi/SurveyCTO/Formhub/Ona/Commcare/Other devs,
A sponsor is paying for two hot features in Enketo: the
development
of
geoshape and geoline widgets. This company wants to use Enketo
with
a server
that is not based on Aggregate, Formhub or CommCare and is
fine
with using
type="string" and
appearance="geoshape"/appearance="geoline"....
This would
obviously be a hack and not use the appearance attribute for
what
it is
meant for, nor would it have proper server-side datatype
validation
of
submissions.... but it would work for my client and would also
work
with the
current XLSForm, Validate, Aggregate, SurveyCTO and Formhub if
Enketo is
used as a client (It would simply show up as a text field in
Collect).This message is an attempt at doing this properly by instead
using
new
datatypes (no new appearances) if there is interest and
time/funding from
some of you.I propose to introduce new XForm datatypes "geoshape" and
"geoline"
with a format that is a comma-separated list of the current
geopoint
datatype (of space-separated coordinates, altitude and
accuracy):geoshape: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3
lng3
alt3 acc3, lat1 lng1 alt1 acc1" (final geopoint is equal to
first)
geoline: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3
lng3
alt3
acc3"It would then be up to the server or data analysis tool
whether
to
transform this into a more useful format such as GeoJSON.Doing this would require:
ODK Validate supportXLSForm supportODK Aggregate++ support Formhub++ supportODK
Collect++
support (or show 'not supported yet' warning)I know other groups have worked on similar widgets for
Collect.
If
any
of these can be accepted (or made acceptable) in the main
branches
of ODK
Validate, ODK Aggregate, ODK Collect, they would be great to
use
as
a
starting point.Any comments, interest, ability to work on this?
Martijn
--
You received this message because you are subscribed to the
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
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
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
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
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, visithttps://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
Dear Trung,
Any progress on this. Capturing polygons and polyline is really much needed requirement. It will ease geo-data collection.
Thanks
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.
Sounds good to approach un-captured states like that. Some things to
clarify though:
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)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 fieldWhat I don't know is how fragile the Javarosa code is. This
would
rely
on it allowing a StringData object to be stored in a
GeolineData
or
GeoshapeData tree element. I don't know if the code is able
to
handle that
(it looks like it could).Going forward, the Activity used for the 'placement-map'
appearance
of
the geopoint could be the starting point for the two needed
widgets
in
Collect.
Mitch
On Wed, Feb 12, 2014 at 12:20 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Thanks Chris,
In this case, it would be better to do it right, right away
because
there isn't a great incremental approach from the hack to the
proper
solution, so worth a (long) shot - less technical debt.On Wed, Feb 12, 2014 at 1:10 PM, Christopher Robert cro...@surveycto.com wrote:
Martijn,
This sounds great!
Unfortunately, we have not had any requests for this among
our
clients, so we wouldn't be in a position to prioritize
contributions. Also,
to be honest, we would naturally take the approach of
implementing
minimally
-- particularly until there was sufficient demand and clear
benefit
to a
more maximal implementation. Thus, the "start as a string
appearance"
approach makes a lot of sense to me. It's just not clear that
the
maximal
vs. minimal implementation maximizes social value. (Sorry,
I'm
an
economist.
But I think that the young Agile types might also agree with
the
less-than-all-in approach.)Best,
Chris
P.S. Maybe this message will provoke an outcry from our
clients
who
have been waiting for such features. If so, we'll react
accordingly!On Wed, Feb 12, 2014 at 2:36 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK/Nafundi/SurveyCTO/Formhub/Ona/Commcare/Other devs,
A sponsor is paying for two hot features in Enketo: the
development
of
geoshape and geoline widgets. This company wants to use
Enketo
with
a server
that is not based on Aggregate, Formhub or CommCare and is
fine
with using
type="string" and
appearance="geoshape"/appearance="geoline"....
This would
obviously be a hack and not use the appearance attribute for
what
it is
meant for, nor would it have proper server-side datatype
validation
of
submissions.... but it would work for my client and would
also
work
with the
current XLSForm, Validate, Aggregate, SurveyCTO and Formhub
if
Enketo is
used as a client (It would simply show up as a text field in
Collect).This message is an attempt at doing this properly by instead
using
new
datatypes (no new appearances) if there is interest and
time/funding from
some of you.I propose to introduce new XForm datatypes "geoshape" and
"geoline"
with a format that is a comma-separated list of the current
geopoint
datatype (of space-separated coordinates, altitude and
accuracy):geoshape: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3
lng3
alt3 acc3, lat1 lng1 alt1 acc1" (final geopoint is equal to
first)
geoline: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3
lng3
alt3
acc3"It would then be up to the server or data analysis tool
whether
to
transform this into a more useful format such as GeoJSON.Doing this would require:
ODK Validate supportXLSForm supportODK Aggregate++ support Formhub++ supportODK
Collect++
support (or show 'not supported yet' warning)I know other groups have worked on similar widgets for
Collect.
If
any
of these can be accepted (or made acceptable) in the main
branches
of ODK
Validate, ODK Aggregate, ODK Collect, they would be great to
use
as
a
starting point.Any comments, interest, ability to work on this?
Martijn
--
You received this message because you are subscribed to the
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
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
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
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
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, visithttps://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
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:
Thanks,
Trung.
That seems fair ;).
A (genuine) question: Does the decimal type in Javarosa not make an
assumption about internationalization and formatting of the values? I think
it may do this in Enketo.
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 martijn@enketo.orgwrote:
Sounds good to approach un-captured states like that. Some things to
clarify though:
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)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 fieldWhat I don't know is how fragile the Javarosa code is. This
would
rely
on it allowing a StringData object to be stored in a
GeolineData
or
GeoshapeData tree element. I don't know if the code is able
to
handle that
(it looks like it could).Going forward, the Activity used for the 'placement-map'
appearance
of
the geopoint could be the starting point for the two needed
widgets
in
Collect.
Mitch
On Wed, Feb 12, 2014 at 12:20 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Thanks Chris,
In this case, it would be better to do it right, right away
because
there isn't a great incremental approach from the hack to
the
proper
solution, so worth a (long) shot - less technical debt.On Wed, Feb 12, 2014 at 1:10 PM, Christopher Robert cro...@surveycto.com wrote:
Martijn,
This sounds great!
Unfortunately, we have not had any requests for this among
our
clients, so we wouldn't be in a position to prioritize
contributions. Also,
to be honest, we would naturally take the approach of
implementing
minimally
-- particularly until there was sufficient demand and clear
benefit
to a
more maximal implementation. Thus, the "start as a string
appearance"
approach makes a lot of sense to me. It's just not clear
that
the
maximal
vs. minimal implementation maximizes social value. (Sorry,
I'm
an
economist.
But I think that the young Agile types might also agree
with the
less-than-all-in approach.)Best,
Chris
P.S. Maybe this message will provoke an outcry from our
clients
who
have been waiting for such features. If so, we'll react
accordingly!On Wed, Feb 12, 2014 at 2:36 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK/Nafundi/SurveyCTO/Formhub/Ona/Commcare/Other devs,
A sponsor is paying for two hot features in Enketo: the
development
of
geoshape and geoline widgets. This company wants to use
Enketo
with
a server
that is not based on Aggregate, Formhub or CommCare and is
fine
with using
type="string" and
appearance="geoshape"/appearance="geoline"....
This would
obviously be a hack and not use the appearance attribute for
what
it is
meant for, nor would it have proper server-side datatype
validation
of
submissions.... but it would work for my client and would
also
work
with the
current XLSForm, Validate, Aggregate, SurveyCTO and Formhub
if
Enketo is
used as a client (It would simply show up as a text field in
Collect).This message is an attempt at doing this properly by instead
using
new
datatypes (no new appearances) if there is interest and
time/funding from
some of you.I propose to introduce new XForm datatypes "geoshape" and
"geoline"
with a format that is a comma-separated list of the current
geopoint
datatype (of space-separated coordinates, altitude and
accuracy):geoshape: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2,
lat3
lng3
alt3 acc3, lat1 lng1 alt1 acc1" (final geopoint is equal to
first)
geoline: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3
lng3
alt3
acc3"It would then be up to the server or data analysis tool
whether
to
transform this into a more useful format such as GeoJSON.Doing this would require:
ODK Validate supportXLSForm supportODK Aggregate++ support Formhub++ supportODK
Collect++
support (or show 'not supported yet' warning)I know other groups have worked on similar widgets for
Collect.
If
any
of these can be accepted (or made acceptable) in the main
branches
of ODK
Validate, ODK Aggregate, ODK Collect, they would be great
to use
as
a
starting point.Any comments, interest, ability to work on this?
Martijn
--
You received this message because you are subscribed to the
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
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
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
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
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, visithttps://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
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--
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
That's great to hear Trung.
The feature has now officially launched in Enketo
too: http://blog.enketo.org/geo/
From the code, it is using:
Double.parseDouble(trimmedText)
The separator is not so much an issue in the Javarosa or ODK layers if
everything is type checked and managed by our software.
It is a larger issue when publishing to downstream systems -- making the
representation unambiguous to those systems.
But, worse, is the case where there are no ODK widgets to capture these
values. ODK Collect would present a String widget
for the user to manually enter the data. If the user enters the geolocation
according to their locale's usage, e.g., using commas for
decimal points, the downstream processing will be very difficult.
Mitch
That seems fair ;).
A (genuine) question: Does the decimal type in Javarosa not make an
assumption about internationalization and formatting of the values? I think
it may do this in Enketo.On Fri, Mar 14, 2014 at 10:50 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
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 <martijn@enketo.org wrote:
Sounds good to approach un-captured states like that. Some things to
clarify though:
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)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 fieldWhat I don't know is how fragile the Javarosa code is. This
would
rely
on it allowing a StringData object to be stored in a
GeolineData
or
GeoshapeData tree element. I don't know if the code is
able to
handle that
(it looks like it could).Going forward, the Activity used for the 'placement-map'
appearance
of
the geopoint could be the starting point for the two needed
widgets
in
Collect.
Mitch
On Wed, Feb 12, 2014 at 12:20 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Thanks Chris,
In this case, it would be better to do it right, right away
because
there isn't a great incremental approach from the hack to
the
proper
solution, so worth a (long) shot - less technical debt.On Wed, Feb 12, 2014 at 1:10 PM, Christopher Robert cro...@surveycto.com wrote:
Martijn,
This sounds great!
Unfortunately, we have not had any requests for this among
our
clients, so we wouldn't be in a position to prioritize
contributions. Also,
to be honest, we would naturally take the approach of
implementing
minimally
-- particularly until there was sufficient demand and clear
benefit
to a
more maximal implementation. Thus, the "start as a string
appearance"
approach makes a lot of sense to me. It's just not clear
that
the
maximal
vs. minimal implementation maximizes social value. (Sorry,
I'm
an
economist.
But I think that the young Agile types might also agree
with the
less-than-all-in approach.)Best,
Chris
P.S. Maybe this message will provoke an outcry from our
clients
who
have been waiting for such features. If so, we'll react
accordingly!On Wed, Feb 12, 2014 at 2:36 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK/Nafundi/SurveyCTO/Formhub/Ona/Commcare/Other devs,
A sponsor is paying for two hot features in Enketo: the
development
of
geoshape and geoline widgets. This company wants to use
Enketo
with
a server
that is not based on Aggregate, Formhub or CommCare and is
fine
with using
type="string" and
appearance="geoshape"/appearance="geoline"....
This would
obviously be a hack and not use the appearance attribute
for
what
it is
meant for, nor would it have proper server-side datatype
validation
of
submissions.... but it would work for my client and would
also
work
with the
current XLSForm, Validate, Aggregate, SurveyCTO and
Formhub if
Enketo is
used as a client (It would simply show up as a text field
in
Collect).This message is an attempt at doing this properly by
instead
using
new
datatypes (no new appearances) if there is interest and
time/funding from
some of you.I propose to introduce new XForm datatypes "geoshape" and
"geoline"
with a format that is a comma-separated list of the current
geopoint
datatype (of space-separated coordinates, altitude and
accuracy):geoshape: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2,
lat3
lng3
alt3 acc3, lat1 lng1 alt1 acc1" (final geopoint is equal to
first)
geoline: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2,
lat3 lng3
alt3
acc3"It would then be up to the server or data analysis tool
whether
to
transform this into a more useful format such as GeoJSON.Doing this would require:
ODK Validate supportXLSForm supportODK Aggregate++ support Formhub++ supportODK
Collect++
support (or show 'not supported yet' warning)I know other groups have worked on similar widgets for
Collect.
If
any
of these can be accepted (or made acceptable) in the main
branches
of ODK
Validate, ODK Aggregate, ODK Collect, they would be great
to use
as
a
starting point.Any comments, interest, ability to work on this?
Martijn
--
You received this message because you are subscribed to the
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
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
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
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
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, visithttps://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
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--
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
Anyone has tested the Collect version with geoshape and geoline yet?
Trung,
I tried it a bit and the functionality is there. Thanks for building it!
Icons weren't intuitive to me. X is for removing the last point, but
it could also be cancel and close window. Save saves the current point
but it could also be save the form. Maybe a place mark with a plus for
add and a minus to remove. Maybe use text labels so it's clear (and
localizable). Also maybe move the buttons down so they don't cover up
the gray bar at top.
Do you have a plan for supporting map based input? That is, users will
probably want to select a place on the map and add a pin there.
Yaw
On Tue, May 27, 2014 at 5:44 AM, Trung Dang Le trungdangle@gmail.com wrote:
Anyone has tested the Collect version with geoshape and geoline yet?
On Thursday, May 22, 2014 5:44:12 PM UTC+1, Martijn van de Rijdt wrote:
That's great to hear Trung.
The feature has now officially launched in Enketo too:
http://blog.enketo.org/geo/On Tuesday, May 20, 2014 4:30:58 AM UTC-6, Trung Dang Le wrote:
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
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 directlyNo, 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: wejust added two new functions to SurveyCTO, for our upcoming 1.21
release:distance-between(geopointfield1, geopointfield2): Returns the
distance, inmeters, between two geopoint fields (as in the calculate expression
"distance-between(${start_gps}, ${end_gps})"). (Keep in mind that
theaccuracy of the distance calculated will depend on the accuracy of
the GPSreadings, 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
thecalculate expression "enclosed-area(${gps_reading})", called outside
arepeat group that includes the gps_reading field). (Keep in mind
that theaccuracy of the area calculated will depend on the accuracy of the
GPSreadings, so try to be sure to get accurate GPS readings.)
For the latter function, it is a series of repeated geopoint fields
ratherthan a single geoshape; and for the former it is two individual
geopointfields rather than a single geoline. We implemented these on the
spur of themoment to support an existing customer, and they seemed potentially
usefulfor other SurveyCTO customers as well.
As geoline and geoshape become supported throughout the toolset, we
caneasily 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 becauseit is very useful to me and my workfield. I am planning to try to
find somefinancing so that the community can build in extra ODK
functionality forsupport sustainable land use projects. I have clear ideas for what
is neededwithin the sustainable land use community. As said before, one of
the mostimportant things here is that you can map an area automatically (by
walkingaround a parcel, just as the tracking mode with GPS, taking a
coordinatebased 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 onlyaccessible to programming experts that are acquintanced with
Xforms. Am Icorrect? As an end-user I am only working with XLSForms, not within
Xformsdirectly. 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 ODKso that everyone who used ODK collect/ODK-build (XLSForms) and
Aggregatecould use this tool? Would additional financing speed things up or
do I justhave to be more pacient with ODK...? So how does this work if I
find somefinancing 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 forthe 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
supportin 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) orfor 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
youare referring to Enketo which is partly a paid service. Will this
tool(geoshape/geoline) also become available as opensource (ODK
collect and ODKaggregate)? If so, can you indicate when this will be available?
I am busysetting up a large fieldwork campaign for sustainable agriculture
projectswith small holder farmers in Afrika and South America for which
this toolwould be very valuable. Would be good to know if I can implement
thesefeatures (polygons and polylines) in my ODK forms and aggregate
service.FYI: The link between Enketo and ODK is not yet entirely clear to
methat 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 onUX). 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 andis planned to become available next month. Read more details
here: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 usein development countries. I am using ODK for our small holder
projects tocollect field data in an efficient manner. In my work field we
work withareas (polygons); many of the field data is related to an area
unit ratherthan to a single point. Hence, a polygon option in ODK and
connectingattribute data to these polygons would be ideal for my work. I
am sure thatmany my colleagues working in land use, forestry etc. are
waiting for suchan extension. ODK is already perfect with the geopoint option,
but when youcould also create polygons I am sure ODK will be used by many
others in byarea. Is it clear if this option will be build in? And in case
the plan isthere: 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
beenbuilding 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
developmentof geoshape and geoline widgets. This company wants to use
Enketo with aserver that is not based on Aggregate, Formhub or CommCare
and is fine withusing type="string" and
appearance="geoshape"/appearance="geoline".... Thiswould obviously be a hack and not use the appearance
attribute for what itis meant for, nor would it have proper server-side datatype
validation ofsubmissions.... but it would work for my client and would
also work with thecurrent XLSForm, Validate, Aggregate, SurveyCTO and Formhub
if Enketo isused 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
usingnew datatypes (no new appearances) if there is interest and
time/fundingfrom 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
geopointdatatype (of space-separated coordinates, altitude and
accuracy):geoshape: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3
lng3alt3 acc3, lat1 lng1 alt1 acc1" (final geopoint is equal to
first)geoline: "lat1 lng1 alt1 acc1, lat2 lng2 alt2 acc2, lat3
lng3alt3 acc3"
It would then be up to the server or data analysis tool
whether totransform 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. Ifany of these can be accepted (or made acceptable) in the main
branches ofODK Validate, ODK Aggregate, ODK Collect, they would be great
to use as astarting point.
Any comments, interest, ability to work on this?
<br
...
--
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.
Dear Yaw,
Many thanks for your useful comments. Our team is working on them.
And the next version will also include map-based inputs.
Hi, Trung.
I'm looking forward to get this feature in the next version of ODK Collect.
Will you contribute this feature?
Regards
Hi All,
We have updated and tested the next version of ODK collect that has widgets
for geoline and geoshape. The new version can be download
here: https://www.dropbox.com/s/h1dfddzbz4b9vdw/RTA%20-%20ODK%20Collect.apk
(again, a form to test can be downloaded
here: https://www.dropbox.com/s/qdqqeu5nvgop1c1/SAMPLE_GEO_POINT.xml)
We hope the version is good enough. And we're ready to share the code so
that the CORE team can incorporate into the next release.
Cheers,
Trung.
Thank you Trung
Hi All,
We have updated and tested the next version of ODK collect that has
widgets for geoline and geoshape. The new version can be download here:
https://www.dropbox.com/s/h1dfddzbz4b9vdw/RTA%20-%20ODK%20Collect.apk
(again, a form to test can be downloaded here:
https://www.dropbox.com/s/qdqqeu5nvgop1c1/SAMPLE_GEO_POINT.xml)We hope the version is good enough. And we're ready to share the code so
that the CORE team can incorporate into the next release.Cheers,
Trung.On Monday, June 9, 2014 10:44:48 AM UTC+7, Bunhann Thou wrote:
Hi, Trung.
I'm looking forward to get this feature in the next version of ODK
Collect. Will you contribute this feature?Regards
On Wednesday, May 28, 2014 2:44:26 AM UTC+7, Trung Dang Le wrote:
Dear Yaw,
Many thanks for your useful comments. Our team is working on them.
And the next version will also include map-based inputs.On Tuesday, May 27, 2014 3:54:32 PM UTC+1, Yaw Anokwa wrote:
Trung,
I tried it a bit and the functionality is there. Thanks for building it!
Icons weren't intuitive to me. X is for removing the last point, but
it could also be cancel and close window. Save saves the current point
but it could also be save the form. Maybe a place mark with a plus for
add and a minus to remove. Maybe use text labels so it's clear (and
localizable). Also maybe move the buttons down so they don't cover up
the gray bar at top.Do you have a plan for supporting map based input? That is, users will
probably want to select a place on the map and add a pin there.Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.On Tue, May 27, 2014 at 5:44 AM, Trung Dang Le trung...@gmail.com wrote:
Anyone has tested the Collect version with geoshape and geoline yet?
On Thursday, May 22, 2014 5:44:12 PM UTC+1, Martijn van de Rijdt wrote:
That's great to hear Trung.
The feature has now officially launched in Enketo too:
http://blog.enketo.org/geo/On Tuesday, May 20, 2014 4:30:58 AM UTC-6, Trung Dang Le wrote:
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.xmlThanks,
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 directlyNo, 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
forthe core team to do it. You should building (yourself or by
funding adeveloper) and the core team will most certainly merge it into the
core.
Yaw
--
Need ODK services? http://nafundi.com provides form design,
serversetup, 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: wejust added two new functions to SurveyCTO, for our upcoming 1.21
release:distance-between(geopointfield1, geopointfield2): Returns the
distance, inmeters, between two geopoint fields (as in the calculate
expression"distance-between(${start_gps}, ${end_gps})"). (Keep in mind
that
theaccuracy of the distance calculated will depend on the accuracy
of
the GPSreadings, so try to be sure to get accurate GPS readings.)
enclosed-area(repeatedgeopointfield): Returns the area
enclosed, insquare-meters, within a series of repeated geopoint fields (as
in
thecalculate expression "enclosed-area(${gps_reading})", called
outside
arepeat group that includes the gps_reading field). (Keep in mind
that theaccuracy of the area calculated will depend on the accuracy of
the
GPSreadings, so try to be sure to get accurate GPS readings.)
For the latter function, it is a series of repeated geopoint
fields
ratherthan a single geoshape; and for the former it is two individual
geopointfields rather than a single geoline. We implemented these on the
spur of themoment to support an existing customer, and they seemed
potentially
usefulfor other SurveyCTO customers as well.
As geoline and geoshape become supported throughout the toolset,
we
caneasily 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 becauseit is very useful to me and my workfield. I am planning to try
to
find somefinancing so that the community can build in extra ODK
functionality forsupport sustainable land use projects. I have clear ideas for
what
is neededwithin the sustainable land use community. As said before, one
of
the mostimportant things here is that you can map an area automatically
(by
walkingaround a parcel, just as the tracking mode with GPS, taking a
coordinatebased 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 onlyaccessible to programming experts that are acquintanced with
Xforms. Am Icorrect? As an end-user I am only working with XLSForms, not
within
Xformsdirectly. 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 ODKso that everyone who used ODK collect/ODK-build (XLSForms) and
Aggregatecould use this tool? Would additional financing speed things up
or
do I justhave to be more pacient with ODK...? So how does this work if I
find somefinancing for further development: Can I just apply to build
thisapplication within ODK (collect/build/aggregate)?
Good to discuss this so that I can take it into account. Thanks
again forthe 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
supportin 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.xmlYes, enketo.org is available as a paid service (with a free
level) orfor 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
youare referring to Enketo which is partly a paid service. Will
this
tool(geoshape/geoline) also become available as opensource (ODK
collect and ODKaggregate)? If so, can you indicate when this will be
available?
I am busysetting up a large fieldwork campaign for sustainable
agriculture
projectswith small holder farmers in Afrika and South America for
which
this toolwould be very valuable. Would be good to know if I can
implement
thesefeatures (polygons and polylines) in my ODK forms and
aggregate
service.FYI: The link between Enketo and ODK is not yet entirely
clear to
methat 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 onUX). 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 andis planned to become available next month. Read more
details
here: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 usein development countries. I am using ODK for our small
holder
projects tocollect field data in an efficient manner. In my work field
we
work withareas (polygons); many of the field data is related to an
area
unit ratherthan to a single point. Hence, a polygon option in ODK and
connectingattribute data to these polygons would be ideal for my
work. I
am sure thatmany my colleagues working in land use, forestry etc. are
waiting for suchan extension. ODK is already perfect with the geopoint
option,
but when youcould also create polygons I am sure ODK will be used by
many
others in byarea. Is it clear if this option will be build in? And in
case
the plan isthere: When could this be expected? Look forward to any
feedback on this.Thanks!
&
...
--
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.
Hi all, do we have support from Formhub for the new geoshape and geotrace widgets along with the newest release of ODK Collect?
Thanks!
