ODK Central v0.1 Alpha

Hey everybody—thanks for your time and feedback so far. We're hard at work addressing your biggest concerns and getting Central to the point where it is useful for more of your projects in the wild.

We wanted to share our thoughts with you, so I am dropping a link to our block 2 release criteria. This is our working document defining everything we'd like to have in there for the next major release of Central in the coming several weeks.

If you have a moment, please take a look and let us know what you think. Do bear in mind that we do actually work off that document daily, so if you have a lot to say please consider leaving a reply here instead of in the document so that we can still actually read the thing. :slight_smile:


Will there be a roadmap for ODK Central development? I would like to know its planned incoming features.

Especially data monitoring, filtering, data mapping, data modification, Enketo integration....

For Google drive backup, could we download the backups on the backup dashboard instead of going back to our Google drive panel?


There isn't yet a roadmap, as Central is still so tiny and the possibility space is so huge that we're still trying to fulfill basic features and learn what you all want. That said, among our top priorities at this moment are permissions and workflow features, like group permissioning. We also have an eye on data modification, as we know that's a big want, but we haven't yet figured out how it should work and it's definitely further out.

For data mapping, we encourage you to use the OData support to pipe the data into a tool that does mapping better than we could—see Yaw's post earlier in this thread for an example. Part of our hope with Central is that by outsourcing data analysis features to tools that do analysis full-time, you get a better analysis experience than we could accomplish with our fairly limited resources, and we buy ourselves more time to look at long-asked-for features (like the advanced permissions and data modification mentioned above). Because the OData feed is live, you can then just press Refresh in the tool to automatically get the latest version of the data, for live monitoring.

As for backup, the current theory is that in a case where you would need a backup restored it is likely you don't have a working, running Central anyway and so the backup dashboard wouldn't be accessible to you. In addition, we would have to build a lot of user interface for you to browse for files and choose the one you want, which would take quite a long time. That said, if it's a popular request we will of course consider it.

Thanks for taking a look, Sounay, and I hope that helps.

1 Like

@Sounay While we don't have a roadmap yet, I'm curious if you had a chance to look over the block 2 release criteria and if you had any feedback on those upcoming features?

For everyone else, @issa has written up some great user documentation at https://docs.opendatakit.org/central-intro to help get you started.

I would like to try ODK Central in the sandbox version, how do I get a username and password?

Thanks in advance

The process is described at https://docs.opendatakit.org/central-install/#using-the-sandbox. I have sent you an invite.

A post was merged into an existing topic: ODK Central v0.2 Beta

A post was merged into an existing topic: ODK Central v0.2 Beta

I've got issue when load data to Power BI from Central via Odata. The issue related to time conversion but i'm not sure what it is so I take screenshot as attachment.
I put the form on the server https://sandbox.central.opendatakit.org for easily check: lightweight-timestamping-if
DataSource.Error: OData: Cannot convert the literal '2019-02-11T16:04:45.638+07' to the expected type 'Edm.DateTimeOffset'.

it looks like the problem here is that whichever version of Collect you are using isn't outputting the correct date format. compare:


this is .. incredibly annoying because this means we now have to explicitly patch this case in central when we see a datetime column, where before we could just plumb the data through untouched.

i will try to have a fix in place for version 0.4, which is releasing relatively soon.

thanks for the report!

1 Like

(also @ggalmazor what became of the standardization work here? is javarosa/collect getting patched at some point in this regard?)

Not sure where this one came from, but just FYI the supported formats going forward are doc'd here

1 Like

yes, and as documented in that file:

JavaRosa doesn’t always use the correct offset format
When the local timezone offset is of multiples of a full hour, it outputs this format:

[HH]:[MM]:[SS].[SSS]±[hh] as in 20:04:16.669+09

Only when the local timezone offset is of odd multiples of half an hour, it uses the format we want to use:

[HH]:[MM]:[SS].[SSS]±[hh]:[mm] as in 20:04:16.669+09:30

We should change JavaRosa to ensure it always adds the minutes fragment in the timezone offset text.

FYI I think it may be here: https://github.com/opendatakit/javarosa/blob/master/src/org/javarosa/core/model/utils/DateUtils.java

 private static String formatTimeISO8601 (DateFields f) {
    String hrs = intPad(value / 60, 2);
    String mins = value % 60 != 0 ? ":" + intPad(value % 60, 2) :"";
    time += offsetSign + hrs + mins;

ie if on hour it drops the mins off the (date)time suffix. On the surface it appears it could be a quick fix, in of itself, but given its potential impact elsewhere it could require some regression testing...?

1 Like

So far we've solved the issues the doc points out in Aggregate. Next, I think it makes sense to focus on JR and fix the issue you've pointed out about the offset lacking the minutes component.

I think we can start by filing an issue https://github.com/opendatakit/javarosa/issues/404


Just want to follow up and say that @Xiphware has fixed this in JavaRosa and the fix will be in the next version of Collect.

1 Like

great, thanks @xiphware; now maybe in 4-5 years i can delete the ugly hack i put in central :slight_smile:

1 Like

any other ugly hacks we should know about? :grin: [not promising anything mind you...]

1 Like

ha! the other bad one was already removed; our openrosa endpoints no longer check the Date field at all because Collect outputs localized date strings that look like HTTP-dates, instead of actually compliant (ie english language) HTTP-dates. but the fix in our case was just not to check the Date field at all, because we don't care about it.

A post was merged into an existing topic: ODK Central v0.4 Beta