<div>Sorry, the queries would be evaluated like this:</div>
<div>
<p># select id,geometry from ways natural join way_tags where k like 'building%' and v='shop';</p>
<p>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 like this:</p>
<p># select id,geometry from building where type='shop';</p>
<p>This requires ONE INDEX, NO JOIN(!!!) and only ONE attribute SELECTION.</p>
<p>S.</p>
<p><span class="gmail_quote">2008/2/15, Stefan Keller <<a href="mailto:sfkeller@gmail.com">sfkeller@gmail.com</a>>:</span></p></div>
<div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<p>Frederik, Thanks for your patience. I appreciate all of your pioneering work of OSM. </p><span class="q">
<p>> But you came lecturing to us, making urgent demands even, based on<br>> perceived technical necessities that you failed to demonstrate. It's</p></span>
<div>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!</div>

<div> </div>
<div>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. </div>
<span class="q">
<p>> To a certain degree, developers are rational enough to know when to<br>> take advice even if it is offered in a condescending voice. But even<br>> leaving aside the tone in which you offered your advice, you failed to<br>
> convince me that OSM would be a better place with a restricted set of<br>> keys.</p></span>
<p>I think I made my points (c.f. my posts on 12.02.2008 14:27 and 13.02.2008 09:47). But see below for another attempt.</p><span class="q">
<p>Jochen wrote:<br>> Stefan sees keys as a sort of identifier, which makes sense from a<br>> programmer point of view, thinking about hashes etc. It is also how many<br>> other systems are structured as Stefan points out. So there is some kind</p>
</span>
<p>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". </p>

<p>Now Martjin gave a clever tip: <br><span class="q">> Do what most programs do: if you don't recognise the key, ignore it.<br></span>> Think HTML. If you do recognise the key then it's irrevelant if it's<span class="q"><br>
> UTF-8 or not. Mapnik loads stuff into a database and just ignores<br>> everything it doesn't understand.</span></p>
<div>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.</div>

<div> </div>
<div>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! </div>

<p>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:</p>
<p># select id,geometry from ways natural join way_tags where k like 'building%' and v='shop';</p>
<p>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:</p>
<p># select id,geometry from building where type='shop';</p>
<p>This requires ONE INDEX, NO JOIN(!!!) and ONE attribute PROJECTION. This is because database schema could look like this:</p>
<p>CREATE TABLE "building" (<br>  geometry varchar(255) NULL,<br>  id int8 NOT NULL,<br>  user_id int8 NULL,<br>  timestamp timestamp NULL,<br>  type varchar(255) NULL,<br>  PRIMARY KEY ("id")<br>);</p>

<div>Now when it comes to display this, things become even more complicated in your model. </div>
<div> </div>
<div>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.</div>

<p>Stefan</p></blockquote></div><br>