[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