Re: [Tagging] Feature Proposal - crossing=marked
On 08/05/2019 22:48, Graeme Fitzpatrick wrote: I thought that controlled means that their is signage / indication of some form that says a driver has to stop to allow pedestrians to cross I would take it to be more than that: something that controls *when* the vehicles have priority and when the pedestrians do. A zebra crossing in the UK is uncontrolled, and a signal-controlled crossing is, er, controlled by signals. Maybe a lollipop lady would also be a controlled crossing (but only at certain times of day). -- Steve --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Maritime=yes for marine river estuaries?
I discovered that maritime=yes has been used about 100 to 150 times to tag areas of river estuaries that should be considered part of the marine environment. These parts of rivers are sometimes mapped outside of the coastline, but in some places the local community feels strongly that the water body should be tagged as a river. The most infamous example is the Rio de la Plata between Uruguay and Argentina. This has been done since at least 2015, and has been used by some database users (eg http://openstreetmapdata.com/data/generalized-coastlines - although this is moving soon). The tag was approved for use on administrative boundaries as a way to specify that the boundary way is outside of the coastline, and has been used about 9000 times in this way (most admin_level=2 and many other administrative boundaries are tagged when they are in the sea), which is quite helpful for rendering marine boundaries differently. But I wonder if it wouldn't be better to make a different tag for the usage on marine rivers and estuaries? This would make it possible to keep the tag marine=yes defined for use on administrative boundaries only. I had previously thought that "river=estuary" could work to tag areas of water that are also tagged waterway=riverbank or natural=water + water=river but which are transitional to the marine environment. Alternatives could be "river=marine" or "river=maritime". There is also the popular tag "tidal=yes" but some parts of the coastline have very small tides, so not all marine estuaries are clearly tidal. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Maritime=yes for marine river estuaries?
On Thursday 09 May 2019, Joseph Eisenberg wrote: > I discovered that maritime=yes has been used about 100 to 150 times > to tag areas of river estuaries that should be considered part of the > marine environment. > > [...] I introduced this tag for this purpose to indicate water polygons where mappers insist on closing the coastline outside of them even though they ecologically belong to the maritime domain and would be placed on the wet side of the coastline according to https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement By far the largest example of this is https://www.openstreetmap.org/relation/3474227 But there are countless other cases both with and without the maritime tag. I have essentially stopped trying to maintain this information within OSM and use either heuristics based on the geometries or external data to draw the line between maritime and inland water areas. This is immensely sad for OSMs ability to record even the most basic information about the physical geography of Earth. But it is not really right to just blame mappers for this because the vast majority of data users also just don't care. > But I wonder if it wouldn't be better to make a different tag for the > usage on marine rivers and estuaries? This would make it possible to > keep the tag marine=yes defined for use on administrative boundaries > only. I see no need for that since there are no collisions between the two - maritime boundaries are never geometrically identical to water polygons. The tag maritime=yes is exactly fitting here - this is to indicate a water polygon ecologically belongs to the maritime domain. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - crossing=marked
> I suggest that you read the discussion I started in December about crossing=zebra because it is the main cause of the current situation. I read it back in December, but I disagree. The cause of the situation is the huge problems with the crossing=* values for marked crossings. That problem also caused the iD editor to use its zebra and now marked presets. > Bryan replaced crossing=zebra with crossing=marked in iD but as the crossing=zebra problems were not understood, the alternative has exactly the same problems as the replaced solution. Such as...? > the crossing key is however simple to use except for badly chosen values does the passage have a fire? crossing=traffic_signals otherwise, does the passage have a marking on the ground? crossing=uncontrolled (the work is not perfect because a marking a kind of controll) otherwise crossing=unmarked I don't understand what you're saying here (fire?), but would be interested in knowing what you mean. Could you please rephrase? > Last year, I have review ~1k crossing=zebra, the fragmentation is mainly due to iD I'd expect quite a few tags to come from iD, as it's the default editor on openstreetmap.org, of course. I'm curious about your methodology, since I don't remember seeing this in that December thread. How did you sample? What were the results? > for now, the "new" iD preset destroys perfectly valid data at a frightening rate! if someone modifies a pedestrian crossing with a light, iD replaces it with crossing=marked, which disrupts the information of the presence of the light. This is not relevant to my proposal. Please keep unrelated gripes regarding editors to another thread. > There is already a tag for the reference of a crossing. I'm aware. Please read my proposal, where I explicitly discuss this. > a bad preset is not a good usage Please explain why it's a bad preset. Best, Nick On Wed, May 8, 2019 at 1:51 AM marc marc wrote: > Le 07.05.19 à 22:57, Nick Bolten a écrit : > > - crossing=* values are not truly orthogonal and this needs to be > > addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are > > not truly orthogonal descriptors. > > I suggest that you read the discussion I started in December about > crossing=zebra because it is the main cause of the current situation. > Bryan replaced crossing=zebra with crossing=marked in iD but as the > crossing=zebra problems were not understood, the alternative has exactly > the same problems as the replaced solution. > the crossing key is however simple to use except for badly chosen values > does the passage have a fire? crossing=traffic_signals > otherwise, does the passage have a marking on the ground? > crossing=uncontrolled (the work is not perfect because a marking a kind > of controll) > otherwise crossing=unmarked > > >- There is fragmentation in tag usage for marked crossings between > > "zebra" and "uncontrolled". > > Last year, I have review ~1k crossing=zebra, > the fragmentation is mainly due to iD > > >- crossing=marked is direct and clear about its meaning and use cases. > > for now, the "new" iD preset destroys perfectly valid data > at a frightening rate! > if someone modifies a pedestrian crossing with a light, iD replaces it > with crossing=marked, which disrupts the information of the presence of > the light. > There is already a tag for the reference of a crossing. > if the reference is not known, it would be easy to use crossing_ref=yes > as it is done with many keys. > > > - crossing=marked is already in use and supported by various editors, > > including being the default in iD > > a bad preset is not a good usage > > Regards, > Marc > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - crossing=marked
> I don't know why we need a new tag scheme. Please check out my proposal, as I've laid out several reasons. As someone who has personally mapped thousands of crossings, the current schema is absolute garbage for reliably collecting accurate data that can be reliably interpreted by data consumers that aren't solely focused on car routing. It is also virtually impossible for any new user to know what tags to use and what they mean. You can see in this thread as well as the one in my other proposal regarding signals that even veteran, expert OSM users have different ideas on what "crossing=uncontrolled" means. > crossing=no (prohibited) > crossing=yes (most generic) > crossing=traffic_light is with traffic lights. So implies crossing=controlled. > crossing=controlled is with traffic signs or with police people or similar (it does not matter the marks because of the laws. Traffic signs are more important than road marks, and, in conflict you have to obey the traffic sign not the road mark.) This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra). > crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled I don't understand what you mean by "so one of them implies crossing=uncontrolled"? Are you saying that all crossings with markings should be tagged, "uncontrolled"? What if they have pedestrian signal lights? That's a crossing that has both, implying a contradiction. Note that crossing=traffic_light does not imply whether there are markings on the ground. That's the whole problem: these tags cover information regarding at least 3 discrete categories of information, but do not themselves contain the full gamut of combinations nor even all 3 in every value: (1) markings on the ground, (2) the "controlled" status, and (3) the existence of a pedestrian signal. These should be separate questions a mapper can easily answer: does the crossing have markings? Does the crossing have a pedestrian signal? Does the crossing have a "controlled" status (or, perhaps better, this can be inferred from other properties like crossing_ref, because nobody has any idea what "controlled" means, apparently)? > If there is a traffic island in the crossing you can tag traffic_calming=island (you can read in the wiki crossing=island is a broken tagging scheme . Yes, and I'm thankful that SelfishSeahorse led the effort to fix that tag. The two proposals I've announced are related to breaking out these non-orthogonal crossings tags, similar to crossing=island. However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes. > And then there are the crossing_ref This is outside the scope of this proposal, aside from the fact that if crossing=marked is used, it creates an opportunity to use a straightforward subtag for different marking types that are currently tagged as crossing_ref. Try explaining to virtually anyone why the crossing type is called, "crossing_ref". What's a ref? What does it mean to apply a ref to a crossing? With that said, this proposal does not hinge on this, it's just an opportunity for a different proposal down the line. > But there is no crossing=zebra or crossing=marked. I mean, they are in current use, but putting that aside, that is the point of this proposal: we should be using a specific tag for markings. > I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems. I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list. > Are you sure we need a new tagging scheme for crossings? I am absolutely positive. > Are you sure there is not other existing way to map whatever you want with the present tagging scheme? Yes, and I've tried many, many times. Best, Nick On Wed, May 8, 2019 at 10:38 AM yo paseopor wrote: > I don't know why we need a new tag scheme. > > I remember my explanation of the question and the adaptation of the > possibilities. I repeat them here: > > crossing=no (prohibited) > crossing=yes (most generic) > > crossing=traffic_light is with traffic lights. So implies > crossing=controlled. > crossing=controlled is with traffic signs or with police people or similar > (it does not matter the marks because of the laws. Traffic signs are more > important than road marks, and, in conflict you have to obey the traffic > sign not the road mark.) > crossing=uncontrolled but with marks. So one of them implies > crossing=uncontrolled > crossing=unmarked with no marks, with no control, but crossing > > If there is a traffic island in the crossing you can tag > traffic_calming=island (you can read in the wiki crossing=island is a broken > tagging scheme . > > And then there are the crossing_ref > > zebra is marked but uncontrolled (if it is controlled you can use other > value) > pelican,panda,tigger,toucan,pegasus are controlled with t
Re: [Tagging] Feature Proposal - crossing=marked
This subthread is doing a good job of showing why "uncontrolled" is opaque to users and mappers, as it is primarily an issue of local legal questions and not physical, on-the-ground features, despite the fact that "uncontrolled" in OSM is meant to also describe those (like markings). Because it's a matter of local legal matters, whether a crossing is "controlled" varies from city to city, county to county, region to region, country to country - yet mappers are asked to describe any crossing that has markings but no "traffic signals" are "uncontrolled". I would be surprised if the vast majority of people could certainly describe whether a particular crossing, even one one a block away from their residence, is "controlled". First, I'd expect wildy varying definitions of what the word means, with most people saying, "I have no idea". Second, if you asked them a question like, "who has the right of way at a marked crossing? How about unmarked?", I expect similar disagreement and lack of certainty. The use within OSM even disagrees with the definitions available at what I assume are the primary sources of this nomenclature, where the crossing itself does not necessarily have any markings whatsoever, but simply lacks all forms of controls. On Thu, May 9, 2019 at 1:46 AM Steve Doerr wrote: > On 08/05/2019 22:48, Graeme Fitzpatrick wrote: > > I thought that controlled means that their is signage / indication of > > some form that says a driver has to stop to allow pedestrians to cross > > I would take it to be more than that: something that controls *when* the > vehicles have priority and when the pedestrians do. A zebra crossing in > the UK is uncontrolled, and a signal-controlled crossing is, er, > controlled by signals. Maybe a lollipop lady would also be a controlled > crossing (but only at certain times of day). > > -- > Steve > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > ___ > 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] Wiki page for natural=mountain_range
> Warning - my interpretation! > SADDLE = low point between two high points (mountains), it does not > descend near the level of the adjacent valleys. > PASS =A gap in a range of mountains or hills permitting easier passage > from one side to the other, it descends near the level of the adjacent > valleys. > This gives me a difference between 'pass' and 'saddle',otherwise they > appear to be the same? > If it were a 'pass' then that would make the range into two separate ways. > If it is a saddle then it does not break the range, but forms part of it. > Some mountain ranges do not have crest along their entire length .. yet > they are a mountain range along the entire length. 'Pass' is almost irrelevant to the observable geomorphology ( 'land forms' ) https://www.sciencedirect.com/topics/agricultural-and-biological-sciences/geomorphology Pass is actually more of a 'route', similar to a nautical 'passage', which while it has a 'highest point' somewhere, may have several ups and downs. Some, like Big Hole Pass and Bridger on Montana State Route 287 are pretty much indistinguishable from the rolling flats around them, the mountains are in the distance. Some, in the American West are thousands of feet above the valley floors ( Beartooth Pass, Wyoming, USA ). The pass doesn't even necessarily route through a local minimum like a col, notch, or saddle, which frequently are canyons, but rather the shoulder of slopes. Further, there's a few that don't even connect adjacent watersheds, they weave between saddles of a crest, passing through multiple watersheds until finally dropping to a valley floor. There's a couple in Wyoming that more or less go over the peak of a single mountain. Ranges, paradoxically, aren't defined by the highest features like peaks and crests, they are distinguished from surrounding terrain by contiguous slope realms, usually back slope, foot slope, and toe slope. Basically, at whatever scale, there is a basal concavity ( http://bit.ly/2H9nn5O ) shared by higher elevations, which marks the transitions - in the case of the Cascades or Rockies, thousands of miles, in Montana sometimes tens of miles. Within the Rocky Mountain Range ( https://en.wikipedia.org/wiki/Rocky_Mountains ) which contain the Sawtooth Montain Range ( https://en.wikipedia.org/wiki/Sawtooth_Range_(Idaho) ). The Front Range of the Rocky Mountain Range consists of several smaller ranges - see https://en.wikipedia.org/wiki/List_of_mountain_ranges_of_Colorado#Mountain_ranges The central highest features of a range are perhaps helpful for labeling purposes, but don't really define the mountain range - it is an area. In less dramatic ranges, sometimes it's easier to look at the interfluves ( https://en.wikipedia.org/wiki/Interfluve ), like for https://www.ndhorizons.com/articles/29/summer-2006-north-dakota-s-mountains.aspx Also, 'saddles' are only one very specific type of local minimum between peaks that have two orthogonal continuous curvatures at a local minimum and maximum. There are other geomorhological terms like cols, notches, that account for discontinuous situations ( https://en.wikipedia.org/wiki/Col ). There already exists classification keys for these landforms which are used in automated terrain analysis. ( see the classic https://www.asprs.org/wp-content/uploads/pers/1993journal/sep/1993_sep_1409-1417.pdf , which validated the defining features mentioned above against the existing nomenclature, and the links on http://www0.sun.ac.za/cga/portfolio-items/terrain-analysis/ ). Michael Patrick Data Ferret OSM Seattle ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals
> ground marking but not traffic signal I listed three discrete categories being covered in the current schema: on-the-ground markings, signals for pedestrians, and signals for cross-traffic. There is some further confusion regarding the word "uncontrolled" having to do with right-of-way, but I'll ask that we keep that to my other proposal whenever reasonable. So, with that in mind, what does "traffic signal" mean? Is there a signal telling pedestrians when to cross? Is there a signal telling cross-traffic to stop, at which point pedestrians have the right of way? The wiki states that it's only about the pedestrian signal, which is another problem that I neglected to cover: traffic_signals is already used for street traffic via highway=traffic_signals and it applies to automotive traffic. Mappers are often confused about what traffic_signals means in the context of crossing=traffic_signals, which is why this proposal originally suggested crossing=pedestrian_signals. > sorry I didn't understand what you mean. crossing describe the crossing. if you want to describe a traffic sign, check traffic_sign key A crossing with signals can and frequently does have separate signals for cross-traffic (cars) and pedestrians. Which are present, according to this tag? Saying, "the crossing" does not disambiguate this question, as any crossing can have any combination. > I didn't see where you see this "implied" The wiki and other OSM resources, including this very mailing list. > the color of the nearest building is not indicated either, fortunately because it is not the role of this key. if you want a traffic sign info, check traffic_sign key You seem to be implying that crossing=traffic_signals is not describing signals for pedestrians. This is what the wiki says about this tag: "Position this tag where the crossing-traffic (pedestrian, bicycles) have their own traffic lights.". That's it. The mapper is left to try and guess about what "traffic lights" means and whether it implies that pedestrians have their own signals. I've seen countless mappers, veteran mappers, say that crossing=traffic_signals means there is a light telling pedestrians when they can cross. I would suggest that this means the existing data is unreliable. To me, this suggests that we should even have another tag: crossing:traffic_signals=yes/no, that is dedicated solely to automotive traffic on the street having a signal at this crossing. > again... (check crossing_ref) I don't know what this means (nor the response before it). > the current situation is far from perfect, but either you have not understood the current tags, or you are blackening the current situation to promote your proposal to change everything, which seems unrealistic. I'm going to ask that we keep personal accusations of dishonesty to a minimum. These mailing lists are full of unnecessary personal invective that are issued at the drop of a hat, with zero invitation, and it does nothing except divide. On Wed, May 8, 2019 at 1:59 AM marc marc wrote: > Le 07.05.19 à 23:08, Nick Bolten a écrit : > > What do crossing=uncontrolled/unmarked/traffic_signals say about these > scenarios? > > > crossing=uncontrolled: > > ground marking but not traffic signal > > >- signalization for pedestrians is undefined > > sorry I didn't understand what you mean. > crossing describe the crossing. > if you want to describe a traffic sign, check traffic_sign key > > >- markings are implied > > I didn't see where you see this "implied" > > > crossing=unmarked: > >- signalization for pedestrians is undefined > > the color of the nearest building is not indicated either, > fortunately because it is not the role of this key. > if you want a traffic sign info, check traffic_sign key > > >- signalization for traffic is undefined > > again... > > > > crossing=traffic_signals > >- markings are undefined > > again... (check crossing_ref) > > > So, you can see the problem: the values are describing completely > > different things and the rest is ambiguous. > > the current situation is far from perfect, but either you have not > understood the current tags, or you are blackening the current situation > to promote your proposal to change everything, which seems unrealistic. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals
> and we already have it : crossing_ref I was only referencing these facts to note a synergy with another proposal. It won't be productive to hash out the entirety of problems with crossing=uncontrolled and the proposal to use crossing=marked in this thread, so I'll ask that we have in-depth discussion on the other thread instead. > beware of caricature : > - unmarked pedestrian crossings with lowered kerb for wheelchairs > - unmarked pedestrian crossing that connects a sidewalk on each side of the crossing > just because you've never seen one before doesn't mean it's a fiction. I'm going to ask, again, that you keep away from personal accusations, particularly ones that are speculative in nature. I have mapped thousands of unmarked crossings and am in no way implying anything derogatory. It is simply a fact that there are very few visual indications of where a pedestrian will cross an unmarked crossing. Therefore, the location where it is drawn is somewhat arbitrary - if you're lucky, there's a dropped curb and you can draw the line through those drops, but this is not necessary. On Wed, May 8, 2019 at 2:10 AM marc marc wrote: > Le 08.05.19 à 00:06, Tobias Knerr a écrit : > > We need a tag for the_type_ of the markings anyway > > (as different patterns for marked crossings can have > > entirely different legal meanings in some jurisdictions), and we can use > > that same tag for presence/absence by also allowing yes/no values. > > and we already have it : crossing_ref > and indeed i agree that adding yes/no to current value is a good idea. > the name of the key is not perfect, but it has the advantage of > existing. changing all the keys and value at once seems unrealistic. it > seems preferable to me to take out the type of marking of the crossing > key in favour of the crossing_ref key, it is not a perfect change, but > it was already a huge step forward. we discussed it on the talk-fr list > last year, no one opposed the mecanical edit. on the contrary only one > contributor would have wanted us to go further and change all at once. > to big to success. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals
> Just because mapping something requires real survey rather than mapping from aerial imagery is not making it fictional or unofficial. You are correct. To clarify, my use of quotation marks is meant to communicate that I'm not literally saying they are a fiction - just similar to one. There is no official, exact linear-ish feature you can trace to know where an unmarked crossing is. Often, pedestrians can legally cross at any point across a particular street - but of course, we're not drawing 200 footway=crossing, crossing=unmarked lines down a single street to make sure we've covered enough options. Mappers (myself included) are doing their best to simulate where a pedestrian can cross, usually near a street intersection, and typically in an attempt to connect sidewalks together, without any dedicated visual indication. > Typical footway is also linear. In theory, but often not in actuality. It's easy to make car traffic into lines, with lanes, where cars move along the path. If they don't, it tends to be illegal and dangerous! In contrast, pedestrians can walk from the bank to a bus stop, moving in a completely orthogonal direction to the "footway" representing the sidewalk: they navigate a 2D space. We are simply providing abstractions for, e.g., the sidewalk or other footways to serve a subset of data needs: "how can I get from here to there using sidewalks?", where "here" and "there" are somewhat distant. > Unmarked crossings may also have legal implications (for example in Poland). Indeed, and this is also true of my area (Seattle, WA, USA). On Wed, May 8, 2019 at 2:37 AM Mateusz Konieczny wrote: > 8 May 2019, 01:30 by nbol...@gmail.com: > > - Unmarked crossings are abstract "fictions" representing where an > individual might cross the street, marked crossings are identifiable from > imagery. > - Because unmarked crossings are "fictions", they are only suggested > places to cross, according to the mapper. In contrast, marked crossings are > "official". > > Just because mapping something requires real survey rather than mapping > from aerial imagery is > not making it fictional or unofficial. > > - Marked crossings are one of the few pedestrian spaces that can be > straightforwardly considered as a linear feature: it connects spaces across > a street. > > Typical footway is also linear. > > - Marked crossings tend to have legal implications, as you note. > > Unmarked crossings may also have legal implications (for example in > Poland). > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals
> Uncontrolled crossings are by far the most common. They are wherever there are drop kerbs, which in my town just about every road junction. Please join our discussion of crossing=marked! On Wed, May 8, 2019 at 2:42 AM Philip Barnes wrote: > On Wednesday, 8 May 2019, marc marc wrote: > > Le 08.05.19 à 01:30, Nick Bolten a écrit : > > > Unmarked crossings are abstract "fictions" > > > > beware of caricature : > > - unmarked pedestrian crossings with lowered kerb for wheelchairs > > - unmarked pedestrian crossing that connects a sidewalk on each side of > > the crossing > > > > just because you've never seen one before doesn't mean it's a fiction. > > > Absolutely Marc. > > Uncontrolled crossings are by far the most common. They are wherever there > are drop kerbs, which in my town just about every road junction. > > Needed for wheelchairs, pushchairs, people with limited mobility and me > occasionally when I need to get my wheeled suitcase to the station. > > It would be pointless to provide traffic lights in residential areas with > minimal traffic. > > Phil (trigpoint) > > -- > Sent from my Sailfish device > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals
> Same around here. Most of them have tactile paving too. Please join our discussion of crossing=marked! Without wanting to invite discussion in this thread, this is not what "uncontrolled" means in OpenStreetMap, and it's one of the reasons we should change it. On Wed, May 8, 2019 at 4:52 AM Paul Allen wrote: > On Wed, 8 May 2019 at 10:42, Philip Barnes wrote: > >> >> Uncontrolled crossings are by far the most common. They are wherever >> there are drop kerbs, which in my town just about every road junction. >> > > Same around here. Most of them have tactile paving too. Which I suppose > could be considered as > marking, because it's a different colour to the ordinary paving (but > sometimes the difference is > subtle). For the pedestrian it's obviously marked (even if there's no > colour change you can see > the drop kerb and feel the bumps) but around here most motorists seem > blissfully unaware that > it's there. > > A problem I found way, way back when I looked at how somebody had mapped > the few pelican > crossings around here is that, if you did it according to the wiki, it > didn't render (no traffic lights > shown). Yes, from the perspective of the pedestrian it's a crossing but > from the perspective of > the motorist it's a set of traffic lights.That may havechanged, but I > found a combination of tags > that sort of made sense (and could be interpreted as complying with the > wiki, maybe) and > actually rendered as traffic lights. > > -- > Paul > > ___ > 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] tracktype=*;*;*
I'm seeing some tracks with multiple tracktype's like this: Way 364707088 [highway=track, name=FR 514, tracktype=grade2;grade1;grade3] Is this generally accepted practice? If so, why? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tracktype=*;*;*
Le 09.05.19 à 21:37, brad a écrit : > I'm seeing some tracks with multiple tracktype's like this: > > Way 364707088 [highway=track, name=FR 514, tracktype=grade2;grade1;grade3] > > Is this generally accepted practice? > If so, why? I see 2 "usecases" : - someone merge several way with different values. it's better to revert - someone map a way that have several "part". it's better to split tiger:reviewed=no;yes makes me think it's a merge, even though version #1 probably means that the way was then cut before sending ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tracktype=*;*;*
On Thu, May 09, 2019 at 01:37:09PM -0600, brad wrote: > I'm seeing some tracks with multiple tracktype's like this: > > Way 364707088 [highway=track, name=FR 514, tracktype=grade2;grade1;grade3] > > Is this generally accepted practice? > If so, why? IMHO does not make sense at all. Most likely somebody joined track segments without noticing the different grades and the editor joined it. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away signature.asc Description: PGP signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tracktype=*;*;*
I've occasionally seen mappers do this sort of thing intentionally. They may know (or guess) that a particular way has more than one tracktype so they simply add other values and separate them with a semicolon. In such cases, if one cannot determine what the tracktype actually is, it might be better to simply delete the entire tag. Unless you want to create a changeset comment or contact the original mapper some other way. On Thu, May 9, 2019 at 1:39 PM Florian Lohoff wrote: > On Thu, May 09, 2019 at 01:37:09PM -0600, brad wrote: > > I'm seeing some tracks with multiple tracktype's like this: > > > > Way 364707088 [highway=track, name=FR 514, > tracktype=grade2;grade1;grade3] > > > > Is this generally accepted practice? > > If so, why? > > IMHO does not make sense at all. Most likely somebody joined track > segments without noticing the different grades and the editor > joined it. > > Flo > -- > Florian Lohoff f...@zz.de > UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - crossing=marked
I have checked out your proposal...and I don't know what is the difference with a crossing=marked (yours) and a crossing=uncontrolled (in OSM) I don't agree with you. I think you are forgotten all the other items to tag and the others tagging schemes in OSM. Kerbs are not for cars, cycleways are not for cars. And there are other traffic lights rather than car traffic lights. > It is also virtually impossible for any new user to know what tags to use and what they mean It is not true. There is a wiki and also a iD which can help to undesrtand the tagging scheme and making easier to tag that crossing. > This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra) What is the proposal: translate crossing=uncontrolled to crossing=marked? > Are you saying that all crossings with markings should be tagged, "uncontrolled"? If there is not any control of the crossing...yes otherwise should be crossing=traffic_signals or supervised=yes as you can read in the wiki. > Note that crossing=traffic_light does not imply whether there are markings on the ground Well, in my country it is, when there is a traffic signals with pedestrian traffic signal there is a crossing=traffic_signals. Otherwise is crossing=no because there is no crossing at all. >does the crossing have markings? Does the crossing have a pedestrian signal? Does the crossing have a "controlled" status (or, perhaps better, this can be inferred from other properties like crossing_ref, because nobody has any idea what "controlled" means, apparently)? Change the questions: -Is there any traffic signal in the crossing? -Is there any supervision in the crossing? -Is there any mark in the crossing? A crossing=marked would not inform if it is supervised, and also if is there a pedestrian traffic signal controlled crossing. > However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes No , for a pedestrian way which passes inside an island I have footway=crossing because there si a footway inside a island. I don't need a tag which says things I can see in the situation for the map. It is the same reason I don't need crossing=marked if I have crossing=uncontrolled. Mark is not a control. > I mean, they are in current use, but putting that aside, that is the point of this proposal: we should be using a specific tag for markings. Well, we have it and it is called crossing_ref. > I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list. I was talking about crossing=zebra issue. > Yes, and I've tried many, many times. Tell me one situation you cannot map in detail with present tagging scheme. This is my point of view. Health and maps (Salut i mapes) yopaseopor On Thu, May 9, 2019 at 5:50 PM Nick Bolten wrote: > > I don't know why we need a new tag scheme. > > Please check out my proposal, as I've laid out several reasons. As someone > who has personally mapped thousands of crossings, the current schema is > absolute garbage for reliably collecting accurate data that can be reliably > interpreted by data consumers that aren't solely focused on car routing. It > is also virtually impossible for any new user to know what tags to use and > what they mean. You can see in this thread as well as the one in my other > proposal regarding signals that even veteran, expert OSM users have > different ideas on what "crossing=uncontrolled" means. > > > crossing=no (prohibited) > > crossing=yes (most generic) > > crossing=traffic_light is with traffic lights. So implies > crossing=controlled. > > crossing=controlled is with traffic signs or with police people or > similar (it does not matter the marks because of the laws. Traffic signs > are more important than road marks, and, in conflict you have to obey the > traffic sign not the road mark.) > > This proposal only concerns crossing=uncontrolled (as well as the > still-in-use crossing=zebra). > > > crossing=uncontrolled but with marks. So one of them implies > crossing=uncontrolled > > I don't understand what you mean by "so one of them implies > crossing=uncontrolled"? Are you saying that all crossings with markings > should be tagged, "uncontrolled"? What if they have pedestrian signal > lights? That's a crossing that has both, implying a contradiction. > > Note that crossing=traffic_light does not imply whether there are markings > on the ground. That's the whole problem: these tags cover information > regarding at least 3 discrete categories of information, but do not > themselves contain the full gamut of combinations nor even all 3 in every > value: (1) markings on the ground, (2) the "controlled" status, and (3) the > existence of a pedestrian signal. These should be separate questions a > mapper can easily answer: does the crossing have markings? Does the > crossing have a pedestrian signal? Does the crossing have a "controlled" > status (or, perhaps better, this can be inferred
Re: [Tagging] tracktype=*;*;*
On 09/05/2019 21:35, marc marc wrote: tiger:reviewed=no;yes makes me think it's a merge, even though version Yes - the history of https://www.openstreetmap.org/way/10191527/history suggests that it's a merge. Likely the mapper didn't spot the extra tags and the editor that they were using (at the time) didn't highlight what had happened. With a bit of forensics you can often re-split the way and apply the original tags, but after 4 years a new survey is probably a better idea :) Best Regards, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - crossing=marked
sent from a phone > On 7. May 2019, at 22:57, Nick Bolten wrote: > > One of the primary confusions is the "uncontrolled" (and "zebra") values, > which are, in effect, intended to mean that a crossing is "marked" they are also intended to mean: not controlled by a traffic light (while „marked“ likely would include traffic light crossings) Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Japan road tagging (Was "what todo if the status of a propal isn't set to Voting")
On Thu, 9 May 2019 at 11:46, 石野貴之 wrote: > This feature has been proposed by our fellow, Yuu Hayashi. You may think > this hasn't been discussed previously, but it's totally wrong. He has been > working on Japanese road tagging for more than four years. > Thank you, & apologies if it sounded like I was suggesting the wrong thing was being done. >> Is it possible to change details for only one country, or would this >> proposal change all highway details, worldwide? >> > If so, shouldn't that be discussed much more widely? >> >> This discussion is aimed for deciding local rules in Japan only and will > not affect highway details all over the world. > Thanks again - & now you've got me curious as to how you can have country-specific road details? :-) Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - crossing=marked
> they are also intended to mean: not controlled by a traffic light (while „marked“ likely would include traffic light crossings) Yes, but a traffic light for whom? I've seen mappers who assume it means "walk"/"do not walk" lights like this: https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg. I've seen mappers who assume it means there is a sign *just* to warn traffic about pedestrians, as can be found in the UK. I've seen mappers who assume it means there is a nearby traffic light that means cars sometimes stop at this location, but it doesn't say anything about having a "walk"/"do not walk" sign. The wiki only says, "Position this tag where the crossing-traffic (pedestrian, bicycles) have their own traffic lights.". Pedestrians having "their own" traffic lights would seem to imply the lights are specific to the crossing and not that cross-traffic has to stop sometimes, but it does not say which type of traffic light: cross-traffic (cars) or pedestrian traffic. I've tended to assume it's the former, but have run into many, many mappers who think it's the latter. I tend to avoid mapping it at all because I don't want to add ambiguous data to the map. On Thu, May 9, 2019 at 2:52 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 7. May 2019, at 22:57, Nick Bolten wrote: > > > > One of the primary confusions is the "uncontrolled" (and "zebra") > values, which are, in effect, intended to mean that a crossing is "marked" > > > they are also intended to mean: not controlled by a traffic light (while > „marked“ likely would include traffic light crossings) > > > Cheers, Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - crossing=marked
> I have checked out your proposal...and I don't know what is the difference with a crossing=marked (yours) and a crossing=uncontrolled (in OSM) crossing=marked indicates that a crossing has markings. That's it: the "type" of crossing is declared to be whether it has markings on the ground or not. crossing=uncontrolled has very unclear meanings. You can see from this and the thread about crossing:signals=* that there are at least 4 different definitions used by veteran-ish OSM mappers, despite most of them saying "of course it means my version". To expound, there are multiple ways in which "uncontrolled" has problems in terms of understanding meaning: (1) The term "uncontrolled" is a transit nerd term. Almost nobody uses this word outside of a select few circles. New mappers have no idea what it means (though veteran mappers also seem to disagree with one another) and make an *incorrect* guess, assuming it means the same as unmarked. (2) the crossing tag, as currently documented, has values that imply meanings regarding right-of-way, markings on the ground, and pedestrian/traffic signals (it's hard to tell what the latter even means, honestly, which is why I have that proposal). That's three totally different categories that are meant to be summed up in one tag value and the current values don't even cover the full combination. "uncontrolled" does not actually say anything about right-of-way, per the OpenStreetMap wiki. (3) However, the real-world meaning of "uncontrolled" is entirely about right-of-way based on "controls" for street traffic. Essentially, it's the polar opposite of the OpenStreetMap usage. Anyone who attempts to look up the term "uncontrolled" outside of the OpenStreetMap will come away with the exact wrong meaning and map the data incorrectly. > I don't agree with you. I think you are forgotten all the other items to tag and the others tagging schemes in OSM. Kerbs are not for cars, cycleways are not for cars. And there are other traffic lights rather than car traffic lights. I don't think I understand what you mean by this. Could you please rephrase? > It is not true. There is a wiki and also a iD which can help to undesrtand the tagging scheme and making easier to tag that crossing. The iD editor never uses crossing=uncontrolled. It actually uses crossing=marked now. It is at odds with the wiki, and what the wiki says is very different from what many people on this mailing list say crossing=uncontrolled means. > What is the proposal: translate crossing=uncontrolled to crossing=marked? Only after robust discussion with local communities and with their approval. I am not recommending any automated edits whatsoever as part of this proposal, only suggesting that it might be possible in limited regions, with community assent (and following all of the other protocols regarding machine edits). I anticipate that many US-based communities would be open to converting crossing=uncontrolled and crossing=zebra to crossing=marked, at a minimum, given how frequently they've been edited with iD. I split this message in two because it was too long - I'm sending another reply shortly. On Thu, May 9, 2019 at 2:26 PM yo paseopor wrote: > I have checked out your proposal...and I don't know what is the difference > with a crossing=marked (yours) and a crossing=uncontrolled (in OSM) > I don't agree with you. I think you are forgotten all the other items to > tag and the others tagging schemes in OSM. Kerbs are not for cars, > cycleways are not for cars. And there are other traffic lights rather than > car traffic lights. > > > It is also virtually impossible for any new user to know what tags to > use and what they mean > It is not true. There is a wiki and also a iD which can help to undesrtand > the tagging scheme and making easier to tag that crossing. > > > This proposal only concerns crossing=uncontrolled (as well as the > still-in-use crossing=zebra) > What is the proposal: translate crossing=uncontrolled to crossing=marked? > > > Are you saying that all crossings with markings should be tagged, > "uncontrolled"? > If there is not any control of the crossing...yes otherwise should be > crossing=traffic_signals or supervised=yes as you can read in the wiki. > > > Note that crossing=traffic_light does not imply whether there are > markings on the ground > Well, in my country it is, when there is a traffic signals with pedestrian > traffic signal there is a crossing=traffic_signals. Otherwise is > crossing=no because there is no crossing at all. > > >does the crossing have markings? Does the crossing have a pedestrian > signal? Does the crossing have a "controlled" status (or, perhaps better, > this can be inferred from other properties like crossing_ref, because > nobody has any idea what "controlled" means, apparently)? > > Change the questions: > -Is there any traffic signal in the crossing? > -Is there any supervision in the crossing? > -Is there any mark in the crossing? > > A crossi
Re: [Tagging] Feature Proposal - crossing=marked
> If there is not any control of the crossing...yes otherwise should be
crossing=traffic_signals or supervised=yes as you can read in the wiki.
But the meaning of "control" varies by region and municipality, and does
not imply the presence or absence of ground markings. A controlled crossing
can have or lack ground markings, and an uncontrolled can have or lack
ground markings.
> Well, in my country it is, when there is a traffic signals with
pedestrian traffic signal there is a crossing=traffic_signals. Otherwise is
crossing=no because there is no crossing at all.
In your country, how do you map a crossing that has traffic controls but
does not have markings on the ground?
> Change the questions:
> -Is there any traffic signal in the crossing?
> -Is there any supervision in the crossing?
> -Is there any mark in the crossing?
I don't know what it means for a crossing to be supervised, but I do like
the others you've listed. I would prefer that the crossing=* tagging schema
reflect the questions you are asking, they're the right ones for
pedestrians. What I'm saying is that the current OSM schema seems to ask
the questions I listed, but they get described by a single value like
"uncontrolled", to the confusion of all. In other words:
crossing=uncontrolled implies at least 3 pieces of information. Imagine if
we instead had a schema for your questions that looked something like this:
crossing:traffic_signal=yes/no/*
crossing:supervision=yes/no/*
crossing:marking=yes/no/* (or crossing=marked/unmarked/*)
That would be separating those questions out much better than the current
schema and be much easier to map.
> No , for a pedestrian way which passes inside an island I have
footway=crossing because there si a footway inside a island. I don't need a
tag which says things I can see in the situation for the map. It is the
same reason I don't need crossing=marked if I have crossing=uncontrolled.
Mark is not a control.
While it is not as thoroughly-documented as it could be, the wiki states
that crossing:island can be applied to the footway:
https://wiki.openstreetmap.org/wiki/Key:crossing:island. Specifically, "or
alternatively on a pedestrian crossing way highway=footway +
footway=crossing".
As an example, imagine that you are a data consumer and you want to tell a
pedestrian router that they are using an island. If you were to look up a
crossing:island key on a given footway, you could tell them, "use a traffic
island to get to ". You can, of course, also use an advanced
router that extracts crossing:island from a node.
> Well, we have it and it is called crossing_ref.
crossing_ref is not actually a tag for noting the type of markings, nor was
it intended to be. It's a dumping ground for the older UK-centric tagging
schema that used zebra, toucan, pelican, etc, with those UK-specific
right-of-way implications. For example, crossing_ref does not have a
"ladder" key, even though that's an extremely common marking type:
https://taginfo.openstreetmap.org/keys/crossing_ref#values. As you can see,
pretty much all of them are just "zebra". Many people from the UK get
annoyed when you call a US-based ladder crossing a "zebra crossing", as our
ladder crossings do not have the same right-of-way implications nor the
angled markings.
> I was talking about crossing=zebra issue.
Ah, I see. I just misunderstood, my fault.
> Tell me one situation you cannot map in detail with present tagging
scheme.
* Map a crossing that is unmarked and has pedestrian signals ("walk"/"do
not walk").
* Map a crossing that is marked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
* Map a crossing that is unmarked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
* Map a crossing that is unmarked and is protected by its own,
non-street-intersection traffic light, then say how you would interpret
this as a data consumer.
* Map a crossing that is unmarked, has pedestrian-specific signals
("walk"/"do not walk"), but no traffic signals at all nearby.
* Map a crossing that has markings and is protected by a traffic light, but
that traffic light is part of the overall highway=traffic_signals
signalization, not specific to just that crossing.
* Map an unmarked crossing that has the same type of traffic light
situation: the light is to stop traffic at the intersection, not that
particular crossing alone. Map an unmarked crossing that has
pedestrian-specific signals ("walk"/"do not walk") and has that same
"intersection-only" traffic light.
* Map a marked crossing where pedestrians lack the right of way.
* Map an marked crossing that has dropped curbs (keep in mind that some
veteran OSM mappers have stated that dropped curbs are a control).
I have no doubt that you can come up with some examples that *mostly* work.
But they will be ambiguous to a data consumer and often most mappers.
Best,
Nick
[Tagging] Looking for Existing Proposal/Feature - Firearm Restrictions
Good Evening, I am considering submitting a proposal for restrictions or allowances on carrying firearms in a particular location. I checked through the proposal pages and the active features pages and did not see anything related to this. The Proposal Process page suggested emailing this list to ensure nothing similar is already in use. Examples of these restrictions in my area would be signs on buildings prohibiting carrying firearms concealed and/or openly. The signs themselves would be nodes, but the allowance or restriction would apply to ways. Thank you. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
