Re: [Tagging] Formally informal sidewalks

If those two footways make up a reasonable continuing path, that's a good case for using the unmarked crossing tagging schema. It communicates all of the features actually being traversed (footway -> crossing the street -> footway) and is extensible: you can easily add curb and surface

Re: [Tagging] Formally informal sidewalks

> --> need to add all driveways? This is generally a good idea - and to make sure they share a node. > --> need to draw virtual crossings at junctions? These aren't totally artificial/virtual. You can consider them 'unmarked crossings' and there's already tags on the wiki: highway=footway,

Re: [Tagging] Formally informal sidewalks

> You can tag the curbs at each side of a crossing using left/right tags, and you can find out the length by looking at the road's width (or estimate it from the number of lanes). It's not perfect, but at least there are good enough ways to deal with this But you can't handle the directional

Re: [Tagging] Formally informal sidewalks

I'm talking about driveways, is it the node shared by the driveway and street? On Sun, Jul 16, 2017, 11:09 AM marc marc <marc_marc_...@hotmail.com> wrote: > Le 16. 07. 17 à 01:29, Nick Bolten a écrit : > > a block with 10 driveways would > > actually need to be split into 10 low

Re: [Tagging] Formally informal sidewalks

ome. It doesn't really add much in terms of routing cars, like you note. On Sat, Jul 15, 2017 at 12:18 AM Nick Bolten <nbol...@gmail.com> wrote: > To John: > > Those are all very good points. This one is particularly interesting: > > >An example of this issue is where a r

Re: [Tagging] Formally informal sidewalks

To John: Those are all very good points. This one is particularly interesting: >An example of this issue is where a road with no sidewalks meets another road with sidewalks, but does not cross it (and is not in an urban environ, so there is no real paint to show a crossing=zebra) . Do you add a

Re: [Tagging] Formally informal sidewalks

> marc marc wrote: > > For wheelchair routing. > If all crossing have a lower kerb, it is maybe enough to add > sidewalk:both:wheelchair=yes to the street. wheelchair=yes should be used sparingly, because it's making an editorial decision on behalf of wheelchair users, who actually have a wide

Re: [Tagging] Formally informal sidewalks

On Sun, Jul 16, 2017, 1:55 PM marc marc wrote: > All crossing between a sidewalk and a driveways I have tag have the same > type of kerb on each side. It's why I use kerb=lowered without any need > for left/right details, it is for the whole crossing. > I think I'm

Re: [Tagging] Formally informal sidewalks

. 17 à 20:38, Nick Bolten a écrit : > >> There is no need to use so many section. A crossing is a node, not a > >> section/way. So put one kerb=raised on the way and kerb=lowered on the > >> node. It's done :-) You have the same number of section/tag in both > cases. &g

Re: [Tagging] Formally informal sidewalks

On Tue, Jul 18, 2017 at 9:24 AM marc marc <marc_marc_...@hotmail.com> wrote: > Le 18. 07. 17 à 16:01, Nick Bolten a écrit : > >> All crossing between a sidewalk and a driveways I have tag have the same > >> type of kerb on each side. It's why I use kerb=lowered wit

Re: [Tagging] Formally informal sidewalks

> no, it isn't a pedestrian way, it is a street with sidewalk, it is not the same for routing. There is certainly a dedicated pedestrian (and maybe cycling) way there: the sidewalk. If the sidewalk:right* keys are meant to only describe features of the street, then they are complementary to,

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

I'd like to second Tod's point that defaults are difficult when they depend on regional variation. When a tag's default has significant geographical variation, one has to have corresponding regional geodata to figure out what value to use - shouldn't that geodata be in OSM? Perhaps a compromise

Re: [Tagging] sidewalk unsuitable for wheelchair

ke a car that moves slower, and crossing (and the sidewalk, typically) doesn't exist at all in that paradigm. On Sun, Dec 10, 2017 at 10:46 AM Philip Barnes <p...@trigpoint.me.uk> wrote: > On Sun, 2017-12-10 at 18:25 +, Nick Bolten wrote: > > The downside of using `wheelchair=no`

Re: [Tagging] sidewalk unsuitable for wheelchair

The downside of using `wheelchair=no` is that there are many conditions that will prevent some, but not all, wheelchair users from using the infrastructure. For example: some wheelchair users don't care about curb ramp info at all because they're comfortable finding driveways and going in the

Re: [Tagging] sidewalk unsuitable for wheelchair

