I am having an issue with the odk aggregator external link to google
docs. I am collecting data on multiple trees in different locations. I
built my form in ODK build; so im running a loop with tree
information: species, dbh, condition, location and then looping those
until I complete the site assessment of multiple trees at which time I
submit the completed project form with multiple tree info records.
My issue is that when you have these loops of data, after you submit a
completed form with multiple rows of data, aggregator adds a link to
the multiple row dataset instead of simply creating rows of
information in the view submission location as it would if you were
submitting multiple individual forms on ODK build. (Which works but is
cumbersome.)
When you access that link the rows that show up are unexportable from
aggregator. The connection that is made in google docs is basically
unusable because it only reads the link data from aggregator
submissions page, not the link page; which means the true input data:
trees, diameters etc... can't be viewed in docs through an external
connection to the aggregator.
Has anyone else run into this, is there an easy way around this?
I think the easy work around is to avoid repeats (let the surveyor do
the loop by starting a new survey for each tree). Unfortunately this
will probably slow down the surveying process.
Andrew
···
On Mon, Jan 24, 2011 at 2:24 PM, parks trial wrote:
> Hi,
>
> I am having an issue with the odk aggregator external link to google
> docs. I am collecting data on multiple trees in different locations. I
> built my form in ODK build; so im running a loop with tree
> information: species, dbh, condition, location and then looping those
> until I complete the site assessment of multiple trees at which time I
> submit the completed project form with multiple tree info records.
>
> My issue is that when you have these loops of data, after you submit a
> completed form with multiple rows of data, aggregator adds a link to
> the multiple row dataset instead of simply creating rows of
> information in the view submission location as it would if you were
> submitting multiple individual forms on ODK build. (Which works but is
> cumbersome.)
>
> When you access that link the rows that show up are unexportable from
> aggregator. The connection that is made in google docs is basically
> unusable because it only reads the link data from aggregator
> submissions page, not the link page; which means the true input data:
> trees, diameters etc... can't be viewed in docs through an external
> connection to the aggregator.
>
> Has anyone else run into this, is there an easy way around this?
>
> Travis
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
Aggregate 1.0 will solve this problem by creating a separate worksheet
that will be created for the repeats. Currently Aggregate 1.0 is on
alpha release 3 and we hope to push Aggregate 1.0 alpha 5 this week.
Cheers,
Wylon
···
On Mon, Jan 24, 2011 at 2:04 PM, Andrew Marder wrote:
> Hi Travis,
>
> I think the easy work around is to avoid repeats (let the surveyor do
> the loop by starting a new survey for each tree). Unfortunately this
> will probably slow down the surveying process.
>
> Andrew
>
> On Mon, Jan 24, 2011 at 2:24 PM, parks trial wrote:
>> Hi,
>>
>> I am having an issue with the odk aggregator external link to google
>> docs. I am collecting data on multiple trees in different locations. I
>> built my form in ODK build; so im running a loop with tree
>> information: species, dbh, condition, location and then looping those
>> until I complete the site assessment of multiple trees at which time I
>> submit the completed project form with multiple tree info records.
>>
>> My issue is that when you have these loops of data, after you submit a
>> completed form with multiple rows of data, aggregator adds a link to
>> the multiple row dataset instead of simply creating rows of
>> information in the view submission location as it would if you were
>> submitting multiple individual forms on ODK build. (Which works but is
>> cumbersome.)
>>
>> When you access that link the rows that show up are unexportable from
>> aggregator. The connection that is made in google docs is basically
>> unusable because it only reads the link data from aggregator
>> submissions page, not the link page; which means the true input data:
>> trees, diameters etc... can't be viewed in docs through an external
>> connection to the aggregator.
>>
>> Has anyone else run into this, is there an easy way around this?
>>
>> Travis
>>
>> --
>> Post: opendatakit@googlegroups.com
>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
Great, I've got it set up as Andrew suggested for now. Thanks again,
I'll keep my eyes open for 1.0. Truthfully i've had trouble creating
my own instance of aggregator. I'm running off the http://odk-tutorial.appspot.com/
currently;)
As a small note, ODK build doesn't send up a red flag when you label
your data name the same thing twice... until you try to run the form,
then its FC city. Troublesome for users like me. But something I
probably should have known without a prompt.
Travis
···
On Jan 25, 12:37 am, "W. Brunette" wrote:
> Aggregate 1.0 will solve this problem by creating a separate worksheet
> that will be created for the repeats. Currently Aggregate 1.0 is on
> alpha release 3 and we hope to push Aggregate 1.0 alpha 5 this week.
>
> Cheers,
> Wylon
>
> On Mon, Jan 24, 2011 at 2:04 PM, Andrew Marder wrote:
> > Hi Travis,
>
> > I think the easy work around is to avoid repeats (let the surveyor do
> > the loop by starting a new survey for each tree). Unfortunately this
> > will probably slow down the surveying process.
>
> > Andrew
>
> > On Mon, Jan 24, 2011 at 2:24 PM, parks trial wrote:
> >> Hi,
>
> >> I am having an issue with the odk aggregator external link to google
> >> docs. I am collecting data on multiple trees in different locations. I
> >> built my form in ODK build; so im running a loop with tree
> >> information: species, dbh, condition, location and then looping those
> >> until I complete the site assessment of multiple trees at which time I
> >> submit the completed project form with multiple tree info records.
>
> >> My issue is that when you have these loops of data, after you submit a
> >> completed form with multiple rows of data, aggregator adds a link to
> >> the multiple row dataset instead of simply creating rows of
> >> information in the view submission location as it would if you were
> >> submitting multiple individual forms on ODK build. (Which works but is
> >> cumbersome.)
>
> >> When you access that link the rows that show up are unexportable from
> >> aggregator. The connection that is made in google docs is basically
> >> unusable because it only reads the link data from aggregator
> >> submissions page, not the link page; which means the true input data:
> >> trees, diameters etc... can't be viewed in docs through an external
> >> connection to the aggregator.
>
> >> Has anyone else run into this, is there an easy way around this?
>
> >> Travis
>
> >> --
> >> Post: opendatakit@googlegroups.com
> >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> >> Options:http://groups.google.com/group/opendatakit?hl=en
>
> > --
> > Post: opendatakit@googlegroups.com
> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > Options:http://groups.google.com/group/opendatakit?hl=en
can you file a bug against this? we should be able to fix this easily.
yaw
···
On Tue, Jan 25, 2011 at 08:01, parks trial wrote:
> As a small note, ODK build doesn't send up a red flag when you label
> your data name the same thing twice... until you try to run the form,
> then its FC city. Troublesome for users like me. But something I
> probably should have known without a prompt.
>
I can't seem to replicate the error. I sent in a few of my FC's
earlier today from the samsung tab. I think instead it may have been
an error with the English vs. the underlying values. if you don't have
the underlying values completely filled out the form wont upload to
aggregate. Or if it does it causes FC's.
Travis
···
On Jan 25, 10:45 am, Yaw Anokwa wrote:
> travis,
>
> can you file a bug against this? we should be able to fix this easily.
>
> yaw
>
>
>
>
>
>
>
> On Tue, Jan 25, 2011 at 08:01, parks trial wrote:
> > As a small note, ODK build doesn't send up a red flag when you label
> > your data name the same thing twice... until you try to run the form,
> > then its FC city. Troublesome for users like me. But something I
> > probably should have known without a prompt.
we got those stack traces and they help. what is more important is to
get a copy of the form so we can reproduce it and make sure it's fixed
properly. you can attach the form to a report at http://code.google.com/p/opendatakit/issues/list. thanks!
···
On Tue, Jan 25, 2011 at 16:23, Travis wrote:
> Hi Yaw,
>
> I can't seem to replicate the error. I sent in a few of my FC's
> earlier today from the samsung tab. I think instead it may have been
> an error with the English vs. the underlying values. if you don't have
> the underlying values completely filled out the form wont upload to
> aggregate. Or if it does it causes FC's.
>
> Travis
>
>
> On Jan 25, 10:45 am, Yaw Anokwa wrote:
>> travis,
>>
>> can you file a bug against this? we should be able to fix this easily.
>>
>> yaw
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 25, 2011 at 08:01, parks trial wrote:
>> > As a small note, ODK build doesn't send up a red flag when you label
>> > your data name the same thing twice... until you try to run the form,
>> > then its FC city. Troublesome for users like me. But something I
>> > probably should have known without a prompt.
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>