Running this new release in test mode but hoping to move to my production
environment soon as it resolves existing issues with Aggregate 0.9.6 (Others
note that release 0.9.7 is the stable version). Looks like a complete UI
congrats.
A couple of questions/issues:
I'd like the have the GPS data show up the way it did before
(aggregate 0.9.6 --> fusion tables). Is there a way to force that in the
xform definition?
The spreadsheet name appears to be inherited from the tag for the
whatchamacallit . If I change <data to <form_y then I can have a
name in FusionTables that is more to my liking. Is this by design? It
takes a lot of xform manipulation to get to that.
Date field - any way to make that backwards compatible with the
previous naming? Is there an xform setting?
I'm still trying to decide when to make this move. Aggregate 0.9.7 might be
a better option given these data structure issues and the code we've written
to pull from fusion tables to our app.
The format change on the GPS was requested by Google to better fit
the fusion table model as it fits now how they represent a geopoint in
fusion tables. I think we are open to discussion if there is a good
reason.
The code works the same as 0.9.7 in regards to naming. The
interesting question is it's not just one name of a table, it's the
name of the form and all the repeat tags. So it would be a multiple
prompt complicated UI interaction.
I am not even going to weigh in on this one... as much email
traffic we have gotten on formatting dates. I think Yaw and Mitch have
done their best to make the largest group of users happy. I will let
them weigh in.
Waylon
···
On Mon, Sep 26, 2011 at 11:53 AM, James Dailey wrote:
> ODK'ers
> Running this new release in test mode but hoping to move to my production
> environment soon as it resolves existing issues with Aggregate 0.9.6 (Others
> - note that release 0.9.7 is the stable version). Looks like a complete UI
> - congrats.
> A couple of questions/issues:
>
> I'd like the have the GPS data show up the way it did before (aggregate
> 0.9.6 --> fusion tables). Is there a way to force that in the xform
> definition?
> The spreadsheet name appears to be inherited from the tag for the
> whatchamacallit . If I change <data to name in FusionTables that is more to my liking. Is this by design? It
> takes a lot of xform manipulation to get to that.
> Date field - any way to make that backwards compatible with the previous
> naming? Is there an xform setting?
>
> I'm still trying to decide when to make this move. Aggregate 0.9.7 might be
> a better option given these data structure issues and the code we've written
> to pull from fusion tables to our app.
> --
> James Dailey
> skype: jdailey
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
i don't understand "Date field - any way to make that backwards
compatible with the previous naming?" can you explain why this is a problem?
yaw
···
On Mon, Sep 26, 2011 at 22:02, W. Brunette wrote:
> 1) The format change on the GPS was requested by Google to better fit
> the fusion table model as it fits now how they represent a geopoint in
> fusion tables. I think we are open to discussion if there is a good
> reason.
>
> 2) The code works the same as 0.9.7 in regards to naming. The
> interesting question is it's not just one name of a table, it's the
> name of the form and all the repeat tags. So it would be a multiple
> prompt complicated UI interaction.
>
> 3) I am not even going to weigh in on this one... as much email
> traffic we have gotten on formatting dates. I think Yaw and Mitch have
> done their best to make the largest group of users happy. I will let
> them weigh in.
>
> Waylon
>
> On Mon, Sep 26, 2011 at 11:53 AM, James Dailey wrote:
>> ODK'ers
>> Running this new release in test mode but hoping to move to my production
>> environment soon as it resolves existing issues with Aggregate 0.9.6 (Others
>> - note that release 0.9.7 is the stable version). Looks like a complete UI
>> - congrats.
>> A couple of questions/issues:
>>
>> I'd like the have the GPS data show up the way it did before (aggregate
>> 0.9.6 --> fusion tables). Is there a way to force that in the xform
>> definition?
>> The spreadsheet name appears to be inherited from the tag for the
>> whatchamacallit . If I change <data to > name in FusionTables that is more to my liking. Is this by design? It
>> takes a lot of xform manipulation to get to that.
>> Date field - any way to make that backwards compatible with the previous
>> naming? Is there an xform setting?
>>
>> I'm still trying to decide when to make this move. Aggregate 0.9.7 might be
>> a better option given these data structure issues and the code we've written
>> to pull from fusion tables to our app.
>> --
>> James Dailey
>> skype: jdailey
>>
>> --
>> 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
>
Thanks for the responses. Of the three issues, the date one is the least of
them. What we have created is an infrastructure where we are expecting
certain field names and data types - this is a relatively minor change that
requires us to parse the date differently. If it were possible to have an
option, that would be nice to have.
The GPS format is pretty cool for how it confirms to google's vision for
fusion tables, but parsing out the string on our server is a pain point for
moving to the new version of Aggregate. The option I'd really want here is
to include both versions - i.e. the Lat, Long and the KML version.
Duplicate a little bit, no idea of the other implications.
The biggest issue by far is the field naming issue. This even seems like a
bug. The behavior I see is that when I publish my table from Aggregate
1.0-RC1, the name of the table is NOT used for the name of the table in
fusiontables. Its also NOT using the ID value. Instead, the root of
is used for the name - all tables get name of "data". Maybe that is
a result of not having full xform compliance in my xform, I don't know. I
do know that the interface says "use table name" and instead it uses the
tag. I confirmed this by changing to something else and voila
the table name changed. This is really a problem for when there are more
than one form and therefore tables.
James
···
On Wed, Sep 28, 2011 at 11:56 AM, Yaw Anokwa wrote:
hey james,
i don't understand "Date field - any way to make that backwards
compatible with the previous naming?" can you explain why this is a
problem?
The format change on the GPS was requested by Google to better fit
the fusion table model as it fits now how they represent a geopoint in
fusion tables. I think we are open to discussion if there is a good
reason.
The code works the same as 0.9.7 in regards to naming. The
interesting question is it's not just one name of a table, it's the
name of the form and all the repeat tags. So it would be a multiple
prompt complicated UI interaction.
I am not even going to weigh in on this one... as much email
traffic we have gotten on formatting dates. I think Yaw and Mitch have
done their best to make the largest group of users happy. I will let
them weigh in.
ODK'ers
Running this new release in test mode but hoping to move to my
production
environment soon as it resolves existing issues with Aggregate 0.9.6
(Others
note that release 0.9.7 is the stable version). Looks like a complete
UI
congrats.
A couple of questions/issues:
I'd like the have the GPS data show up the way it did before (aggregate
0.9.6 --> fusion tables). Is there a way to force that in the xform
definition?
The spreadsheet name appears to be inherited from the tag for the
whatchamacallit . If I change <data to <form_y then I can
have a
name in FusionTables that is more to my liking. Is this by design? It
takes a lot of xform manipulation to get to that.
Date field - any way to make that backwards compatible with the previous
naming? Is there an xform setting?
I'm still trying to decide when to make this move. Aggregate 0.9.7
might be
a better option given these data structure issues and the code we've
written
to pull from fusion tables to our app.
The behavior I see is that when I publish my table from Aggregate 1.0-RC1, the name of the table is NOT used for the name of the table in fusiontables.
It is not designed to use the title, it's designed to use the xml node
name that corresponds to the needed table. The 1.x code works the same
as 0.9.7 in regards to naming. The issue is we need to generate
multiple tables per form so a single name won't work (we have the name
of the main table and all the repeat tables). So it would be a
multiple prompt complicated UI interaction to get all the names
squared away so we chose not to try to design a UI prompt system. To
make it easy we are using the node name as you end up with distinctive
names for each part. Google spreadsheets works the same way, we allow
you to name the spreadsheet but the worksheet is named automatically
based on the xml node name. This also keeps it easier as people avoid
putting illegal characters generally in the xml node.
Once we are able to have an API to merge columns together across
fusion tables we might consider have one overall name for the main,
merged table. Please feel free to file an issue if you like for us to
keep this in mind for future reference.
···
On Wed, Sep 28, 2011 at 6:01 PM, James Dailey wrote:
> Yaw/Mitch -
> Thanks for the responses. Of the three issues, the date one is the least of
> them. What we have created is an infrastructure where we are expecting
> certain field names and data types - this is a relatively minor change that
> requires us to parse the date differently. If it were possible to have an
> option, that would be nice to have.
> The GPS format is pretty cool for how it confirms to google's vision for
> fusion tables, but parsing out the string on our server is a pain point for
> moving to the new version of Aggregate. The option I'd really want here is
> to include both versions - i.e. the Lat, Long and the KML version.
> Duplicate a little bit, no idea of the other implications.
> The biggest issue by far is the field naming issue. This even seems like a
> bug. The behavior I see is that when I publish my table from Aggregate
> 1.0-RC1, the name of the table is NOT used for the name of the table in
> fusiontables. Its also NOT using the ID value. Instead, the root of
> is used for the name - all tables get name of "data". Maybe that is
> a result of not having full xform compliance in my xform, I don't know. I
> do know that the interface says "use table name" and instead it uses the
> tag. I confirmed this by changing to something else and voila
> the table name changed. This is really a problem for when there are more
> than one form and therefore tables.
> - James
>
> On Wed, Sep 28, 2011 at 11:56 AM, Yaw Anokwa wrote:
>>
>> hey james,
>>
>> i don't understand "Date field - any way to make that backwards
>> compatible with the previous naming?" can you explain why this is a
>> problem?
>>
>> yaw
>>
>>
>> On Mon, Sep 26, 2011 at 22:02, W. Brunette wrote:
>> > 1) The format change on the GPS was requested by Google to better fit
>> > the fusion table model as it fits now how they represent a geopoint in
>> > fusion tables. I think we are open to discussion if there is a good
>> > reason.
>> >
>> > 2) The code works the same as 0.9.7 in regards to naming. The
>> > interesting question is it's not just one name of a table, it's the
>> > name of the form and all the repeat tags. So it would be a multiple
>> > prompt complicated UI interaction.
>> >
>> > 3) I am not even going to weigh in on this one... as much email
>> > traffic we have gotten on formatting dates. I think Yaw and Mitch have
>> > done their best to make the largest group of users happy. I will let
>> > them weigh in.
>> >
>> > Waylon
>> >
>> > On Mon, Sep 26, 2011 at 11:53 AM, James Dailey wrote:
>> >> ODK'ers
>> >> Running this new release in test mode but hoping to move to my
>> >> production
>> >> environment soon as it resolves existing issues with Aggregate 0.9.6
>> >> (Others
>> >> - note that release 0.9.7 is the stable version). Looks like a
>> >> complete UI
>> >> - congrats.
>> >> A couple of questions/issues:
>> >>
>> >> I'd like the have the GPS data show up the way it did before (aggregate
>> >> 0.9.6 --> fusion tables). Is there a way to force that in the xform
>> >> definition?
>> >> The spreadsheet name appears to be inherited from the tag for the
>> >> whatchamacallit . If I change <data to > >> have a
>> >> name in FusionTables that is more to my liking. Is this by design? It
>> >> takes a lot of xform manipulation to get to that.
>> >> Date field - any way to make that backwards compatible with the
>> >> previous
>> >> naming? Is there an xform setting?
>> >>
>> >> I'm still trying to decide when to make this move. Aggregate 0.9.7
>> >> might be
>> >> a better option given these data structure issues and the code we've
>> >> written
>> >> to pull from fusion tables to our app.
>> >> --
>> >> James Dailey
>> >> skype: jdailey
>> >>
>> >> --
>> >> 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
>> >
>>
>> --
>> Post: opendatakit@googlegroups.com
>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>
>
>
> --
> James Dailey
> skype: jdailey
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
Ah, ok. Well, that works as designed then. You said the same thing before
only this time I got it. Thanks for the patience!!
···
On Wed, Sep 28, 2011 at 7:16 PM, W. Brunette wrote:
The behavior I see is that when I publish my table from Aggregate
1.0-RC1, the name of the table is NOT used for the name of the table in
fusiontables.
It is not designed to use the title, it's designed to use the xml node
name that corresponds to the needed table. The 1.x code works the same
as 0.9.7 in regards to naming. The issue is we need to generate
multiple tables per form so a single name won't work (we have the name
of the main table and all the repeat tables). So it would be a
multiple prompt complicated UI interaction to get all the names
squared away so we chose not to try to design a UI prompt system. To
make it easy we are using the node name as you end up with distinctive
names for each part. Google spreadsheets works the same way, we allow
you to name the spreadsheet but the worksheet is named automatically
based on the xml node name. This also keeps it easier as people avoid
putting illegal characters generally in the xml node.
Once we are able to have an API to merge columns together across
fusion tables we might consider have one overall name for the main,
merged table. Please feel free to file an issue if you like for us to
keep this in mind for future reference.
Yaw/Mitch -
Thanks for the responses. Of the three issues, the date one is the least
of
them. What we have created is an infrastructure where we are expecting
certain field names and data types - this is a relatively minor change
that
requires us to parse the date differently. If it were possible to have
an
option, that would be nice to have.
The GPS format is pretty cool for how it confirms to google's vision for
fusion tables, but parsing out the string on our server is a pain point
for
moving to the new version of Aggregate. The option I'd really want here
is
to include both versions - i.e. the Lat, Long and the KML version.
Duplicate a little bit, no idea of the other implications.
The biggest issue by far is the field naming issue. This even seems like
a
bug. The behavior I see is that when I publish my table from Aggregate
1.0-RC1, the name of the table is NOT used for the name of the table in
fusiontables. Its also NOT using the ID value. Instead, the root of
is used for the name - all tables get name of "data". Maybe that
is
a result of not having full xform compliance in my xform, I don't know.
I
do know that the interface says "use table name" and instead it uses the
tag. I confirmed this by changing to something else and
voila
the table name changed. This is really a problem for when there are more
than one form and therefore tables.
James
On Wed, Sep 28, 2011 at 11:56 AM, Yaw Anokwa yanokwa@gmail.com wrote:
hey james,
i don't understand "Date field - any way to make that backwards
compatible with the previous naming?" can you explain why this is a
problem?
The format change on the GPS was requested by Google to better fit
the fusion table model as it fits now how they represent a geopoint in
fusion tables. I think we are open to discussion if there is a good
reason.
The code works the same as 0.9.7 in regards to naming. The
interesting question is it's not just one name of a table, it's the
name of the form and all the repeat tags. So it would be a multiple
prompt complicated UI interaction.
I am not even going to weigh in on this one... as much email
traffic we have gotten on formatting dates. I think Yaw and Mitch have
done their best to make the largest group of users happy. I will let
them weigh in.
ODK'ers
Running this new release in test mode but hoping to move to my
production
environment soon as it resolves existing issues with Aggregate 0.9.6
(Others
note that release 0.9.7 is the stable version). Looks like a
complete UI
congrats.
A couple of questions/issues:
I'd like the have the GPS data show up the way it did before
(aggregate
0.9.6 --> fusion tables). Is there a way to force that in the xform
definition?
The spreadsheet name appears to be inherited from the tag for the
whatchamacallit . If I change <data to <form_y then I can
have a
name in FusionTables that is more to my liking. Is this by design?
It
takes a lot of xform manipulation to get to that.
Date field - any way to make that backwards compatible with the
previous
naming? Is there an xform setting?
I'm still trying to decide when to make this move. Aggregate 0.9.7
might be
a better option given these data structure issues and the code we've
written
to pull from fusion tables to our app.
and to follow up on the date issue, i think we'll be keeping it like
this. it's a more standard format that we should have adopted much
earlier.
···
On Thu, Sep 29, 2011 at 07:05, James Dailey wrote:
> Ah, ok. Well, that works as designed then. You said the same thing before
> only this time I got it. Thanks for the patience!!
>
> On Wed, Sep 28, 2011 at 7:16 PM, W. Brunette wrote:
>>
>> > The behavior I see is that when I publish my table from Aggregate
>> > 1.0-RC1, the name of the table is NOT used for the name of the table in
>> > fusiontables.
>>
>> It is not designed to use the title, it's designed to use the xml node
>> name that corresponds to the needed table. The 1.x code works the same
>> as 0.9.7 in regards to naming. The issue is we need to generate
>> multiple tables per form so a single name won't work (we have the name
>> of the main table and all the repeat tables). So it would be a
>> multiple prompt complicated UI interaction to get all the names
>> squared away so we chose not to try to design a UI prompt system. To
>> make it easy we are using the node name as you end up with distinctive
>> names for each part. Google spreadsheets works the same way, we allow
>> you to name the spreadsheet but the worksheet is named automatically
>> based on the xml node name. This also keeps it easier as people avoid
>> putting illegal characters generally in the xml node.
>>
>> You can easily change the name of the table by renaming your node to
>> something other than data. For example the widgets form in the sample
>> form repo, will show up with the table name as widgets.
>> http://code.google.com/p/opendatakit/source/browse/Widgets.xml?repo=forms
>>
>> Once we are able to have an API to merge columns together across
>> fusion tables we might consider have one overall name for the main,
>> merged table. Please feel free to file an issue if you like for us to
>> keep this in mind for future reference.
>>
>>
>> On Wed, Sep 28, 2011 at 6:01 PM, James Dailey wrote:
>> > Yaw/Mitch -
>> > Thanks for the responses. Of the three issues, the date one is the
>> > least of
>> > them. What we have created is an infrastructure where we are expecting
>> > certain field names and data types - this is a relatively minor change
>> > that
>> > requires us to parse the date differently. If it were possible to have
>> > an
>> > option, that would be nice to have.
>> > The GPS format is pretty cool for how it confirms to google's vision for
>> > fusion tables, but parsing out the string on our server is a pain point
>> > for
>> > moving to the new version of Aggregate. The option I'd really want here
>> > is
>> > to include both versions - i.e. the Lat, Long and the KML version.
>> > Duplicate a little bit, no idea of the other implications.
>> > The biggest issue by far is the field naming issue. This even seems like
>> > a
>> > bug. The behavior I see is that when I publish my table from Aggregate
>> > 1.0-RC1, the name of the table is NOT used for the name of the table in
>> > fusiontables. Its also NOT using the ID value. Instead, the root of
>> > is used for the name - all tables get name of "data". Maybe
>> > that is
>> > a result of not having full xform compliance in my xform, I don't know.
>> > I
>> > do know that the interface says "use table name" and instead it uses the
>> > tag. I confirmed this by changing to something else and
>> > voila
>> > the table name changed. This is really a problem for when there are
>> > more
>> > than one form and therefore tables.
>> > - James
>> >
>> > On Wed, Sep 28, 2011 at 11:56 AM, Yaw Anokwa wrote:
>> >>
>> >> hey james,
>> >>
>> >> i don't understand "Date field - any way to make that backwards
>> >> compatible with the previous naming?" can you explain why this is a
>> >> problem?
>> >>
>> >> yaw
>> >>
>> >>
>> >> On Mon, Sep 26, 2011 at 22:02, W. Brunette wrote:
>> >> > 1) The format change on the GPS was requested by Google to better fit
>> >> > the fusion table model as it fits now how they represent a geopoint
>> >> > in
>> >> > fusion tables. I think we are open to discussion if there is a good
>> >> > reason.
>> >> >
>> >> > 2) The code works the same as 0.9.7 in regards to naming. The
>> >> > interesting question is it's not just one name of a table, it's the
>> >> > name of the form and all the repeat tags. So it would be a multiple
>> >> > prompt complicated UI interaction.
>> >> >
>> >> > 3) I am not even going to weigh in on this one... as much email
>> >> > traffic we have gotten on formatting dates. I think Yaw and Mitch
>> >> > have
>> >> > done their best to make the largest group of users happy. I will let
>> >> > them weigh in.
>> >> >
>> >> > Waylon
>> >> >
>> >> > On Mon, Sep 26, 2011 at 11:53 AM, James Dailey wrote:
>> >> >> ODK'ers
>> >> >> Running this new release in test mode but hoping to move to my
>> >> >> production
>> >> >> environment soon as it resolves existing issues with Aggregate 0.9.6
>> >> >> (Others
>> >> >> - note that release 0.9.7 is the stable version). Looks like a
>> >> >> complete UI
>> >> >> - congrats.
>> >> >> A couple of questions/issues:
>> >> >>
>> >> >> I'd like the have the GPS data show up the way it did before
>> >> >> (aggregate
>> >> >> 0.9.6 --> fusion tables). Is there a way to force that in the xform
>> >> >> definition?
>> >> >> The spreadsheet name appears to be inherited from the tag for the
>> >> >> whatchamacallit . If I change <data to > >> >> have a
>> >> >> name in FusionTables that is more to my liking. Is this by design?
>> >> >> It
>> >> >> takes a lot of xform manipulation to get to that.
>> >> >> Date field - any way to make that backwards compatible with the
>> >> >> previous
>> >> >> naming? Is there an xform setting?
>> >> >>
>> >> >> I'm still trying to decide when to make this move. Aggregate 0.9.7
>> >> >> might be
>> >> >> a better option given these data structure issues and the code we've
>> >> >> written
>> >> >> to pull from fusion tables to our app.
>> >> >> --
>> >> >> James Dailey
>> >> >> skype: jdailey
>> >> >>
>> >> >> --
>> >> >> 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
>> >> >
>> >>
>> >> --
>> >> Post: opendatakit@googlegroups.com
>> >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> >> Options: http://groups.google.com/group/opendatakit?hl=en
>> >
>> >
>> >
>> > --
>> > James Dailey
>> > skype: jdailey
>> >
>> > --
>> > 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
>
>
>
> --
> James Dailey
> skype: jdailey
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>