On Mon, Aug 11, 2014 at 12:28:59PM -0400, Christopher Hoess wrote:
Hi,
> 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.
my criticism was limited to the slight redundancy of
bridge=movable + bridge:movable
One minor issues with the description, Key:bridge:structure says "describe
the load-bearing architecture of individual bridge spans". This meaning of
"span" may not be well known for folks who are not bridge experts and not
native english speakers. Perhaps "sections" or "segments" could be added in
brackets for explanation.
> 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.
agree.
> 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.)
This may be too subtle for many people and somewhat against the principle
of least surprise.
> 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?
it is probably good to keep that one as I have seen plenty of defunct canals
going over aqueducts.
> 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.
the trestle is something that doesn't fit into bridge:structure well, but
bridge=trestle doesn't describe it terribly well either, so some subtag
describing the average width and technical details might be a good idea.
> 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.
I would be in favor of keeping that one but the problem is - you can't have
covered bridge=movable or aqueduct. I have seen covered aqueducts.
> 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.
those can also look as culverts and it would be nice to have the same solution
whether it is a bridge or a culvert. I have tagged those with tunnel=culvert
and ford=yes
Richard
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
