Dowsing - Hamilton's open data app to find water

[Joey Coleman]

Greetings everyone,

I'm happy to announce that I've launched an interactive Google Map using the Fusion Tables API that helps people find the nearest public water play feature, swimming pool, or beach.

I've launched it on the Open Hamilton website for now: http://www.openhamilton.ca/dowsing.html

I'm going to work this weekend to get our new website up and running in Wordpress. For now, I have an index page with the map .

This is the first step towards completing an swimming open data set and an series of apps for our fellow citizens.

We're installing A/C at think|haus this weekend, so we'll be able to start meeting in the space again!

A brief description of what the app will entail:

A “simple” app which allows people to input the time they want to go swimming and get a list of recreation centres / outdoor pools / non-City (Ys Kiwanis Lakeland) with swimming available at the time.

Using the HTML5 Geo feature, the app will provide driving directions to the recreation centre.

The goal is to gather Hamilton’s best developers to create an application that solves a real problem. Presently, Hamilton lists it swim times on different pages across the city website with the data organized by recreation centre.

The app will be officially launched in early July during the first heatwave of the month.

It will showcase what is possible if the City adopts open data and improve public awareness of the cause.

Development of the app will create the opportunity to experiment with and learn about HTML5. There will also be social components to the hackfest.

[Joey Coleman]

Wow, I was tired last night. I locked this thread instead of pinning to the top of the page. Sorry everyone.

[Gavin Schulz]

I developed a mobile-friendly UI for dowsing. Is there anyways that
can be added to the site?

[Joey Coleman]

Thanks, this is awesome!

Yes,

If you post the code, I'll update the site.

I'm working on planning a hackfest to do more with dowsing (swim times search, etc). I'll have details by Sunday.

[Keith Mann]

Any details on the next Hackfest? I have a couple of people who might
be interested and I'd like to be sure to keep our calendars clear.

On Jul 22, 5:29 pm, Joey Coleman <j...@thinkhaus.org> wrote:
> Thanks, this is awesome!
>
> Yes,
>
> If you post the code, I'll update the site.
>
> I'm working on planning a hackfest to do more with dowsing (swim times
> search, etc). I'll have details by Sunday.
>

[Joey Coleman]

Evening everyone,

Attached is the data in one spreadsheet as a CSV.

I've also attached the Excel workbook I used when merging the five CSV files into one dataset.

- Joey

[Joey Coleman]

Keith,

I'm aiming to have a planning meeting next Wednesday to plan how we can create a dataset for City of Hamilton swimming in the fall.

There's a lot of data involved:

• Locations
• Swimming Facility type (pool size {olympic, length, number of lanes}, slides, hot pools, diving boards, etc) and when those extras are open
• Swim Types (family, woman, adult, open, lengths, etc)
• Hours of public swims
  
• Cost
• Swimming Courses (course names, cost, registration dates, course prerequisites, times, etc)

I'm think we may to need to build a data format like GTFS that places all this data into a ZIP file that allows any municipality to quickly plugin their data to a swim app and use it in their city. Nik G is looking to see if these standards already exist.

I'd like to see use build something that can easily be used by other cities that is developer friendly and civil servant friendly. Hence my thought that a ZIP file with all this data could be the method to employ.

 

I've drafted most of an email to the City of Hamilton asking for Fall Swim schedules, city staff from recreation to advise us on the app, and for use of City Hall meeting spaces for the hackfest to build this.

 

It's ambitious and I think we can do it.

I will confirm dates tomorrow afternoon.

At this point, next Wednesday (August 3) at 7:00pm is the likely time.

[Milton Friesen]

Have you seen this twist on public transportation mapping? It gives you a visual shape over a map that lets you know how far you can get on public transit in a given period of time - if you have ten minutes, it will show you where you can get using various options. I like how a single, morphable shape over a map can communicate a lot of information.

http://www.mapnificent.net/

Milton

--

_____________
Milton Friesen
Cardus :: research for the common good
Ingenuity Arts :: adaptive leadership
Profile
Recent Article
Adaptive Cities

Twitter: @ingenuityarts
Skype: ingenuityskype

[Joey Coleman]

Great progress tonight, lots of great ideas.

The PBworks page for Open Hamilton is now started:
http://openhamilton.pbworks.com

[Mark]

The one concern I would have is the static nature of this data. The
single most important piece of data for any public facility is
"current_status". Beaches get closed. Waterpads fail down to "out of
order". Unless you know that a facility is indeed open and working as
designed, the rest of the data is moot.

It's a mobile world now, and people consume data on the fly. Static
data doesn't really help them. Especially when you just found out
that Sally's soccer practice in cancelled and you need to find a way
to entertain the kids on a hot day in a hurry.

The big question is - does this data exist at all? I would ASSUME
that the facilities managers have some way to report their daily
status to the city ... no? Yes? Maybe? And if they do, how? And
can we get at it?

On Jul 27, 12:02 am, Joey Coleman <j...@joeycoleman.ca> wrote:
> Keith,
>
> I'm aiming to have a planning meeting next Wednesday to plan how we can
> create a dataset for City of Hamilton swimming in the fall.
>
> There's a lot of data involved:

> SNIP<

[Scott Elcomb]

On Thu, Aug 4, 2011 at 9:17 PM, Mark <mhorn...@gmail.com> wrote:
> The one concern I would have is the static nature of this data.  The
> single most important piece of data for any public facility is
> "current_status".  Beaches get closed.  Waterpads fail down to "out of
> order".  Unless you know that a facility is indeed open and working as
> designed, the rest of the data is moot.
>
> It's a mobile world now, and people consume data on the fly.  Static
> data doesn't really help them.  Especially when you just found out
> that Sally's soccer practice in cancelled and you need to find a way
> to entertain the kids on a hot day in a hurry.
>
> The big question is - does this data exist at all?  I would ASSUME
> that the facilities managers have some way to report their daily
> status to the city ... no?  Yes?  Maybe?  And if they do, how?  And
> can we get at it?

If not, is crowdsourcing an option? Users (the public) could interact
with the system by tagging locations for which the "official"
information is either unknown or in conflict with reality, perhaps
with moderated(?) comments.

--
  Scott Elcomb
  @psema4 on Twitter / Identi.ca

  Atomic OS: Self Contained Microsystems
  http://code.google.com/p/atomos/

  Member of the Pirate Party of Canada
  http://www.pirateparty.ca/

[Keith Mann]

I'd argue that current status isn't really that critical as long as there's a reasonable expectation that "current status" is "open". Do we have any information on how often there are closures? If we did, we could quantify the risk.

Keith

On Thu, Aug 4, 2011 at 9:17 PM, Mark <mhorn...@gmail.com> wrote:

[Mark @truenorthBBQ]

Sadly, there doesn't seem to be any on-line data regarding historical
or current closures of pools or pads. However, checking the health
services beach report I see that today one of the three beaches listed
on the map is closed:

http://www.hamilton.ca/HealthandSocialServices/PublicHealth/SafeWater/Beaches.htm

As far as pools go, however, you can probably assume that at least one
pool is closed for a fouling each week. And one facility closed is
one facility that a LOT of people depend on.

The problem here is that "reasonable expectations" is meaningless if
you are parent trying to pack your kids along to the beach. Even one
closed facility will hose over a number of people. Remember that the
average resident has no way to differentiate between "posted hours"
and "open". If they see splash pad on the map, and the hours show it
as open, they assume it IS open. People have come to believe that
online data is current and infallible. If they get there, kids in
two, and the pool has been fouled or the splash pad is dry then their
reaction is "that web page / app / whatever is useless. it said the
pool was open and it wasn't".

This isn't a project for us to play with data. This is a project to
give people in our city back their data to make their lives easier and
better.

[Mark @truenorthBBQ]

I don't think that crowdsourcing is a valid option - simply because
average people don't check in / update / broadcast / etc. Look at
foursquare - 95 percent of their check-ins come from less than 10
percent of their users. A member of the geek community will happily
check in for you - but a parent trying to wrangle a couple of kids,
not a chance. They've only got two hands.

