2009/12/18 Steve Bennett <stevag...@gmail.com>: As others have stated this should have gone to the tagging mailing list.
> What's not scalable about it - presumably that you have to tag a fall back Your suggestion as is only copes with 1 alternative, rather than gracefully falling back to less specific alternatives. > 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? To come up with a list of options that things fall back to, this may not need to be in mapnik etc, but could be handled by a pre-processor. > 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. And here you were complaining about me suggesting redundency on layer tags was a bad thing and you've basically done the same thing, except worst since you are making suggestions about dictating how renderers handle tags, rather than letting them make their own minds up about falling back to less specific tagging schemes. As I said before, this would be no better than adding an URI for the icon that should be displayed for POIs just because one or more rendered may not render all POI icons. > 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. Isn't that the point of this exercise, to fall back to something else if a more specific tag isn't currently handled, what if the fall back tag isn't handled. That's just an exercise in 2 unrendered tags instead of one. > IMVHO, that approach is harmful in general (have you *seen* how many > different tags are out there?), and ironic in this instance. They differ because of perceived need, renderers on the other hand have perceived needs in what they think should be rendered rather than users forcing things one way or the other. > It may be heavy on code – I hadn't thought about the way Mapnik renders, for Mapnik, or more to the point osm2pgsql does a bunch of pre-processing on OSM data, you could easily supply code or psuedo code to make a lookup table in osm2pgsql handle fall back rather than tryng to do it in extra tags that just have to be processed regardless of if the server should render them or not. > 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. No, that would be heavy on a person making a lookup table, but certainly not to the scale you are suggesting labour should be applied. > 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. Why is park not ideal if the current usage is a park? There is a lot of land that is reserved for roads in future if needed that has been taken over by land holders and they graze stock or cultivate it, the only difference is if the road is ever built the government doesn't need to aquire the land it just needs to evict the squatters. Should they render the same as a park because it's a reserve, but the land use is completely different. > 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. There is already attempts to shift rendering to the client side, there is a javascript site that does this, and now potlatch 2.0 is heading in the same direction. Just because mapnik is the way things are handled at present doesn't mean it will be 5 years from now. _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk