First, thanks for the thoughtful replies, everyone. I'll reply to all in one email.<br><br>>It is just that I dont see your solution as a scalable one<br><br>What's not scalable about it - presumably that you have to tag a fall back every time you use the tag? What's an alternative that's more scalable, for someone who doesn't have the ability/time/whatever to setup a rendering system and produce their own custom maps?<br>
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You are sort of advocating a top down approach while others think it has to be a bottom up approach. </blockquote>
<div><br>IMHO what I am (was?) advocating is somewhere in the middle, but closer to bottom up. True top down would be standardising all tags and forcing renderers to be compliant. Somewhat less so is a central list that renderers can optionally implement. I was only advocating a single tag that renderers should know how to deal with, leaving all the rest of the decisions to individuals. Pretty bottom up, if you ask me.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">And all of us are entitled to our opinions. If you have a solution which can make the renderers render what they are supposed to render without adding layers of complicacy, it will be welcome.<br>
</blockquote><div><br>I don't think anyone spontaneously generates perfect solutions out of nowhere. I had an idea, I wanted to see whether it could go anywhere with some workshopping. Sure, maybe it was a dumb idea. But I don't think we can shoot down every idea on the basis that it's not comprehensive. <br>
<br>>Then just start using your fallback tag.  There's no need to tell the list about it.<br><br>IMVHO, that approach is harmful in general (have you *seen* how many different tags are out there?), and ironic in this instance.<br>
<br>>More precisely, the fallback that you are proposing would be relatively heavy both on code and people.<br><br>It may be heavy on code – I hadn't thought about the way Mapnik renders, for instance – but by definition it's light on people: it's a completely optional tag, there for those that want to use it. If you use it, you get some additional benefit, if you don't, you lose nothing. If I was proposing that everyone tag everything with multiple fallback tags, *that* would be heavy on people.<br>
<br>>If it's use *now *is a park, tag it as a park.<br>
>When & if (and that's a *big *if when talking about civil
engineering projects) it changes use re-tag it then & not before.<br><br>Did everyone misunderstand my example this way? The thing is a reserve, not a park. It has grass, but no amenities. It only exists to protect the land for future development. People tag them as parks because that's the closest tag...but it's not ideal. My "tagging for the future" remark had nothing to do with future development, only future support of a "reserve" tag.<br>

<br>>Also, I think this should be on the Tagging forum.<br><br>Yeah, maybe. I thought it was slightly out of scope for that.<br><br>>In the end, OSM is a database, and how you are rendering a map is
something accessory, as "everyone" can set up the rendering the way
they want. It is the greatest strength of OSM that you can choose what
kind of rendering you can do. I think the map should deemphasized at
some point from the main site as more and more people want custom
rendering.<br><font color="#888888">
</font><br>I guess I will have to investigate this further, but that's really not at all how I see OSM, and not how I think the public perceives it. The diehards on this list may all have their own renderers set up at home, but that's rare. For most people, the mapnik view *is* OSM, and switching it off would be dumping OSM's biggest selling point. The world has very much moved to a cloud model, whereas what you're proposing (download the data, render it using an offline client) is exactly the opposite of that. I just don't see that approach gaining traction any more. If anything, I would have thought you'd put more effort into custom rendering on the server, like cloudmade does.<br>
<br>Of course, I could be completely wrong. That would at least explain why I find the response of "make your own stylesheet" so jarring to my original problem statement.<br><br>>Yes, they are. If the render of your choice doesn't render a key/tag,fix it yourself so that it does.<br>
<br>Hmm, and I put so much effort into explaining the difference between a one-off solution and a scalable solution. I thought I'd get more than "yes it is".<br><br>>*You *asked for opinions!?! - "What do people think?"<br>

>Replies are in the negative because they think your idea is poor for the<br>>reasons stated. It's as simple as that.<br>
<font color="#888888"><br></font>Constructive critism is great, and there were some good points raised. But by and large the response was not constructive.<br><br>Steve<br></div></div>