But Keith Mann raises a valid concern about data assumptions: CAN we
find out how often things are closed? Maybe I am just being a gloomy
gus, who knows? I wish I had gone through the data format this
morning instead of this aft so that I could have pestered Joey to ask
about historic data at the meeting tonight. Dang.



On Aug 4, 9:33 pm, Scott Elcomb <pse...@gmail.com> wrote:

[Joey Coleman]

Great discussion tonight. Peter and I were discussing this at Think|haus tonight and the ideas we tossed around were:

A JSON format feed that is outside of the recreational data specification (our new GTFS for recreation) that can be used by city's for their facilities using the address (71 Main Street West, Hamilton, Ontario, Canada) as the unique identifer for each facility. The JSON feed would be used for unscheduled/unexpected closures as a way of informing the data users of a temporary change to facility status. The JSON feed can also serve as a notification method to notify developers when the static programming schedule data is updated.

I offered, free of charge, to teach Hamilton's public health department how to update a JSON feed of beach conditions. Sadly, my offer was not responded to.

Since Peggy Chapman's "if you have a boss" comments, I've noticed a nearly complete lock-down on information flowing from City Hall on any topic. I can't even get the City to confirm the status of the wading pool they list on their website as existing at Inch Park.

The original Dowsing "app" was designed to show people the power of open data and get more public buy-in to pressure our municipal government to move more quickly on open data open government. It was a huge success in this regard, we have a City Councillor moving an open data policy for our city.

Beach conditions is definitely something we need to push for open data from the City on and then figure out how to get it into the app.

In terms of crowd-sourcing the info, I don't believe this is the most effective method. We'll need to figure out a method of making an application that supervisors at City pools can quickly and easily report a closure.

- Joey

[NikGarkusha]

@Mark @Keith @Joey

I think an indicator of status is a fantastic idea. A good
implementation is based on:
(a) a data schema that accounts for a way to indicate status and/or by
flagging exceptions to what the normal schedule is.
(b) processes / workflows to update the data feed
(c) frequency of updates to stay current

The draft spec that we tackled on Wednesday has ability to flag
exceptions to schedule, which we can tweak. That can be tweaked to
indicate status and/or closure comments. Unfortunately for us, the
schema/feed/spec is not the problem, and it's not "static" by nature
of the schema. It's the implementation of (b) and (c) above, getting
the processes to update frequently by the city that will ultimately
dictate if the data will be useful to citizens via app(s).

I propose we evaluate the best way to keep track of changes of status
of Activities within a Resource and do a test or two with real data to
see if that works. Rotary Park splash pad in Milton was closed for
repairs for a few weeks, while the Rotary Park swimming pool was still
open. If there are any closings of any other facilities/resources that
we can use for testing, that will help us validate whether the feed
spec appropriately handles that.

Nik
http://openhalton.ca

> On 4 August 2011 22:54, Mark @truenorthBBQ <mhornblo...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Sadly, there doesn't seem to be any on-line data regarding historical
> > or current closures of pools or pads.  However, checking the health
> > services beach report I see that today one of the three beaches listed
> > on the map is closed:
>

> >http://www.hamilton.ca/HealthandSocialServices/PublicHealth/SafeWater...

[Gavin Schulz]

@Nik:

I don't see why the current way of handling exceptions is not
sufficient for the purposes of closure. We could add an optional
field called description/note/message that would give an explanation
of the cancellation; I think that would suffice.

