Re: [Tagging] Separating usage docs from design docs (was: Increasing voting participation)
On Wed, Mar 18, 2015 at 6:39 PM, Warin 61sundow...@gmail.com wrote: I like the incentive to document the use .. as undocumented tags can be removed .. maybe this could be automated ;-)Say 6 months of undocumented presence = automatic deletion. A warning meassage to the user may provide documentation, ay after 3 months? Flames here... I think that's carrying it a bit far, and too close to the central planning model. I think it would be sufficient to think of undocumented tags as resembling unsupported APIs: yes, you can use them, and they'll probably work most of the time, but they could break or change without warning. If we had a culture where properly documenting tags was the rule rather than the exception, and we had worked through most of the huge backlog of undocumented tags that now exist, *AND* we were happy with the state of affairs, maybe we could think about purging in that way, but I think that would be premature to consider. The 'peer review' I currently see as the comments/voting process. I think it does help with improving tags provided suggestions for improvements are made rather than demands, commands and derogatory comments. Offering a problem is only one side of the coin .. there needs to be a solution too. I try to provide both. Good point. I don't have a concrete process suggestion, but maintaining a collegial and constructive tone in discussions is important. A lot of what people have been saying on this list about resolving votes, abstentions, coming to consensus and so forth could be applied to on-wiki discussions of proposed changes. My proposal was aimed more at the fact that there are very few social incentives to use the wiki right now; the approval process is a mess because it's only used by people willing to take a lot of time and energy for little concrete gain. Adding new values should be the same process as adding a new key, maybe it can be shorter in time? Simply adding things to the wiki does not get the attention of people .. notifying the group gets attention that may lead to improvement. And puting things to the group before going to the wiki is better as basic ideas may be discussed rather than going into a full detail ... things like this discussion don't fit well on the wiki. I think it's important that editing the wiki to incorporate a new key or value be very easy to do, otherwise we start sliding back towards a central planning model. 90% of the documentation will probably be of interest only to a few mappers and won't get changed much after being created. We want to let people do that and go map without trouble. However, if you're changing something important or popular, it's probably best to change the wiki and see what people say before you start adding it to the map. Right now, we don't notice things on the wiki because we're socialized to consider it unimportant. However, pages like http://wiki.openstreetmap.org/wiki/Special:NewPages, maybe with a little filtering, could easily be used to track new key creations; maybe a bot could even monitor it and send a digest to a mailing list regularly. Discussion could take place at the discussion/talk pages in the wiki: e.g., I could say at Talk:Railway I think we should add new value xyz, this is how it fits with the current scheme, what do you think? If on-wiki discussion was the norm, people interested in railroads would have that page on their watchlist, they would see my change when I made it, and could reply. Maybe we could also have a forum on-wiki where people could announce I have a new idea, comment on talk page ... if it interests you. I think the talk pages work OK for that, but I admit that I have been brainwashed by almost a decade of Wikipedia editing, maybe other people do not like to discuss there. -- Chris ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Separating usage docs from design docs (was: Increasing voting participation)
On Wed, Mar 18, 2015 at 6:30 PM, moltonel 3x Combo molto...@gmail.com wrote: On 18/03/2015, Christopher Hoess caho...@gmail.com wrote: That's an interesting idea, but I think it may be a little too heavy on coexistence; I think we'd gradually accumulate a cloud of contradictory proposals with no incentive to resolve them. Are you afraid of wiki bloat ? I don't think it'd be much of an issue. Proposals that fall into disuse will naturally lose their links from feature pages and disappear from public view. We already have a collection of old contradictory proposals that have never been officially rejected. It doesn't hurt much, they sometimes come up in a search, but since we probably never want to fully delete them from the wiki anyway... Well, we should encourage people to try to reconcile proposals and agree on tagging schemes, although there will be some cases where we agree to disagree and document that. How hard we push from that is largely a question of procedure, I suppose. So, my modest proposal: if you want to create a new key, add a new page to the wiki. If you want to create a new value for a key, add it to the existing page for the key. If someone sees that edit and wants to change it, they can change it; if you object, the two of you can discuss it on the talk page. Tags used in the database that are not documented in the wiki (here comes the outrageous part!) are treated as provisional; they can be added or removed at will, by any editor, mechanically or otherwise. Tempting, but I don't think it'll fly, for a few reasons: * We've got a huge backlog of frequently-used non-documented keys to work through : http://taginfo.osm.org/reports/frequently_used_keys_without_wiki_page Yeah. We'd have to have a lengthy amnesty period (= 1 year), with targeted notifications, challenges to write documentation, etc., before making a change in policy like this. * For good or ill, a lot of contributors don't (want to) use the wiki. Turning it into a mandatory part of osm just won't work from a social point of view * You're raising the bar quite a bit for the creation of new tags, without even improving the quality of tags in the process. Is that because using the wiki is intrinsically terribly hard (admittedly, having unified login for the wiki and the database proper would be nice), or is this a side effect of the fact that there's very little incentive to use it? People (hopefully) use tags more than once: slapping down a sentence or two in the wiki on the occasions you need to invent one doesn't strike me as an extraordinarily high bar. I don't think we can get everyone who needs a new tag to submit high-quality, well-thought-out proposals from the beginning. But making their ideas publicly visible via the wiki should get more feedback on the tags and sooner. As it stands today, bad or incomprehensible tagging can fly under the radar until it's so widespread it can't readily be corrected. * Suggesting that it's ok to undo somebody's work because he didn't document it is a recipe for nasty conflicts. See my caveats above my reply to Warin: I wouldn't want to launch search-and-destroy missions against undocumented tagging. But if there's really a serious conflict over how to use certain tags, it's going to manifest *somehow*. Because, under this proposal, documentation on-wiki provides a positional advantage, I would expect these conflicts to flow away from the database towards the wiki, which IMO is more transparent than having them buried in map changesets. It seems like the best way to get your way under the current system is not to waste energy on the wiki and tag as energetically as possible according to whatever scheme suits you. That's not entirely a bad thing--in the big picture, adding to the map is what's important--but it's a recipe for perpetual semantic confusion and ambiguity within the database. -- Chris ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Separating usage docs from design docs (was: Increasing voting participation)
On Wed, Mar 18, 2015 at 9:14 AM, moltonel 3x Combo molto...@gmail.com wrote: On 18/03/2015, Frederik Ramm frede...@remote.org wrote: So please, don't go over board here by trying to force-involve every mapper in tag votes; they're simply not important enough, and they *should not be*. Don't try to make them important, lasting, or binding. +1 to all that. While I think that voting is very usefull, I think the whole concept of accepting a proposal (all the related arguments about voter thresholds) should be scraped entirely. Instead, how about revisiting the purpose of proposals pages vs key/tag pages : * key/tag pages would document the actual use (mainly observed via taginfo) * proposal pages would document a desired use (and include the current list of supporters/opponents) * ideally both pages would reference each other (many to many), maybe using a used/encouraged/discouraged by link template * key/tag pages could be kept up to date fairly objectively * proposal voters should put the page on their watchlist, in case a change in the proposal changes their opinion * proposals should only be end-of-lifed if there is near-unanimous opposition and near-zero actual usage This should clarify the old question of whether the wiki does/should document usage or intent. It'll allow competing proposals to coexist more visibly. It keeps the interesting opinion poll use of voting, while removing the obnoxious proposal is ready ! vote now so that we can start using it ! calls. That's an interesting idea, but I think it may be a little too heavy on coexistence; I think we'd gradually accumulate a cloud of contradictory proposals with no incentive to resolve them. I have a modest proposal to make on the tagging/approval workflow. (For readers not familiar with the idiom, it's a proposal put forward to spur discussion rather than a serious policy recommendation.) I feel that many people's reaction is going to be No! That's ludicrous and against the spirit of OSM! but I'd like to hear *why* you think that. Let's start with a few principles. Tags are here to convey information about objects being mapped. Because we map a wide variety of features and serve many different interests, the process of tag creation needs to be fairly egalitarian. No matter how intelligent or well-meaning, a small central board can't design all necessary tags from scratch (wisdom of crowds, etc.) However, in order to serve their purpose of conveying information, tags also need to be documented. If only one person understands what a tag means, it really hasn't conveyed information. They're weakly self-documenting, but the meaning of a given key-value pair may be ambiguous or obscure; it's vastly preferable to have written documentation in the wiki, in whatever language, to clarify the mapper's intentions. Perhaps somewhat more controversially, while we want an egalitarian process for tag creation, I would propose that we also want new tags to undergo some form of peer review, if possible. Feedback from others can improve the design of the original proposer. So, my modest proposal: if you want to create a new key, add a new page to the wiki. If you want to create a new value for a key, add it to the existing page for the key. If someone sees that edit and wants to change it, they can change it; if you object, the two of you can discuss it on the talk page. Tags used in the database that are not documented in the wiki (here comes the outrageous part!) are treated as provisional; they can be added or removed at will, by any editor, mechanically or otherwise. Essentially, this serves two purposes: 1) We have very strong social norms to avoid damaging other people's data. However, these norms protect not only good data (where the meaning of the data is shared and readily available) but data which is only understood by the original mapper, if anyone (essentially, private mapping). (cf. this recent message: https://lists.openstreetmap.org/pipermail/talk-us/2015-March/014445.html) The protection of data becomes part of a reciprocal contract: if you want your data protected, you need to tell us what it means. 2) It leverages the rich toolset on wiki to let people keep track of how tags are being expanded and redefined. MediaWiki has features like Special:Newpages, watchlists, related changes, and so forth which would make it easier to keep track of new ideas about tagging. It's much trickier to do this if you have to monitor changesets on the map, even when aggregated by tools of taginfo. OK, flame away! What don't you like? -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridge Parapets
This sounds like it would be connected to the man_made=bridge proposals to map bridges as polygons. Maybe representing the parapets as lines that share nodes with part of the man_made=bridge polygon? -- Chris Hoess On Wed, Mar 18, 2015 at 5:05 PM, Dudley Ibbett dudleyibb...@hotmail.com wrote: It would appear that the rendering for a bridge might include the parapet. Much of my local mapping however includes barriers along roads. These are generally connected to the bridge parapet. It would seem reasonable to therefore have a seperate way for each bridge paparet that links the barriers either side of the bridge. Perhaps, barrier=wall, wall=parapet. Parapet is however used in more that one context http://en.wikipedia.org/wiki/Parapet If bridge parapets were to be mapped would they therefore need a more distinct name in this context bridge_parapet of should there be some sort of relation between the highway segment of the bridge and its associated parapets? At the moment I just leave the barriers hanging but it doesn't seem like a very satisfactory approach to mapping given they are attached to the bridge. Regards Dudley ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=movable?
Dave, My rationale for the revisions was roughly as described by Dominik and Tobias. Movability is a potentially important property for routers, and there are a lot of different types of movable bridge; some are nearly unique and difficult to classify as to type, or they may simply be hard to classify without on-site observation. The router isn't going to care what mechanism is used to move the bridge, so having an explicit bridge=movable tag lets us convey that information even if we're having trouble with a more detailed classification. I didn't add a tag to indicate the bridge is fixed in position because that's the default state for bridges; they should be assumed to be fixed unless explicitly tagged as movable. The trick Dominik mentioned Note that this key may be used without tagging bridge=movable, to indicate a formerly movable bridge that has been fixed shut, was criticized as being a bit too subtle and prone to misinterpretation as an error; I could float a proposal for a fixed bridge tag to make that explicit if people feel it's worthwhile. -- Chris On Fri, Feb 27, 2015 at 7:05 AM, Dave F. dave...@madasafish.com wrote: Hi What's the purpose of bridge=movable? http://wiki.openstreetmap.org/wiki/Key:bridge:movable It's good that the different types of bridge are tagged the graphics are excellent, but I'm unsure why they need to be separated to a sub tag. bridge=movable bridge:movable=swing gives bridge=swing If there is a genuine reason, then surely there should be the equivalent: bridge=static bridge:static=* Cheers Dave F. -- http://www.avast.com/ This email has been checked for viruses by Avast antivirus software. www.avast.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Voting system- time for reform?
That's somewhat overstates the case. Adoption vs. non-adoption is the acid test of whether a proposal is acceptable or not, but the laissez-faire approach does let the tagging get stuck in local minima. For instance, the initial development of railway mashed together several distinct and independent attributes under one key: gauge between rails (railway=narrow_gauge, railway=miniature), type of service (railway=preserved), lifecycle (railway=disused, railway=abandoned, railway=construction). This works OK about 98% of the time, but sometimes these values come into conflict (a preserved narrow gauge railway that's disused due to washouts)? In retrospect, a little forethought would quickly have identified these problems and allowed us to draft a more expressive tagging scheme that would have avoided this. And one has, sort of, grown up around this (the gauge key, and OpenRailwayMap has started using railway:preserved=yes). But since we've also decided that, socially, mass retagging of old data is on a par with public defecation, we're more or less permanently stuck with the deficiencies of the original scheme that just grew. Don't get me wrong--I see a lot of the proposals that float across this list and it's clear that many proposed tagging schemes have a precision or level of detail that vastly exceeds what anyone will ever map. You could also, reasonably, argue that if we'd had a more complex railway tagging scheme initially, it would have hindered mapping, or that we only retrospectively know that the attributes I've listed are important to map because they became common under the initial scheme. The idea that the current process is the best possible way to develop tagging smacks of Dr. Pangloss. On Thu, Feb 12, 2015 at 9:57 AM, Paul Johnson ba...@ursamundi.org wrote: You're missing the point. OSM is already a meritocracy and tagging schemes either float or they don't, in the wild, under their own merit. There's no reforms that could be made to change this short of locking out the ability to use key and value combinations that aren't anointed. Good luck with that. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=adit_entrance
On Sat, Dec 6, 2014 at 1:43 PM, Friedrich Volkmann b...@volki.at wrote: Wikipedia says: An adit (from Latin aditus, entrance)[1] is an entrance to an underground mine... An adit_entrance would be an entrance to an entrance. An adit is the entrance to a mine in the way a lobby is an entrance to a building; you could still have a lobby entrance without committing a solecism. In the parlance I'm familiar with (generally hard-rock mining in the northeastern US), an adit is a more or less horizontal tunnel that's driven from the outside of the mine to bring miners to the vein of the desired mineral, and often to provide drainage. That is, the material excavated to create the adit is generally country rock rather than the ore being sought; a horizontal tunnel following the ore is a drift. The problem with all this is that identifying adits, drifts, stopes, etc. may require knowledge about the working of the mine and the ore body which has long since been lost. While I was composing this, Mateusz hit what I think is the key point for mapping: for a given entrance, the main thing we'd like to know is whether it's an entrance to a roughly horizontal tunnel, a roughly vertical shaft, or some intergrade between the two. (e.g., past a certain gradient, the entrance should probably be marked as a shaft rather than a vertical entrance). There's nothing wrong with tagging the adit itself, but that should be applied to the underground passage rather than the portal to the passage. -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] cobblestone, sett and surface=*
FWIW, in my area (northeastern US), sett is referred to as Belgian block, but most people would indiscriminately refer to both surfaces as cobblestone. -- Chris Hoess On Sat, Aug 23, 2014 at 2:57 AM, Mateusz Konieczny matkoni...@gmail.com wrote: How one should tag surfaces: - paved with equally sized, flat stones ( https://www.google.pl/maps/@50.061304,19.938305,3a,30y,270.75h,72.93t/data=!3m5!1e1!3m3!1sBcAaihLoEYmtOQbTnOlxWA!2e0!3e5?hl=pl ) - paved with roughly shaped stones, only partially flattened ( https://www.google.pl/maps/@50.059029,19.940113,3a,30y,276.76h,68.16t/data=!3m4!1e1!3m2!1sJiyUyJYQx9Fqv_dC1-18_A!2e0?hl=pl ) I tag in the first situation as surface=sett and in the second as surface=cobblestone. Bur according to https://wiki.openstreetmap.org/wiki/Key:surface both should be tagged as surface=cobblestone. cobblestone:flattened is mentioned (without any description). To further complicate situation it seems that both surfaces should be described as sett - see http://en.wikipedia.org/wiki/Sett_%28paving%29 Meanwhile, on taginfo - https://taginfo.openstreetmap.org/keys/surface#values : - cobblestone 119 216 - sett 6 261 - cobblestone:flattened 2 176 Cobblestones, sett mistaken for cobblestone and flat sett are clearly different and I hope for way to differentiate between these, better than using smoothness. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
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
Re: [Tagging] bridge=humpback ?
On Mon, Aug 11, 2014 at 7:03 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: The wiki says for viaduct A bridge composed of a series of short spans. The spans may be arches, girders supported by piers, etc. We should remove the word short, because this is relative and depends on the scale and design. A famous example is in France: http://www.fosterandpartners.com/m/projects/millau-viaduct/images/gallery/ Well, dictionary.com offers a bridge for carrying a road, railroad, etc., over a valley or the like, consisting of a number of short spans, but I agree with you in practice that the spans don't necessarily have to be short, just that there have to be a reasonable number of something. I don't think there's really a hard definition for what a viaduct is; it's a matter of having a certain gestalt. What about A bridge composed of a series of spans, often short relative to its overall length as a definition? Yours, -- Chris ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On Mon, Aug 11, 2014 at 3:33 PM, Tod Fitch t...@fitchdesign.com wrote: The image reminds me of a bridge, no longer open for traffic, on the old National Pike in Western Maryland. I can see where one might want to reduce speed on one of those to avoid bottoming out or becoming airborne. I think rather that bridge:structure=humpback I'd prefer bridge:geometry=humpback. At least something that conveys shape meaning. For me structure implies the design element that gives a building, bridge, dam, etc. its strength. In the case of the photo that would be masonry arch for structure. +1. Humpback seems mostly to be defined by the aesthetic effect and the potential effect on vehicles; there seems to be a popular Humpback Bridge on Virginia that's a covered truss with a mild humpback. I'd rather not dilute the more or less coherent nature of bridge:structure=, although better that than bridge=. Although tagging it as some sort of highway hazard or condition is not a bad idea either. -- Chris ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
Martin, OK, viaduct boldly fixed on-wiki! Also added some explanatory text to Key:bridge:structure, overlapping with Key:bridge, as to what a span is and how to deal with bridges with multiple span types. -- Chris On Mon, Aug 11, 2014 at 8:11 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Il giorno 12/ago/2014, alle ore 01:55, Christopher Hoess caho...@gmail.com ha scritto: A bridge composed of a series of spans, often short relative to its overall length +1 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On Mon, Aug 11, 2014 at 5:33 PM, Richard Z. ricoz@gmail.com wrote: On Mon, Aug 11, 2014 at 12:28:59PM -0400, Christopher Hoess wrote: 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. Good point. I can easily see people correcting bridge=yes to bridge=movable because they see the bridge:movable tag on a span. What if we made bridge=fixed a synonym of bridge=yes? 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. I don't think there are any extant covered movable bridges. Re. aqueducts, in what sense was that covered? A closed pipe? If we retain bridge=covered in addition to covered=yes, I think it should be particular to the classic covered bridge where a truss (usually) has been covered to keep out the weather. 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 flood_prone might be a little better for both in that I think of a ford as having water more or less perennially covering the crossing, whereas a low water bridge, like a road dipping into an arroyo, is only covered by irregular intervals of high water. Yours, -- Chris ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
On Mon, Aug 11, 2014 at 7:57 PM, SomeoneElse li...@mail.atownsend.org.uk wrote: For the benefit of anyone looking at taginfo stats in this thread, it's worth mentioning that there's some non-survey-based editing going on: http://www.openstreetmap.org/changeset/24690099 All bridge=drawbridge to bridge=movable bridge:movable=drawbridge. The bigger problem is that many of these bridges, whether originally tagged by local surveyors or not, are probably strictly speaking bascule bridges, drawbridge being used casually for any sort of movable bridge. -- Chris ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
On Sat, Aug 9, 2014 at 8:25 AM, Richard Z. ricoz@gmail.com wrote: thanks, that looks much better now. Would it be fine to add the simple_suspension type (http://en.wikipedia.org/wiki/Simple_suspension_bridge) to http://wiki.openstreetmap.org/wiki/Key:bridge:structure ? It appears that most of the illegal values were intended to map this type of structures. Do you think simple_suspension or hanging is better as a type? If not, I don't feel strongly about this, but it's a single word and not readily confused with conventional suspension bridges. Yours, -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
Volker, There was a rather inconspicuous sentence at the end of http://wiki.openstreetmap.org/wiki/Key:bridge linking to the additional bridge:... keys. I've reordered the introductory material in that page somewhat to make it more clear that these additional options exist for adding detail about bridges. I'm sorry I didn't follow up on this more promptly when the proposal closed, but I think the wiki is in pretty good shape now. If there's something that needs more detail, let me know. I've also asked for http://github.com/gravitystorm/openstreetmap-carto/issues/440 to be reopened to get proper cartographic support for what's now in the wiki, including bridge=movable. Yours, -- Chris Hoess On Fri, Aug 8, 2014 at 7:10 AM, Volker Schmidt vosc...@gmail.com wrote: agreed That means producing a revised bridge wiki page that combines all info. Who does the work? :-( On 8 August 2014 13:07, Tobias Knerr o...@tobias-knerr.de wrote: On 08.08.2014 11:35, Richard Z. wrote: My idea was * abandon bridge=swing in favor of bridge=movable which could provide subtyping if someone really needed it. We already have an approved proposal that provides this subtyping: http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types * introduce bridge=suspension bridge=simple_suspension Said proposal also introduces bridge:structure=suspension. So I think the only problem is to get people to use these tags instead of the problematic bridge=swing. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Bridge types)
Dave, I'm officially agnostic on that question! I know both tunnel=culvert and culvert=yes are used much more frequently in OSM than bridge=culvert; I think one of them predominates, but I don't know which. Yours, -- Chris Hoess On Mon, Sep 23, 2013 at 11:33 PM, Dave Swarthout daveswarth...@gmail.comwrote: Hi Chris, I have been following this thread for a few days and have one question although it might be too late to ask it. Do you want to drop the tag culvert in favor of tunnel altogether? I see from the discussion that some people prefer tunnel=culvert in the cases where I have used culvert=yes and layer=-1. I have done some mapping in Alaska and there are many, many culverts in use as drainage ditches, etc., all over the state. To call a culvert, which is usually a heavy, corrugated, galvanized metal pipe from 1 to 6 feet in diameter, a tunnel is a bit of a stretch IMO. I can live with the change but wanted to pass along my thoughts to you. Thanks, Dave Swarthout AlaskaDave On Sun, Sep 22, 2013 at 11:02 PM, Christopher Hoess caho...@gmail.comwrote: Greetings, I've just been over the bridge types proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types which I brought to the list twice earlier this year. I think the bugs have been pretty well ironed out, and further changes would largely be a matter of taste, so I bring it to you for voting. Summary points since the last discussion: The bridge_type key has been changed to the more appropriate bridge:structure. The installed base of bridge_type is relatively small (547 objects), so this shouldn't be a big deal. Typology will stay in bridge for simplicity. I decided to keep the bridge=movable; bridge:movable=... tagging scheme. I think the complexity of the movable bridge types, plus the fact that the average person may not know how to distinguish them, makes a two-tiered hierarchy reasonable here. I dropped culvert, since our accepted practice seems to use that to tag a tunnel on the lower way at such crossings. I know I can't please everyone in every point, but I think your input has made this a very sound proposal with plenty of room for future extension. Thanks for your consideration. Yours gratefully, -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - shop=musical_instrument
Andreas, Those are somewhat exceptional situations, since clothes doesn't really have a singular in English and shoes are inevitably sold by the pair. -- Chris Hoess On Sat, Sep 21, 2013 at 11:32 PM, Andreas Labres l...@lab.at wrote: On 21.09.13 18:00, Matthijs Melissen wrote: For shops selling musical instruments, there are currently two tags in use: shop=musical_instrument and shop=musical_instruments. The singular (1327) is used nearly 10 times as much as the plural (126). This IMHO is a consequence of Key:shop suggesting the singular since 2009. OTOH it is shop=clothes or shop=shoes, so wouldn't the plural make more sense (that's probably what those 126 thought)? /al ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - (Bridge types)
Greetings, I've just been over the bridge types proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types which I brought to the list twice earlier this year. I think the bugs have been pretty well ironed out, and further changes would largely be a matter of taste, so I bring it to you for voting. Summary points since the last discussion: The bridge_type key has been changed to the more appropriate bridge:structure. The installed base of bridge_type is relatively small (547 objects), so this shouldn't be a big deal. Typology will stay in bridge for simplicity. I decided to keep the bridge=movable; bridge:movable=... tagging scheme. I think the complexity of the movable bridge types, plus the fact that the average person may not know how to distinguish them, makes a two-tiered hierarchy reasonable here. I dropped culvert, since our accepted practice seems to use that to tag a tunnel on the lower way at such crossings. I know I can't please everyone in every point, but I think your input has made this a very sound proposal with plenty of room for future extension. Thanks for your consideration. Yours gratefully, -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Visual editor for the wiki (WAS: How to overcome lack of consensus)
Rob, I'm not sure I'd rush into it, anyway. Even granted that en.wikipedia probably uses more complex markup and templates than we do, uptake of the visual editor (among new editors and otherwise) doesn't seem very high, and no one outside of the WMF seems very impressed by its current state of development. Yours, -- Chris Hoess On Tue, Sep 17, 2013 at 3:49 PM, Rob Nickerson rob.j.nicker...@gmail.comwrote: Daniel wrote: - Make it easier to edit the wiki. Hi Daniel, I agree - the wiki can be hard to edit if you have never done this before. This is why I requested a visual editor (that is now used by Wikipedia) to be added. Unfortunately this requires an update to the version of MediaWiki that we use so is not a simple case of installing a plug-in. Hopefully it will be picked up sooner rather than later but in a volunteer based project patience is essential :-) https://trac.openstreetmap.org/ticket/4920 Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
To speak to Malcolm's point, there is a default rendering strategy for unknown bridge tags. Unfortunately, because there's an ill-defined group of values used to indicate that a bridge is closed, damaged, gone, etc., the default rendering is not to render an undefined bridge value as a bridge. Looking at Mapnik's osm.xml, there appears to be a whitelist of accepted values that will get rendered as a bridge: yes,true,1,viaduct. Since, in practice, mappers are unlikely to use a tag that has a disruptive or unexpected rendering, any new value is going to have to be coded into that whitelist before it gets much practical use. Movable bridges are a fairly eclectic lot, with a lot of oddball solutions to the problem of clearing the channel; rather than try to stuff a completely comprehensive list into bridge=*, I still think it makes sense to use bridge=movable to indicate them and push the detailed information, which is unlikely to affect rendering or routing, into bridge:movable=*. I see the situation as being analogous to highway=service; service=*, which allows us to render service roads more or less uniformly without having to specify an exhaustive list of possible types. I appreciate Richard's point that the tools available on the programming side aren't your grandfather's regexp, but I was basically considering the whitelist problem I discussed above, which as far as I can see isn't really soluble by sophisticated parsing alone. From a human interface point of view, even with bridge:movable and bridge:type thrown into the mix, this proposal is still a set of fairly concrete (no pun intended) key-value pairs. I don't feel that using this syntax would be a terrible hurdle for typical mappers, particularly when compared to some of the more abstract relations, conditional syntax, and so on. I'm trying to strike a balance between several goals: easy and intuitive tagging so mappers mostly get it right, a rich, expressive vocabulary so mappers don't have to choose between conflicting tags, and some amount of flexibility and modularity, so that extending our tagging beyond what's now proposed will still more or less work with programs that implement the proposal. -- Chris Hoess (choess) On Thu, May 9, 2013 at 6:09 PM, Malcolm Herring malcolm.herr...@btinternet.com wrote: On 09/05/2013 21:41, Christopher Hoess wrote: I'm not absolutely set either way; since you bring it up, I'd like to hear other people weigh in as well. As a renderer developer, I see no problems with Richard's simplification. Renderers should always have a default for unrecognized types, since these are frequent, owing to typos and mappers inventing their own. My view is that the simpler the tagging scheme is, the better. __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
On Mon, May 13, 2013 at 7:58 AM, Steve Bennett stevag...@gmail.com wrote: On Fri, May 10, 2013 at 8:24 PM, Richard Fairhurst rich...@systemed.net wrote: So for the tiny number of renderers/routers which want to show bridge types differently - and my canal renderer will be one of them! - differentiating based on a single bridge= tag is plenty easy enough. For the majority of renderers/routers, it's a bridge will suffice. In this case, movable is such an obvious place to break the hierarchy down. It's very easy to imagine a non-specialist map would want to show movable bridges slightly differently. It's much harder to imagine many maps caring about the difference between bascules and drawbridges. Agreed. Similarly, the bridge_type=* is a convenient place to get all the bridge nerdery out of the way of normal data consumers. (But I'd quibble: I'd promote floating and culvert as a fundamental kind of bridge, and demote trestle and cantilever as bridge_types). Well, bridge_type or bridge:structure or whatever isn't *just* for offloading technical detail of limited rendering value; it's also a conflict-prevention measure. Demoting cantilever into that key, for instance, makes it impossible to express both cantilever and truss simultaneously, which presents a problem. Now, I've realized that bridge=covered is actually superfluous to bridge=yes; covered=yes; if that goes away, several of the values (trestle, viaduct, movable, cantilever) sort of have a loose association in describing how the spans are supported or mounted. So promoting floating up there would make sense to me, but I wouldn't demote cantilever and I'm inclined to keep trestle together with the nearly synonymous viaduct. Because it's almost always tagged on the lower, rather than the upper, way, I'm inclined to drop culvert entirely barring a strong argument to keep it. -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
On Wed, May 8, 2013 at 5:39 PM, Martin Koppenhoefer dieterdre...@gmail.comwrote: I think we could also keep typology in bridge=* like we do for buildings, but if there was a majority for bridge:type I had no problem either. From comments so far, I think I'm happy to go with this for simplicity. [...snipped...] Maybe we could also add some key to distinguish the kind of material of the structure, e.g. masonry, riveted steel, iron, wood, ...? I'm holding on that for later. (There's a base_material key in the Humanitarian Data Model that looks useful.) I want to try to do this proposal /right/; thorough discussion on-list and on-wiki, get it formally approved and changed on the wiki, and, with some help, get patches out so that Mapnik, Potlach, and JOSM (and now iD, I suppose) will parse the new scheme and support it in their presets. Hopefully, in the long run, this means more stability for bridge and related tags. However, it does mean I don't want to make it too big in scope: the more issues I try to address, the harder it is for me to keep up with all of them, and the more likely it is that the whole proposal will get snagged on one contentious part. Once this proposal seems well along towards completion, I'll probably go back and start drafting separate proposals for structural material, bridge name, and maybe try to make sense of the various values indicating that a bridge isn't usable. -- Chris Hoess (choess) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
Richard, I included the types of movable bridge in the bridge key in the previous round of my proposal in January, for similar reasons (compatibility, brevity). I made the change based on LM_1's comments ( http://lists.openstreetmap.org/pipermail/tagging/2012-January/009163.html and reiterated on the wiki). Specifically, what made me switch was thinking about renderers, routers, and other consumers of the data. The list of movable bridge types is rather volatile: it's easy to imagine someone coming up with additional types besides the ones I've listed for movable bridges. If all the movable bridge types are filed under bridge, adding a new type will not work with downstream consumers until they've been patched (which seems to be a fairly serious obstacle). Using bridge=movable with bridge:movable is a little more wordy, but it allows renderers to render it as a bridge and routers to recognize that it might open in the middle of the commute, even if it's some exotic type of movable bridge not provided for here. 577 instances isn't that big an installed base, all things considered (and they don't even render properly, right now). movable vs moveable is annoying, but they shouldn't build up too badly as long as someone is regularly sweeping taginfo for the misspelling. I'm not absolutely set either way; since you bring it up, I'd like to hear other people weigh in as well. Yours, -- Chris Hoess On Thu, May 9, 2013 at 10:35 AM, Richard Fairhurst rich...@systemed.netwrote: This is generally good. One comment: Christopher Hoess wrote: [...] we might also consider whether movable should be under bridge or bridge:type. Placing it in the former would mean patching current renderers (e.g., Mapnik), but placing it in the latter makes specific movable bridge types (e.g., bascule, swing) rather wordy to tag, with three separate keys. It makes more sense to replace: bridge=movable; bridge:movable=swing bridge=movable; bridge:movable=lift bridge=movable; bridge:movable=bascule bridge=movable; bridge:movable=drawbridge bridge=movable; bridge:movable=transporter with simply bridge=swing bridge=lift bridge=bascule bridge=drawbridge bridge=transporter This removes unnecessary duplication, is more memorable (is it 'moveable' or 'movable'...?) and accords with current usage (e.g. 577 occurrences of bridge=swing). cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Bridges-redux-tp5760227p5760348.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Bridges redux
Greetings to the list, I've started revising my bridge tagging proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types based on the comments received in the last go-round in January. There are three specific questions I'd like some feedback on before I submit a full RFC again. As preface, I should note that I feel it is important to create at least one key in addition to bridge. Trying to fit all of the proposed values in one key will inevitably lead to conflicts: how do we represent a beam bridge that is also covered? A viaduct that is also an arch bridge? a cantilever made of truss spans? The railway key has problems caused by the all-in-one approach: how do you represent a disused narrow-gauge heritage railway? I'm not going to float a bridge proposal that sets us up for similar problems. That said, the first of my questions is How should we divide these values among keys? My proposal basically follows the dichotomy Martin Koppenhoefer laid out here http://lists.openstreetmap.org/pipermail/tagging/2012-January/009162.html: one set of tags for typology (originally proposed by me under bridge), and one set for structure (originally proposed by me under bridge_type). I'm in favor of placing the structure classifications under bridge:structure to make it clear what's being classified; there are about 550 occurrences of bridge_type at present, most of which can go to bridge:structure. The bigger question is whether the typological values (covered bridges, viaducts, trestle) should stay under bridge or move to a bridge:type key. The main disadvantage of this move is that there are a large number of existing bridge=viaduct instances (about 27,000). The advantage of putting typology under bridge:type is that it reduces the number of types a renderer or downstream consumer has to be aware of. All ways tagged with bridge=yes; bridge:type=... would be rendered properly as bridges without changes to the current renderers, as would future additions or removals of types. If we consider this, we might also consider whether movable should be under bridge or bridge:type. Placing it in the former would mean patching current renderers (e.g., Mapnik), but placing it in the latter makes specific movable bridge types (e.g., bascule, swing) rather wordy to tag, with three separate keys. At present, I tend to favor placing the typology under bridge:type except for bridge=movable but I would like further opinions and discussion. My second question is whether culverts should be included in this proposal. I included values for culverts in the structure classification to maintain compatibility with the Humanitarian Data Model http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Model, but tagging culverts on the overhead way (rather than the way that passes through them) is a very small minority tagging style. JaakkoH, who's active in Haiti work, suggested dropping it, and I'm inclined to follow his advice. My third question is what to do about the drawbridge value for the proposed bridge:movable key. NE2 pointed out that this is something of an attractive nuisance; people tend to use drawbridge when they really mean bascule. Should we drop this value from the proposal because of the potential for misuse? Is there another name that can be applied to those bridges? Your comment on these three points is much appreciated. Once I feel like I have a sense of the community's position, I'll revise the proposal page and put it up for RFC again. Yours, -- Chris Hoess (choess) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
On Thu, Jan 31, 2013 at 11:14 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2013/1/31 Martin Vonwald imagic@gmail.com: In my opinion this is a rather obvious approach therefore I'm not surprised that someone already came up with it earlier. But I am definitively surprised that we don't have any documentation in the wiki for it. there are real examples, e.g. these two: http://www.openstreetmap.org/browse/way/42922473 http://www.openstreetmap.org/browse/way/44097288 which started with bridge=area and name=* but were fixed in the meantime (fix nonconforming uses of bridge tag) ;-) My sincere apologies. At the time, I was rooting through the long tail of bridge= values trying to figure out what values were being used and should be supported by a new proposal, fixing typos (bridge=ye) and so on; I really shouldn't have removed that. IIRC, it was only two bridges I saw in Italy that were tagged that way, so I haven't been going around removing large numbers of bridges marked up this way. It was neither a common nor a documented usage, which is probably why I was overbold in removing the markup. I have no objection to a good system for dealing with outlining bridge area, multiple ways sharing a span, and so forth, but as I haven't any particularly good ideas to offer, I haven't really engaged the problem. -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Bridge types
On Fri, Feb 1, 2013 at 7:38 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2013/1/13 Paul Johnson ba...@ursamundi.org: Perhaps instead of bridge_type, it should be bridge:structure, or some other indication that it's referring to the general engineering and architecture of the bridge rather than the vague type which might get confused with foot, cycleway, motorway etc; and _ which isn't a good separator for what is effectively a subkey. sorry for replying quite late to this thread. I agree with Paul, tagging explicitly the structure in one subtag would be better, and IMHO one subtag is not sufficient for classifying bridges. I'd like to add a reference to another thread about the same topic one year ago: http://lists.openstreetmap.org/pipermail/tagging/2012-January/009162.html In my original proposal, the way I'm using bridge= more or less corresponds to Martin's bridge:type=, and my bridge_type= corresponds to your bridge:structure=. Changing bridge_type to bridge:structure seems reasonable; is it necessary to create a separate bridge:type tag, and if so, what should be the values for the bridge tag? I haven't dealt in this proposal with the differences between abandoned, damaged, removed, etc. as I don't have a well-thought-out classification of those yet, and the proposal is sufficiently complicated as it stands. It would make renderer support much simpler if the renderer only needed to parse bridge=yes and not worry about the bridge:structure and bridge:type tags unless it wanted to. I appreciate all the comments I've received thus far and will make changes to the wiki page soon to incorporate them. -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Bridge types
Response to selected comments: On Sat, Feb 2, 2013 at 12:57 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: +1 these are all bridge values with more than 100 occurrences, my comments inline after the percentages: yes 1 656 829 97.79% the very most ✔ null Not surprising, given that other than viaduct (and 1, true) it's the only one supported by the OSM mapnik setup. viaduct 24 314 1.44% not sure if we need this, what is the difference to a bridge? It mostly tells that there is a road or railway going over it (what you can already see from the data, as you can see the length) ✔ A ''long'' rail, road, or other bridge made up of many short spans. You may be focusing on the wrong attribute: it's the many short spans, not the length, that make a viaduct. I think I'd file it under bridge:type, like a trestle (which also has many short spans). [...snip...] aqueduct 1 084 0.06% prefer historic=aqueduct for historic aqueducts (also fragments) and would rather introduce a tag similar to power for water if I wanted to map modern aqueducts. Anyway an aqueduct has not much to do with bridges - null Ambiguity in the word. In the US, it's used both for long structures carrying drinking or irrigation water, above or below ground (which seems to be your use), but also for elevated structures carrying canals, usually navigable, across lower terrain. The latter use of the word seems very much like a bridge. [...snip...] abandoned 556 0.03% could be an idea to keep these. There is also the alternative way to tag it abandoned:bridge=yes - null As I said, I haven't yet tried to systematize the various ways of saying a bridge is unused/damaged/removed and so on, so I wouldn't interfere with these. Anyway, I agree with your classifications of other values that I haven't quoted. I agree, looks as if bridge=yes is the only remaining value if we introduce type and structure and prefix abandoned, disused, etc. Since it's already renderer-supported, that would be quite helpful. Yours, -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Digest, Vol 40, Issue 15
On Fri, Jan 11, 2013 at 8:52 AM, Michael Patrick geodes...@gmail.com wrote: Just my clarification ... we are blessed just about all those bridge types except the gondola. First,on first glance 'movable' subsumes all the other movable types. if it is exclusive of those, I might suggest 'movable_other', or something similar (our former I-520 Evergreen Point bridge had a bulge, which had a 'retractable' span (see http://ww1.hdnux.com/photos/03/01/47/793032/3/628x471.jpg ). Also, when the bridge has multiple types of structures and spans, how is that addressed - i.e. beam, floating, truss, and viaduct probably simultaneously exist on the same named 'bridge, is each way segment named the same but separately? Or just the primary distinctive feature? Could you tag the I-90 Bridge from Seattle to Bellevue as an example (Tunnel - beam - viaduct - float - beam - etc.)? Michael, Comments at the bottom of the proposal have also suggested creating a separate tag for the types of movable bridge. I think I like the bridge:movable suggestion made there. (So movable bridges would be tagged, e.g., bridge=movable; bridge:movable= bascule and so forth.) That also makes it a little easier to parse for a (hypothetical) downstream piece of routing software; it doesn't care to learn about all the different varieties of movable bridge, it just needs to be able to spot bridges that could open and leave you stuck in a traffic jam. In the case of complex bridges, there would be a different way segment for each type of span the way passed over. (If you have, say, several consecutive truss spans, I don't see a need to break that into multiple segments.) This is my approximation for the eastbound lanes of I-90, moving from west to east. Segment 1 (over roads): bridge=yes; bridge_type=beam. Segment 2: bridge=yes; bridge_type=truss. (bridge=viaduct might be OK for this, too; that's sort of a matter of taste.) Segment 3: bridge=yes; bridge_type=arch. Segment 4: bridge=yes; bridge_type=floating. Segment 5: bridge=yes; bridge_type=arch. Segment 6: bridge=yes; bridge_type=beam. That seems rather extreme, but in practice, I think people will largely continue using bridge=yes for most road and highway bridges and largely concentrate on marking charismatic things like covered bridges, (stone) arches, and so on; detailed tagging like this example will probably be the province of bridge aficionados. And this kind of span-by-span breakdown does have some potential when it comes to navigation. In bridges crossing navigable estuaries, it's not uncommon to have a long series of fixed spans with a movable span somewhere in the middle over the navigation channel. In that case, it's certainly useful to distinguish between the movable and the fixed spans, as it defines the location of the channel. Yours, -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Bridge types
Greetings, I'd like to draw your attention to the following proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types In short, it's a scheme for marking up bridges (using key:bridge and key:bridge_type) that's largely based on existing values from Taginfo and fairly comprehensive. Outside of OSM, there's quite a bit of interest in bridges, by hobbyists (e.g., bridgehunter.com) and as objects of tourism or aesthetic interest (particularly covered and suspension bridges). It makes sense that OSM should support more detail for bridges, in general, than just whether or not they exist. The Humanitarian Data Model includes tagging with a third key, BaseMaterial, to indicate whether the bridge is made of wood, stone, iron, etc., but I would prefer to raise that as a separate proposal to keep the scope of this one manageable. Please leave comments, as I believe properly documenting these values would increase their use by taggers and make rendering support more likely. Yours, -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Bridge types
On Thu, Jan 10, 2013 at 7:00 PM, Clifford Snow cliff...@snowandsnow.us wrote: Very through list of bridge types. Far more than I'm familiar with. Question - are you proposing that we map in the pier (support) as a node on the bridge similar to towers for power lines? At user discretion, yes. It's probably most useful for when you have an abandoned/removed bridge from which the piers and/or abutments remain; it might also be of interest for marine folks (for bridges over navigable waters). Doing it for viaducts and trestles is probably less useful. -- Chris Hoess ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
