Re: [Tagging] Water featuers
On Fri, May 22, 2015 at 03:54:57PM +0100, Andy Mabbett wrote: On 22 May 2015 at 15:29, Dave Swarthout daveswarth...@gmail.com wrote: I am uncomfortable with cascade - in several languages it means waterfall so there is considerable potential for confusion. I agree. A cascade is a waterfall in American English. How, then would you describe: https://commons.wikimedia.org/wiki/File:Water_Feature_in_Cabot_Place,_Canary_Wharf_%282%29_-_geograph.org.uk_-_1472986.jpg it could be a weir and waterfall http://wiki.openstreetmap.org/wiki/Waterfalls#Artificial_waterfalls or some kind of playground Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema
On Thu, May 21, 2015 at 09:52:06PM -0700, Bryce Nesbitt wrote: Note that just because you can collect some data, does not make it a good idea to put in OSM. Maintenance is harder than collection: and who's going to go back three years after the HOT event and clean up? same is even worse with other data like phone=* Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema
On Thu, May 21, 2015 at 09:36:10PM +0200, Andreas Goss wrote: As you linked to this on the HOT list a few things noticed... What about the typhoon:, earthquake: or tsunami: tags? Replaced with damage:event? What about e.g. damage:building? This could still be used even if you have building= and damage= What about the status= and impassable= keys and tags? some of the lifycecle prefixes would fit this situation and are already documented and in use. http://wiki.openstreetmap.org/wiki/Lifecycle_prefix Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Water featuers
On Fri, May 22, 2015 at 09:26:34AM -0500, John F. Eldredge wrote: The water feature we are talking about here is an artificial waterfall, usually pump-driven. in that case it might be better to either use normal waterfall tagging node with waterway=waterfall+ way waterway=weir, possibly also waterway=dam and man_made=yes or a distinct tag which is not so easy to confuse as synonymous. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Water featuers
On Fri, May 22, 2015 at 02:00:30PM +0200, Martin Koppenhoefer wrote: Am 22.05.2015 um 13:35 schrieb Andy Mabbett a...@pigsonthewing.org.uk: These might be cascades, rills, reflecting-pools, rain-chains, moats, etc. We might, for example, have: natural=water water=cascde etc. - but not: water=fountain as we already have amenity=fountain or we could have: amenity=cascade I am uncomfortable with cascade - in several languages it means waterfall so there is considerable potential for confusion. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Group of islands?
On Sun, May 17, 2015 at 04:15:02PM +0100, Philip Barnes wrote: Archipelago? the text says Groups of islands: add the natural=coastline into a multipolygon. why would I do that? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Group of islands?
___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access tags (was contact: tags)
On Sun, May 10, 2015 at 12:22:07AM -0700, Bryce Nesbitt wrote: On Sat, May 9, 2015 at 11:31 PM, Mateusz Konieczny matkoni...@gmail.com wrote: IMHO it would make editing and using data harder. It sounds like something that should be improved by a better interface for editors (grouping similar tags together). Exactly the problem. How can a computer tell that dog hgv and mofa should all be grouped? With a prefix, a consumer like a smartphone app can group all the restrictions,. Right now building automated tools against the data is fragile. For example the access for boats is spread across quite a number of tags. Even determining if a facility is applicable to a boat would require the consumer to keep up with all the various boat tags. Having a class hierarchy would enable generic actions for watercraft, even if the data consumer did not understand all the options (e.g. generic watercraft which might be a fishing boat, wave runner, rowboat). makes a lot of sense for me, the old system makes it pretty difficult to keep track of all possible tag combinations. The transition from the old to the new system would probably take some time where the old and new system would have to coexist. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] surface=pebbles - surface=pebblestone ?
On Sun, May 10, 2015 at 01:29:48PM +0100, SomeoneElse wrote: Regardless of pebbles vs pebblestone, where did the distinction of gravel=sharp, pebblestone=rounded come from? Is there any way to easily see who first contributed a particular section of a wiki page? wikiblame would do it but as afaics does not search our wiki so someone would have to setup a server or arrange something with wikiblame itself. https://en.wikipedia.org/wiki/Wikipedia:WikiBlame Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] surface=pebbles - surface=pebblestone ?
On Sun, May 10, 2015 at 03:03:14PM +0200, Richard Z. wrote: On Sun, May 10, 2015 at 01:29:48PM +0100, SomeoneElse wrote: Regardless of pebbles vs pebblestone, where did the distinction of gravel=sharp, pebblestone=rounded come from? Is there any way to easily see who first contributed a particular section of a wiki page? wikiblame would do it but as afaics does not search our wiki so someone would have to setup a server or arrange something with wikiblame itself. actually wikiblame apparently works out of the box if you know which parameters to enter: language: the word blank without quotes (not a blank) project: wiki.openstreetmap Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path
On Fri, Apr 24, 2015 at 11:16:47AM +0200, Martin Koppenhoefer wrote: 2015-04-24 11:01 GMT+02:00 Richard Z. ricoz@gmail.com: so are you happy that this http://www.bergsteigen.com/klettersteig/trentino-suedtirol/gardasee-berge/ferrata-rino-pisetta is tagged as highway=path ? I believe this clearly isn't a path, at least not at the spot you can see on the photo linked by you above. If you are aware of such mistagging, please correct it, it's a wiki... FYI this is a 400 meters vertical wall. I would correct it but it appears there are some more higway=paths in that impressive wall and I don't know them all. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path
On Fri, Apr 24, 2015 at 04:27:23AM +0200, Friedrich Volkmann wrote: On 24.04.2015 02:16, Warin wrote: Via ferrata should not be lumped into path or footway .. they are very significantly different and cannot be used in place of a path or footway. Would you take a 3 year old along it? Did you read the discussion tab? Farratas are not more difficult nor more dangerous than other paths. Where there's a ferrata and a parallel unsecured path in the same terrain, I would take the 3-year-old along the ferrata. so are you happy that this http://www.bergsteigen.com/klettersteig/trentino-suedtirol/gardasee-berge/ferrata-rino-pisetta is tagged as highway=path ? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path
On Fri, Apr 24, 2015 at 04:57:06AM +0200, Friedrich Volkmann wrote: On 23.04.2015 11:59, Richard Z. wrote: there were ongoing discussions concerning this subject so I have ammended the wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata#Criteria_for_taging_as_either_via_ferrata_or_path use highway=via_ferrata where people commonly use ferrata kits This is an individual decision. I know someone who did all ferratas (difficulty A-E) in eastern Austria without a ferrata kit. I also saw people using a ferrata kit on an easy ladder, and on a short wire rope that is meant as a handrail. Sure. But the phrase where people commonly use ferrata kits means where you commonly see people using ferrata kits. It may be even a toy ferrata for children - if you see plenty of them using ferrata kits it is probably better to tag as ferrata. There are ferratas which are more than hundred years old. Nobody used ferrata kits back then, because they simply did not exist. Back to today. Some of those very olde ferratas may be called ferrata but perhaps don't really deserve to be tagged as that. Which is why I tired to formulate this cirteria. a path is way where a hiker can walk without a ferrata kit and without extensive use of arm muscles See above. What's an extensive use? Experienced climbers will tell you that they do it all by technique instead of muscle power. it means to say you do not hang on your arms for a substantial part of the path. Ladders can and should be mapped separately so they need not to be considered here. Btw most hikers are not experienced climbers. a path should be safely passable without a ferrata kit even in less than optimal weather So we need to delete all paths in high mountains, because they are neither ferratas nor safely passable when icy. no. But if you can use the way safely only with a ferrata kit or climbing equipment it should be mapped accordingly. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path
On Fri, Apr 24, 2015 at 10:16:55AM +1000, Warin wrote: Some minor things .. overhang ? Should not 'covered' be used? http://wiki.openstreetmap.org/wiki/Key:covered overhang here means an additional technical difficulty of the path. Key:covered could be used in addition to that. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC - Criteria for taging as either via_ferrata or path
Hi, there were ongoing discussions concerning this subject so I have ammended the wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata#Criteria_for_taging_as_either_via_ferrata_or_path Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Way inside riverbank
On Mon, Apr 20, 2015 at 06:31:23PM +0200, Martin Koppenhoefer wrote: 2015-04-20 18:14 GMT+02:00 Dave Swarthout daveswarth...@gmail.com: IMO you guys are kidding yourselves if you think most mappers actually measure the depth of rivers before drawing in the main stream yes, it is not the typical way we do map, but it is an ideal / a clear definition how it ideally should be. I believe it is so far away from current practice that it would deserve an own tag waterway=deepest_path. Also because in some cases the navigation route may not exactly follow the deepest path. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ambiguous translations of waterway=dam - should be moved to man_made=dam
On Thu, Apr 16, 2015 at 07:16:22AM +0300, Dave Swarthout wrote: I think redefining waterway=dam is gonna be a hard sell for most Americans. But now thanks to this list I understand why some reservoirs I've worked with in Thailand have had the name of the dam applied to the water behind them as well. As you probably know, many reservoirs in the U.S. have names that are different from the names of the dam that formed them, Lake Mead and the Hoover Dam, Lake Roosevelt and the Grand Coolee Dam, are just two of the better known ones. The dam and the water impounded behind it usually have different names. Even though I can agree that dams are man_made there are roughly 200K uses of the waterway=dam tag. You have a lot of convincing ahead of you. not all of the dams are man_made, beavers are busy builders. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] volcanic features proposal
having a second look at it - geological=volcanic_lava_channel — way — lava flowing in a defined direction for wide lava channels it would be usefull to define the shape somehow? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recommend tagging of volcanos as ways rather than nodes
On Mon, Mar 30, 2015 at 01:26:35PM +0200, Martin Koppenhoefer wrote: Just discovered, this was changed only one year ago by user geozeisig, before there was a recommendation for areas as well: http://wiki.openstreetmap.org/w/index.php?title=Tag%3Anatural%3Dvolcanodiff=996213oldid=995784 no it was not. As pointed out in wiki it was part of the original proposal, Geozeisig only corrected the infobox to reflect what the text says. Are there objections to put this back to areas or nodes? Is there support for such an action? objections here. volcano is not here to map the crater rim. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recommend tagging of volcanos as ways rather than nodes
Hi, http://wiki.openstreetmap.org/wiki/Talk:Tag:natural%3Dlava has some thoughts how to map lava fields and calderas - I think those should be finalized and documented. Cut paste Lava fields natural=bare_rock (rock being used in the broad sense of a consolidated (solid) or unconsolidated (granular) layer) geological=* with =volcanic_lava_field or more specific tagging for solidified molten rock, pyroclastic mud flows etc Lava field features geological=volcanic_lava_channel — way — lava flowing in a defined direction geological=volcanic_lava_tube — way — naturally formed lava tunnel, may be active or extinct, https://en.wikipedia.org/wiki/Lava_tube etc Crater rims natural=cliff or natural=ridge and geological=volcanic_caldera_rim Volcanic vents (a volcano can often be a complex and have multiple vents) geological=volcanic_vent Fumaroles geological=volcanic_fumarole Geysers natural=spring or or natural=hot_spring (proposed) geological=volcanic_geyser (I notice that the Iceland geyser is Geysir but the common English spelling is geyser. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] volcanic features proposal
I have lifted the scheme originally proposed by Mike to a proposal page, did not have time for details yet. http://wiki.openstreetmap.org/wiki/Proposed_features/Volcanic_features Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] areas (eg rocks) underwater and across coastline/water shores
Hi, it is mostly so that an area eg natural=bare_rock does not end at the shoreline but extends some way under the water. Current practice of having it end exactly on the shoreline is both incorrect and a technical complication for mappers. In many cases some of the underwater racks would be easy to map. Similar could apply to many other natural objects: ridges, cliffs and (sand) beaches usualy extend some way below water. In fact mapping cliffs across rivers is the commonly used solution in waterfall mapping. So it would appear straightforward to map such natural features across shore lines both under and above water. How do people think about it? Should we generalise that approach or seek another solutions? What would happen with various renderers and other apps? Should we use underwater/awash tag or prefix? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] areas (eg rocks) underwater and across coastline/water shores
On Thu, Mar 26, 2015 at 03:31:36PM +, Malcolm Herring wrote: On 26/03/2015 12:35, Richard Z. wrote: How do people think about it? Should we generalise that approach or seek another solutions? The way I have approached this is to map separate areas above and below the natural=coastline way add the tag tidal=yes on the below HW area. has the rendering of the tidal areas been defined somehow? Should we use underwater/awash tag or prefix? The OpenSeaMap object underwater/awash rock (seamark:type=rock) only refers to isolated rocks rather than a rocky seabed. Therefore it is only appropriate on a node. how about underwater:natural=* and awash:natural=* ? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] areas (eg rocks) underwater and across coastline/water shores
On Thu, Mar 26, 2015 at 04:42:45PM +0100, Martin Koppenhoefer wrote: Am 26.03.2015 um 13:35 schrieb Richard Z. ricoz@gmail.com: Current practice of having it end exactly on the shoreline is both incorrect and a technical complication for mappers. I believe for mappers it is the easiest solution, not a technical complication. It is typically very difficult to find out until where which landcover reaches underwater. Having areas end exactly at the waterline seems to be a common reason for mapping mistakes and broken coastlines so I don't see that it would be the easiest solution. Also it is almost never so that the rock would end exactly at the waterline and even if you do not know exactly how far it extends underwater a good guess is still better than inserting wrong information. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
On Wed, Mar 18, 2015 at 01:49:26PM +, Malcolm Herring wrote: On 18/03/2015 11:58, Richard Z. wrote: so should for example the OpenSeaMap tagging for bridges become deprecated? Not deprecated, but considered on a case-by-case basis. It is a question of whether important navigation information would be deleted if the seamark tags were removed. In the case of bridges, the safe air draft and beam are important attributes that should be kept, but a bridge that is absent those seamark attribute tags need not carry the seamark:type=bridge tag. thanks, btw do you have any background info regarding the many obstacle nodes which are present in German waterways? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
On Tue, Mar 17, 2015 at 04:31:12PM +, Malcolm Herring wrote: On 17/03/2015 16:06, Brad Neuhauser wrote: Is there something I'm missing? No, you have spotted the fact that (as always!) that the documentation is unfinished. I had done it on this page: http://wiki.openstreetmap.org/wiki/OpenSeaMap/INT-1_Cross_Reference but I need to add notes/links on the other pages to direct people to the appropriate tag:* and key:* Wiki pages. so should for example the OpenSeaMap tagging for bridges become deprecated? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
On Mon, Mar 16, 2015 at 08:50:48AM -0500, Brad Neuhauser wrote: For boat navigation purposes this should be crosslinked: http://wiki.openstreetmap.org/wiki/OpenSeaMap/Gates Isn't it the other way around? That is, the people who tagged seagate:category:gate=lock (24 objects) should be making sure to also tag waterway=lock_gate (15K objects), not vice versa. it should be both ways. Actually in some cases I am wondering if the OpenSeaMap tags are really usefull where other tags exist (bridges, waterfalls and lock_gates for example). Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
On Mon, Mar 16, 2015 at 10:53:21AM +0100, Mateusz Konieczny wrote: According to wiki[1] waterway=lock_gate should be used only on nodes. Some are tagged on ways[2]. Why wiki considers node as the only valid element where this tag may be used? Is it because page is older than mapping rivers also as areas? Routing for boats? Some other reason? Is it a good idea to change wiki and mark tagging on nodes as a good idea? Is it a good idea to promote tagging also on ways[3]? I think it makes sense to tag them as ways, analogous to weirs and dams. For boat navigation purposes this should be crosslinked: http://wiki.openstreetmap.org/wiki/OpenSeaMap/Gates Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
On Thu, Feb 26, 2015 at 11:22:10AM +0700, Dave Swarthout wrote: The Trans-Alaska pipeline has many underground sections and these have no layer tag. Why that is, I don't know. It also uses a key type to specify what it carries. In this case type=oil this would be a case where location=underground seems well established. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
On Wed, Feb 25, 2015 at 05:34:04PM -0800, Bryce Nesbitt wrote: Would layer work for this. A layer of zero for something you can't pass at ground level. A layer of -1 for pipelines. A layer of 1 for ski lifts and areoways. No. Aerialways (most of them) and powerlines have an implicit location=overground. Pipelines use location as well. Layer is defined differently than location and does say nothing whether something is above or under ground. It should be used where features cross or overlap. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
On Wed, Feb 25, 2015 at 02:13:34PM +0100, Friedrich Volkmann wrote: http://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor I resurrected this old draft, because we need a tag for this and I know of no alternative tag currently in use. I wonder if goods may be misleading, because I think of goods as finished products, while many conveyors carry raw materials. Anyway, there are 589 uses of man_made=goods_conveyor, so we better stick with it. there is aerialway=magic_carpet which is intended for human transport only but together with usage access keys could be used to tag that as well. The proposal looks good, add location=* to it. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - goods_conveyor
On Wed, Feb 25, 2015 at 07:14:36PM +0100, Friedrich Volkmann wrote: The proposal looks good, add location=* to it. I dislike location=* for various reasons. But you may use it if you like. the proposal could be more detailed in this point. How do you tag conveyors above ground? As bridge? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecating aerialway=goods
So let us see: On Thu, Feb 19, 2015 at 05:57:47AM +0100, Andreas Labres wrote: A Materialseilbahn is a special type of aerialway (Seilbahn) and should have its own value. See the picture linked in the wiki. This is not a cable car, this is not a gondola, it is a Materialseilbahn (if you don't have an english word for it, this doesn't mean it doesn't exist). ... On Thu, Feb 19, 2015 at 01:12:22PM +0100, Andreas Labres wrote: Richard, Those Materialseilbahnen (ropeways for goods) are typical in the Alps to supply alpine huts (where everybody can get something to eat and stay overnight) with everything that is needed. The only alternative there is a helicopter flight... On 19.02.15 12:24, Richard Z. wrote: try harder to find an english word for the special aerialway in the picture becuase mappers all over the world have been using this improperly to map large mining and industrial aerialways. I'd disagree that this is improper use. They are also Materialseilbahnen (ropeways for goods). There is no cabin for passengers but a loading platform or kind of hanging lorry. The principle is the same as with (hanging) cable cars with a track rope and a drag rope, but the technolgy is much, much simpler, as there is no passengers in potential danger. well in one place you insist on a very specific type specified in the picture and used in the Alps which may or may not take passengers but you also say it is fine to use the same tagging for industrial or mining aerialways of whichever construction. By that definition goods would be good to tag any kind of aerialway construction which may or may not transport passengers. I believe it would be more usefull to tag aerialways by type of construction (gondola, zip_line,cable_car,drag_lift,magic_carpet, funitel) and use additional tags to say it is used for transport of persons, goods or mixed. As it happens we already have all the tags needed: usage=* and access=* type tags. We can also have more special values things like the open casket miniature cable_car in the picture. Btw, an interesting case of mixed use: http://1.bp.blogspot.com/-FReKw2jaO-Y/UG1s7Iq9J9I/IXI/04Z1fOD7u9I/s640/DSC_0149.JPG http://2.bp.blogspot.com/-amlErNFPUYM/UG1s-w6gnBI/IXQ/KnO9g60tO74/s640/DSC_0136.JPG found here http://unserewohnwagenreisen.blogspot.de/2012/10/eine-woche-sudschweiz-maggiatal.html https://www.openstreetmap.org/way/68299644 Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecating aerialway=goods
On Thu, Feb 19, 2015 at 06:05:40PM +0100, Pieren wrote: On Thu, Feb 19, 2015 at 12:38 PM, Richard Z. ricoz@gmail.com wrote: How is routing software supposed to know that some aerialway=goods are actually taking passengers? like roads tagged with access=no or private. Or highway=pedestrian not allowed for cars. We create simple tags for the average contributors, not to simplify routing software dev's life. perfect, so we do actually agree that normal access keys should be used. Incidentally I believe this will also greatly help routing software which should understand access keys anyways. I am not doing this to help routing software but to do the right thing - orthogonalize tagging by reusing already well established keys and apply them to aerialways instead of reinventing endless variations of them. As of usage=*, I think it can be still used in addition to access keys where it makes sense. The railways also have railway:traffic_mode=passenger/mixed/freight which might also be interesting to ship, aerialways and similar if it wasn't for the railway: prefix. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecating aerialway=goods
On Thu, Feb 19, 2015 at 05:57:47AM +0100, Andreas Labres wrote: On 18.02.15 14:36, Richard Z. wrote: suggest deprecating this particular value of aerialway -1 A Materialseilbahn is a special type of aerialway (Seilbahn) and should have its own value. See the picture linked in the wiki. This is not a cable car, this is not a gondola, it is a Materialseilbahn (if you don't have an english word for it, this doesn't mean it doesn't exist). try harder to find an english word for the special aerialway in the picture becuase mappers all over the world have been using this improperly to map large mining and industrial aerialways. Or - if an English word can not be found use the German word or make up something like aerialway=almbahn. for this special case. Meanwhile, key:access and usage should be usefull for all aerialways, even for the almbahn - they do allow passenger or personel transport in some cases so good is rather misleading. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] ?=maze
On Thu, Feb 19, 2015 at 06:48:33PM +0900, johnw wrote: I think it should be k kept under attraction, because a large mappable maze is certainly an interest of tourists - especially if it is part of a larger complex. Then it would be tourism=attraction attraction=maze maze=hedge or attraction:maze=hedge instead of attraction=maze + maze=hedge (so a generic maze would be attraction:maze=yes) I actually like this better. I don’t know which is better, but it certainly feels that any large maze - new or historic - is a form of attraction, so it should go into that - Especially if we are going to have a definition for special gardens in there as well. in addition to that I think any large enough maze should be mapped with highway=maze or highway=path, dead end markers and emergency exits. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecating aerialway=goods
On Wed, Feb 18, 2015 at 05:27:30PM +0100, Pieren wrote: On Wed, Feb 18, 2015 at 2:49 PM, fly lowfligh...@googlemail.com wrote: http://wiki.openstreetmap.org/wiki/Key:aerialway#Usage -1 I don't like such general keys like usage (or type) in general. well the key is already here and perfect fit for aerialways. Argue with the railway folks to improve or abolish it and aerialways will happilly adopt it. Basically, it could be used in all tags (e.g. highway=yes + usage=residential). It's not because it is now spread in railways that we have to repeat the same mistake (how about mixed usage ? again with the semicolon joke ?). unlike highways, aerialways and railway are closely very closely related types of tranpsort. It makes sense to reuse parts of the tagging developed by railways for aerialways in those cases where it is clearly decribing the same concept. As of mixed use, you could read the description on the page and talk page. An aerialway for goods is not the same as an aerialway for skiers. Until now, we use different values based on the different cabins/cars/lifts type. Perhaps instead of goods it could be replaced by fork or container or container_for_goods, just enhancing the existing list following the same principle. For routing purposes it would be highly desirable to have tagging valid accross all trasnportation means that are potentially relevant to routing, including and not limitted to ship lines, railways and aerialways. How is routing software supposed to know that some aerialway=goods are actually taking passengers? In principle *all* aerialways (even lifts) can be used for the transport of goods as well. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Deprecating aerialway=goods
Hi, suggest deprecating this particular value of aerialway as there are much better ways to map industrial/freight lines with usage=* and foot=* type restrictions. The new description is already in: http://wiki.openstreetmap.org/wiki/Key:aerialway#Usage discussion: http://wiki.openstreetmap.org/wiki/Talk:Key:aerialway#Obsoleting_aerialway.3Dgoods Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC aerialway=zip line
On Tue, Feb 17, 2015 at 02:32:21PM +0100, fly wrote: Am 17.02.2015 um 12:59 schrieb Richard Z.: Hi, RFC for aerialway=zip line is opened: This was a typo. True is aerialway=zip_line. https://wiki.openstreetmap.org/wiki/Proposed_feature/aerialway%3Dzip_line Would not include the zip_line on playgrounds as playground=zipwire [1][2] is already in use and there seem to be some differences between a playground feature and aerialways. Otherwise you need to deprecate playground=zipwire. ok, I am in favor of deprecating playground=zipwire. Large share of aerialway ziplines are part of adult playgrounds. Technically there are no universally valid principal differences that could differentiate the two uses. Afaics no information is lost when playground zipwires are mapped with the more general aerialway=zip_line plus additional playground attributes. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC aerialway=zip line
Hi, RFC for aerialway=zip line is opened: http://wiki.openstreetmap.org/wiki/Proposed_feature/aerialway%3Dzip_line Regards, Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC aerialway=zip line
On Tue, Feb 17, 2015 at 07:19:35PM +0100, Tom Pfeifer wrote: Richard Z. wrote on 2015-02-17 15:26: Otherwise you need to deprecate playground=zipwire. ok, I am in favor of deprecating playground=zipwire. Large share of aerialway ziplines are part of adult playgrounds. Technically there are no universally valid principal differences that could differentiate the two uses. Afaics no information is lost when playground zipwires are mapped with the more general aerialway=zip_line plus additional playground attributes. I see no reason for deprecating the playground feature for the sake of the big one. They can coexist peacefully, works well with playground=climbingwall and features tagged sport=climbing. it could coexist but there is no reason it should coexist - there is no fundamental technical or other difference between playground=zipwire and aerialway=zip_line. Exactly the same construction can be used on a playground or to cross a river. Deciding between the two would be always arbitrary and would not add any information which could not be added with other well known tags. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Lifecycle concepts, REMOVED
On Mon, Feb 02, 2015 at 04:53:03PM +0100, Janko Mihelić wrote: 2015-01-28 19:25 GMT+01:00 Frederik Ramm frede...@remote.org: If there used to be a building but all that is left is a clearing in the forest, then the clearing will be in OSM, and not a building with a lifecycle tag of removed. But what if hikers still refer to the spot? Like Let's go to the burnt alpine hut, and then go left. That is a pretty important landmark, even if there is no sign of the hut any more. Maybe we can tag it as place=locality. perhaps the destroyed: prefix? I would assume it should be used mostly if there are still visible ruins but should be also ok as long as it is well known what it refers to. Otherwise locality seems better. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Lifecycle concepts, REMOVED
On Wed, Jan 28, 2015 at 03:22:51PM +0100, Martin Koppenhoefer wrote:
thank you all for your comments, user:RicoZ, the creator of that page also
agreed and has changed the description.
thank you all for the unexpected attention, the problematic text snippet
was cutpaste from [[Comparison of life cycle concepts]] where it must
have been lurking for some time.
Its a bit early for the first April, but maybe someone will find my new
proposal for the fictional:mythical:{dead,undead}:{zombie,...} namespace
interesting.
Richard
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=wadi problem
On Sat, Jan 17, 2015 at 12:14:53PM -0800, Tod Fitch wrote: usually you will assume it if there are ponds of open water or swamps in several places along a valley. A pond/swamp/oasis/cienega in an arid or even semi-arid area is a significant feature that deserve mapping in its own right. Using that to infer information about a nearby or connected item seems a stretch to me. ponds and such should be mapped. Infering an underground waterflow from them may or may not be a stretch depending on the information that you have available. Often the underground waterflow is locally well known or can be inferred from many other informations. The more I think about this issue the more I am coming to the feeling that waterway=wadi ought to be deprecated and we should come up with a way of further defining intermittent to distinguish between seasonal and ephemeral flow patterns. Based on other responses on this thread maybe: that would be the best thing to do.. seems like otherwise every single mapper would use wadi in a different way. waterway=* intermittent=yes/no (default assumption of no) intermittent:frequency=winter/spring/summer/fall/seasonal/ephemeral/unknown (default assumption of unknown) +intermittent:frequency=random_rare/random_frequent ? We are still missing a definition of natural=valley afaics. There are some old proposals but I have been told on some other mailing list that valeys are nowadays mapped as a line natural=valley along the valley bottom. So maybe we should also document this or make a proposal to that effect. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=wadi problem
On Sat, Jan 17, 2015 at 07:50:36AM -0800, Tod Fitch wrote: Based on where I sometimes see old wind driven pumps, I'd guess that many longer (10s of miles long) washes have an underground flow. I think so. On the other hand, in the field or using Bing imagery neither I nor any other typical citizen mapper can really determine if there is unseen underground water flow. So so how can that be a criteria for mapping the feature? usually you will assume it if there are ponds of open water or swamps in several places along a valley. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=wadi problem
On Thu, Jan 15, 2015 at 11:41:26AM +0900, johnw wrote: I strongly disagree. A wadi is usually only an active river through very rare flash flood events, and almost never any other time. Entire biomes are defined by the presence of (and situated in) a wadi. how about reading wikipedia? Wadi (Arabic: وادي wādī) is the Arabic term traditionally referring to a valley. In some cases, it may refer to a dry (ephemeral) riverbed that contains water only during times of heavy rain or simply an intermittent stream. I consider a wadi a geologic feature. In addition to the above wadis are expected to carry underground water. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=wadi problem
On Fri, Jan 16, 2015 at 08:23:33AM -0800, Tod Fitch wrote: Since we are supposed to use British English, I decided to look up wadi in my old paper edition of the Oxford English Dictionary (can we trust that more than Wikipedia?): Wadi or Wady [Arabic: وادي wādī] In certain Arabic speaking countries, a ravine or valley which in the rainy season becomes a watercourse; the stream or torrent running through such a ravine. also http://en.wiktionary.org/wiki/%D9%88%D8%A7%D8%AF%D9%8A - valley. So it seems it could either be the valley or the actual intermittent watercourse. In that respect the term wash in the U.S. southwest is more specific as it is only applied to the intermittent watercourse. My impression from Southern California is that arroyo can be the valley/ravine as well as the actual watercourse, so that might match the OED definition of wadi more than wash does. I think we should look at how wadi is used in Arabic and decide if the feature is somehow interesting - and if the correct usage is compatible with prevalent usage in OSM https://www.google.de/search?q=%D9%88%D8%A7%D8%AF%D9%8Asafe=offhl=artbm=ischgbv=1sei=TlS5VKm5EOia7AbVvIDYCQ To me it looks too much like a synonym for valley, not sure if we need that. But maybe we need natural=valley? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sport= non-physical tags and the exceptions people come up with...
sorry, didn't see your email earlier. On Sat, Nov 08, 2014 at 09:27:03AM +0100, Andreas Goss wrote: The club page seems to suggest that club=sport + sport=cycling type tagging should be used for competitive sports. Which in my optinion is a bad idea, too. There is really no generel agreement as far as I know that club=sport is for competitive stuff only. I also don't think it's a good idea, because it would confuse a lot of people. I think subtagging makes a lot more sense. why should everything that is remotely related to sports go under club=sport+sport= ? According to the approved http://wiki.openstreetmap.org/wiki/Proposed_features/Club chess has an own club=chess, as has fishing, automobile, hiking - all of which can be either leisure type or sport type activities. Bicycle was apparently added later but it makes as much or little sense as the other cases. So this is not a new exception for diving. Tag:sport=scuba_diving as divespot has been in use for a long time already and http://wiki.openstreetmap.org/wiki/Proposed_features/scuba_diving2 has been approved. It just makes no sense to allow exceptions like this. If we allow this then everybody will find exceptions for other sports and you won't be able to combine them. Like even now how would you tag a sport shop that sells e.g. sailing and scuba diving gear? You can't tag it sport=sailing;scuba_diving ... so what now? http://wiki.openstreetmap.org/wiki/Key:shop list a whole range of values. So I don't see any technical problem for example with shop=computer;cheese;bicycle;scuba_diving;water_sports How would you tag this particular shop with your favorite tagging.. perhaps shop=computer;cheese;sport + sport=bicycle;scuba_diving;water_sports ? Imho this looks rather arbitrary, the computers sold there are probably related to the sports offered there but treated completely differently. That does not mean I am happy with current tagging of part-sport-part-leisure activities such as swimming and diving. It is broken to tag garden pools, kiddie beaches or dangerous oceans beaches with sport=swimming. There is no way to tag swimming routes and areas in water, hazardous areas etc. Most outdoor sports are in reality outdoor *activities* (whether leisure or sport) and rather bad match for tagging with key:sport. Clearly in need of a sane proposal. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sport= non-physical tags and the exceptions people come up with...
On Mon, Nov 24, 2014 at 02:13:07PM +0100, Martin Koppenhoefer wrote: 2014-11-24 13:57 GMT+01:00 Richard Z. ricoz@gmail.com: According to the approved http://wiki.openstreetmap.org/wiki/Proposed_features/Club chess has an own club=chess, as has fishing, automobile, hiking - all of which can be either leisure type or sport type activities. I think club=automobile for a motorsport / racing club would not be very well chosen as this might really mean a lot of different things, some of them clearly neither leisure nor sport, e.g. the ADAC (biggest German automobile club, almost every 4th German is a member, http://en.wikipedia.org/wiki/ADAC ) does organize also some racing event, but is mostly seen as kind of insurance if your car breaks down (and as very strong political lobbyist advocating mainly individual motorized traffic). Documentation of the club tag is very scarse at the moment: http://wiki.osm.org/wiki/Key:club and I am not sure how it can be improved, e.g. if I wanted to write something about club=automobile, would I have to write to all the mappers that have put these 127 club=automobile on the map, to ask what they have used the tag for? I think much the same problem exists with other club=value as well like club=chess? Nevertheless.. you may walk by a building with a tag something like a chess-club and if it is mapped as club=chess it is correct. It is also fairly un-informative but we are supposed to map what we see and not do background checks of clubs with google or wikipedia? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sport= non-physical tags and the exceptions people come up with...
On Mon, Nov 24, 2014 at 02:53:32PM +0100, Colin Smale wrote: Let's look at the entity relations in play here. Surely a club IS an organisation, not a building. The club MAY USE one or more buildings, and MAY OWN one or more buildings. A club HAS a contact address, HAS members, HAS a board etc etc. So following the rules of one object, one set of tags, putting club=chess on a building could be considered to be wrong, as the building may be used by several clubs. Bearing in mind how some people hate multi-valued tags with semicolons, how about club:chess=meeting_place? Then multiple clubs could use the same building, each with a different role if required. Otherwise use a simple node (per club) within the building to indicate some relationship between the club and the building. ++1 Richard Colin On 2014-11-24 14:36, Richard Z. wrote: On Mon, Nov 24, 2014 at 02:13:07PM +0100, Martin Koppenhoefer wrote: 2014-11-24 13:57 GMT+01:00 Richard Z. ricoz@gmail.com: According to the approved http://wiki.openstreetmap.org/wiki/Proposed_features/Club [1] chess has an own club=chess, as has fishing, automobile, hiking - all of which can be either leisure type or sport type activities. I think club=automobile for a motorsport / racing club would not be very well chosen as this might really mean a lot of different things, some of them clearly neither leisure nor sport, e.g. the ADAC (biggest German automobile club, almost every 4th German is a member, http://en.wikipedia.org/wiki/ADAC [2] ) does organize also some racing event, but is mostly seen as kind of insurance if your car breaks down (and as very strong political lobbyist advocating mainly individual motorized traffic). Documentation of the club tag is very scarse at the moment: http://wiki.osm.org/wiki/Key:club [3] and I am not sure how it can be improved, e.g. if I wanted to write something about club=automobile, would I have to write to all the mappers that have put these 127 club=automobile on the map, to ask what they have used the tag for? I think much the same problem exists with other club=value as well like club=chess? Nevertheless.. you may walk by a building with a tag something like a chess-club and if it is mapped as club=chess it is correct. It is also fairly un-informative but we are supposed to map what we see and not do background checks of clubs with google or wikipedia? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [4] Links: -- [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Club [2] http://en.wikipedia.org/wiki/ADAC [3] http://wiki.osm.org/wiki/Key:club [4] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions
On Tue, Nov 11, 2014 at 11:08:56AM +, Lukas Sommer wrote: Just as a reminder: Voting is still open at https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions question - key:junction has many more possible values than just yes for the single point variant. Are those values also allowed for junction as area? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] place=island wiki page - coastline
On Wed, Nov 05, 2014 at 10:22:03AM +0100, Peter Svensson wrote: I have seen many users doing the mistake of tagging an island inside an lake as natural=coastline. I suspect that the root cause in many cases might be the wiki page for place=island. The page encourages the use of natural=coastline without warnings and restrictions. Would is be possible to make natural=coastline usage more clear on place=island wiki page? or - would it be possible to make coastline work for lakes as well? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] place=island wiki page - coastline
On Wed, Nov 05, 2014 at 11:29:04AM +0100, Martin Koppenhoefer wrote: 2014-11-05 11:03 GMT+01:00 Richard Z. ricoz@gmail.com: Would is be possible to make natural=coastline usage more clear on place=island wiki page? or - would it be possible to make coastline work for lakes as well? I recall from older discussions that mappers prefer to keep the semantics clean. If it is a lake, it shouldn't be tagged as coast (you could use shoreline?), because a coast implies a sea or an ocean. From a practical point of view, including big lakes into the coastline extract would be something useful for many people using a rendering approach similar to that of carto-osm, but it doesn't necessarily require to twist tagging. how is that clean, Lake Eerie is a lake, Caspian sea is a sea, Baikal lake... Even worse, some cross-broder water-bodies can be a lake in one language and sea in the other language on the other sea/lake-shore. From a practical pov I would prefer * no distinction at all - or * distinction based on approximate size and complexity Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
On Wed, Nov 05, 2014 at 10:01:47AM +0100, Martin Koppenhoefer wrote: 2014-11-04 22:56 GMT+01:00 Friedrich Volkmann b...@volki.at: This discussion comes late. Both natural=ridge and natural=arete have been approved by voting just 2 years ago. arguably it is not too late, there are only 450 uses of arete by now (and 17K+ ridges). Please also note that the tag natural=arete was formally rejected (not enough votes: http://wiki.osm.org/wiki/Proposed_features/arete ) after two years in the wiki where it was marked as approved and active it would not appear as a great idea to declare the vote for invalid based on nitpicking formalities, how many votes were missing for approval? Would be better to make a new proposal including details of a transition path. Another reason I don't like current arete/ridge state is that some ridges are very long - and they may be partially arete and ridge in different segments. Having a way that is tagged partially as natural=ridge and partially as natural=arete seems like a bad idea. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] natural=ridge vs natural=arete
Hi, following some discussions on github (1) and talk-at (2) I have tried to clarify the definition of natural=ridge in the wiki http://wiki.openstreetmap.org/w/index.php?title=Tag:natural%3Dridgediff=1104725oldid=998905 Not sure if this is good enough, personaly I would prefer a single ridge key with additional subkeys denoting properties such as gentle,sharp, cliff ridges. 1. https://github.com/gravitystorm/openstreetmap-carto/issues/1097 2. https://lists.openstreetmap.org/pipermail/talk-at/2014-November/007058.html Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Pathways with steep vertical slopes, accessed via climbing chains
On Tue, Nov 04, 2014 at 07:54:46PM +0900, johnw wrote: Thanks Alberto, Mike Martin for the suggestions. I was a avid hiker in the US, but this was the first time for me to encounter such assistance devices myself. never knew their collective name until now. Dan - I understand about “tagging for the renderer” , but what you personally consider your “creation” when you are working affects your motivation. Some people here are tagging to make a complete dataset of tags, some are tagging for making a good looking map via OSM’s renderer in -carto, and some are using the dataset for their own project. Personally, I want the -carto map to be the best it can be, so I consider that my output. I try to give useful input in -carto and here, so I’d like it tagged correctly and rendered in a nice manner. however they both get done. check out openandromaps.org - it does render via_ferrata and many other outdoor features not yet rendered in mapnik. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=bay as nodes are evil
On Thu, Oct 30, 2014 at 08:41:18AM +0100, Marc Gemis wrote: Could we try an example to see whether mappers agree on bay areas ? could you draw the Gulf of Biscay on a map ? This guy did it : http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4/s1600/Golf+van+Biskaje.jpg I might have extended it a bit further to the west on the Spanish coast... note that the big bodies of water such as the bay of biscay have been defined by the international hydropgraphic organization, wikipedia provides the link. Those definitions should be probably mapped, but most likely with a special tag rather than our natural=bay because their definition of gulf of mexico is obviously not compatible with our definition of bay (refering to the sentence fragment in Cuba, through this island to the meridian of 83°W which includes a landmas to the definition) Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=bay as nodes are evil
On Tue, Oct 28, 2014 at 05:21:06PM +0100, moltonel 3x Combo wrote: On 28/10/2014, Richard Z. ricoz@gmail.com wrote: On Tue, Oct 28, 2014 at 11:18:43AM +0100, Martin Koppenhoefer wrote: 2014-10-28 10:57 GMT+01:00 Richard Z. ricoz@gmail.com: The assumption is that a large bay will typically be more important than a smaller bay. For a good rendering you'd show only the more important bay names in medium zoom level and show the less important ones in higher zoom levels. You would use the size to decide which name to omit in case you'd not have space to render all of them. so to decide which label should be bigger or rendered at lower zoom level you would suggest to: * map bays as areas, with all previously mentioned issues The issues are real, but we disagree on how big they are. I'm of the opinion that they aren't worth fussing over, but YMMV. well even if the issues were nonexistent, mapping the area of a bay seems to me like mapping an artificially introduced concept for which there is very little real world use or recognition otherwise. Also bays with very flat or deep geometry will result in disproportionately small areas so mappers may feel compelled to do some ugly workarounds if the name of the bay isn't shown as expected. So I would say * if there is some other reason valid to map the bay as area, do it * something better needs to be invented for hinting the renderer. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Default maxspeed unit on waterways
On Wed, Oct 29, 2014 at 02:47:48PM +, Malcolm Herring wrote: On 29/10/2014 14:12, Ilpo Järvinen wrote: I don't know about other countries, but here in Finland the water maxspeed signage is in km/h although knot is used for almost everything else. In UK waterways, both MPH and knots are used. Usually MPH on canals and knots on rivers, though even this can depend on who the navigation authority is and how far back in history their statutes were written. ouch. Luckily we don't map anything in UK vs US gallons or UK vs US barrels or tons.. or do we? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=bay as nodes are evil
On Mon, Oct 27, 2014 at 04:28:53PM -0400, Eric Kidd wrote: But the key point here is that none of these official sources represent bays as polygons. GNIS uses a pointssomewhere in the bay. The nautical charts print the name somewhere in the middle of the bay. Effectively, the official data really is a point, plus whatever guesswork a human reader supplies. +1 Also, I am reading the arguments about estimating bay area so I am curious - when was the last time someone asked about bay area in square kilometers? I think it makes only sense in the context of territorial waters, fishing or mining rights etc. In such cases there will be an officially supplied boundary that can be used but will not necessarily agree with traditional extent of the bay. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=bay as nodes are evil
On Tue, Oct 28, 2014 at 11:18:43AM +0100, Martin Koppenhoefer wrote: 2014-10-28 10:57 GMT+01:00 Richard Z. ricoz@gmail.com: Also, I am reading the arguments about estimating bay area so I am curious - when was the last time someone asked about bay area in square kilometers? I think it makes only sense in the context of territorial waters, fishing or mining rights etc. The assumption is that a large bay will typically be more important than a smaller bay. For a good rendering you'd show only the more important bay names in medium zoom level and show the less important ones in higher zoom levels. You would use the size to decide which name to omit in case you'd not have space to render all of them. so to decide which label should be bigger or rendered at lower zoom level you would suggest to: * map bays as areas, with all previously mentioned issues * design a sophisticated computer algorithm to calculate the size of bays and derive bay importance from this Wow.. masterpiece of mapping for the renderer I would say. There must be easier ways of achieving this. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=bay as nodes are evil
On Mon, Oct 27, 2014 at 10:44:01AM +0100, moltonel 3x Combo wrote: On 26/10/2014, Christoph Hormann chris_horm...@gmx.de wrote: I don't see what information is missing and cannot be easily determined automatically with a properly placed node that is contained in an area - except for the outer edge of course, which is usually ill-defined though as you said yourself. If you think about it a bit and do not try to place the node where you would place the label (which depends on the map projection anyway) properly placing a node for a bay is usually quite simple. The most difficult are long, fjord-like bays where a way along them would be more appropriate. I'm really curious what your method to figure out the bay area from the node is, because even as a human I find that most bay nodes can lead to many different interpretations. you don't. Al that the node says is somewhere there is a bay called XXX A computer algorythm would probably get it wrong most of the time. Think back to the bays within bays situation. How far along the coast do this bay extend ? Are those two nearby nodes separate bays or overlapping ones ? Most of the time there is very little agreement or hard data about the extents and hierarchy of bay naming. Sources from different countries will make different subdivisions. Great fun with multipolygons and even with perfect tagging and computer algorithm we get approximate results at best. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=bay as nodes are evil
On Mon, Oct 27, 2014 at 12:33:48PM +0200, Ilpo Järvinen wrote: On Sun, 26 Oct 2014, Christoph Hormann wrote: On Sunday 26 October 2014, Mateusz Konieczny wrote: Furthermore the outer edge of a bay, i.e. the edge that is not coastline is usually not well defined and would require an arbitrary cutoff. Yes, cutoff is unfortunately quite arbitrary. But node placement is completely arbitrary - and lacks important information. I don't see what information is missing and cannot be easily determined automatically with a properly placed node that is contained in an area - except for the outer edge of course, which is usually ill-defined though as you said yourself. Any data consumer could quite easily, if not trivially, detect that fuzzy edge in this case if it cares about it in the first place (I've have some trouble in figuring out a sensible use case in which it would make a difference to know where the fuzzy border of a bays is). Besides, we really need to deal with object that have fuzzy borders already, e.g., some of the natural=wetland object come to my mind as an example. I quickly browsed through the related pages and discussions, for some strange reason the fuzzy border issue seems to not have been raised there at all? I suppose it's currently left solely to mappers discretion where to put the the edges. http://wiki.openstreetmap.org/wiki/Proposed_features/Fuzzy http://wiki.openstreetmap.org/wiki/List_of_proposals_regarding_landuse,_geology,_geography_and_vegetation (my early draft for the purpose of getting some overview over similar issues) Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=bay as nodes are evil
On Sun, Oct 26, 2014 at 05:12:20PM +0100, Mateusz Konieczny wrote: Please, try mapping bays as areas - not as nodes. It is really rare to see it done this way - but it is doable, see http://overpass-turbo.eu/s/5CQ not practical in most cases. Almost every bay is part of a larger bay and so forth. The borders and hierarchy are very arbitrary. The nodes, as much as they suck give a quite realistic picture of this fuzzy state. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sport= non-physical tags and the exceptions people come up with...
On Sat, Oct 18, 2014 at 03:42:35PM +0200, Andreas Goss wrote: Can you please stop trying to come up with exceptions for the sport= tag? Just saw this on scuba diving: Should be used to mark a place for scuba diving, preferably as an attribute of natural=beach, natural=stone natural=cliff or a fitting segment of a coastline or lake. For dive bases or dive shops see: amenity=dive_centre or shop=scuba_diving How do you tag a store shop=sports now? How do you tag a club=sport now? See also: http://wiki.openstreetmap.org/wiki/Talk:Tag:sport%3Dscuba_diving#Divespot_:_sport.3D.2A_non-physical_tag seen your message on the talk page. The main page has apporved suggestions how to tag dive shops and centers. For dive clubs I don` been 't see why club=scuba_diving should not be sufficient. The club page seems to suggest that club=sport + sport=cycling type tagging should be used for competitive sports. Not seen a scuba diving competition club for a very long time. Perhaps this should be added to the summary of the scuba_diving page? Tag:sport=scuba_diving as divespot has been in use for a long time already and http://wiki.openstreetmap.org/wiki/Proposed_features/scuba_diving2 has been approved. So changing divespots to leisure=* is not a good idea at this point. I have added the scuba_diving:divespot=yes to the summary although it is not seen as obligatory in the proposal. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sport= non-physical tags and the exceptions people come up with...
On Thu, Oct 23, 2014 at 01:46:45PM +0100, Philip Barnes wrote: I like this tagging, but as an ex-diver I do feel it needs some expansion. compressor=yes/no To indicate whether there is air available to refill tanks or not. this would be mostly covered by http://wiki.openstreetmap.org/wiki/Tag:shop%3Dscuba_diving and http://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddive_centre What other places would you attach scuba_diving:filling* to? recompression_chamber=yes/no To indicate if there is a recompression chamber on-site. nothing like hyperbaric chamber mapping on OSM yet? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] sport:scuba_diving ?
Hi, just noticed that http://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddive_centre has a reference to sport:scuba_diving=yes in the infobox. However, the reference points to http://wiki.openstreetmap.org/wiki/Key:sport:scuba_diving which is redirected to Key:sport:scuba_diving Should the stale reference to sport:scuba_diving=yes be deleted or is it some clever plan for the future? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] floating or pontoon bridges?
Hi, the approved and currently active proposal for bridges is not quite clear on this - the older bridge=pontoon was not obsoleted but a new bridge=yes+bridge:structure=floating was introduced with the description A bridge whose load is supported by floating on water, rather than resting on fixed supports. Typically a pontoon bridge. https://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types Are there floating bridges other than pontoon bridges? Should pontoon be moved into bridge:structure and replace floating? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] floating or pontoon bridges?
On Tue, Sep 02, 2014 at 04:22:34PM +0200, Martin Koppenhoefer wrote: 2014-09-02 16:14 GMT+02:00 Volker Schmidt vosc...@gmail.com: Wikipedia does not agree with Martin: http://en.wikipedia.org/wiki/Pontoon_bridge it depends on the language ;-) language problems are a disaster for us. Yesterday looked at suspension bridges, apparently in some parts of the world suspension is understood to mean suspended operation, abandoned or whatever. Today noticed that someone tagged a rather unusual single node object with bridge=yes + bridge:moveable=bascule https://www.openstreetmap.org/node/2301185674 - it appears that in French Pont Bascule has this meaning: https://www.google.com/search?q=Pont+Basculesafe=offie=utf-8hl=engws_rd=ssltbm=isch Something like pontoon bridge is definitely much better than floating bridge which may have any number of meanings for different people - google image search is my favorite method to look for meanings. Summary, I am strongly in favor of moving pontoon to bridge:structure and forgetting about floating until someone disambiguates it from pontoon and writes a description for it in 12 languages. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - nudism
On Tue, Aug 19, 2014 at 01:08:25AM +0200, Heiko Wöhrle wrote: Hi, added a table to the page, maybe this way it is easier to see which additional cases should be added. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On Mon, Aug 11, 2014 at 11:40:00PM -0400, Christopher Hoess wrote: 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? coming back to this because I am now looking at adapting JOSM presets for the current bridge definitions and there it would appear that if bridge=yes + bridge:movable=* were considered a valid choice the dialog would directly offer it as first choice and 99% of contributors would accidentally select it in places where they actually wanted to select bridge=movable+bridge:movable=* at least I do not see how to tweak the preset otherwise. So a better combination is required for historic movable bridges before this gets done. Some alternatives that already were suggested or that I came up right now: (1) bridge=fixed + bridge:movable (2) bridge=historic_movable + bridge:movable (3) bridge=movable + bridge:movable + bridge:movable_status=operational|frequent|rare|historic|suspended I would prefer something like (3) as it offers the possibility to additional information about how frequently the moving mechanism is operated. Also there could be bridge:movable_schedule in addition to this? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map Features template
On Tue, Aug 26, 2014 at 02:36:04PM -0300, John Packer wrote: I'm not sure that's the right mailing list for talking about this, but it's probably the closest Am I the only one that dislikes the Map Features templates on the wiki? (example: [1]) I think they make it harder to edit the wiki. which may not be that bad in some cases. When someone cares enough to create a template it is quite likely to be for an approved and well documented feature where there should not be much demand to edit it frequently by beginners. Some people like these templates because it seems they can make new tag values appear in non-english pages by adding them in the english page. But this new value appears in english, so in my opinion it kinda defeats the purpose of the non-english page... not too bad, some templates have example pictures which are almost as good as an native description. It depends how the template is used. However it is important that if something is changed in the English template the other languages at least see that there was a change. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] usage of maxspeed:practical is described as recommended on wiki
On Mon, Aug 25, 2014 at 10:43:36AM +0200, Pieren wrote: I would modify the section [1] by replacing it is recommended by it is suggested and adding at the end a note saying that a large part of the community consider these two tags -smoothness and maxspeed:practical - too subjective. I have rewritten it even a bit more, hope it is better now. Also changed the old proposal page a bit. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wadi vs intermittent stream?
On Sat, Aug 23, 2014 at 02:52:41PM -0700, Tod Fitch wrote: So which is the preferred tagging? If waterway=wadi then I have some OSM editing to do but at least the renderer should be easy. If waterway=stream, intermittent=yes then I need to get some changes done by the project who's rendering database I am using. Wadi is something different than a wash. While not easy to state objectively, some hints are * wash tends to be shorter and steeper, they often run out in alluvial fans as soon as they get into flat areas. Some collect into intermittent rivers though. * the wash-valley form will be merely a deepening from erosion and often quite young and quickly changing ( in the order of decades or hundreds of years ) * when a wash is dry there is no water flow close underneath the surface * wadi will be longer, perhaps 10km or much more * the valley is older, has gone through several geological stages of riverbed formation * even in dry seasons there will be often underground water, places with swamps or pools and distinct vegetation. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] minus or underscore in attribute values?
Hi, another mapper metnioned to me that it is unusual to have attribute values with a minus, like bridge:structure=cable-stayed On the other hand, it is an apporved proposal - what are the opinions on that? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] usage of maxspeed:practical is described as recommended on wiki
On Sat, Aug 23, 2014 at 09:08:08AM +0200, Mateusz Konieczny wrote: See https://wiki.openstreetmap.org/wiki/Talk:Key:surface#maxspeed:practical for proposed change with 12000 ways already tagged maxspeed:practical and lack of alternatives I would think twice removing any documentation. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] usage of maxspeed:practical is described as recommended on wiki
On Sat, Aug 23, 2014 at 10:55:15AM +0200, Mateusz Konieczny wrote: 2014-08-23 10:48 GMT+02:00 Richard Z. ricoz@gmail.com: 12 000 ways is really low number in this situation. Surface tag is used on nearly 9 million roads, number of highway=* ways crossed 76 million. possibly it is used in many situations where other tags are desperately insufficient. No matter how bad it was considered in voting it is sometimes needed. I would be in favor of improving that proposal instead of removing all references. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] usage of maxspeed:practical is described as recommended on wiki
On Sat, Aug 23, 2014 at 10:33:16PM +0200, Martin Koppenhoefer wrote: Il giorno 23/ago/2014, alle ore 21:08, Ilpo Järvinen ilpo.jarvi...@helsinki.fi ha scritto: How much of such ways that would be a candidate for maxspeed:practical IMHO this is a highly subjective tag that depends heavily on your driving ability and the vehicle and driving comfort you expect. E.g. a moderately modern battle tank can drive 70-90km/h on an open field with no road at all ;-) as I wrote on the talk page I am fully in support to update the proposal to include modern tanks and other relevant vehicle types. As we are generally rejecting subjective tagging like suitability and the like, this practical speed tag does not fit well in our system It just fills a gap. Many other tags such as track type and even highway type (primary/secondary...) are highly subjective and used very differently from country to country. There is no reason to think track types are any more objective than maxspeed:practical. Just tagged a road in the Seychelles as tertiary.. I remember it is a slightly difficult single lane partially paved road with a steep incline in some places. Even if I would remember every single detail of the road and use all existing tags - what can you deduce from that? What can routing software deduce from it? If I add maxspeed:practical=25 everyone from anywhere in the world has a first idea what to expect. Even if people would argue that it should be 15 or 30 instead of 25, all other tags taken together are not anywhere close to help you predict a similar value. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - nudism
On Tue, Aug 19, 2014 at 01:08:25AM +0200, Heiko Wöhrle wrote: Hi everybody, i'd like to readdress an old draft from Xan, that has never been voted but is nevertheless in use. Please feel free to comment the slightly changed proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Nudism Someone (you?) has removed the permissive value from the proposal and replaced it with * designated to places where nudity is officaly permitted but not prevalent That does not make a good replacement for me. Maybe there is room for both values but I think it needs some tweaking.. Current proposal: yes where nudism is officially permitted no where it is forbidden, strongly discouraged or likely to cause trouble customary to clothing optional places where nudity is prevalent, unofficial, legal status unknown or not important designated to places where nudity is officaly permitted but not prevalent obligatory to official nudist only places Previous description that was in use for some time: yes where nudism is officially permitted no where it is forbidden, strongly discouraged or likely to cause trouble customary to clothing optional places where nudity is prevalent, unofficial, legal status unknown or not important permissive to places where nudity is permitted or tolerated but not prevalent, or wilderness areas where nobody cares obligatory to official/designated nudist only places Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - nudism
On Wed, Aug 20, 2014 at 08:28:13PM +0200, Heiko Wöhrle wrote: Hi, yes i changed the values because i found the differentiation between customary with prevalent nudity and permissive but not prevalent nudity difficult. But i had a mistake in my description, it should be: designated to places where nudity is officially permitted but not obligatory Hope this clarifies it... Or maybe you can point a possible differentiation if we keep both we are trying to squeeze into one value something that has many more aspects: * legal: allowed yes/no/unkonwn/dontcare obligatory yes/no/unknown .. more values? * prevalence maybe widespread, customary, clothing optional * local usage : eg permissive is fairly well understood in many places Will one tag be enough? I think there are not so many meaningful combinations so one tag could work but we should not be afraid to list many possible values. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Forest vs Wood
On Wed, Aug 20, 2014 at 06:45:30PM +0100, Rob Nickerson wrote: Hi, Sorry to raise this issue again but it really does need resolving: * for ensuring good data; and * to prevent forest and wood being rendered as the same thing [1] Currently the descriptions in the green box on the right of the wiki page (and thus those that get picked up by taginfo and other software) are: Wood: Woodland with no forestry Forest: Managed woodland or woodland plantation. In my eyes this is pretty clear. What am I missing / why does there seem to be so much confusion? landuse/landcover/natural need resolving so I would not spend too much energy on partial improvements of it. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - nudism
i was also thinking about that. i think it is only neccesary if a former nudist place is changed to a place where clothing is expected in some areas nudism is so prevalent that it is a good idea to use nudism=no in places where it is not expected/allowed. In other areas it would not make sense. Another issue, while it is not related to nudism it should be somehow elaborated in the same go how to tag those more sexually oriented areas/facilities (swinger clubs etc) so that people don't abuse the nudism/naturism/FKK tag for this purpose. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - nudism
On Tue, Aug 19, 2014 at 12:54:21PM +0200, Martin Koppenhoefer wrote: Maybe a more generic tag like dress_code would also catch these places? This was already proposed some time ago IIRR. this was already discussed on some talk page - why can't I find it now? :( It could also be interesting sometimes if nudism is obligatory or clothing is admitted as well it seems the proposal already took care of that? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
On Wed, Aug 13, 2014 at 09:12:07AM +0200, Martin Vonwald wrote: Hi! 2014-08-12 22:57 GMT+02:00 Richard Z. ricoz@gmail.com: what else can I do? Maybe it's time to open up a change request for the main map style? The tag man_made=bridge seems to be used worldwide [1] in some - more or less - consistent way. It provides useful data, is simple to tag, it should be easy to render and it solves some ugly rendering issue. Is there a place where someone could take the main style, change it and see the difference in rendering? So we could not only open a ticket but also provide a patch. the ticket is already there: https://github.com/gravitystorm/openstreetmap-carto/issues/436 Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] To: Tag discussion, strategy and related tools
On Sat, Aug 16, 2014 at 05:50:06PM +0200, Martin Koppenhoefer wrote: Il giorno 15/ago/2014, alle ore 23:52, St Niklaas st.nikl...@live.nl ha scritto: I would go for building=bridge, since a bridge is a building actually a bridge isn't a building according to standard terminology, it is a structure. But since in osm it seems we are using building synonymously for all kinds of structures it might work for us nonetheless. it won't, building=bridge has a special meaning: http://wiki.openstreetmap.org/wiki/Tag:building%3Dbridge some other values of building might work. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping cave tunnels passable by human
On Thu, Aug 14, 2014 at 12:31:28PM +0200, Martin Vonwald wrote: 2014-08-14 12:25 GMT+02:00 André Pirard a.pirard.pa...@gmail.com: On 2014-08-14 11:08, Janko Mihelić wrote : Well first, tunnel=yes is obviously wrong. We need to replace this with cave=yes. Other than that, I have no problems with this. If a cave has two cave entrances, then information that they are connected by footpaths is valuable information. Obviously? Regarding paths and waterways, especially ones fitted up for tourism, I wonder... Maybe not completely obvious, but I would agree with Janko. In my opinion, a tunnel is man-made, while a cave is not. whether or not man-made is not the biggest problem. The big problem with tunnel=yes or tunnel=cave is that they only would ever get rendered if they were also tagged as a highway or similar. This is a big disadvantage because most caves don't have even paths. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On Wed, Aug 13, 2014 at 11:48:35PM -0400, David K wrote: I support a general tag for hill crests with sufficient vertical curvature to introduce a visibility, grounding, or takeoff hazard. It could be applied to railroad crossings, humpy bridges, or just roads traversing hilly terrain; all of these situations can be found in central Ohio. Using this tag on a node at the crest of the hill should be acceptable, as the hazard may occur (potentially in multiple places) along fairly long way. any good name for such a tag? It should be also good for dips if possible.. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
On Wed, Aug 13, 2014 at 09:12:07AM +0200, Martin Vonwald wrote: Hi! 2014-08-12 22:57 GMT+02:00 Richard Z. ricoz@gmail.com: what else can I do? Maybe it's time to open up a change request for the main map style? The tag man_made=bridge seems to be used worldwide [1] in some - more or less - consistent way. It provides useful data, is simple to tag, it should be easy to render and it solves some ugly rendering issue. yes I think it is about time that man_made=bridge is rendered. Is there a place where someone could take the main style, change it and see the difference in rendering? So we could not only open a ticket but also provide a patch. have no idea. Just noticed that some mappers resort to adding building=yes or similar to make it render at all. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
On Wed, Aug 13, 2014 at 09:25:33AM -0300, John Packer wrote: Just noticed that some mappers resort to adding building=yes or similar to make it render at all. Note that bridges that are buildings actually exist. [1] But adding building=* to a bridge when it's not the case would be tagging (incorrectly) for the renderer. the one case I have examined is a clear case of tagging for the renderer. I can somewhat understand it when someones local landmark bridge doesn't show up using the correct methods. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On Wed, Aug 13, 2014 at 06:54:11AM +0200, Mateusz Konieczny wrote: 2014-08-11 18:28 GMT+02:00 Christopher Hoess cahoess@gmail.c caho...@gmail.com 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. Some people consider freeform values in bridge tag as a problem and think that bridge tag should have only yes/no values and specific type of bridge should be stored in a separate tag. It is notable as these people maintain Default Style - see https://github.com/gravitystorm/openstreetmap-carto/issues/440 the result of the mentioned redesign is exactly that - there should be much fewer freeform values now. Other subtypes of bridges (humpback, suspension, drawbridge, swing etc) have been moved to subtags bridge:structure and bridge:movable. It would be important that those few bridge values that remained after the redesign are rendered. Also rendering the outline of man_made=bridge would be a huge progress. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On Mon, Aug 11, 2014 at 11:40:00PM -0400, Christopher Hoess wrote: 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? fine for me. 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. not a pipe, a classic viaduct with canal, a roof and arcade style half-open side walls. The purpose was not quite clear - not drinking water and other parts were not covered. Should we have bridge:cover ? 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. the flooding can be more or less frequent. In some places that I have seen the flooding was manmade und thus mostly predictable, bellow a dam. The difference I think is how it will be used for routing, so perhaps both are valid alternatives. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On Mon, Aug 11, 2014 at 09:27:45PM -0400, Christopher Hoess wrote: 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. I was thinking maybe bridge:architecture would cover both bridge:structure and bridge:geometry but I guess it is too late to change? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
On Tue, Aug 12, 2014 at 12:23:35AM -0400, Christopher Hoess wrote: 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. it was a test to see what can go wrong during such conversion. There were quite some odd cases, like bridge=drawbridge used to draw the outline of the bridge. Some time in the future I would like to review all bridge=swing and fix at least those which are not movable at all but hanging rope bridges instead. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
On Tue, Aug 12, 2014 at 09:02:39AM -0300, John Packer wrote: Richard, Perhaps these cases in which the outline of the bridge was drawn is related to this proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/man_made%3Dbridge yes, I am pretty sure it was a desperate attempt to make the bridge outline render. I have converted a few of them to man_made=bridge but last I looked they did not render anyway :( Anyway, those that I have converted look like * outline - man_made_bridge * way/calceway - bridge=movable + bridge:movable=drawbridge Better ideas? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
On Tue, Aug 12, 2014 at 09:06:02AM -0300, John Packer wrote: PS: If you removed these 'bridges as area', you probably should fix that. I have removed the area around this one: https://www.openstreetmap.org/way/25397414 and filed this ticket as it did not render sanely: https://github.com/gravitystorm/openstreetmap-carto/issues/877 Not going to add back an outline as area of bridge=drawbridge hack for a 5x4m cycle path - that is one of the strangest cases of tagging for the renderer that I have seen. I might add man_made=bridge if it would render but I still think that a bikepath/bridge with a width attribute should render sanely. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
another lamentable attempt is here: http://www.openstreetmap.org/way/241772803 what else can I do? Richard On Tue, Aug 12, 2014 at 09:06:02AM -0300, John Packer wrote: PS: If you removed these 'bridges as area', you probably should fix that. 2014-08-12 9:02 GMT-03:00 John Packer john.pack...@gmail.com: Richard, Perhaps these cases in which the outline of the bridge was drawn is related to this proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/man_made%3Dbridge I believe it's main purpose is to solve a known rendering problem in bridges. Nowadays, when two or more parallel ways are in a bridge/viaduct, they are drawn as separate bridges. Drawing the area of the bridge would solve that. Cheers, John 2014-08-12 6:26 GMT-03:00 Richard Z. ricoz@gmail.com: On Tue, Aug 12, 2014 at 12:23:35AM -0400, Christopher Hoess wrote: 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. it was a test to see what can go wrong during such conversion. There were quite some odd cases, like bridge=drawbridge used to draw the outline of the bridge. Some time in the future I would like to review all bridge=swing and fix at least those which are not movable at all but hanging rope bridges instead. Richard ___ 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] bridge=humpback ?
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). Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On Mon, Aug 11, 2014 at 12:40:57AM +0200, Colin Smale wrote: Hi, http://farm2.static.flickr.com/1263/1186115057_7f88a4aaed_o.jpg looks like a landmark or tourist attraction to me and a narrow single lane bridge. The speed limiting factor on this particular bridge might be that you don't see far enough? But using bridge=humpback to imply a hazard may not be such a good idea, will American tourists be familiar with the dangers of humpback bridges? Instead we could describe the hazards as visibility, bump, dip, and narrow single lane with higher chances of universal usability. We could also use reasonable_max_speed (per vehicle category) or do both. Hence I am now inclined to tag humpback bridges as bridge=yes + bridge:structure=humpback Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
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
Re: [Tagging] bridge=humpback ?
Hi, lots of the national wikis refer to bridge=humpback which is missing in the English wiki, how to add it? Also, should the key:bridge pages really encourage user defined bridge values? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
