[OSM-dev] Restrict key names on order to retain reusability of OSM
sfkeller at gmail.com
Fri Feb 15 00:10:45 GMT 2008
Sorry, the queries would be evaluated like this:
# select id,geometry from ways natural join way_tags where k like
'building%' and v='shop';
So for a comparison, we have TWO INDEXES to maintain, ONE JOIN and TWO
attribute SELECTIONs. Whereas according to my proposal the same would look
# select id,geometry from building where type='shop';
This requires ONE INDEX, NO JOIN(!!!) and only ONE attribute SELECTION.
2008/2/15, Stefan Keller <sfkeller at gmail.com>:
> 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
> 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
> 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
> # 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev