|It has been proposed that this page be deleted or replaced by a redirect. See the discussion page for further information.|
Note to casual browsers - we're not giving this talk any more, but it may resurface in another form soon. Steve will still be speaking at another session. Details here
NTK talk outline
OpenStreetMap is a collaborative website using wiki-like techniques to make maps of the world. GPS traces made by physically travelling on routes and aerial images from aircraft or satellites are used as a base layer upon which streets and features are drawn. Out of copyright maps from the 1950's can also be scanned and used. The data and software produced by individuals is released under free licenses for all to rip, mix and burn.
Openstreetmap was born from the desperate state of geodata (street maps, postcode locations and more) available to anyone with little money in the UK, as the Ordnance Survey holds an effective monopoly on data. This is opposed to citizens in the USA where practically the entire country is available in electronic form for free use. Openstreetmap was envisaged as a collaborative environment where anybody could contribute local knowledge toward a map of the UK, Europe and beyond.
Our recent work on OpenStreetMap has targeted the ever-creeping version 1.0 release, which will address a few lingering (and gaping) issues:
The dynamic nature of OpenStreetMap's data model has been a bittersweet feature, since so much effort has been spent on writing reasonably efficient SQL for database queries and updates. We'd happily avoid reinventing the wheel, but Free technologies like PostGIS only solve part of the problem; most of our difficulty and complexity rests in enabling a journaled view of the model. And so to support OpenStreetMap's Wiki nature, our SQL zen is a necessarily-awful nest of table joining and timestamps.
The culture of OpenStreetMap is one of code now, ask questions later. "Real artists ship" and all that. So our codebase has not always been the most loving beast, with a goodly amount of recent effort going into a gradual rewrite with more disciplined Java practices. For instance, we've had at least one performance problem with head-slapping, un-closed JDBC statements.
Our editing applet does an admirable job of journaling all data modifications in a rollback-able Wiki format, but we do not currently offer enough facilities for adding and modifying street metadata interactively. Our data model and XMLRPC API cheerfully provide these key and value pairings, but our applet does not yet have the GUI widgetry to enable the non-'bot user.
Another current direction in OpenStreetMap work is in bootstrapping Stateside metadata by importing U.S. Census TIGER data. Although our victim up until this point has been the U.K. and more specifically London, there is a reasonable call for U.S. street data as a backdrop for a community of spatial metadata above the level of street name and postcode. A sexy Ruby script has been committed that scrubs tempermental TIGER data, by merging duplicate streets and extracting zip codes. With this script, we have imported New York County (Manhattan), and will soon import the rest of the U.S.
In addition to bootstrapping Stateside higher-level metadata, the TIGER import script has been a practical and intense stressing of the XMLRPC API. As developers we've made a few rounds of performance tweaking, with a successful TIGER data import of Manhattan as the benchmark.
Like other emerging Free software projects, OpenStreetMap is a punchy mix of vision-driven bug fixes, cranky server bouncing, and the precious feature commit.
You're probably familiar with:
- blogs vs newspapers
- Wikipedia vs Britannica
OSM isn't about "scaring" the OS into releasing more stuff. (And it shouldn't have been a waste of time if they do.)
Steven Johnson on blogs vs books, Everything Emergent Is Good For You.
- we lose: sustained argument, quality, consensus and authority,
- we gain: responsiveness/timeliness, context, participation and collateral problem solving.
I argue that OSM could offer much the same for mapping.
Peter Merholz on designing for the sandbox: "a space for content, tools, and people to interact and create their own meaningful experience". OpenStreetMap is a sandbox for making maps. Personal, meaningful content, with some sense of ownership.
Where next for OpenStreetMap?
- more data
- aerial data, scanned map data, etc.
- better management/ownership of data sources, and maps
- postcode lookup
- placename lookup
- more eyeballs, more footsteps,
- easier ways to help out (location-based changelogs, digests etc. email/RSS)
- location-based discussion / issue resolution
- keep building on top of it
- WirelessLondon map cf. previous, context-free Consume map (borrow Schuyler's slide?)
- integrate with other open projects
- e.g. OpenGuides as gazetteer?
- provide hooks for developers
- e.g. map image/tile generation with options
- e.g. more comprehensive XML-RPC interface
- REST interface?
- WMS interface?