[OSM-dev] Restrict key names on order to retain reusability of OSM

bvh bvh-osm at irule.be
Fri Feb 15 10:07:19 GMT 2008


On Fri, Feb 15, 2008 at 12:57:41AM +0100, Stefan Keller wrote:
> This is the last resort and the only feasible solution as OSM is now. It
> assumes that OSM data will be always stored in the "fixed" key/value-meta
> model and will never evolve or be re-imported from other databases. Users
> will be 'surprised' when they miss their data on the map like with 'Tunnel '
> instead 'Tunnel' or with things like that '¨name'='Südstrasse'. My proposal
> would eliminate that.

No it would not, because users could still use 'tunel' instead of
'tunnel' or even 'naam' (dutch) instead of 'name' as keys.

> Now obviously it's about "geographic data" as said in the OSM homepage and
> its about databases and it's hopefully not HTML. The model you choose it a
> sort of meta model which is ok for initial capturing but not optimal for
> post-processing and showing it in maps - and the difference (from your point
> of view) is just restricting key characters to some smaller set!

See below.

> This requires ONE INDEX, NO JOIN(!!!) and ONE attribute PROJECTION. This is
> because database schema could look like this:
> CREATE TABLE "building" (
>   geometry varchar(255) NULL,
>   id int8 NOT NULL,
>   user_id int8 NULL,
>   timestamp timestamp NULL,
>   type varchar(255) NULL,
>   PRIMARY KEY ("id")
> );

Are you now proposing a completly new database scheme?

> Now when it comes to display this, things become even more complicated in
> your model.

And still numerous renderers have been written for OSM data.

> This specific use case shows that because of my proposal the whole thing
> scales up, needs less space, is easier to query and to program, and it's
> lossless(!) when sync'ing back some data. And you get all this for free and
> - as I said before - without compromising the freedom of mappers values.

An example has been given with a specific German jurisdiction earlier
in this thread where limiting the keynames to utf8 poses extra problems for
the mappers.

cu bart




More information about the dev mailing list