Frederik, Thanks for your patience. I appreciate all of your pioneering work
of OSM.
> But you came lecturing to us, making urgent demands even, based on
> perceived technical necessities that you failed to demonstrate. It's
As regarding the condescending voice, I'm sorry about this. It was really
meant as an advice. I should have realized from the very first answer (sic!)
that there are some top dogs around barking aloud. If someone's fulminating
against other open source technology like Mapserver, this is kind of
irritating!
I perhaps should have introduced myself before hand, before making such an
"demanding" proposal - which irritating too, because in fact this would have
almost no implication for mappers and on the current database.
> To a certain degree, developers are rational enough to know when to
> take advice even if it is offered in a condescending voice. But even
> leaving aside the tone in which you offered your advice, you failed to
> convince me that OSM would be a better place with a restricted set of
> keys.
I think I made my points (c.f. my posts on 12.02.2008 14:27 and
13.02.200809:47). But see below for another attempt.
Jochen wrote:
> Stefan sees keys as a sort of identifier, which makes sense from a
> programmer point of view, thinking about hashes etc. It is also how many
> other systems are structured as Stefan points out. So there is some kind
This gets the core of the issue: The OSM key in fact (i.e. in technical
reality and "best practices") is an *attribute* or a *table name*.
"Flurstück" could become a value of the attribute "Art" in table
"Bodenbedeckung".
Now Martjin gave a clever tip:
> Do what most programs do: if you don't recognise the key, ignore it.
> Think HTML. If you do recognise the key then it's irrevelant if it's
> UTF-8 or not. Mapnik loads stuff into a database and just ignores
> everything it doesn't understand.
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.
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!
Look e.g. at this typical query: "Select all 'shops' (from key
'buildings')". In the current OSM database schema this query would look like
this:
# select id,geometry from ways natural join way_tags where k like
'building%' and v='shop';
So to scale up, we have TWO INDEXES to maintain, ONE JOIN and TWO attribute
PROJECTIONs. Whereas according to my proposal the same would look like this:
# select id,geometry from building where type='shop';
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")
);
Now when it comes to display this, things become even more complicated in
your model.
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.
Stefan
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
