[OSM-talk] Suggestion: fallback tag

[John Smith]

2009/12/18 Steve Bennett <stevagewp at 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.