On Jan 30, 2008 12:52 AM,  <<a href="mailto:matthew-osm@newtoncomputing.co.uk">matthew-osm@newtoncomputing.co.uk</a>> wrote:<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;">
Hi,<br><div class="Ih2E3d"><br>On Mon, Jan 28, 2008 at 07:16:25PM -0000, Andy Robinson (blackadder) wrote:<br>> >> Why is it not a property like bridge, cutting etc. and<br>> >> will it render correctly? Should it be changed to<br>
> >> viaduct=yes?<br>> ><br>> >Ewww, yuck... boolean flags.<br>> ><br>> >Personally I would tag as:<br>> ><br>> >  railway=rail<br>> >  bridge=viaduct<br>> ><br>><br>
> bridge and viaduct are two separate types of structure so<br>> strictly speaking bridge=viaduct is incorrect.<br><br></div>They might be different to you as a civil engineer... to me<br>a viaduct looks like lots of bridges next to each other<br>
(i.e. huh, what's the difference, really?) ;-)<br><br>Actually, it's more of a thing I have about using on/off,<br>yes/no, true/false type tags - they generally are not right<br>in my opinion.<br><br>For instance, take the same principle applied to roads<br>
<br>  highway=yes<br>  motorway=yes<br><br>We use highway=motorway here - if nothing else it stops you doing the silly<br><br>  highway=yes<br>  motorway=yes<br>  secondary=yes<br><br>Similarly, something can't be both a bridge and a viaduct.<br>
Therefore you want something like<br><br>  over=bridge<br><br>or<br><br>  over=viaduct<br><br>a) you reduce the keyspace, and b) you can't have<br><br>  bridge=yes<br>  viaduct=yes<br><br>As usual in my case "over" is a bad name for a key. I guess<br>
that's why I stuck to the more generic "bridge" before, with<br>"bridge=yes" being the general case. It's the same as saying<br>bridge=suspension, rather than bridge=yes, suspension=yes<br>(or even bridge_type=suspension - eugh).<br>
<br>Maybe something like "transit=" would be better (in the<br>sense of "how this way gets from A to B") and could then<br>include tunnel, cutting, embankment, etc in the list of<br>values as well as bridge and viaduct.<br>
<br>Basically, I would say that every "object-type" key (i.e.<br>not things like name=) should have as many non-coexistant<br>values* as possible (if that makes sense), and that single<br>flags (i.e.  where a key only ever has one value) should be<br>
discouraged wherever possible.<br><br>* i.e. you can't have both on the same "object", such as<br>  suspension and viaduct<br><div class="Ih2E3d"></div></blockquote><div><br>That's usually the plan I think. The main problem we have with putting this into practice, is that to maintain an optimal number of tags we need to know the entire tagging domain before we start... which we don't.  So taking your example, if instead of bridge=yes we allow bridge=suspension, we don't actually have a problem (assuming everybody agrees to assume the existence of the bridge tag implies a bridge regardless of the value, maybe excluding "no"). But if we had started with transit=bridge/tunnel/ferry, then we'd still need the bridge tag anyway because it's probably not sensible to add the transit=suspension_bridge etc, simply for the ease of processing. Ofcourse you could argue we need the transit tag, and just don't have it.<br>
<br>I think for many of these things where we have x=yes/no, we find that there is often a number of subtypes that could be substituted for the "yes". Although most people probably wouldn't know how to classify them, and just want to record the main type.<br>
 <br>Dave<br><br></div></div>