[OSM-talk] labels for road names and route designations

[Colin Mackay]

[Sorry Lars, you'll get two copies of this as I hit reply and it went
only to you rather than the group]

On 28/02/06, Lars Aronsson <lars at aronsson.se> wrote:
> David Sheldon wrote:
>
> > The best solution would probably to store the tag data in
> > another table of the database with a number of tags per item
> > that is tagged. This is more relational, and has no problems
> > with deliminators.
>
> Yes, the current "label" concept is totally anti-SQL.  But at the
> same time, the segments are under version control.  The rows are
> not updated, but a new row is inserted with the same ID but a new
> timestamp and a new username.  So you can track the edit history,
> just like for wiki articles.  And how do you solve that with a
> fully relational model?  The current OSM API version 0.2
> http://wiki.openstreetmap.org/index.php/REST
> doesn't really give access to the version controls, but the next
> version API could do this.

A couple of years ago I created a system version managed data in SQL
Server 2000. So it is possible.

> The need for version control is also a show stopper for applying a
> traditional GIS database (PostGIS or MySQL GIS functions).

Although a proprietary system, Smallworld GIS employed a VMDBMS
(Version Managed DataBase Management System). Obviously the sheer cost
of Smallworld would be a showstopper in this case. But I mention this
just to show that it is possible. I wouldn't seriously suggest using
Smallworld.

> Within the Wikipedia community, Erik Möller has been designing a
> "Wikidata" system that should be capable of applying version
> control to relational data.  But I don't know if he is done yet.
> http://meta.wikimedia.org/wiki/Wikidata
>
> Perhaps one way is to keep old versions in a separate archive
> table, where snapshots of objects are stored according to the
> current aggregate "label" concept (one row per version), but to
> use a fully relational model for the current data.  This would
> allow advanced SQL queries on the current data (e.g.: give me
> streets where bicycles are allowed, having names starting with A,
> within the polygon border for this city), but not on historic data
> (give me ... as OSM looked in November).

Yes, that is along the lines of my thoughts. It would allow individual
objects to be rolled back if the change was in error or found to be
incorrect.

> We should probably stick to the GIS terminology, where "label" is
> a name printed on a map, and street names and types are
> "attributes".

That would be grand. :-)