On Aug 5, 10:23 am, NikGarkusha <nikgarku...@gmail.com> wrote:
> @Mark @Keith @Joey
>
> I think an indicator of status is a fantastic idea. A good
> implementation is based on:
> (a) a data schema that accounts for a way to indicate status and/or by
> flagging exceptions to what the normal schedule is.
> (b) processes / workflows to update the data feed
> (c) frequency of updates to stay current
>
> The draft spec that we tackled on Wednesday has ability to flag
> exceptions to schedule, which we can tweak. That can be tweaked to
> indicate status and/or closure comments. Unfortunately for us, the
> schema/feed/spec is not the problem, and it's not "static" by nature
> of the schema. It's the implementation of (b) and (c) above, getting
> the processes to update frequently by the city that will ultimately
> dictate if the data will be useful to citizens via app(s).
>
> I propose we evaluate the best way to keep track of changes of status
> of Activities within a Resource and do a test or two with real data to
> see if that works. Rotary Park splash pad in Milton was closed for
> repairs for a few weeks, while the Rotary Park swimming pool was still
> open. If there are any closings of any other facilities/resources that
> we can use for testing, that will help us validate whether the feed
> spec appropriately handles that.
>

> Nikhttp://openhalton.ca

[NikGarkusha]

@Gavin

Totally Agree. Exception message makes sense, but I think we should
change to a date range (vs one date) and a time range (in case the
activity is only partially taking place)

Handling status changes via exceptions vs.a status field provides a
way to track changes, get granular and provide a way to "schedule"
changes in status

[Mark @truenorthBBQ]

You also need to make sure the exception field is ONLY populated for a
closure, since you want to be able to flag/update/modify the icons on
your map (or other top-level) interface so that people can see
immediately that there is a problem without having to open up the
details page for the facility in question.

Good thoughts all around on this one, tho. I like it!

[Bill Dunphy]

Quick hurrah from the sidelines:

It's fascinating watching you folks collectively work through these issues - solving these problems will provide the city with an information source that is light years above and beyond what city staff seems currently capable of. And that's a compelling argument for open data.

Bill

--
Bill Dunphy

Blog - Breaking News

Twitter- Typist

Facebook

[Gavin Schulz]

Nik,

I don't think we need to change the exception format to a date range
because instead we can just have n-exception rows with each date in
the range. Adding a range to the exception field, imo, adds
unnecessary complexity to processing the data. I also don't think we
need a time range as we have already discussed this situation. If the
time range were shortened you would make an exception for the usual
time slot and then add a new one day time slot to activity_times to
represent the amended/shortened activity. And we can add a message
field to the exceptions to allow explanation of the cancellation/
amendment.

On Aug 5, 11:08 am, NikGarkusha <nikgarku...@gmail.com> wrote:

[Keith Mann]

I actually like Nik's idea of a date range, but again, without knowing much about the frequency and duration of closures it's kind of hard to make an objective call.

Keith

[NikGarkusha]

@Gavin,

If a facility is closed (meaning all resources X & activities Y are
too), that's "n exceptions" times "X facilities" times "Y activities".
That's a lot of rows.
Wouldn't it be more efficient to specify a range of dates that can
also be easily modified in case the dates change? e.g.:
(1) Oops, this pool needs to be closed for repairs, let me set an
exception with a range that will automatically cancel all activities
falling within that range?
(2) Hey, this is taking longer than we thought -- let's edit the
exception to extend the closed until date
(3) But wait, we found the part we were missing, the pool is going to
be opened sooner - let's edit the exception 3rd time to indicate that.

IMHO, this works vs. adding new exceptions or rows in the
activity_times?

Thoughts?

[NikGarkusha]

..and to address the facility & resource situation (in case all
activities / resources are unavailable in a specific facility), should
we add Facility_ID and Resource_ID as potential other ways to add an
exception?

[Gavin Schulz]

Based on the discussions here I've made a variety of changes to the
spec. The working version is at http://openhamilton.ca/graf.
A quick overview of the changes...
The activity_exceptions table is now much more flexible. The date has
been changed to a date range and you can know cancel, an activity
time, activity or resource.

Based on discussions at the OpenHamilton meetup Aug 11 there has been
some progress in relation to fees. Currently the idea is to support
single use fees and extend that once we have come up with a workable
framework for fully extensible fees. We have also introduced the
concept of fee classes which simplifies linking fees to activities.
Basically fee classes are collections of fees.

Given that we have a pretty robust spec as it is I'm going to start
building some tools around it such as a better interface for adding
data and a feed validator.

> ...
>
> read more »