[Talk-ca] Fwd: Ottawa OpenData and Geographic Information Systems (GIS)

[john whelan]

Ottawa City organised a hack fest around open data.  You've probably seen
some of my posts as I scrabbled to at least get them to look at alternatives
to Google.  The ability to display road names in both languages turned out
to be something that was commented favourably on.  It was done using an
unreleased version of Maperitive but there should be an easier way.  The
ability to select what is displayed is glossed over but some improvement in
ease of use might be useful.

Anyway Sam thought others might be interested and have some ideas.

Cheerio John

---------- Forwarded message ----------

Background

These thoughts arose from the Ottawa Opendata Hackfest April 24th 2010 and
are based on my thirty five years of computer systems.  I tend to look for
possible problems and implications early on when they are cheaper to address
and to see if I can find ways to make techniques available to a wider
audience.  The major theme here seemed to be about combining OpenData and
maps and could the city gain benefit from offering a $50,000 prize.
Requirements

There are a number of groups with different ideas and requirements for
combining OpenData and GIS systems.  These maybe different from the clients
or expected end users.

If we start with the group I saw making a presentation then I think they
would like something simple to program.  I'm making this assumption based on
the predominance of Mac lap tops and I suspect the use of Google API and the
drawing functions over the map which is currently easier in Google.  Also
their presentation of a drinking fountain application which overlaid
drinking fountains on top of a Google map.

If we look at the city councilors they would like something to promote
Ottawa or be Ottawa specific, this was stated at the informatics
subcommittee I attended where OpenData was raised.   There are also
background requirements to lower 311 costs, improve response times, improve
road safety, balance improved bilingual services and cost and the other 101
things the city is responsible for.

Ottawa Businesses like maps that show where they are.  The success of Google
Maps show this.  A search for "florist, K1E3P6, Canada" in both Google Maps
and OpenStreetMap (OSM) turns up "Select Blooms, 1675, Tenth Line Road,
K1E3P6, Ontario, " the only difference is that Google displays the phone
number whilst if you click on the small+ sign on the right OSM allows you to
drill down to the associated tags, thus giving the phone and fax numbers,
web site address, and other information such as hours of opening for the
point of interest (POI).  OSM doesn't charge businesses but does accept
donations.  One difficulty with electronic maps is sometimes there is too
much data to display clearly.  OSM historically has had close connections
with cyclists, so one option on the + sign is to display the cycling routes
or lanes such as Merkley.  This is done by the use of rules which control
which POIs such as drinking fountains or cycle paths are displayed.  The use
of the + sign once learnt does give a consistent way to access tags.  So a
park could have a tag that says no dogs and this can be determined by
inspecting the tags.

End users or Ottawa citizens would like something stable, reliable,
consistent, easy to find, useful, easy to use and they also think in terms
of cost.  Can I click on the library or supermarket to see the hours of
opening?  Will domains such as fixmystreet.ca be available next year if
someone forgets to renew the domain name?  Why isn't the interface
consistent on these different web sites?  Do I trust this web site enough to
run scripts?  Can I trust it anyway?  Will I remember that
fixmystreet.caisn't just to report potholes?
Why doesn't this web site accept my postal code?  Can we involve citizens in
some way by giving them the ability to contribute?  ie to be able to enter
points of interest that interest them in the underlying map.

One end user interviewed liked the idea that he could click on a street lamp
to report it not working.  He wasn't impressed by the idea that an email
going to 311 to be passed on to the relevant department could take four
working days to be read by 311 before being passed on.  This is a more
complex type application that needs to pick up data from the map and forward
it to the city.

Another couldn't see why they had to have an internet connection to view a
map.  Wireless Internet connections cost money, and if they were quite happy
using a printed map that was three years out of date why did they suddenly
require up to the moment information.  The comment was buildings tend not to
go for walks in the middle of the day.  Thinking about it the data in these
maps is usually imported from other sources and can be several years out of
date.  How much value is the requirement for Internet access adding?

One of my favourite comments was why do I need a computer at all?  Can't you
just give me a bit of paper with the specific information on?  So much
easier to carry around.  This one is quite an interesting idea, printing on
paper is higher resolution than a computer screen, it's also much cheaper
and doesn't need an internet connection.  I didn't have a lap top with
wireless internet access available for the Hackfest but did leave a number
of small printed maps at the sign in desk showing the location of the
nearest Second Cup coffee shop.  The City Hall 111 coffee house being closed
on Saturdays.  A spin off would be to provide something that could be
displayed on an ebook or GPS device.  Tourists would find a tailored map
perhaps showing the Points of Interest for the Jazz festival, or the Tulip
festival useful.

Wheel chair users have specific needs such as ease of access, some have
incomes that prohibit the purchase of wireless enabled internet devices can
we find ways to not exclude them at low cost?  An option of paper maps that
show information of specific interest to them would be valuable.