ias-knerr.de> wrote: > On 10.12.2017 19:25, Nick Bolten wrote: > > More or less, you describe sidewalks as `highway=footway` > > `footway=sidewalk` > > Unfortunately, this breaks the semantic relationship between sidewalks > and the rest of the road ("this section

Re: [Tagging] access=disabled

il.com> wrote: > > > 2018-05-10 21:56 GMT+02:00 Nick Bolten <nbol...@gmail.com>: > >> As a follow-up, it is valuable to know whether a parking space has >> dedicated room for a ramp (i.e. one that extends out of the vehicle). >> capacity:disabled onl

Re: [Tagging] access=disabled

As a follow-up, it is valuable to know whether a parking space has dedicated room for a ramp (i.e. one that extends out of the vehicle). capacity:disabled only describes whether there's dedicated parking for the disabled. Would it be too deeply nested to have capacity:disabled:ramp=yes/no/#? On

Re: [Tagging] access=disabled

10, 2018 at 8:56 PM, Nick Bolten <nbol...@gmail.com> wrote: > >> Would it be too deeply nested to have capacity:disabled:ramp=yes/no/#? >> > > I don't know about being too deeply nested, but if you consider it > hierarchical I'm not > happy with the implied se

Re: [Tagging] RFC proposed water property key 'ephemeral '

a time series of observations, and if so, how frequently? It feels like a tag that is science-ie, but I don't know whether, for example, scientists would use it. 1. https://www.epa.gov/sites/production/files/2015-03/documents/ephemeral_streams_report_final_508-kepner.pdf Best, Nick On Fri, May 25, 2

Re: [Tagging] RFC proposed water property key 'ephemeral '

If I understand this proposal right, the goal of this tag is to provide more specific information for the general likelihood of whether a water feature (only rivers?) exists: when it comes and goes every days. This sounds like there are two pieces of information that are desirable to map: - What

Re: [Tagging] Kerbs

the level of the sidewalk? > > On 31 Dec 2017 19:43, "Selfish Seahorse" <selfishseaho...@gmail.com> > wrote: > > On 29 December 2017 at 00:32, Nick Bolten <nbol...@gmail.com> wrote: > > That's a really great example of how it may make sense to separate out >

Re: [Tagging] Kerbs

> * `mountable`: mountable for wheelchairs and vehicles (...) While this may seem easier to tag on a first pass, it's not ideal, as it's making a broad-brush executive decision about accessibility on behalf of others. I'm also not sure how it's different from wheelchair=yes/no combined with

Re: [Tagging] Kerbs

uot;Selfish Seahorse" <selfishseaho...@gmail.com> > wrote: > > On 29 December 2017 at 00:32, Nick Bolten <nbol...@gmail.com> wrote: > > That's a really great example of how it may make sense to separate out > the > > idea of a 'curb ramp' from the curb interface. I

Re: [Tagging] Kerbs

e:Sloped_kerb.jpg> > <https://wiki.openstreetmap.org/wiki/File:Kerb-45deg.jpg> > > Regards > > On 7 January 2018 at 19:15, Nick Bolten <nbol...@gmail.com> wrote: > >> * `mountable`: mountable for wheelchairs and vehicles (...) > > > > While this may see

Re: [Tagging] Kerbs

length. On Sun, Dec 31, 2017 at 10:43 AM Selfish Seahorse <selfishseaho...@gmail.com> wrote: > On 29 December 2017 at 00:32, Nick Bolten <nbol...@gmail.com> wrote: > > That's a really great example of how it may make sense to separate out > the > > idea of a 'curb ra

Re: [Tagging] Kerbs

> The question is: does it make sense to introduce another `kerb` value in order to differentiate between standard high kerbs and very high kerbs at public transport stops? If I understand the question right, it really comes down to what you consider to be a curb. Some transit stops have raised

Re: [Tagging] Kerbs

kerb=raised is a bit subjective, but you can always add kerb:height when in doubt. Another way to look at it is as the shape at the interface: flush = straight on, lowered = approaching linearly at an angle, rolled = rounded, raised = square edge. On Thu, Dec 28, 2017, 12:15 PM Selfish Seahorse

Re: [Tagging] Put the name in sidewalks and cycleways

Thanks for the examples! I've run into this issue as well, many times, and it's like I said: the 'name' tag is meant to answer the question 'what is the name of this thing?', sidewalks themselves usually don't have names, and the street name isn't the name of the sidewalk. We've been trying to

Re: [Tagging] Put the name in sidewalks and cycleways

The most common convention is to tag footways with a name only if it has its own designated title, like a particularly famous path (and that is often better on a relation). I'm not totally sure if I'm understanding your question, but what are some examples where you're unsure about the tags? On

Re: [Tagging] Estimated values for height

You raise many good points! My primary concern is in being able to distinguish estimated values that are "guesstimates" of different types from something where someone took the effort to use something more precise. Examples: (1) Jessica is walking along the street and is prompted to estimate a

Re: [Tagging] Estimated values for height

I like the ideas using height:source or height:accuracy, but want to point out that they could imply different things. I think we're mostly talking about situations where we're eyeballing some measurement - like the height of a building or the width of something (e.g. I'd really like something

Re: [Tagging] Estimated values for height

, Nov 13, 2018, 2:55 PM marc marc Le 13. 11. 18 à 23:30, Nick Bolten a écrit : > > My primary concern is in being able to distinguish estimated values that > > are "guesstimates" of different types from something where someone took > > the effort to use something more

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

I like the idea of addressing the area-ness of steps! Thanks for taking the initiative on this. I have a couple questions and ideas that are hopefully helpful. # curb (kerb) lines What would you think of tagging each step way as a kerb line? e.g., each step way could be barrier=kerb,

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

://taginfo.openstreetmap.org/search?q=kerb#keys > > Then...you know you will need more tags...cuz it is not enough ;) > PD: don't map for the render (instead it would be OSM official's one). All > real info is welcomed > > Salut i mapes > yopaseopor > > On Sun, Mar 3, 2019 at

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

parking information (e.g. hours, duration, type) that is currently recommended as going on street ways? Should we split streets in cities into 30 pieces? On Sun, Mar 3, 2019, 3:06 PM Warin <61sundow...@gmail.com> wrote: > On 04/03/19 06:12, Nick Bolten wrote: > > A recent post o

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

what would you think of a way that only had kerb=lowered? Should there be a barrier=kerb tag there? Or *=kerb? Best, Nick On Mon, Mar 4, 2019 at 8:44 AM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 4. Mar 2019, at 17:28, Nick Bolten wrote: > > > > P

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

tends to go unmapped. Best, Nick On Mon, Mar 4, 2019 at 12:05 PM Tobias Knerr wrote: > On 03.03.19 20:12, Nick Bolten wrote: > > I wanted to get a discussion started to see what people think of > > mapping curbs as ways. > > Can we please first define a solution

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

rian modeling + parking if I felt confident in the tagging schema. Best, Nick On Tue, Mar 5, 2019 at 2:32 PM Tobias Knerr wrote: > On 05.03.19 01:01, Nick Bolten wrote: > > What would you think > > of a new 'associatedStreet'-style relation that would organize the >

[Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

A recent post on the Mapillary blog ( https://blog.mapillary.com/update/2019/02/12/potential-for-openstreetmap-to-seize-the-curb.html) reminded me of my long-running wish to have more curb lines mapped, so I wanted to get a discussion started to see what people think of mapping curbs as ways. The

Re: [Tagging] How to tag sidewalk slides

The amount of time someone spent at an incline is important for some pedestrians, so I'd use an option that splits the way and sets the incline tag. sidewalk=slide might be related to a tag I've wanted for a while. I think I would personally call that a ramp, so maybe a use of a tag like ramp=yes

Re: [Tagging] Feature Proposal - crossing=marked

I agree that it's very confuddled. I'm going to start a new thread soon after I make some updates to the proposal, primarily for clarity and covering some of the most common questions that have come up here. I'd like to steal your examples, if you don't mind, for the wiki. The response you

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> What sort of feature gets tagged crossing=no? Does one draw a line or node to represent the footway that isn't there? Personally, I've tagged crossing=no on ways either when it's illegal (there's a sign saying no crossing) or when it appears to be very dangerous and it's already been tagged

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

Neat! I've been seeing those FHWA guidelines in various state regulation PDFs, didn't know they were coming from the feds. On Fri, May 24, 2019 at 7:09 PM Clifford Snow wrote: > > > On Fri, May 24, 2019 at 6:27 PM Nick Bolten wrote: > >> Well, now I'm having troubl

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> crossing=traffic_signals – there are explicit traffic signals that tell pedestrians when to stop. There are very likely road markings, but even if not, the absence of road markings, in the presence of actual traffic signals, is irrelevant for how this crossing operates. I think the other

Re: [Tagging] Filter bubbles in OSM

n Fri, May 24, 2019 at 3:14 PM Andy Townsend wrote: > On 24/05/2019 19:42, Nick Bolten wrote: > > > > I'd like that to be the case. What is the plan for making this an > > inclusive community that doesn't devolve into negative, personal > > accusations so easily? It has

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> Do you happen to know what the legal implication is, if any? Pedestrians have the right of way at both marked and unmarked crossings in Texas, which is pretty common in other states of the USA. Sticking strictly to legal implications, marked crossings define a space where cars can't occupy

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> AFAIK once traffic lights are present markings are not changing anything (and crossing with traffic lights without markings are really rare, I suspect that almost always result of worn-out painting or recent surface reconstruction). Change anything for whom? Markings and their location/style

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

, so let's keep them there. On Fri, May 24, 2019 at 4:01 PM Paul Allen wrote: > On Fri, 24 May 2019 at 23:16, Nick Bolten wrote: > > > Legally, it is. "Blind" in the UK legally covers a wide range of visual >>> impairment (...) >> >> >> Neverthele

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

rent crossing=* > values imply default values for various other tags (the same way as the > wiki currently already documents what e.g. crossing=zebra or > crossing=pelican implies). > > > > > > *From:* Nick Bolten > *Sent:* Saturday, 25 May 2019 03:55 > *To:* Tag discus

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

nding would even be an insult. I don't recall calling anyone's intelligence into question, but I've sure been on the receiving end of it. Am I wrong to point this out? On Fri, May 24, 2019 at 12:33 PM Paul Allen wrote: > > On Fri, 24 May 2019 at 19:57, Nick Bolten wrote: > >> > Yes.

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> Nothing I said changes the meaning of any existing tags. It does, because the tags did not specify your exact meanings. You're adding them: that's a change. > You seem to be one of very few people that is incapable of understanding the existing tags, and you shouldn’t be projecting your

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

: > On 5/24/2019 8:13 PM, Nick Bolten wrote: > > I do believe that in at least some parts of Texas, zebra crossings > > have some additional legal/right-of-way implications. In this case, > > when I say zebra, I mean the diagonal stripes enclosed by parallel > > line

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

Oof, sorry, I managed to discuss software despite your last message. Please disregard. On Fri, May 24, 2019 at 7:06 PM Nick Bolten wrote: > I like the thesis (and it's so organized)! I give it a. > > I like the idea of using discourse - or at least something similarly > flexi

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

Nick. Let's > be positive, and talk about ideas. > > We can't change the people, but we can change the communication medium > which can have a very big effect. > > > > I would like to brainstorm what features of a desired communication > medium would have a positive i

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> Such purely implied crossings would be crossing=unmarked, and under the "do not map local legislation" rule, I would only map them if they have a physical presence (e.g. lowered kerbs). If we only mapped marked crossings and/or ones implied from curb ramps, then most sidewalks would be

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> You can’t cross here Fully agree. This tag is the least ambiguous. There are some good discussions to have in the future to of whether to add language to the wiki to state whether the crossing must be illegal, or if it's also okay to tag if the crossing is unsafe or unreasonable. > You can

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

y 24, 2019, 10:55 AM Nick Bolten wrote: > Hi everyone! > > I have two proposals out regarding the crossing tag and how it is not > orthogonal, leading to all kinds of issues in mapping crossings and later > interpreting that data. As currently written, if both proposals

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> What do you mean by a crossing with traffic signals AND with road markings? Status quo, per the wiki: tag with crossing=traffic_signals, hiding/erasing any information about markings that would be communicated in other values. Under the new proposals: tag with crossing=marked (or

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> Which seems to be precisely the opposite of how most people interpret it. Which is very bad, because those people are all diametrically opposed to the wiki definition that, for all its problems, been around for about a decade. To me, this says that there is likely a lot of bad data out there.

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> Here we seem to be in fundamental disagreement. A crossing with traffic signals is a crossing with traffic signals independent of road markings These proposals are literally to tag these things independently. > the interaction of pedestrians and traffic is determined by the status of the

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

I think I'll start using access=no as well, that's a good idea. On Sat, May 25, 2019, 8:44 AM Mateusz Konieczny wrote: > > > > 24 May 2019, 23:41 by nbol...@gmail.com: > > > What sort of feature gets tagged crossing=no? Does one draw a line or > node to represent the footway that isn't there? >

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

tin Koppenhoefer wrote: > > > sent from a phone > > On 24. May 2019, at 23:35, Nick Bolten wrote: > > > crossing=traffic_signals – there are explicit traffic signals that tell > pedestrians when to stop. There are very likely road markings, but even if > not, the absence

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> Legal status/right of way as far as pedestrians and drivers on the road are concerned. Ah, I see. This is not as clear-cut as it might seem, worldwide. There are many laws on the books about marked crossings that are not directly superceded by the existence of signals. It can get pretty

Re: [Tagging] solving iD conflict

find one. Especially with these non specific accusations which few here can recognise. This seems to justify the idea that disagreement = expect petty fights, given the context. This is also demonstrating my points about decorum. On Fri, May 24, 2019 at 11:09 AM Dave F wrote: > > > On 24/05

Re: [Tagging] Filter bubbles in OSM

on its own. On Fri, May 24, 2019 at 5:26 AM Andy Townsend wrote: > On 23/05/2019 20:58, Nick Bolten wrote (in the "solving iD conflict" > thread: > > OSM needs an alternative for community tagging discussions outside of > > these mailing lists. Ones that people will a

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

hreads. On Fri, May 24, 2019 at 11:21 AM Paul Allen wrote: > On Fri, 24 May 2019 at 18:30, Nick Bolten wrote: > >> Notice the extent to which personalisms are being launched. >> > > Yes. I noticed when you implied that I hated blind people. I noticed > when you called

Re: [Tagging] Filter bubbles in OSM

a third option? On Fri, May 24, 2019 at 11:54 AM Paul Allen wrote: > On Fri, 24 May 2019 at 19:43, Nick Bolten wrote: > >> It's a two-pronged recipe for disaster: make it very difficult to >> independently know what to do, then have an often toxic environment for >> tho

Re: [Tagging] wheelchair = hiking

I would suggest developing a new tag that means, "this authority has designated this path as accessible by wheelchair users", as that's the information you actually possess and can communicate. A description of on-the-ground infrastructure would also be appropriate, though I suspect there might

Re: [Tagging] wheelchair = hiking

> IMO wheelchair=yes means accessible for most basic wheelchairs. Yes, but it's something that is frequently difficult to estimate. In interviews with wheelchair users, many will give strong opinions about what they personally think is accessible and their responses vary more than most people

Re: [Tagging] Feature Proposal - crossing=marked

st that, either. On Fri, May 10, 2019 at 4:45 AM Paul Allen wrote: > On Thu, 9 May 2019 at 23:26, Nick Bolten wrote: > >> >> Yes, but a traffic light for whom? I've seen mappers who assume it means >> "walk"/"do not walk" lights like this: >> https

Re: [Tagging] Feature Proposal - crossing=marked

lace the old scheme. Given that I've received a different definition of the term "uncontrolled" from every response in this and the other proposal thread, I do not suspect this is an issue that is occasional nor restricted to new mappers. On Fri, May 10, 2019 at 1:20 PM Paul Allen wrote:

Re: [Tagging] Feature Proposal - crossing=marked

on’t be a crossing tag. I think I'm confused. crossing=unmarked and crossing=uncontrolled would both apply in that situation, right? On Fri, May 10, 2019 at 4:24 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 11. May 2019, at 00:57, Nick Bolten wrote: > >

Re: [Tagging] Feature Proposal - crossing=marked

t; > Map a marked crossing where pedestrians lack the right of way. > Error: Pedestrian has ALWAYS the right of way in a crossing with marks of > crossings (crossing=uncontrolled if there is no traffic_signal) > > > Map an marked crossing that has dropped curbs (keep in mind that some &g

Re: [Tagging] Feature Proposal - crossing=marked

ing:island=yes, the other two are... well, I don't know, really. That's what I'm asking questions about. Maybe crossing=traffic_signals. On Fri, May 10, 2019 at 4:31 PM Paul Allen wrote: > On Fri, 10 May 2019 at 23:59, Nick Bolten wrote: > >> >> - A crossing might be marked

Re: [Tagging] Feature Proposal - crossing=marked

_signals tag has been used to describe all of these things, somehow. On Fri, May 10, 2019 at 12:31 PM Paul Allen wrote: > On Fri, 10 May 2019 at 19:27, Nick Bolten wrote: > >> This all makes sense, but the question is: what does >> crossing=traffic_lights mean given these conte

Re: [Tagging] Feature Proposal - crossing=marked

t; 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. > Tel

Re: [Tagging] Feature Proposal - crossing=marked

id 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 "uncon

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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

> > 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

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

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

Re: [Tagging] Feature Proposal - crossing=marked

, 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

Re: [Tagging] Feature Proposal - crossing=marked

ing scheme for crossings? Are you sure > there is not other existing way to map whatever you want with the present > tagging scheme? > > I don't think so > Health and maps (Salut i mapes) > yopaseopor > > > On Wed, May 8, 2019 at 10:51 AM marc marc > wrote: > >>

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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

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? > > > crossi

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

Re: [Tagging] Feature Proposal - crossing=marked

ontent/uploads/2016/03/cities-skylines-canal.jpg I'd like to harness those people by writing some accessible mapping apps and get good pedestrian tags, but I don't want to add bad crossing tags... On Fri, May 10, 2019 at 5:02 PM Paul Allen wrote: > On Sat, 11 May 2019 at 00:44, Nick Bolt

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

tin Koppenhoefer wrote: > > > sent from a phone > > On 20. May 2019, at 17:17, Nick Bolten wrote: > > > I would suggest to tag the exception, i.e. the absence of crossing > markings where there is a pedestrian traffic light controlled crossing, > with an additional propert

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

ew subtags for markings/signals, old tags still allowed? On Wed, May 22, 2019 at 8:39 AM Tobias Knerr wrote: > On 08.05.19 01:30, Nick Bolten wrote: > > Would it be fair to say you're suggesting something along the lines of > > crossing:marking=*, where * can be yes, no, or a marking

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

footways? On Thu, May 23, 2019, 9:35 AM Jmapb wrote: > On 5/23/2019 12:26 PM, Nick Bolten wrote: > > I'm confused, because these two statements seem incompatible. If it's > > redundant, how can it also have a conflict like different address > > restrictions? I'd like t

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

The only coherent rule I can surmise based on how footways are mapped "in the wild" is that it's an outdoor linear feature and it's primarily intended for pedestrians. Linear transit platforms people walk to, from, and on seem to fit the other uses of the tag, hence my questions. The rendering

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

I'm confused, because these two statements seem incompatible. If it's redundant, how can it also have a conflict like different address restrictions? I'd like to know how, as a data consumer, I should reliably interpret existing platforms without the tag added by iD. Taking a step back, can

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

Ah, I see! That all makes sense. On Thu, May 23, 2019, 10:42 AM Markus wrote: > On Thu, 23 May 2019 at 18:28, Nick Bolten wrote: > > > > I'm confused, because these two statements seem incompatible. If it's > redundant, how can it also have a conflict like different address &

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

ns, > but that does not make a bus stop platform a footway. > Giving an extreme example: Paved brownfields and parking lots are not > footways. But following the argument of the iD developers, they probably > should. > > Tobias > > On 23/05/2019 18:26, Nick Bolten wrote: &

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

That segment of platform by the bus shelter is both a footway and a platform. In many scenarios, the "platform" might be distinguished by nothing but some paint on a curb - clearly it's just a part of the sidewalk where a bus stops. We shouldn't ask mappers to decide how platform-ie or footway-ie

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

how do these threads serve it, given these behaviors? Surely there is a better way to collaborate. On Thu, May 23, 2019 at 4:39 PM Frederik Ramm wrote: > Hi, > > On 5/23/19 21:58, Nick Bolten wrote: > > OSM needs an alternative for community tagging discussions outside of > > these

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

> Yes, it would be great. There is plenty of negative emotion on both sides and it would be great to reverse this (for example title that I used was frankly stupid what I realized after sending the message). OSM needs an alternative for community tagging discussions outside of these mailing

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

ead of with a rant ;-) > > Tobias > > On 23/05/2019 21:58, Nick Bolten wrote: > >> Yes, it would be great. There is plenty of negative emotion on both > sides and it would be great to reverse this (for example title that I used > was frankly stupid what I realized

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

ess it's absolutely necessary. On Thu, May 23, 2019 at 2:43 PM Michael Reichert wrote: > Hi Nick, > > Am 23.05.19 um 21:58 schrieb Nick Bolten: > > # My experience with this mailing list: > > - Quick to exasperate. > > - You will be assumed to be coming to the

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

That bus stop has essentially the same surface conditions as the picture for `highway=platform`. Who wants to update the wiki? On Thu, May 23, 2019 at 3:46 PM Jo wrote: > Indeed not a platform, just a bus stop with a bench and maybe a shelter, > not sure. If the kerb were a bit higher where the

  1   2   >