On Mon, Aug 11, 2014 at 7:40 AM, Richard Z. <ricoz....@gmail.com> wrote:
> On Mon, Aug 11, 2014 at 11:00:06AM +0200, Martin Koppenhoefer wrote: > > > > > > > Il giorno 11/ago/2014, alle ore 10:30, Philip Barnes < > p...@trigpoint.me.uk> ha scritto: > > > > > > I do not like the idea of bridge=movable. whilst true, it is only > useful to > > > routers and looses the diversity of OSM, we should not dumb-down > tagging just > > > because it is not universally understood Movable in itself could mean > many > > > things, lifting, swing or even transporter. > > > > > > +1, I believe the redesign of bridge tagging, whilst being an > improvement because of the introduced sub keys for some properties, still > lacks some consistency and logics for some cases, one of them being > "movable" which I'd not set as primary bridge value. > > I would also think that bridge=movable is not needed given bridge:movable. > But is it worth the trouble changing it? I am not against it... but enough > work around:) > Bridge=trestle would be a much clearer candidate to remove from the primary > values table.. whoever knows how it got there. > > What is imho much more important is to decide that the primary bridge > values > should not be further extended without *very* good reasons and the existing > system used as far as possible. > Currently http://wiki.openstreetmap.org/wiki/Key:bridge#Values seems > suggests > that anyone should freely invent his own types (bottom of table). As the author of the last big redesign, I'm having trouble understanding some of these criticisms and would appreciate it if people would draw out the critique a bit so I can try to improve things. I don't see how using bridge=movable constitutes "dumb-down" tagging; all I've done is move the many different possible values to "bridge:movable". I think this is an excellent arrangement, because movable bridges seem to stimulate engineering ingenuity: there are many different types, and I do not feel confident that we can build a comprehensive list of them. In practice, we will need to accept occasional user-defined values for types of movable bridges, but we can't show bridge rendering for an open-ended set of values ("bridge=*") because many user-defined values indicate the bridge is not functional. Moving them into this subtag seems like an excellent way to balance tagging expressiveness with usability. Maintaining both "bridge=movable" and "bridge:movable=*" has at least one useful side effect, which I documented, for bridge geeks like me (i.e., the people who are probably going to be adding hyper-complicated bridge detail); it lets you tag a formerly or planned movable span that is now fixed in place with "bridge:movable=*" but not "bridge=movable". So you could search for "bridge:movable=swing" and find both working and fixed swing spans, but a router wouldn't treat the fixed ones as movable. (See here http://en.wikipedia.org/wiki/1993_Big_Bayou_Canot_train_wreck for the relevance of such spans.) The table of values for "bridge=" is something of a hodgepodge, reflecting common uses in taginfo that didn't fit into the subkeys; what's common in taginfo, in turn, basically represents what people built into the renderers and editing tools. Since I was already proposing to replace "bridge=suspension" with "bridge:structure=suspension", I didn't want to go much further in turning existing practice upside-down. Some thoughts: bridge=aqueduct has longstanding usage, but could probably be dispensed with. The fact that the bridge is applied to a canal or waterway tells us it's an aqueduct. (For the same reason, we don't need an explicit tag for footbridges; that's determined by the way crossing it plus restrictions.) The main argument I can think of for retaining it would be drained aqueducts from defunct canals, which there's no *de jure* official way to tag. Any thoughts from frequent waterway/canal mappers? bridge=boardwalk can be dispensed with; Alv pointed out after voting already started that it's redundant to duckboard=yes. bridge=cantilever, trestle, and viaduct form a natural group of some kind. I don't have a single word to easily sum them up, but they all have to do with the way in which multiple spans of the bridge are arranged and supported. Note that as far as I know, in both American and British English, the term "viaduct" can be applied to both road and railroad bridges; it isn't confined to roads. They can't be parceled into "bridge:structure" because they conflict with the ability to specify the individual spans (e.g., an arch viaduct), but these would be a good target for moving into a subtag. "bridge=viaduct" has a lot of existing uses because of renderer support. bridge=covered has been mentioned now and before as possibly redundant to "bridge=yes" and "covered=yes". I left it in because of this message: http://lists.openstreetmap.org/pipermail/tagging/2013-May/013546.html <http://lists.openstreetmap.org/pipermail/tagging/2013-May/013546.html> which suggested that a bridge covered over wasn't quite the same thing as a covered bridge. I don't have a strong opinion on changing or keeping it at this point. As long as we're simplifying possible values in bridge=, "bridge=low_water_crossing", which is somewhat established but a bit awkward, could theoretically just be marked by a separate tag, maybe "flood_prone=yes". The essential quality we're looking to convey is that the bridge is engineered to spend some time underwater and come out intact. Please give me more detailed criticisms of consistency and logic in the current system: I'd like to float another proposal to fix some of the bugs from the last one before I get really active trying to get renderer/editor support. Yours gratefully, -- Chris
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