Are we using any public funds or providing service from the city's web site?
If so then addressing the needs of Francophones should be considered.  Google
Maps is available in French but the roads are shown with their English
names.  One Francophone interviewed showed great interest in the idea of the
French street names being displayed.  The two .jpgs below show the same OSM
map data with English and French names.  Only a couple of roads have their
French names tagged.
http://groups.google.com/group/maperitive/web/French.jpg
http://groups.google.com/group/maperitive/web/English.jpg  This technique
can be extended to all names so City assets could display either a French or
English name depending on the configuration and if the information had been
entered.

Within the city departments there are a variety of needs, for example two
years ago the City forester mentioned it would be very nice to map the trees
in Ottawa but they didn't have the funds to do this.  There are a number of
organisations who have the members who could volunteers to do this but not
the technical expertise.  Can we make it easier?

A member of the planning department mentioned they would like a map that was
copyright free.

Different city departments seem to have different ideas about what data is
available to the city.  For example the footpath by the side of 717 Morewood
is snow ploughed by the city in winter but doesn't seem to be considered as
an option by OC Trip Planner.

The Paramedic Public Access Defibrillator Program probably would like a map
showing the automated external defibrillator (AED) devices but like the
locations under their control.

Finally computer programs and people like consistent names for things such
as phone should be labeled phone in some places and not telephone in others.
 The OSM data is available for correction in XML format and to get better
consistency so the tag data can be processed programmatically more easily
there is a need to standardize terms etc.

As I went through these requirements it became apparent that some were quite
technically complicated but there was a real demand and it would be nice to
meet these demands if possible.
GIS & database Background

Geographic Information Systems (GIS) basically have points described with
latitude and longitude on a map and tags to describe the data.  Two or more
points can be linked to describe a road with the tag applied to the link.  This
is very similar to a database and the information is searchable.  For
example "florist, K1E3P6, Canada" brings up a point of interest (POI) with
tags such as "name=Select Blooms, Florist."  In general terms the more data
we have in a single database the more complex the search can be.  If we link
a map to a separate source containing the locations of drinking fountains
that works but if we want to create more complex queries such as a
playground with a drinking fountain within 200 meters of a cake shop it is
simpler to build the query if all the data is in a single collection of
data.  Note all the data is held in a database and we create the visible map
by extracting the relevant data and rendering it.  In the case of the Google
apps it is a two stage process with Google rendering the underlining map and
the app creating an overlay.

There are technical issues about how much data can be displayed at once and
which data should be on top.  For example a name should be layered above a
forest area in order for it to be visible.
What can we do simply today?

If we start with an imaginary application we want low cost but a good
payback.  A car can carry a GPS device that can record tracks.  If one had
an application that could read the tracks and confirm the car hadn't gone
above the speed limit then we might feel more comfortable about letting a
teenager borrow the car since we can reasonably expect fewer and less
serious accidents at lower speeds.  A good quality GPS device with tracing
would cost $150 but gives us some of the benefits of a GPS speed limiter at
lower cost.
www.carsguide.com.au/site/news-and-reviews/car-news/gps_speed_limiters_in_action
.  By making the speed limit information available in this way GPS speed
limiters can make use of it and make our roads safer.

In general Google based solutions have a number of drawbacks, lack of French
names, we can't easily add tags and data to the Google data base, privacy
issues, it doesn't include footpaths and most businesses and organisations
have to pay to be included.  They are US based so not covered by Canadian
privacy legislation, data can be supplied to the CIA, who have previously
used the possession of a Casio watch as proof of being a terrorist.  Even
searches relating to drinking fountains will be collated, perhaps to point
out a nearby cafe or for some other reason.  "What exactly is Google up to?
That's the question some may ask based on recent news that the search
giant's Street View cars are scanning private WLAN networks. Although
there's no word if Google is conducting its invasion of privacy here in the
States, German officials have discovered that the automobiles are not only
scanning consumer-based networks, but is possibly obtaining users' unique
Mac addresses in the process."
www.tomsguide.com/us/Google-Mac-Address-Wi-Fi,news-6574.htm "Google CEO Eric
Schmidt has said that Internet users shouldn't worry about privacy unless
they have something to hide."  If these issues are not addressed they could
come back later on in the project.  Note there is a subtle difference
between me choosing to use a Google Map and finding myself forced to use one
because of an application.

On the positive side it does have a seductive API and it's easy to add a
small application.  From the city's point of view if its OpenData and Google
chooses to use it then it doesn't have any responsibility for a French
language version.  Google has developed some useful interfaces such as the
Google Transit Feed Specification (GTFS) which has now become the General
Transit Feed Specification and is becoming a more generally used interface
standard.  Ottawa GTFS data appears to be available on the web although
currently little is known about the source or how this information is
licensed.

With any Open Data licensing of the data must be considered.  Ideally the
data license should align with accepted practice or people will have trouble
understanding the license.  The creativecommons.org 3.0 is recommended,
creativecommons.org/licenses/by-sa/3.0/ and
creativecommons.org/licenses/by-sa/3.0/legalcode since this is well
understood.

