--
You received this message because you are subscribed to the Google Groups "Vancouver Data" group.
To post to this group, send email to vancouv...@googlegroups.com.
To unsubscribe from this group, send email to vancouver-dat...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vancouver-data?hl=en.
When building VanTrash, we wanted to host the whole dataset (in our
case, garbage zones and schedules) so our application could be fast
and optimized. So we wouldn't have used RESTful APIs if they were
around. We ended up taking the raw data and then building a RESTful
API around the data for our app. (http://vantrash.ca/api.html)
I've used the OGDI data browser on Edmonton's data site and it was
pretty cool. Not sure I'd use it in an application though. For small
hacks, I think an API can be useful, but for more substantive projects
I think people would typically grab the whole dataset and then carve
it up specific to their app.
My preference is for data.vancouver.ca to keep with the raw data
downloads. APIs for those datasets would be cool, but maybe expensive
to build & maintain. In my experience, the key to building a good API
is to be a consumer of that API - so you're building based on a real
need. If you build an API just guessing at what people will want,
it's easy to build features people won't use and to miss features that
are useful. (Of course this would all iterate over time towards
something workable...)
One thing I would like would be some kind of "social features" around
the datasets. For instance, I'd like to get some kind of notification
when a dataset (eg: garbage zones) are updated. Or I'd like to see
what other community projects are using each dataset. For example,
people browsing to data.vancouver.ca and looking at the garbage zones
dataset would not know that VanTrash has already built and hosts a
RESTful API to that data. This could be a good resource to share.
Glad to see y'all practicing kaizen on the city data!
Luke
On Fri, Jul 9, 2010 at 1:53 PM, Darrin <darri...@vancouver.ca> wrote:
In other projects I work on professionally, when our upstream data
sources put out a new release it often means a week or two for me to
figure out how they've broken the dataset and update my parser. Not
that I'm saying the City would ever do such things, but an API
definitely has the danger of making a large number of applications
stop working by either changing the API or if the API should go down
for some reason.
An update notification for data sets as Luke said would also be
fantastic, even if its just a machine queriable version number so we
can know when we should grab a new version and try parsing it in to
existing applications. Yes it might mean new data isn't instantly
available in community created applications (a definite point in
favour of an API), but just based on experience it can be so much more
fragile a setup.
I don't think this is an either/or choice, for some data sets a flat
file may be more appropriate, for some an API. And for more static
ones there's certainly nothing preventing and API along side the
existing flat file, once the infrastructure is in place upkeep should
be minimal. Hell, if done right the flat file could be generated on
the fly from the dynamic data if you really wanted (with proper
versioning previsions of course to allow users to consistently get a
desired point in time), we already do this in some projects I work on
professionally. The user never knows its not actually a file sitting
on our server.
As to where the crunching is done, well I guess that's a debate on if
the mobile app developer should also be responsible for munging then
hosting the data their app accesses. I've seen apps where you get
regular data updates from the app developer's server which does have
the ability to download and munge updated data to a form optimized for
the mobile app's needs. However if you can save a step by having a
RESTful API on the City's server, and they don't mind the extra
infrastructure costs of hosting it for mobile apps to access on the
fly, that's great too! As you've said, yes for real time data that
might be the optimal choice anyhow, since who would want the time
delay of it having to bounce through the app developer's server first.
So final answer, yes. We want it all! Gimme. Gimme. Gimme. :)