<div class="gmail_quote"><div>Hi Jonathan, </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"></div>
I don't claim to be an osm2pgsql expert, but I think that's a misunderstanding of the situation. I think *any* new tag added to osm.xml results in an extra column, whether it has a colon or not.<br></blockquote><div>
You are right, the colons are not significant.  What I should have said is that I do not like inventing new keys when they are not necessary because they end up needing to be an extra column in the database - adding a colon to an existing key may appear to be some sort of lower level in a hierarchy, but as far as I can tell it is just creating a new key that looks similar to the existing one - at least in the osm2pgsql schema.</div>
<div><br></div><div>In this specific case we have two options:</div><div>         - craft = brewery</div><div>         - craft = cider</div><div>         - craft = brewery; cider etc. etc...</div><div><br></div><div>or</div>
<div>         - craft:brewery = true</div><div>         - craft:cider = true</div><div><br></div><div>both achieve the same thing, but the first uses only a single, pre-existing key, whereas the second creates two new ones.</div>
<div>If the second version ended up storing boolean values, I could see an argument for it because it could reduce storage space, but everything is just text, so there is not much in it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Generally you shouldn't consider any performance implications when creating a tag, because you don't know what will change in the next version of the code. The easy-for-mappers-but-maybe-a-<u></u>bit-computationally-intensive scheme you're trying to avoid may become a non-issue with a few lines of code changed. Equally the opposite may happen.<br>

<br></blockquote><div>Not too sure about that - I don't think either of the options is significantly harder for mappers!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

For information, I'm assured that extra columns produce next to no performance degradation anyway since osm2pgsql started using hstore.</blockquote><div>I am thinking about scrapping my hstore enabled database because things seem to have got a lot slower since I added it, but might do a bit more testing first.....</div>
<div><br></div><div>It is as much about neatness as performance - with a simple 'craft=' schema I can have a single sql query that extracts everything with a craft= tag, then just filter on the value of craft to decide how to render it.   With craft, craft:brewery, craft:cider etc., they will each need a  different bit of sql.</div>
<div><br></div><div>All quite possible, just the simpler one seems neater to me.</div><div><br></div><div>Graham.</div><div> </div></div>-- <br>Graham Jones<div>Hartlepool, UK.</div><br>