Would we be any better off with a solution based on OSM?   We can add tags
with the speed limit to OSM.  The data is incomplete in that some footpaths
are mapped, some aren't.  Some coffee shops are in, others aren't.  The data
can be added to or modified by anyone, including computer savvy teenagers so
it isn't reliable enough to see if your teenager has been keeping to the
speed limits. However it does mean volunteers can add trees to the database.


However what OSM does have is an environment.  So tested routines already
exist for importing CANVEC data and from other sources including GTFS.  It
has different rendering options both web based and standalone options.  The
information can be displayed on the web, or off line, or on a GPS device
such as a Garmin, formatted for an ebook, or even printed with a variety of
options.  Customised town guides have been created.  Other cities have
created wheel chair friendly routes.  This modular approach means it is open
to new applications.  So can we build on the OSM standard interfaces and
routines?  What some organisations have done is set up their own OSM server.
This allows control over the data so we know we can trust the speed limits
and AED locations for example.  The low cost way of using the speed limit
data is to compare a trace against a map.  Commercial GPS speed limiters are
available but need a map with the speed limits as infrastructure.  If Ottawa
was to come up with a secure map based on open standards with speed limit
tags it is highly likely that other cites would follow.

OSM also opens the door to use many other applications such as Maperitive
which is a standalone program that can display OSM format data without being
connected to the Internet.  It also takes the load off a web server and
improves response time for those on dial up.

It is possible to repoint Google applications so they run over OSM but using
Openlayers wiki.openstreetmap.org/wiki/OpenLayers is preferred.  It is also
possible to do a "Mash up" using JavaScript in about the same time as using
the Google approach but you need some experience in JavaScript.
What GIS resources are available in Ottawa?

Ottawa is home to a considerable expertise in GIS.  For example Open GIS
Consortium (OGC) has a chapter in Ottawa.  They know about things such
as OpenGIS
Web Map Service (WMS) which can use OSM as a data source.  Natural Resources
Canada has a lot of expertise in GIS systems.  Carlton University has
courses that combine Mapping, GIS, mathematics  and computer programming.  The
city itself creates maps and internally has expertise.  It might well be
worthwhile consulting internally in the planning department at least to see
which direction the city should be going.
What can we expect as a response to our $50,000 prize?

Realistically applications process data.  Ottawa's data really isn't that
much different to anyone else's data.  For example all libraries have
opening times but do we really need an application to display these
specifically for the Ottawa ones when these can be displayed directly in OSM
anyway.  If an application displays drinking fountain information on a map
for Vancouver it doesn't take much effort to modify the code to display the
same information for Ottawa and my expectation is that many of the entries
will be along the same lines.  Small applications that have been modified
from previous work.  I doubt if many will be original and given the amount
of effort that needs to go into testing, this approach produces robust
applications fairly quickly.  This may not be the city council's hope or
intention.  More complex programming takes time to design and integrate with
existing systems.  We might be lucky and have someone come up with a way to
make OSM rules more user friendly to display florists or drinking fountains.
Recommendations

If the city would like to tag the streets with speed limit data or have maps
with AED device locations under its control then the recommendation would be
for the city to run its own OSM format server importing the road data
directly either from the OSM servers or from CANVEC using existing tested
import scripts which I think are available.  Speed Limit tags and AED
locations can be added to this data.  Then I'd populate the rest of the map
from the existing OSM for Ottawa after filtering out the road data.  This
approach would allow people to add information about businesses for example
into OSM knowing that it would be imported into the city's version when the
map was renewed.  Note that Microsoft has a very useful tool called Biztalk
which can be used to combine spreadsheets, structure text files, databases
etc. with XML to make the process of generating maps easier but isn't
normally thought of as a GIS tool.

If the city decides it doesn't need that level of control then the
recommended approach would be to simply release as much data as possible
under the creativecommons.org 3.0 license and take a hands off approach to
what happens next.  Hopefully OSM will be augmented with the city's data by
releasing the data under license so that information about the city services
such as libraries opening hours, web sites etc.  can be merged in using
database techniques of a using a matching key then copying the opening hour
information etc over to the tags.  Example
www.openstreetmap.org/?lat=45.47062&lon=-75.49196&zoom=17&layers=B000FTT and
click on the library building to see the web link and other information.

On the Google side just releasing the data would mean the city wouldn't have
any responsibility on whether the end users could find the appropriate web
site for their information request, nor if the web sites rejected a valid
post code as I've seen one do, nor would they have any responsibility to see
that clients weren't infected as a result of visiting an insecure web site.

Finally thank you to the many people who have been patient enough to answer
questions or with whom a conversation triggered off a thought.  I must
confess I hadn't come across the Google API before and I learnt quite a bit
about OSM's capabilities compiling this report.


Cheerio John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20100503/0a4b0c2a/attachment.html>