Re: [Tagging] Continuous Sidewalk or Cycleway

[Nick Bolten]

Hi Florimand!

This is an interesting situation. Would it be possible to draw an overhead
diagram of the situation in question? Also, is this a tag that could
potentially go through the proposal process? It isn't in taginfo I'd be
happy to help any way I can.

Best,

Nick


On Thu, Jan 23, 2020, 12:11 PM Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> Hello,
>
> How to map a continuous sidewalk or cycleway ?
> In order to solve this question I created a wiki page to sum up my first
> try to tag this:
> https://wiki.openstreetmap.org/wiki/Continuous_Sidewalk
>
> The main idea is to use the tag:
> junction=continuous_sidewalk|continuous_cycleway
> on node or ways of a feature.
>
> Helpful comments are welcome.
>
> --
> Florimond Berthoux
> ___
> 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] Foot or foot.cycle crossing

[Nick Bolten]

Sorry for being late to the party!

My understanding is that there isn't a documented tagging strategy for a
marked cycle lane crossing that's mapped as on a street way.

cycleway=crossing covers this scenario if the cycleway has been separately
mapped, so I wonder if a proposal for a tag like cycleway:
right:lane=crossing would be a logical extension. It could be applied to
the street way from the start of the crossing to the end of the crossing.

Specifying the crossing type (if necessary) could lead to an awkwardly long
key, as the nested would always need a side-of-street reference, like
cycleway:right:lane:crossing=uncontrolled. Maybe there should just be one
tag: cycleway:right: crossing=yes/no/uncontrolled (whatever that
means)/unmarked.

Best,

Nick

On Wed, Nov 27, 2019, 7:13 AM Volker Schmidt  wrote:

> I do have a topological problem with the mapping of a junction of two
> roads one of which has parallel cycle lanesa and sidewalks
> Both are correctly mapped: the sidewalk as a separate highwy=footway and
> the cycle lanes as cycleway:left|right=lane.
> How to you tag the foot-cycle crossings.
> See this Mapillary photo
>  to make things
> clearer.
> Two possible options:
>
> (1)
> way with:
> crossing=uncontrolled
> footway=crossing
> highway=footway
> plus node with:
> crossing=uncontrolled
> highway=crossing
>
> (2)
> way with:
> bicycle=designated
> foot=designated
> highway=path
> path=crossing
> segregated=yes
> plus node with:
> bicycle=yes
> crossing=uncontrolled
> highway=crossing
>
> Both are "incorrect" in some aspects.
> Which one is less incorrect?
> Is there a better tagging solution?
> ___
> 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 - footway=link

[Nick Bolten]

ap the staircases, but what do I connect to at the
landing? It's not really a footway.

- https://www.openstreetmap.org/way/223362697. There's a building entrance
in the middle of the south side of this building. It has a single stair. To
make this accurately mapped, one would currently draw a footway, then
steps, then a footway. It's not really a footway, though - just a path to
an entrance.

- https://www.openstreetmap.org/way/223362694. This post office has a
pretty complex set of ways to get to the entrance. Are they really
footways? They're not exactly linear features, more just a set of paths
over a large space that one would take to get to the entrance.

Paths that deviate from footway centerlines that could benefit from a path
description:

- https://www.openstreetmap.org/node/3884332795. There is a set of 2-3 bus
shelters that split the sidewalk. If you mapped just the centerline of the
sidewalk, it'd go directly through the bus shelters (and this is how it's
currently mapped). If one actually mapped the shelters, it would be
unintuitive to keep that path going straight through them - it would be
adjusted to the east for an unobstructed path. That part of the sidewalk
has a distinct usable width that differs from the total width of cement in
that area. In addition, there's some value in indicating the alternative
path that uses the shelters - waiting for the bus. This might seem like
over-the-top micromapping, but those paths matter: some of them go through
width-constrained regions that would prevent some (but not all) wheelchairs
- so they should have their own width=* tags. These paths could be obtained
by mapping areas, but would require fairly intense CS skills to extract.

The above example would work neatly with Allroads' suggestions.

Hope this makes sense!

Best,

Nick

On Sun, Nov 24, 2019 at 1:52 PM Markus  wrote:

> Many thanks for your thoughts, Nick!
>
> On Sat, 23 Nov 2019 at 02:36, Nick Bolten  wrote:
> >
> > I would propose that under an expansive definition it be thought of this
> way: a "footway link" is a path connecting pedestrian-accessible ways that
> is not, itself, a centerline of a designated physical pedestrian space.
>
> Wouldn't this mean that any footpath leading into a road would need to
> be split for its last few metres, like the last 3 m of the path here?:
>
> https://www.openstreetmap.org/node/413988097
>
> I doubt that this were very useful, but would only complicate mapping.
> If you want to know the precise location where the footpath begins or
> ends, it should be possible to get that information from the road
> width or area:highway=*.
>
> Besides, only defining footway links, but e.g. not connections of
> tracks with roads (example [1]) or of roads with other roads (example
> [2]) seems quite arbitrary.
>
> I think the only situation where such links are really required is
> when connecting two adjacent parallel ways (your point 1), like for
> example a road and a sidewalk, a parallel cycle path [3] or parallel
> steps, as such a connection isn't an extension of either way (the 3 m
> in the example above is the extension of the foot path, but the
> connection of an ending sidewalk with the road is neither sidewalk nor
> road).
>
> I am thinking about a definition like "a footway/cycleway/path=link is
> a way that is used to change from a road to an adjacent parallel
> path".
>
> > 3. Transitioning from a sidewalk to a crossing, where both are
> separately mapped: [...] It's that short path that extends from the
> sidewalk to the street.
>
> That short way definitely isn't a separate sidewalk (no lateral kerb,
> not parallel to the road), but the extension of the crosswalk. In my
> opinion there isn't a necessity tag it differently – if the width of
> the sidewalk is specified, it is clear where the crosswalk begins.
> While it wouldn't harm if people tag that short way or the extension
> of a path that is inside the area of a road as footway=link, i think
> that this shouldn't be a requirement.
>
> > 4. Plazas. While it is possible to extract many plausible paths through
> pedestrian area features, there is value in simply mapping the most direct
> paths and not requiring data consumers to become intimately familiar with
> skeletonization algorithms or robotics pathfinding. Mapping canonical paths
> through plazas as links allows both options: they can be ignored (as they
> are acknowledged to be connections rather than distinct paths) or consumed
> directly.
>
> This is a very different situation from the connections i have in
> mind. Besides, these aid ways likely aren't verifiable.
>
> > 5. Short paths to building entrances from sidewalks, other footways.
> [...]
> >
> > 6. Short paths that deviate slightly from centerlines to make use

Re: [Tagging] Feature Proposal - RFC - footway=link

[Nick Bolten]

Looks very nice! I have some different concerns about the curbs, but don't
want to derail. Is there discussion about that curb tagging schema
somewhere?

Overall, I think the concept of overlaying areas, centerlines, and links
between them is a good one.

On Sat, Nov 23, 2019, 3:28 AM Allroads  wrote:

> I worked out a visualisation image.
> From the situation I linked in my earlier post.
>
> https://i.postimg.cc/jqJSxT1w/service-crosssing-text.png
>
>
> Allroads.
>
> ___
> 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 - footway=link

[Nick Bolten]

I'm a big fan of this proposal and like others I think it could be useful
in many scenarios. Expansion beyond connecting sidewalks to streets would
be great!

I would propose that under an expansive definition it be thought of this
way: a "footway link" is a path connecting pedestrian-accessible ways that
is not, itself, a centerline of a designated physical pedestrian space.

Examples:

1. Connecting a dead-end sidewalk to the street (already in the proposal):
real pedestrians may want to walk on a sidewalk that only extends partially
down a street, then revert back to walking on the side of a street. A
footway link acknowledges this transition and maintains network
connectivity.

2. Connecting orthogonal footways to the street, even when there's no
designated footway (the steps example): Similar to the first example,
pedestrians may want to fall back on the street network after transitioning
from steps, or we may want to maintain connectivity for routing software
that makes primary use of streets without having "fake" pedestrian ways
connected to the street: steps connecting directly to a street across a
sidewalk, a footway from a park doing the same, etc.

3. Transitioning from a sidewalk to a crossing, where both are separately
mapped: we've often run into the challenge of saying 'what is this thing?'
when mapping highway=footway, footway=crossing, highway=footway,
footway=sidewalk, and kerb=* to describe pedestrian spaces. It's that short
path that extends from the sidewalk to the street. It isn't really a
sidewalk, even though it's on top of one. It isn't really a crossing,
because you're still on the sidewalk at that point. It's a link between
footways! This would be helpful for QA and increased mapping: when a
footway=link meets a footway=crossing, we can ask for mappers to add kerb=*
using software like StreetComplete.

4. Plazas. While it is possible to extract many plausible paths through
pedestrian area features, there is value in simply mapping the most direct
paths and not requiring data consumers to become intimately familiar with
skeletonization algorithms or robotics pathfinding. Mapping canonical paths
through plazas as links allows both options: they can be ignored (as they
are acknowledged to be connections rather than distinct paths) or consumed
directly.

5. Short paths to building entrances from sidewalks, other footways. These
are often not truly a designated footway, just a path from the sidewalk
centerline to the building's entrance, but they can still be complicated:
they might have steps along them, or have a unique geometry due to fencing
or walls. A link will assist in mapping this accessibility information and
remove confusing data from the map.

6. Short paths that deviate slightly from centerlines to make use of
facilities, but are still related to those other footways. For example,
there may be a single clear way to navigate from a sidewalk centerline to a
bus stop that is not the canonical sidewalk centerline. It's a path on the
sidewalk that could be worth describing (for example, street furniture may
cause it to have a narrow passable width), but it's not itself the primary
sidewalk way.

Thanks for proposing this! It really scratches an itch.

Nick

On Mon, Nov 18, 2019 at 1:25 PM Markus  wrote:

> Hello everyone
>
> As the discussion has moved from pedestrian lanes to linking ending
> sidewalks with a road and as there haven't been any more changes or
> suggestions to the proposal on pedestrian lanes, i'm opening the vote
> on that proposal and requesting comments on the proposal on
> footway=link:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:footway%3Dlink
>
> Definition: to link steps or a sidewalk with a road
>
> Best regards
>
> Markus
>
> ___
> 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 - Pedestrian lane

[Nick Bolten]

> The following pedestrian router already seems to work quite well with
sidewalk=* tags and highway=crossing nodes (examples):

When something "works" 99.9% of the time, it's the edge cases that matter.
But, because this is a network problem, a single edge case can disrupt tons
of paths.

Here's an example (drawing from your very nice diagrams):
https://wiki.openstreetmap.org/wiki/File:Ambiguous_sidewalk_and_crossing_via_street_metadata.svg

Attempting to use this schema requires doing two things:

(1) We infer a set of sidewalk paths from street metadata, usually guessing
about the offset distance. This ends up being an important source of errors
in the routago example in Zollikofen.

(2) We infer street crossings from guesswork that uses street topology,
distances, and any other number of rules we can make up because we don't
actually know for sure which crossings can be used by which sidewalks.

In the case of the marked crossing on top, which sidewalks can use it
(i.e., how should we create our routable graph)? Visually, it is clear that
the marked crossing is to be used by the sidewalk associated with the
rightmost street. However, a heuristic approach could easily identify it as
usable by the other street's sidewalk as well: it is in the correct
topological location (a 'right turn' from an incoming sidewalk) and a short
distance from the intersection (x). Even with more complex heuristics, like
assigning crossings to the nearest intersection, we still get errors
depending on the exact sizes of x and y: perhaps, sometimes, it's usable by
both. This would be no issue were the connections mapped directly.

There's a similarly complex example here:
https://www.openstreetmap.org/#map=19/47.71953/-122.31794. Attempting to
figure out exactly which crossings can be used by which sidewalks is a bit
of a mess due to the proximity of different sidewalk endpoints to nearby
crossings.

This guesswork means the pedestrian paths are uncertain. Imagine if our
street networks were like this, not knowing how they connect to oen another!

>
https://www.routago.de/pedestrian-routing/?map=46.9802955,7.421488,19=46.9798388,7.4200845=46.9800291,7.4229276
>
https://www.routago.de/pedestrian-routing/?map=46.9932946,7.4567288,18=46.9936495,7.4545938=46.9927603,7.4568951

These examples exhibit other issues, though I'll skip the first one because
they're small. The second (Zollikofen) has very clear errors resulting from
this schema: when crossing Zelweg, routago predicts four maneuvers: (1)
turn left to get to the start of the crossing, (2) turn right and get on
the crossing, (3) get off the crossing and turn right (while not called
out, it's visually there), and (4) turn left to get on the sidewalk (or
pedestrian lane, as it is one).

None of those maneuvers are actually required or implied by the on-ground
realities:
https://www.mapillary.com/app/?lat=46.99333843=7.45498349=17=photo=wtKKmazts0SR6pNE8J_8FA=0.8600724394834813=0.514884292476=0.
You can see the crossing on the left. In reality, the path taken by most
pedestrians will be direct, requiring no particular turns of any kind.

These errors are an artifact of not knowing where the sidewalks and
crossings actually interface and having to guess about them.

Aside from producing errors, this guesswork is highly technical and not
something the vast majority of interested data consumers can do, which
limits the value of the data to a very small set of computer scientists or
extremely enthusiastic programmers + GIS enthusiasts with a background in
graph theory, geospatial analysis, and constructive geometric methods. In
contrast,  pedestrian ways that are directly connected to one another can
be analyzed using any transportation network software and are compatible
with common OSM routers.

> I use highway=footway + footway=link connect steps and sidewalks to a
road, in order to retain the real length and geometry of the steps or
sidewalks and to indicate that these aren't steps or a sidewalk anymore,
but part of the carriageway of the road. Other mappers seem to use this
scheme too (already 743 uses and only every 7th is from me).

Neat! I really like that proposal and would be interested in chatting about
other potential use cases.

Thanks again,

Nick

On Sat, Nov 16, 2019 at 2:25 AM Markus  wrote:

> On Tue, 12 Nov 2019 at 23:54, Nick Bolten  wrote:
> >
> > > You mean a situation like this?:
> >
> > > https://wiki.openstreetmap.org/wiki/File:Sidewalk_and_crossing.svg
> >
> > One very similar to that, yes! I think I normally wouldn't add
> sidewalk=both to any length of the highway=residential. Is that a typical
> thing to do? I would assume that meant the highway=residential street had
> its own short piece of sidewalk, when it actually doesn't.
>
> You're right, sidewalk=both doesn't make sense in that example. I use
> this tagging only when the junction and the sidewalks are curv

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Nick Bolten]

You make a very good point! A road can have a pedestrian lane, shoulder,
both, or neither, so it wouldn't make any sense for a pedestrian lane to be
a type of shoulder. The widths do vary quite a bit as well, regionally.

> You mean a situation like this?:

> https://wiki.openstreetmap.org/wiki/File:Sidewalk_and_crossing.svg

One very similar to that, yes! I think I normally wouldn't add
sidewalk=both to any length of the highway=residential. Is that a typical
thing to do? I would assume that meant the highway=residential street had
its own short piece of sidewalk, when it actually doesn't.

The challenge I'm describing is in reliably associating the crosswalk with
the pedestrian paths. After all, the crosswalk is a node on a different
street way. I know that I could do it 99.x% of the time, but it will
require using some graph traversal approaches that most people aren't
familiar with. Plus, those cases where I couldn't reliably determine it
could be very important. I suspect this is one of the reasons I haven't
found anyone using these data in concert (sidewalk=both + highway=crossing)
to do pedestrian routing.

Mapping for a router isn't the end-all-be-all of this kind of data, of
course, but it is one thing that would be hard to do with this tagging
schema. I'd be interested to know if there are other data consumer plans
for the data, since use does dictate what the schema looks like. Making
streets be ways was a conscious choice informed by routing, for example!

> I would simply connect the sidewalk way with the road where the
sidewalk ends (and map a barrier=kerb + kerb=* node) and add
pedestrian_lane=* to the road starting from where the pedestrian lane
begins.

So there would be a segment of footway=sidewalk that is not actually on a
sidewalk? I've been unsure about what to do in similar situations, like how
to connect footways to roads without implying there's literally a footway
on top of the road. Probably worth its own, separate discussion (it was
discussed previously, but without conclusion), so I won't elaborate.

> There is a pedestrian lane along the the south-eastern part of the road
Reichenbachstrasse. On the opposite side there are public steps as well as
many (currently unmapped) driveways and private footpaths. Mapping the
pedestrian lane as a separate way would either make it disconnected from
the steps, driveways and footpaths on the opposite side of the road or you
would need to add many highway=footway connections from the pedestrian lane
to the steps, driveways and footpaths, which would make the map very
confusing.

> Therefore i strongly advise against mapping pedestrian lanes as separate
ways.

> By the way, the same problem occurs with sidewalks mapped as separate
ways.

Yes, it's a trade-off: the actual pedestrian path's primary connections and
attributes vs. its association with the street. Neither are actually
perfect options, which is why I'm suggesting the possibility of redundant
tagging. Ideally, we'd come up with a universal strategy for relating these
ways together, but I don't want to monopolize this proposal!

> I'm not a programmer and therefore don't have concrete plans to use this
data, but i imagine (and hope) that pedestrian routers could use this data
to prioritise roads with pedestrian lanes and to tell blind people on which
side of the road they should walk.

Maybe it would be helpful to set up a meeting with some organizations that
serve the visually impaired along with programmers that build routing
software. We (Taskar Center) might be able to help with that sort of
meeting, and it would be even better to have organizations from different
cultures and geographies involved as well. As-is, I think the challenge of
reliably associating paths with crosswalks is a big one for mapping for
routing for the blind.

> Thanks. The content of this page seems to be identical to this PDF
document by the FHWA i mentioned in some of my earlier messages:

Oh, you're right! Sorry I missed that!

Thanks again for raising this tagging question and proposal!

Best,

Nick

On Mon, Nov 11, 2019 at 2:02 PM Markus  wrote:

> Hi Nick,
>
> Please excuse my late reply. :(
>
> On Wed, 6 Nov 2019 at 00:53, Nick Bolten  wrote:
> >
> > ## Similarities to shoulders and an opportunity to figure out how to tag
> them.
> >
> > Would it be fair to say that the only differences between this feature
> and a shoulder are (A) it has paint designating where pedestrians should go
> and (B) it has some right-of-way implications? Because it's often the only
> pedestrian option in rural areas near me, I'd appreciate having a way to
> tag shoulders and then enhancing them with a subtag. e.g., something like
> shoulder=left/right/both + shoulder:right=pedestrian_lane.
>
> Another difference is the width: in Switzerland, pedestrian lanes are
> about 1.5 m wide and shoulders about 4.5 m. But in my opinion their

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Nick Bolten]

At the risk of going down a rabbit hole, I'm going to suggest some ways to
think about this that will hopefully spark some discussion related how this
tag could be used with pedestrian navigation.

## Similarities to shoulders and an opportunity to figure out how to tag
them.

Would it be fair to say that the only differences between this feature and
a shoulder are (A) it has paint designating where pedestrians should go and
(B) it has some right-of-way implications? Because it's often the only
pedestrian option in rural areas near me, I'd appreciate having a way to
tag shoulders and then enhancing them with a subtag. e.g., something like
shoulder=left/right/both + shoulder:right=pedestrian_lane.

## Challenges of mapping pedestrian paths as street attributes

As proposed, this tag would apply to streets. I understand the appeal -
it's a minimal change from current maps and the feature is basically just
paint on a street - but I think there are also some potential risks to
describing the pedestrian path this way that would be valuable to discuss.
Examples:

(1) Intersections, particularly ones with marked crossings.
sidewalk=left/right/no/both has difficulties with this as well. Put
yourself in the shoes of someone trying to analyze the paths a pedestrian
could take using this tag to determine that there is a path using
pedestrian lanes and a crosswalk. There is a street way (way 1) with
pedestrian_lane=right that continues through an intersection. There is a
crosswalk tagged as highway=crossing, crossing=uncontrolled on another way
that shares a node with another street way (way 2). How do you proceed and
associate these path data so that you can reliably say that a pedestrian
path exists that uses that crosswalk? I believe it will require some fairly
nerdy graph analysis I think it could be a significant hurdle for using
this data.

(2) Transitions to other pedestrian paths, such as sidewalks. Pedestrian
lanes are sometimes used as a means to have a "temporary" sidewalk-like
feature, pending some future construction of actual sidewalks. There will
be sidewalks that are half-built, then transition into a pedestrian lane.
How do we tag that situation, given a separately-mapped sidewalk?

With the above issues in mind, what would you think about allowing
highway=footway, footway=pedestrian_lane as a possibly redundant tagging
option?

## Usefulness / data consumption

Knowing where pedestrian lanes are would be very useful, in my opinion, but
the devil is always in the details. Do you have any examples of how this
data could be consumed downstream? Not saying there always has to be a data
consumer, but the exercise could reveal advantages between different
approaches.

## Other sources

A potentially helpful resource during these international comparisons:
https://www.fhwa.dot.gov/environment/bicycle_pedestrian/publications/small_towns/page05.cfm.
The FHWA defines standards in the United States.

Best,

Nick

On Fri, Nov 1, 2019 at 2:13 PM Markus  wrote:

> Hi everyone,
>
> Following the recent discussion about pedestrian lanes (marked lanes
> on a roadway, designated for pedestrians), i've now written a proposal
> page for a new key pedestrian_lane=*:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pedestrian_lane
>
> Best regards
>
> Markus
>
> ___
> 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] wheelchair = hiking

[Nick Bolten]

> 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 expect. A few have even shared strong opinions about what they
believe all/most wheelchair users care about, even though a large
proportion of wheelchair users would actually disagree (for example,
avoiding curbs).

It might be helpful to break this down into examples comparing what
information the mapper has vs. what information the tag contains.

# In the case suggested by Andreas:

The mapper knows: that hiking associations have been creating hiking paths
in Italy that are deemed wheelchair-accessible by some metric. I don't know
what the metric is, but the effort sounds great!
The tag confers: that most wheelchair users can use that path.
The disconnects:
- The mapper does not actually know that the path is wheelchair-accessible,
they are trusting an authority to make that (complex) determination.
- That authority is not stated anywhere in the tag values so we cannot go
back and reevaluate the tagging based on a new understanding of their
metrics for wheelchair accessibility.
- It is challenging to verify wheelchair=yes on the ground. Except in the
most simple cases (flat, wide, textured concrete), you'd need some kind of
evaluation form based on a study on wheelchair users and statistics on
their use of different paths/barriers.
- How would we ever update this with wheelchair=no based on a ground
survey? Is there a metric for how many wheelchair users can't use the path
and who is collecting that data?

# In a case where an individual is actually at one of the trails and can do
a ground survey:

The mapper knows: what the ground conditions are along the trail.
Potentially, some of the information to look out for: steepness, cross
slopes, rugged terrain, narrow paths, sudden uplifts, stairs,
bollards/posts, surface conditions.
The tag confers: an assessment that most wheelchair users can use that path.
The disconnects:
- The mapper is likely not doing a thorough enough survey to actually know
what percentage of wheelchair users can use it.
- If another mapper uses their own, subjective idea of what counts as
wheelchair-accessible, they could easily disagree with the assessment and
prefer wheelchair=no. Who is right?

If the map simply states wheelchair=yes, a data consumer will not know by
which process the path was evaluated and any guess will end up being wrong
in one of the examples list above.

To address this situation, I recommend keeping the distance between what
the mapper knows and what the tag implies as small as possible. In this
case, what the mappers knows is that an authority (the hiking association)
is labeling the path as wheelchair-friendly, so we need a tag that
communicates, at most, that information. For example:
wheelchair:authorized=.

Best,

Nick

On Tue, Jun 18, 2019 at 10:01 AM Markus  wrote:

> On Tue, 18 Jun 2019, 18:42 Andreas Lattmann, 
> wrote:
>
>> would be included in the relations
>>
>> I was thinking about this new tag because often particular wheelchairs
>> are used, for example: [1] [2]
>>
>> So if I insert wheelchair = yes what other tag can I use to make it clear
>> that special equipment is needed?
>>
>>
>> [1] http://www.dappertutto.org/files/montagna_natura1.jpg
>>
>> [2]
>> https://www.disabili.com/images/stories/disabiliabili/Extreme_X8/carrozzina_elettronica_per_sabbia.jpg
>
>
> If special wheelchairs are needed, i wouldn't tag the paths
> wheelchair=yes. IMO wheelchair=yes means accessible for most basic
> wheelchairs. We may need a tag for paths accessible for mountain or
> off-road wheelchairs.
>
> ___
> 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] wheelchair = hiking

[Nick Bolten]

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 not be good tags for doing this on trails. Example: I'm not
sure if anyone has evaluated whether different users consistently tag
"smoothness" the same way (a potential issue with data maintenance /
accuracy) nor whether the tag captures the information wheelchair users
need to know.

wheelchair=yes is usually an inappropriate tag for most situations because
wheelchair users tend to disagree about what paths are accessible. Factors
such as the chair they use, experience with their chair, athleticism, and
comfort with risk-taking all factor into it, so a one-size-fits-all
approach is tricky. You will find wheelchair users that are happy to ignore
an 8 cm raised curb and others who are uncomfortable with inclines flatter
than the legal limits.

I just reviewed how wheelchair=designated is documented. In terms of the
actual words in the tag, I initially thought this would be a reasonable tag
(someone has designated this path as wheelchair accessible!), but the wiki
makes me think it shouldn't be used here. The wiki states that this tag is
rarely used and that it implies specific infrastructure has been built to
support wheelchair users, which might not be the case for a path that's
been declared accessible by a particular authority.

Best,

Nick

On Tue, Jun 18, 2019 at 7:32 AM Andreas Lattmann 
wrote:

> Hi everyone,
> I don't know if it's the right mailing list.
> I would like to propose a new tag (if it is not already there).  The new
> tag is wheelchair = hiking because in Italy many associations are creating
> mountain trails for disabled people.
> It would be nice to be able to map these paths.
> Thank you
>
> Andreas Lattmann
>
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

> The zebra markings at traffic lights might be a fallback for when the
lights are turned off or not operating regularly (e.g. blinking yellow
light)

This is a good point and could potentially be relevant for disaster
response / evacuation procedures.

On Sat, May 25, 2019, 3:39 PM Martin 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 of road markings, in the presence of actual traffic
> signals, is irrelevant for how this crossing operates.
>
> I think the other definitions match up with the wiki (though they are more
> specific here than there).
>
> What does it mean for a crossing to operate and why would ground markings
> be irrelevant?
>
>
>
> The zebra markings at traffic lights might be a fallback for when the
> lights are turned off or not operating regularly (e.g. blinking yellow
> light)
>
>
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

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?
>
> Personally, I've tagged crossing=no on ways either when it's illegal
> (there's a sign saying no crossing)
>
> I add also access=no to such ways (as
> it is illegal to enter it) and add
> crossing=no on node where it crosses
> with road (or railway).
>
> I map such objects where path with
> Illegal crossing is present,
> mostly to protect mistaken mapping
> from aerial images.
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

> 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 complex: it may
be illegal (and sometimes dangerous) for a pedestrian to enter an
intersection under a "do not walk" signal, but the law can still imply
virtually all of the crosswalk statutes, including that drivers must still
yield when that pedestrian breaks the law.

One option is to just explicitly tag right of way on every crossing, but I
wouldn't ever actually help with that and I'm not entirely certain that the
data would even be useful. That seems like something better left to data
consumers, who can just know the laws for a region being serviced. If it's
really necessary to tag laws in OpenStreetMap, I'd favor tags on a regional
polygon.

Not saying you were asking for any of those things. I believe it's just the
logical conclusion to "right of way" coming up so frequently.

On Sat, May 25, 2019, 8:40 AM Mateusz Konieczny 
wrote:

>
> 24 May 2019, 23:43 by nbol...@gmail.com:
>
> > 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?
>
> Legal status/right of way as far as
> pedestrians and drivers on the road
> are concerned.
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

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

I'm going to skip the remaining, "markings don't change the interaction"
claims given they've already been addressed.

> Worth mapping for the benefit of the visually impaired, but not by
redefining current usage.

It can't be mapped under current usage. "Worth mapping" implies fixing this
tag.

> So then we need
marked_and_not_controlled_by_lights and marked_but_controlled_by_lights.
Which is fine, as long as you don't redefine current usage, because that
would cause major problems if it went through (which it almost certainly
would not).

Those tag values would be redundant with and surely deprecate
traffic_signals.

> Explain how your proposal would significantly reduce errors

It's in the wiki under the proposal. I also walked through it twice in my
response.

> Aerial mapping a new crossing with
stripes is going to result in a marked crossing either way.

Nope. If it has pedestrian signals, which marked crossings clearly can, the
current schema calls for it to be described with crossing=traffic_signals,
which erases marking information. Look at imagery outside of the UK or some
of the examples posted in other threads. And if someone maps
crossing=uncontrolled from aerial imagery of a crossing based on ground
markings, the crossing tag is set, so that crossing won't be "fixed"
through usual QA or quests based on missing data.

> Currently if I edit an existing
crossing because I see stripes in aerial imagery I see from the tag list
that it's already been marked as having lights and would have to change
that to being uncontrolled, so I do further checks (has the type of
crossing changed, can light-controlled crossings have stripes in this
jurisdiction).

The example I've given is the case where a mapper is creating a new
crossing: they're armchair mapping and can identify the markings, but
signals are hard to gauge from an aerial view.

In this case, the crossing has already been mapped. If they are truly using
the schema I've proposed, they've set crossing:signals=yes. If they set
crossing=marked as well, it doesn't erase the crossing:signals tag and data
consumers have sufficient data to present appropriate information to any
user. If we're still using crossing=traffic_signals for some reason, then
that would be an argument for using crossing:markings: don't erase
information.

> Wikipedia?  > Like https://en.wikipedia.org/wiki/Pedestrian_crossing  It
makes a distinction between signalized and unsignalized crossings.

This doesn't disagree with anything I said.

> The tag values are unclear and misleading without referring to the
documentation, which is the case of many tags, but this is how most people
interpret matters (...)

Hard disagree. If we went solely by the various responses in these threads,
I would say there is no majority opinion on their use. Example: the
definitions recently endorsed by Thorsten and yourself explicitly disagree
with the wiki because they keep involving legal right of way.

> That is the current usage, and the current implication of the wiki;
redefining it would cause big problems.

Let's look at what redefinition would be: taking tags created under one
impression of the tag's meaning and then everyone else wholesale declaring
that it now means something else. This is actually what is implied by the
wide variety of definitions we've seen in these discussions. People are
redefining each others' tags all over the place, reinterpreting what
"uncontrolled" means entirely separately from the wiki.

My proposals do the opposite: they create new tags with clearer meanings
and don't touch the old data. Addressing the mass of "bad schema" data is
left to regionally-specific efforts that could range from tasked reviews
(probably a good idea in many places, given the diversity of
interpretations of the current schema) to machine edits (something I could
certainly justify for my area).

> Suppose we wanted to replace landuse=grass with landcover=grass. (...) It
would require a mass edit (...)

It wouldn't. It could be used in some cases, but is not necessary. It's not
even appropriate if the tag being fixed was ambiguous because that calls
for manual review. There are many other tools at our disposal beyond
machine edits. MapRoulette, Street complete, a variety of QA tools. I could
create an OSM tasking manager instance to split up work in a particular
area.

Data consumers that can make sense of the current schema for pedestrians
(haven't seen one yet) can keep interpreting the old data as best they can.
They can support both during a transition, because there actually isn't any
redefinition.

> On 2.5 million POIs, that's not going to happen.

Yes, it is. That number is less impressive 

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

[Nick Bolten]

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

I've given examples for how it isn't actually solely determined by the
lights. I'll give them again.

- The delineated area of a crossing is often protected: it dictates a place
that cars shall not stop.

- Interactions go beyond right of way and signals: marking existence,
styles and their location relative to signals impact pedestrian safety.

Other impacts that are, luckily, already in their own tags:

- Audible signals for pedestrians to cross/not cross.

- Stop lines.

> Yes, it's of interest that in some areas a crossing controlled by lights
also has road markings but, unless you can show a case that those markings
make it a different type of crossing, they're cosmetic enhancements.

I'm confused. I thought we weren't going to go argue about what "controls"
things, as that's a legal construct.

I think it's good to stop thinking of crossings as types, as this is not a
globally-relevant concept. The UK has its variously-named crossings (which
now live in crossing_ref if you want to tag that) that tie together
right-of-way, controls, markings, APSs, etc, almost all of the rest of the
world doesn't. This is, in theory, why OSM deprecated those tags so long
ago. Unfortunately, the attempted solution was deeply flawed.

> I have yet to see anyone present a case where the presence or absence of
road markings at a
crossing controlled by traffic signals requires different behaviour by
either pedestrians or
traffic.

These have been offered many times. Though, again, I thought we weren't
arguing about controls.

> Road markings alone is a more difficult.case because different
jurisdictions assign different
behaviours to them.  But an important characteristic is that there are no
traffic lights.

Great, so let's map those things in separate tags.

> Acid test: explain to a child how to cross the road.  It is going to be
along the lines of "At this type of crossing you wait for the green signal
(or whatever) before you cross."  and "At this type of crossing there are
no lights, you behave in this (country-specific) way."

The use of signaled crossings also varies by regional statute. Visitors to
the UK are often confused about how to use all of the crossings, including
pelican crossings. There are, for example, pelican crossings that make the
little green person blink as a warning to not enter the intersection. This
is not how it works in other countries. For example, in my area, a similar
warning is a flashing, "do not walk" message.

> Does the presence or absence of those road markings fundamentally change
the interaction between pedestrian and traffic?

Arguing the semantics of fundamentally is going to be even worse than
"controlled", but I've given examples of how it impacts it many times.

>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

> 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 crossing:markings=yes
if it ends up the proposal) and crossing:signals=yes.

> Have you ever seen a crossing with lights AND zebra stripes?  Which of
the two takes
precedence?

Neither. They are separate properties of the crossing and can communicate
different information. We can describe the number of lanes a street has as
well as it's speed limit without having to decide which takes precedent,
let's use that same idea for crossings.

> However, if you include the zig-zag lines before and after the crossing
(...)

Maybe the proposal should be updated to be even clearer: a marked crossing
is one where the pedestrian crossing space is, specifically, visibly
outlined with designated markings.

> then you have the dangerous situation that the map leads people to think
that a light-controlled crossing (...) is a marked crossing (like a zebra)
where pedestrians have priority.

With orthogonal crossing tags for markings and pedestrian signals, such a
crossing could and should be tagged as having signals. The situation
described appears to be a tagging error: someone said the crossing was
marked when it wasn't and also neglected to tag the pedestrian signals.
Situations like this, where signals get neglected, are actually easier
under the current schema due to markings being mappable from aerial imagery
while signals usually aren't.

> But I suspect this is Nick;s interpretation
of what a marked crossing is - there are some marks on the road (I can't
make sense of his
proposals without that interpretation).

My interpretation is the boringest one: a marked crossing is a marked
crossing. It's described roughly the same way by transit agencies,
Wikipedia, dictionaries, etc.: crossing with visual markings designating
the pedestrian space for crossing the street.

> That's why it's a bad idea to tag in a way that could lead somebody to
conclude that a crossing with signals is a marked crossing.

If the crossing is marked, it's marked. Failing to tag the existence of
traffic signals is simply a mapping error that can occur under both the
current schema and the proposed ones. It is also, as argued on the proposal
page, an error that is easier to make and persist under the current schema.
If you tagged a crossing with crossing=marked, you could still use
MapRoylette/Street complete/other QA tool to fill in crossing:signals
values.

> Should we say that light-controlled crossings are marked?  Nope.
traffic_signals and marking
are NOT orthogonal, they are mutually exclusive alternatives.  Well, in the
UK they are - it's possible there's some country where you can have
zebra-light-controlled crossings.

Pelican crossings tend to have a dotted line outlining the pedestrian space
of the crossing...

Outside the UK it's common to find pedestrian-signaled crossings with
virtually any marking style. Some are shown on the proposal page.

On Fri, May 24, 2019, 12:54 PM Paul Allen  wrote:

>
> On Fri, 24 May 2019 at 20:06,  wrote:
>
>>
>>
>> As you said, what others suggested, and what would be a welcome addition,
>> is to leave the existing tag untouched (it seems to work fine for most
>> people except you), and tag the special exception where a
>> crossing=traffic_signals doesn’t have road markings with
>> crossing:markings=no
>>
>
> I think this is the nub of the issue: what is meant by crossing markings.
> I think Nick's interpretation
> is different from that of some on this list.  However, your paragraph
> seems to conform to Nick's
> interpretation.  What do you mean by a crossing with traffic signals AND
> with road markings?
>
> Hint: crossing=unmarked is defined as being a crossing without road
> markings or traffic
> lights.  Have you ever seen a crossing with lights AND zebra stripes?
> Which of the two takes
> precedence?  Motorists have right of way if their signal is green;
> pedestrians have absolute
> right of way just by stepping on the crossing irrespective of the lights.
> Does not compute.
>
> However, if you include the zig-zag lines before and after the crossing
> that do NOT define
> the interaction of pedestrian and motorist but impose conditions on the
> motorist alone (cannot
> park, cannot wait, cannot load or unload, etc) as being
> crossing_markings=yes then you have
> the dangerous situation that the map leads people to think that a
> light-controlled crossing
> (pedestrians and motorists are controlled by the lights) is a marked
> crossing (like a zebra)
> where pedestrians have priority.  See the problem?  But I suspect this is
> Nick;s interpretation
> of what a marked crossing is - there are some marks on the road (I can't
> make sense of his
> proposals without that interpretation).
>
> I don't consider the zig-zag 

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

[Nick Bolten]

Hi all

I appreciate the discussions about tagging crossing - more examples and
local usages are important! If possible, though, I'd appreciate feedback on
crossing=marked/unmarked vs crossing:markings=yes/no.

A current rundown:

Pro crossing=marked/unmarked:

- Already in use in the wild. No need to update some editors.
- Fewer tags to deprecate if namespace is fully orthogonalized.

Pro crossing:markings=yes/no:

- Describes markings as attribute of crossings, not a contentious "type" of
crossing.
- Could potentially live alongside current non-orthogonal schema (good for
community acceptance, potentially bad for long-term consensus)
- Even more taggable crossing attributes would be in a crossing:*=*
namespace. Easier to find/organize/understand.

I think both fix the problem of orthogonality equally well.

Thoughts? Any other advantages to one vs. the other?

On Fri, May 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 were
> accepted, crossing=traffic_signals/uncontrolled/unmarked would become two
> tags: crossing=marked/unmarked and crossing:signals=yes/no.
>
> Both Tobias and Masteuz have made an interesting suggestions about
> crossing=marked/unmarked, which is that it still has the problem of
> declaring that a crossing has a "type" (marked or unmarked) whereas it
> could be considered another attribute, just like having traffic signals.
>
> To give background, I initially chose crossing=marked/unmarked because (1)
> both are in use in the wild, (2) the schema is equally non-ambiguous, and
> (3) if I had to decide on the "type" of a crossing, I'd separate those with
> no indication of their presence aside from regionally-varying conventions
> (which is currently mapped as crossing=unmarked) from all the rest. But
> point 3 isn't completely true: a crossing that has only signals but no
> clear ground markings is less abstract/"fictitious" than a crossing
> established solely by convention, with no infrastructure saying where to
> cross.
>
> In contrast, crossing:markings=yes/no would let us avoid making decisions
> about the "type" of crossing entirely. If it were swapped out for the
> crossing=marked/unmarked proposal, it would result in this schema for
> crossings:
>
> crossing=no (for crossings that should be specifically called out as not
> doable/allowed)
> crossing:markings=yes/no
> crossing:signals=yes/no
> crossing_ref=* (unchanged)
>
> There has also been the suggestion that crossing=* could be left
> unchanged, and these two new tags added as alternatives. I like that this
> potentially avoids conflict and therefore makes it easier to start mapping
> this data separately, but think it would result in competing schemas and
> redundant data.
>
> So, what are you thoughts? Is crossing:markings=yes/no better than
> crossing=marked/unmarked? Are there any downsides/upsides I've missed? If
> crossing:markings were preferable, what should happen to the crossing=* tag?
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

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 trouble finding any real regulations saying so, so
>> take that with a grain of salt. I think someone from Austin, TX told me
>> that once...
>>
>> I believe the primary stated purpose of bars on a crosswalk is increased
>> visibility to cars.
>>
>> That's what I've read [1] although the markings tend to make pedestrians
> less observant. Also note that their should also be a stop behind line, as
> someone in Santa Clara has been adding. The crosswalk should be after the
> stop behind line.
>
> Another good source, for the US at least, is the Manual on Traffic Control
> Devices [2]. Crosswalks start around pg 385.
>
>
> [1]
> http://highstreethill.org/wp-content/uploads/2013/09/DPW-Crosswalk-Policy.pdf
> [2]  https://mutcd.fhwa.dot.gov/pdfs/2009r1r2/mutcd2009r1r2edition.pdf
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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] Constructive communication medium (was:Filter bubbles in OSM)

[Nick Bolten]

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
> flexible and open. In discourse's case, it's all the same
> language/framework as openstreetmap.org (rails), which might be a plus.
> The ability to easily modify the platform would provide the opportunity to
> create systematic improvements and funnel activism in productive directions.
>
> Example 1: One potential action item during/after a discussion should be
> to update the wiki. A slightly ambitious dev could integrate discourse with
> a ticketing system without too much effort. Someone's trying to build one
> here already: https://github.com/angusmcleod/discourse-tickets.
>
> Example 2: You can use tags. This would help with some of the noise
> inherent in the mailing list and make it easier to discover relevant past
> discussions.
>
> Best,
>
> Nick
>
>
>
>
> On Fri, May 24, 2019 at 5:29 PM Tobias Zwick  wrote:
>
>>
>> 1. Thesis: Mailing lists (and to a lesser degree, classical forums)
>> promote a culture of dissent. This is because if people just agree, they
>> tend towards not answering at all on these mediums because they do not want
>> to litter the conversation when they don't have something own to say. So,
>> as someone posing a topic that does not develop into a long thread (like
>> this one), you never know if it was due to that nobody is interested, or if
>> everyone is like "ok sounds good".
>> Now, what we actually want to achieve when starting a discussion on the
>> mailing list or forums to get so some kind of result with which all or most
>> people are actually fine with, to a consent.
>>
>> 1.1 A Solution: In real life, if you agree but have nothing more to say,
>> you simply show that by nodding or clapping. While, if you don't, you voice
>> this and state your reasons. So, I think simply a  "sounds good" button,
>> aka  "like" (facebook) or  "clap" (medium.com) will make a big
>> difference. (Did you know that a "thanks" button was introduced in our wiki
>> recently? Use it!) This will make it much easier also for people who
>> usually just lurk on the mailing list and don't feel they want to actively
>> participate in the discussion to give the people who write some feedback.
>>
>> 2. Get more "normies" on board. I think it can only be good for the
>> overall communication culture to get more people on board.
>>
>> 2.1 Linked from the main page. Was already mentioned before in this
>> thread somewhere - the communication medium should be linked directly from
>> the openstreetmap.org start page to get more people on board. See for
>> example https://kotlinlang.org/community/ on how it could look like
>>
>> 2.2. OAuth. Users should simply be able to use their openstreetmap login,
>> no further registration required.
>>
>> 3. Moderation and Edits.
>>
>> 3.1 Edit: Every now and then, people derail verbally, it happens. We are
>> all humans. So, to be able to edit your post after you realized that you
>> shouldn't have said something inflammatory, abusive or stupid, is important.
>>
>> 3.2 Report: And sometimes, a person will just not cool down and fail to
>> see that he is being abusive, then this needs to be moderated in order to
>> keep the discussion factual. An abusive comment on the mailing list will
>> stay forever, while one on a well moderated medium will only be seen by
>> those that see it before it is reported. Having an abusive comment just
>> stay there, even if it is rebuked, broadcasts a nasty odor and poisons the
>> discussion. This is the "toxicity" that pops up time and again here. Don't
>> underestimate emotions. Just remember how this discussion here started (
>> https://lists.openstreetmap.org/pipermail/tagging/2019-May/045501.html
>> ). So, my conclusion, *good* moderation is most important really.
>>
>> 3.3 Moderation: Sometimes discussions go off topic or branch off.
>> Especially if using a threaded forum or a mailing list. Then, it should be
>> possible to put those branches into own threads.
>>
>> 3.x All three are not possible on a mailing list, but at least in the
>> forum.
>>
>> All those points I mentioned are nothing new or outrageous. Any modern
>> conversation software will have all of this.
>>
>> For example F-Droid (Android OpenSource Software Repository) and Kotlin
>&

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

[Nick Bolten]

tructively. You can
> see that happen pretty often. How do we make that happen more?
> >
> > The discussion pretty quickly drifted from considering technical
> solutions to behaviors, toxicity, cultural differences etc. etc., I have
> read this a thousand times. I don't see how this brings us forward.
> >
> > But I was waiting for a cue like this. Thank you for that, 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 impact on the discussion culture, and also on
> the ability of us, to find something like a consensus.
> >
> > Please, everyone, feel invited in this branch of this thread to give
> some input. I have some ideas myself so I will start with that, but in the
> next message. :-)
> >
> > Tobias
> >
> > On 25/05/2019 00:47, Nick Bolten wrote:
> >>> What I'd suggest is that (much as I suggested before) everyone tries
> to understand how points of view can be misunderstood and how conversations
> >> can go downhill, when each side believes that there is malice on
> the other.  This thread is actually a pretty good example of it ...
> >>
> >> Yes, of course. It's important to ask questions and assume the best,
> when possible.
> >>
> >> Sometimes, the insults are as subtle as a sledgehammer. It's not
> miscommunication, it's a free-for-all, and it turns away new users. I've
> seen it happen in real time.
> >>
> >>> The initial "OSM needs an alternative for community tagging
> discussions" message in the other thread said a number of things that
> surely were not intended as
> >> personal attacks but were directed at a place with which people felt
> a sense of community, and therefore _were_ interpreted as direct
> personal attacks.  I'd suggest everyone asks themselves "If I write this,
> how will it be interpreted?  How will it make other people feel?".
> >>
> >> This point is well-taken. I should have contextualized my points so
> that it was clear that I'm objecting to a particular atmosphere and want it
> to improve. I do believe there are fundamental problems with the mailing
> list format that contribute to that atmosphere.
> >>
> >>> The next thing that I'd suggest is when someone has said something out
> of order (or that seems at first glance to be out of order) to wait a
> >> bit before replying.  An initial retort will be be unlikely to
> contain the clearest thought out response.  If you've managed to get into
> an argument with someone and the other person behaves in a
> particularly childish way, you can rely on someone else to tell them that
> what they are saying is silly (as happened in this thread when Clifford
> Snow intervened).
> >>
> >> Of course, but this won't help new users asking questions. They will
> still have a negative experience. This is still (in theory) a
> volunteer-driven effort, so that really matters. They can (and do) just
> leave. You can see that the main dev of the most popular editor has already
> given up on these lists for very similar reasons. That's why this is
> relevant: that's a surprisingly reasonable response, so how can we fix it?
> How can we interface properly and decrease alienation?
> >>
> >> Finally, while it is surely helpful when certain behavior is called out
> as unacceptable, and it's appreciated, it doesn't happen nearly often
> enough to establish a minimum sense of decorum.
> >>
> >>> Finally, (and this is one for British politicians as well) if it feels
> like everyone's ganging up on you and no-one seems to agree, stop, take
> >> a step back and try and draw a thread between what "everyone" seems
> to be saying.
> >>
> >> Oh, I think "ganging up" is fine so long as it's civil. That would be
> something like consensus - sounds great!
> >>
> >> I may not be making my point about disagreement clear. I love
> disagreement: it's healthy, it's productive, there's no other way to get
> consensus. New users should be met with it, when appropriate. We should all
> have robust discussions about differing views to establish the meaning of
> tags.
> >>
> >> However, it's hard to see how "establish the meaning of tags" is served
> when there are 3, 4, 5, 6, etc absolutist, often insulting, yet also
> incompatible, opinions offered. That forces the visitor into this position:
> ignore at least N - 1 of those people and either 

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

[Nick Bolten]

Well, now I'm having trouble finding any real regulations saying so, so
take that with a grain of salt. I think someone from Austin, TX told me
that once...

I believe the primary stated purpose of bars on a crosswalk is increased
visibility to cars.

On Fri, May 24, 2019 at 5:32 PM Jmapb  wrote:

> 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
> > lines that outline the crossing.
>
> Right, same -- stripes, not zebra in the crossing_ref=zebra sense.
>
> So if they question is "do stripes on a crossing in the USA mean
> anything at all, versus just painted bars?" and the answer is "yes, in
> Texas" then thanks, I've learned something today.
>
> J
>
>
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

> 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 cross here, but there is no special legal status to it

This definition disagrees with what the wiki states as well as the
face-value semantics of the value: crossing=unmarked is just about whether
the crossing has markings (it doesn't). There is actually nothing about the
current schema that says anything about legal status, which is one of the
reason the 'uncontrolled' tag has lead to confusiong, as in the real world
that's a legal thing. What hierarchy exists is about infrastructure in all
cases.

> You can cross here, and it is a designated crossing place with some kind
of special legal status (that in most jurisdictions prioritizes pedestrians
over vehicles, specifics depend on local jurisdiction)

I believe the legal status part is also questionable in this case, which is
crossing=uncontrolled. The wiki states that it's about markings and there
are cases where the legal distinction between marked and unmarked crossings
is minimal (possibly nonexistent?).

> You can cross here, and there is a traffic signal that tells you exactly
when you can and can’t cross that you have to follow

This matches my best understanding of the wiki.

The strategy of using on-the-ground-describable features is a good one.
Legal status varies by country, region, metro area, municipal regulations
and can hopefully be predicted based on those ground conditions. I'd be
interested to hear about exceptions, though - where legal status can't be
inferred from location and ground surveyed features.



On Fri, May 24, 2019 at 5:10 PM  wrote:

>
>
>
>
> *From:* Warin <61sundow...@gmail.com>
> *Sent:* Saturday, 25 May 2019 09:49
> *To:* tagging@openstreetmap.org
> *Subject:* Re: [Tagging] Non-orthogonal crossing=* tag proposals:
> crossing=marked/unmarked vs crossing:markings=yes/no
>
>
>
> On 25/05/19 07:32, Paul Allen wrote:
>
> On Fri, 24 May 2019 at 22:12, Kevin Kenny  wrote:
>
>
> Yeah, there really are combinations around here:
>
> does it have signs?
> does it have traffic signals?
> does it have specific pedestrian-facing traffic signals? (Some
> intersections just have you cross at the same time as motor traffic in
> your direction rolls)
> are the traffic signals pedestrian- or cyclist-controlled? (Is there a
> button for you to push?)
> does it have pavement markings?
>
>
> We also have;
> tactile paving - a sequence of small raised bumps/dots on the paving that
> can be sensed by walkers/wheelchairs
> audio warning - the button also has an audio output that signals when the
> traffic lights state to allow pedestrian crossing, and just before the
> pedestrian crossing closes.
>
> And none of that matters for the broad classification that the crossing=*
> key does, which is:
>
>
>
>- You can’t cross here
>
>
>
>- You can cross here, but there is no special legal status to it
>
>
>
>- You can cross here, and it is a designated crossing place with some
>kind of special legal status (that in most jurisdictions prioritizes
>pedestrians over vehicles, specifics depend on local jurisdiction)
>
>
>
>- You can cross here, and there is a traffic signal that tells you
>exactly when you can and can’t cross that you have to follow
>
>
>
> The labels chosen for these 4 categories are : no, unmarked, uncontrolled,
> traffic_signals. But they may as well have been a, b, c, d. Don’t try to
> interpret anything more into the label.
>
>
>
> These are the 4 different mutually exclusive types of crossings that need
> to be distinguished. Additional tags can provide further details, but don’t
> fundamentally change the type of crossing from one of these 4.
>
>
>
> In different jurisdictions, there may be multiple legally categorized
> variations of these 4 broad types. That’s what the crossing_ref tag is for.
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

> 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 while stopped.

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 lines that outline
the crossing. I have poor internet access at the moment, or I'd provide a
source.

On Fri, May 24, 2019 at 3:03 PM Jmapb  wrote:

> On 5/24/2019 5:27 PM, Shawn K. Quinn wrote:
>
> (I'm not aware of anywhere in the USA where there are stripes without
>> traffic signs/signals. I'm sure this exists somewhere but if I saw it I'd
>> think that a sign was missing.)
>>
>> J
>>
>
> There is at least one such crossing near the Museum of Fine Arts, Houston
> (1001 Bissonnet Street).
>
> Do you happen to know what the legal implication is, if any?
> ___
> 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] solving iD conflict (was: pointlessly inflamatory title)

[Nick Bolten]

I don't believe there is any purpose being served by this back-and-forth. I
could kind of justify it for a bit in that it's demonstrating my original
points about decorum, but that's a dead horse now.

I think drawn-out rehashings of a particular proposal thread should
probably go in that thread, 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 (...)
>>
>>
>> Nevertheless, I said low vision.
>>
>
> Potatoes, potahtoes.  Actually, now I think about it, that's not a good
> analogy.  Here's what you said:
>
> Anyways, that's a strange way to frame "mapping something I don't care
> about". How is it obsessive? I've already listed several important use
> cases, so I will be blunt: do you think people with low vision are
> irrelevant and don't matter? Is this an ableist community? Do pedestrians
> getting struck by cars not matter? Is it okay that they die?
>
> So, according to your correction, I don't just hate the legally blind, I
> hate people with "low vision," a
> far lower bar than the one I assumed you intended.  My hatred for humanity
> has been greatly
> extended, it seems.
>
> > You implied it.
>>
>> I don't believe I did, but I apologize if that's the case.
>>
>
> And  I apologize for saying your behaviour seemed obsessive.  However,
> back then I did not
> know why you were so eager to push us down a particular path when so many
> felt (and still feel)
> it unnecessary.  That doesn't mean I agree with your reasons for
> disrupting a couple of
> million tags, now I know what is driving this push, because I don't.  But
> at least I know it's not
> obsession driving it.
>
> > It sure didn't read that way to me. Or, I suspect, to others.  Not in
>> the context of the rest of the paragraph which set the tone for your
>> "rhetorical question."  Read the whole paragraph again. I can quote it back
>> to you again, if necessary.
>>
>> Sure, but on the thread for that proposal, please.
>>
>
> Ooops.  I did it here.  Because I'm responding here.  And I don't know
> which other thread you mean,
> since so many threads have been spawned about this.
>
>>
>> > I'm willing to assume you're arguing in good faith but that you're bad
>> at it.  I'm willing to assume that you may be right but that you're bad at
>> getting your points across.  I'm even willing to assume that I'm too stupid
>> to understand you, but judging by the enthusiastic lack of support for your
>> proposals, so are most people here, which doesn't bode well for your
>> proposals being adopted or used correctly if they are adopted.
>>
>> I don't see how responses like this serve any purpose. Seems like a good
>> example of the toxicity I'm saying we should try to do away with, as a
>> community.
>>
>
> It serves a purpose because the toxicity came with you.  It wasn't here
> before.  It seems that anything
> that runs counter to your viewpoint is toxic.  Anyone who points out that
> we didn't have any
> noticeable toxicity before you appeared is toxic.  In short, you appear to
> be using "toxicity" to silence
> anyone who disagrees with you, a behaviour which some of us feel actually
> is toxic.  I was willing
> to assume you're bad at communicating rather than behaving as you do as a
> deliberate strategy
> to silence criticism.  That position is becoming less tenable for me as
> the thread continues.
>
> 3. When I search my email, nothing comes up recently for "condescending"
>> aside from this particular thread. I mean, there have been some pretty
>> clearly condescending replies from various individuals in the past week or
>> two, but I don't believe I used that language.
>>
>
> I can't find it now.  Which could mean memory problems on my part.  Or
> worse.  In which case,
> my apologies.
>
> 4. I fail to see how describing a response as condescending 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?
>>
>
> You are no more wrong (or right) to point it out than I am to point out
> where your posts appear to
> be personal attacks.  I don't think it's doing much for the list in
> general and I suspect many are
> bored with it.  But at least one person here is having difficulty
> communicating in a way that doesn't
> arouse ire in at least one other person.
>
> --
> 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

Re: [Tagging] Filter bubbles in OSM

[Nick Bolten]

> What I'd suggest is that (much as I suggested before) everyone tries
to understand how points of view can be misunderstood and how conversations
can go downhill, when each side believes that there is malice on
the other.  This thread is actually a pretty good example of it ...

Yes, of course. It's important to ask questions and assume the best, when
possible.

Sometimes, the insults are as subtle as a sledgehammer. It's not
miscommunication, it's a free-for-all, and it turns away new users. I've
seen it happen in real time.

> The initial "OSM needs an alternative for community tagging discussions"
message in the other thread said a number of things that surely were not
intended as
personal attacks but were directed at a place with which people felt
a sense of community, and therefore _were_ interpreted as direct
personal attacks.  I'd suggest everyone asks themselves "If I write this,
how will it be interpreted?  How will it make other people feel?".

This point is well-taken. I should have contextualized my points so that it
was clear that I'm objecting to a particular atmosphere and want it to
improve. I do believe there are fundamental problems with the mailing list
format that contribute to that atmosphere.

> The next thing that I'd suggest is when someone has said something out of
order (or that seems at first glance to be out of order) to wait a
bit before replying.  An initial retort will be be unlikely to contain the
clearest thought out response.  If you've managed to get into an argument
with someone and the other person behaves in a particularly childish way,
you can rely on someone else to tell them that what they are saying is
silly (as happened in this thread when Clifford Snow intervened).

Of course, but this won't help new users asking questions. They will still
have a negative experience. This is still (in theory) a volunteer-driven
effort, so that really matters. They can (and do) just leave. You can see
that the main dev of the most popular editor has already given up on these
lists for very similar reasons. That's why this is relevant: that's a
surprisingly reasonable response, so how can we fix it? How can we
interface properly and decrease alienation?

Finally, while it is surely helpful when certain behavior is called out as
unacceptable, and it's appreciated, it doesn't happen nearly often enough
to establish a minimum sense of decorum.

> Finally, (and this is one for British politicians as well) if it feels
like everyone's ganging up on you and no-one seems to agree, stop, take
a step back and try and draw a thread between what "everyone" seems to be
saying.

Oh, I think "ganging up" is fine so long as it's civil. That would be
something like consensus - sounds great!

I may not be making my point about disagreement clear. I love disagreement:
it's healthy, it's productive, there's no other way to get consensus. New
users should be met with it, when appropriate. We should all have robust
discussions about differing views to establish the meaning of tags.

However, it's hard to see how "establish the meaning of tags" is served
when there are 3, 4, 5, 6, etc absolutist, often insulting, yet also
incompatible, opinions offered. That forces the visitor into this position:
ignore at least N - 1 of those people and either give up or plod along
hoping that those positions can be, in some way, taken back. I'm not simply
talking about proposals: if you ask, "how do I tag this?" and are in that
situation, you'll come away thinking that nobody knows the answer, but some
people will be very annoyed if you try to do it your way.

Sometimes, it goes the other way - the good way. There's consensus, or if
disagreement, the different options are offered constructively. You can see
that happen pretty often. How do we make that happen more?

On 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 hasn't happened on its own.
> >
> What I'd suggest is that (much as I suggested before) everyone tries to
> understand how points of view can be misunderstood and how conversations
> can go downhill, when each side believes that there is malice on the
> other.  This thread is actually a pretty good example of it ...
>
> Firstly, it helps if everyone tries to understand how "community" works
> both within and without OSM.  People attach themselves to communities
> both electronic and physical, and when you attack the place where the
> community is based to some extent you attack the community itself and
> the people in it.  For example, if I talk about the town down the road
> in a derogatory way people from that town are going to think I'm 

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

[Nick Bolten]

> Legally, it is.  "Blind" in the UK legally covers a wide range of visual
impairment (...)

Nevertheless, I said low vision.

> You implied it.

I don't believe I did, but I apologize if that's the case.

> It sure didn't read that way to me. Or, I suspect, to others.  Not in the
context of the rest of the paragraph which set the tone for your
"rhetorical question."  Read the whole paragraph again. I can quote it back
to you again, if necessary.

Sure, but on the thread for that proposal, please.

> I'm willing to assume you're arguing in good faith but that you're bad at
it.  I'm willing to assume that you may be right but that you're bad at
getting your points across.  I'm even willing to assume that I'm too stupid
to understand you, but judging by the enthusiastic lack of support for your
proposals, so are most people here, which doesn't bode well for your
proposals being adopted or used correctly if they are adopted.

I don't see how responses like this serve any purpose. Seems like a good
example of the toxicity I'm saying we should try to do away with, as a
community.

> It was another of your anonymous "one person was condescending to me"
side-swipes.  You do a lot of that.  I'm willing to assume you think it
makes you less confrontational, but I think
otherwise.  Because everyone can work out who you're talking about but you
deny that person the ability to easily respond without risking a deflection
like "I never called YOU condescending,
I just said there were condescending people."  A veiled insult is still an
insult.

1. There were several people asking for an explicit reference / evidence
for my claims. They did not "work it out" and find your interpretation.
2. I wasn't thinking of you, at all, in any of my bullet points. You've
taken that on yourself, assuming they're about you. In fact, I wasn't
thinking about anyone in particular - I did that on purpose. I have zero
interest in picking on any individual. I think I've been pretty clear on
that.
3. When I search my email, nothing comes up recently for "condescending"
aside from this particular thread. I mean, there have been some pretty
clearly condescending replies from various individuals in the past week or
two, but I don't believe I used that language.
4. I fail to see how describing a response as condescending 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.  I noticed when you implied that I hated blind people.
>>
>> 1) I referred to people with low vision. That is not the same as blind.
>>
>
> Legally, it is.  "Blind" in the UK legally covers a wide range of visual
> impairment:
>
> The *legal* definition of *blindness* varies from country to country but
> most nations, including the *UK* define it as having a visual acuity of
> worse than 20 in 200. ... The limit usually imposed is a visual field of 20
> degrees or less, which is about 10% of the visual field of someone with
> 'normal' eyesight.
>
> It's been a long time since "blind" meant "no vision whatsoever."  It's
> sometimes considered more
> polite to refer to the visually impaired, but that is more typing when you
> are referring to people who
> are legally blind.  BTW, I am visually impaired but not legally blind (or
> close to it).  If you wear
> spectacles, you are visually impaired (I have other visual problems
> besides wearing spectacles).
> It is not incorrect to use "blind" here.
>
> 2) I didn't say you hated anyone.
>>
>
> You implied it.  Read what you wrote carefully.  About me not caring if
> blind (visually-impaired
> if you insist) people die crossing the road.  I'd have to hate people to
> not care if they live or die.
> At best I'd have to be sociopathic.
>
> 3) The question was rhetorical: the premise is that you don't actually
>> believe that.
>>
>
> It sure didn't read that way to me. Or, I suspect, to others.  Not in the
> context of the rest of
> the paragraph which set the tone for your "rhetorical question."  Read the
> whole paragraph again.
> I can quote it back to you again, if necessary.
>
>
>> The hope was that those making these claims would be jostled into
>> confronting the issue head-on. Unfortunately, there was no response - this
>> could've been clarified.
>>
>
> I'm willing to assume you're arguing in good faith but that you're bad at
> it.  I'm willing to
> assume that you may be right but that you're bad at getting your points
> across.  I'm even
> willing to assume that I'm too 

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

[Nick Bolten]

> 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 seeming inability
to understand them onto all mappers.

If you look at these threads, there are tons of people issuing completely
incompatible interpretations of these tags. I'm not alone, at all, in these
opinions, at all. In fact, even announcing that crossing=uncontrolled only
makes a statement about ground markings seemed to generate quite a lot of
disagreement, as many focus on the "controlled" vs. "uncontrolled" aspect
of the values rather than the wiki-stated meaning. How shall we consolidate
these differently-mapped tags, in the wild? As a data consumer, If I
interpret crossing=uncontrolled to mean crossing=marked, it seems that I
will be wrong a not insignificant amount of the time amount of the time.

Anyways, please keep insults to yourself, they are not helpful.

On Fri, May 24, 2019 at 1:58 PM  wrote:

>
>
> > What can be done here is to basically define that the different
> 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).
>
>
>
> I'm interested in this, in theory, but doesn't it actually imply
> redefining those 2.5 million tags? Previous mappers were never told these
> meanings, nor do I think they had them in mind. Redefining those tags
> post-hoc is actually a harder problem to address via editors / QA / data
> consumption than deprecation.
>
>
>
> Nothing I said changes the meaning of any existing tags. You seem to be
> one of very few people that is incapable of understanding the existing
> tags, and you shouldn’t be projecting your seeming inability to understand
> them onto all mappers.
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

> 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 disconnected islands and everyone would be
unhappy. There needs to be some tag representing the pedestrian network
that spans across the street, which is what crossing=unmarked seems to be
for. Maybe it's not an we need a new tag?

On Fri, May 24, 2019 at 1:26 PM  wrote:

> > Does any of this change in a jurisdiction where there is an implied
> > crossing at every intersection unless posted otherwise?
>
> 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).
>
> > What sort of feature gets tagged crossing=no? Does one draw a line
> > or node to represent the footway that isn't there?
> It's a tag that should be rarely used, and it's primary purpose is if
> there is a context in which people may think that there should be crossing
> here, to indicated that there really isn't one. Mainly to keep armchair
> mappers from later coming along and thinking "hey, someone forgot to tag
> the crossing" and add some other crossing=* value.
>
> It's important to mention that crossing=no does NOT get a highway=crossing
> tag, to prevent data consumer that only look for highway=crossing and not
> interpret the crossing=* value from wrongly thinking there is a crossing
> here.
>
>
>
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

> 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 impact
pedestrian safety, even when traffic signals are present.

On Fri, May 24, 2019 at 1:23 PM Mateusz Konieczny 
wrote:

>
>
>
> 24 May 2019, 22:16 by pla16...@gmail.com:
>
> On Fri, 24 May 2019 at 21:09,  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 of road markings, in the presence of actual traffic
> signals, is irrelevant for how this crossing operates.
>
>
> Yep.
>
> That was how I interpreted it all until the Polish contingent threw a
> spanner in the works.  I'm
> waiting for a response to see if it's a big spanner or a little spanner.
>
> 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).
>
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

> 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 with footway=crossing. Example: "this is an
unmarked crossing on a highway and there's an alternative marked crossing 5
meters to the East".

In terms of jurisdictions, in my neck of the woods, all corners are,
legally, crossings. So, there are many places to create crossing=unmarked.

On Fri, May 24, 2019 at 1:15 PM Kevin Kenny  wrote:

> On Fri, May 24, 2019 at 4:09 PM  wrote:
> > The way I see it:
>
> > crossing=no – crossing here is not legal/possible
>
> > crossing=unmarked – there are no road markings (or traffic signals) that
> indicate this is a designated crossing, but based on other factors, it’s a
> location where pedestrians common cross, e.g. because of lowered kerbs, or
> because the sidewalk on one side of the road ended
>
> > crossing=uncontrolled – there are road markings indicating this is a
> designated pedestrian crossing, but no traffic signals that explicitly tell
> pedestrians when they have to stop
>
> > 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.
>
> Does any of this change in a jurisdiction where there is an implied
> crossing at every intersection unless posted otherwise?
>
> What sort of feature gets tagged crossing=no? Does one draw a line or
> node to represent the footway that isn't there?
>
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

> 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 definitions match up with the wiki (though they are more
specific here than there).

What does it mean for a crossing to operate and why would ground markings
be irrelevant? The answers to these questions would be definitions of how
to use these tags, if we came to consensus.

For example, my interpretation is that in this case, "operate" is that
contentious idea of "control" of traffic and pedestrians. This is
reinforced by the example of "tells pedestrians when to stop". But maybe
you're thinking of something different. If that is the case, we're back to
square 1: some tags are about ground conditions (unmarked/uncontrolled),
others are about "control" and lights (traffic_signals).

I can't interpret this schema, as a data consumer attempting to route
pedestrians. Too much is left unknown. As a mapper and organizer of mapping
parties, I still have an almost impossible task in front of me explaining
these tags and what to prioritize (ground condition vs. undocumented
"control").

On Fri, May 24, 2019 at 1:09 PM  wrote:

> The way I see it:
>
>
>
> crossing=no – crossing here is not legal/possible
>
>
>
> crossing=unmarked – there are no road markings (or traffic signals) that
> indicate this is a designated crossing, but based on other factors, it’s a
> location where pedestrians common cross, e.g. because of lowered kerbs, or
> because the sidewalk on one side of the road ended
>
>
>
> crossing=uncontrolled – there are road markings indicating this is a
> designated pedestrian crossing, but no traffic signals that explicitly tell
> pedestrians when they have to stop
>
>
>
> 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.
>
>
>
> All other crossing=* values that are currently in use are either simply
> undefined in meaning, or, like the ones listed in the wiki (zebra, pelican,
> toucan, …) are shorthand for one of the 4 values above + implicit values
> for additional tags.
>
>
>
>
>
>
>
> *From:* Paul Allen 
> *Sent:* Saturday, 25 May 2019 05:53
> *To:* Tag discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] Non-orthogonal crossing=* tag proposals:
> crossing=marked/unmarked vs crossing:markings=yes/no
>
>
>
>
>
> On Fri, 24 May 2019 at 20:06,  wrote:
>
>
>
> As you said, what others suggested, and what would be a welcome addition,
> is to leave the existing tag untouched (it seems to work fine for most
> people except you), and tag the special exception where a
> crossing=traffic_signals doesn’t have road markings with
> crossing:markings=no
>
>
>
> I think this is the nub of the issue: what is meant by crossing markings.
> I think Nick's interpretation
>
> is different from that of some on this list.  However, your paragraph
> seems to conform to Nick's
>
> interpretation.  What do you mean by a crossing with traffic signals AND
> with road markings?
>
>
>
> Hint: crossing=unmarked is defined as being a crossing without road
> markings or traffic
>
> lights.  Have you ever seen a crossing with lights AND zebra stripes?
> Which of the two takes
>
> precedence?  Motorists have right of way if their signal is green;
> pedestrians have absolute
>
> right of way just by stepping on the crossing irrespective of the lights.
> Does not compute.
>
>
>
> However, if you include the zig-zag lines before and after the crossing
> that do NOT define
>
> the interaction of pedestrian and motorist but impose conditions on the
> motorist alone (cannot
>
> park, cannot wait, cannot load or unload, etc) as being
> crossing_markings=yes then you have
>
> the dangerous situation that the map leads people to think that a
> light-controlled crossing
>
> (pedestrians and motorists are controlled by the lights) is a marked
> crossing (like a zebra)
>
> where pedestrians have priority.  See the problem?  But I suspect this is
> Nick;s interpretation
>
> of what a marked crossing is - there are some marks on the road (I can't
> make sense of his
>
> proposals without that interpretation).
>
>
>
> I don't consider the zig-zag markings before or after the crossing to be
> relevant to tagging the
>
> crossing.  Any more than I consider a white line down the centre of the
> road to mean that it's
>
> a marked crossing.  Those markings do not define pedestrian/motorist
> interaction.
>
>
>
> I agree with Nick (that will surprise him) that these things matter.
> Somebody with macular
>
> degeneration may have lost all of their central vision.  It may be far
> easier to spot a 

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

[Nick Bolten]

> This is not in line with hat others have suggested (...)

I think it's in line with what Mateusz suggested, but sorry if I
mischaracterized your ideas.

Also, apologies to you both because I somehow managed to screw up both
names.

> and invalidating 2.5 million existing crossing=* tags (everything with a
value different from yes/no) is a complete no go.

Here's my attempt at restating this as a downside: using
crossing:markings=yes/no combined with deprecating crossing=* tags is even
worse, as it deprecates even more tags.

> As you said, what others suggested, and what would be a welcome addition,
is to leave the existing tag untouched (it seems to work fine for most
people except you), and tag the special exception where a
crossing=traffic_signals doesn’t have road markings with
crossing:markings=no

I wouldn't call this a special exception, as traffic_signals does not
currently imply markings. Some people on this list kind of sort of say it
does, but the wiki doesn't. I don't think any editors do either, but I
guess I haven't checked every single one. There's multiple things wrong
with the current tagging schema - the others still apply if you leave
crossing=* unchanged.

> What can be done here is to basically define that the different
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).

I'm interested in this, in theory, but doesn't it actually imply redefining
those 2.5 million tags? Previous mappers were never told these meanings,
nor do I think they had them in mind. Redefining those tags post-hoc is
actually a harder problem to address via editors / QA / data consumption
than deprecation.


On Fri, May 24, 2019 at 12:06 PM  wrote:

> This is not in line with hat others have suggested, and invalidating 2.5
> million existing crossing=* tags (everything with a value different from
> yes/no) is a complete no go.
>
>
>
> As you said, what others suggested, and what would be a welcome addition,
> is to leave the existing tag untouched (it seems to work fine for most
> people except you), and tag the special exception where a
> crossing=traffic_signals doesn’t have road markings with
> crossing:markings=no
>
>
>
> What can be done here is to basically define that the different 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 discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* [Tagging] Non-orthogonal crossing=* tag proposals:
> crossing=marked/unmarked vs crossing:markings=yes/no
>
>
>
> In contrast, crossing:markings=yes/no would let us avoid making decisions
> about the "type" of crossing entirely. If it were swapped out for the
> crossing=marked/unmarked proposal, it would result in this schema for
> crossings:
>
>
>
> crossing=no (for crossings that should be specifically called out as not
> doable/allowed)
>
> crossing:markings=yes/no
>
> crossing:signals=yes/no
>
> crossing_ref=* (unchanged)
>
>
>
> There has also been the suggestion that crossing=* could be left
> unchanged, and these two new tags added as alternatives. I like that this
> potentially avoids conflict and therefore makes it easier to start mapping
> this data separately, but think it would result in competing schemas and
> redundant data.
>
>
>
> So, what are you thoughts? Is crossing:markings=yes/no better than
> crossing=marked/unmarked? Are there any downsides/upsides I've missed? If
> crossing:markings were preferable, what should happen to the crossing=* tag?
> ___
> 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] Filter bubbles in OSM

[Nick Bolten]

How do you propose visitors of the mailing list address responses like
this, Andy? I'm not being sassy: I honestly want to know.

Should it be ignored, becoming implicitly acceptable to the community?

Should it be called out, creating a long-running petty thread?

I've tried both. Maybe there's 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
>> those who suss out the semi-official, non-obvious place to ask questions.
>>
>
> A toxic environment, eh?  Doesn't that imply that some of those posting
> here are toxic?  Wouldn't
> accusing people of being toxic itself be toxic behaviour?  Oh, only if you
> mention them by name,
> eh?
>
> In any case, I didn't notice any toxicity about this environment until you
> showed up.  Strange, that.
>
> --
> 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

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

[Nick Bolten]

> Yes.  I noticed when you implied that I hated blind people.

1) I referred to people with low vision. That is not the same as blind.
2) I didn't say you hated anyone.
3) The question was rhetorical: the premise is that you don't actually
believe that. The hope was that those making these claims would be jostled
into confronting the issue head-on. Unfortunately, there was no response -
this could've been clarified.

> I noticed when you called me condescending.

I don't believe I've ever called anyone condescending.

The rest of the response seems like something to discuss on other threads.

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 me
> condescending.
>
>
> claims about how mapping these things don't matter, despite the use cases
> I had repeatedly gone over. I felt that directness was necessary, because
> that is the implication of these facts: (1) low vision individuals need
> this information to navigate and pedestrians are safer at marked crossings,
> and (2) it was repeatedly stated that mapping these things isn't important.
>
>
> These things are important.  It's just that some of us think your logic is
> wrong.
>
> They were asked as questions, and there was no response.
>>
>
> YET.  Your points seem (to me) to be invalid and self-contradictory at
> times.  I have finally
> managed to come up with a perversely-pedantic interpretation of "markings"
> that would
> make your position consistent, but still deeply flawed (and, in fact, your
> position would
> put those with visual impairment at greater risk).  And, given your
> behaviour here, is there
> any point in me attempting to take this further?  Most people here don't
> seem to see the
> problems you claim to exist, so why bother?
>
> BTW, if we're going to harp on points that were not responded to, what
> about you poisoning the well
> by implying I hate blind people?
>
> --
> 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

Re: [Tagging] Filter bubbles in OSM

[Nick Bolten]

> I don't doubt your last sentence at all - but these people are all
(in some sense) people like you.  They're people that you know
personally well enough to meet personally or exchange emails with, or from
a geographically-centred community (Slack) that you have both joined.

Of course. Though the people that have self-selected outside of this
mailing list are on an international scope and often have no more obviously
in common than being an OSM enthusiast with the time (and resources) to
attend an event.

> OSM is a global project.  By that very definition there will be people
who don't share your views, approach or language, yet it the map belongs
to everyone, and sometimes we have to find ways to talk to each
other because we need to talk about stuff that applies to everyone.

That's exactly right, and one reason why toxicity is incredibly
counterproductive: there's enough challenges in communicating on a global
scale, already.

I don't believe any of the points I've made wouldn't apply to an
international audience. Nobody is incapable of not going after someone else
personally. The lack of decorum is not a language problem. I speak one of
the non-English languages that is often used to excuse this behavior. I've
visited countries where it is spoken, I've visited other communities in
that language. It's not in any way intrinsic to that language or associated
cultures.

> The problem with "an alternative for community tagging discussions
outside of these mailing lists ... that have a reasonable,
community-oriented code of conduct" is that it sounds like you want to set
rules about who is allowed to participate in those discussions and who is
not, and that people that would be allowed to participate are (in some
sense) "people like you".

I'm not sure why anyone assumes this is the case. I want no part in
moderation - if anything, that's where I should be criticized! Not even
going to take on mod duties, what's he complaining about?

I'm suggesting that there be a community-oriented code of conduct. I say
this because self-regulation is failing - would if I could not have to
suggest it. As an example, the SOTM has one:
https://2019.stateofthemap.org/codeofconduct/. Its purpose is to avoid
harassment and promote an inclusive community, though other conferences
tend to include more language that extends beyond harassment.

The idea is: maybe the primary place people are supposed to go for feedback
on tags, sometimes their first experience with the community, shouldn't be
alienating. I want more people mapping OSM and I want to tell them to use
this resource. I'm conflicted on that recommendation.

> To be clear, this isn't just about iD, or mailing lists, or Slack, or USA
mappers vs German mappers.  I've seen a few examples around the
world recently with DWG hat on where a bunch of people decided to do X, but
some other people somehow didn't know about it and complained.
> The first bunch of people could perhaps have tried to make things a
bit more public, but they probably didn't realise they hadn't done this
as they were using the communications channel that "everyone" uses (in
a few specific examples I can think of that was Telegram, Slack, or
a subforum at forum.osm.org).

Exactly! There are many places to go and none appear to be any more
official than the next - a side-effect of a distributed community with no
central, open, discoverable forum. Perhaps that situation could've been
avoided with better community discussion tools and UX on openstreetmap.org.

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
those who suss out the semi-official, non-obvious place to ask questions.

> The second bunch of people complain that something happened that they
weren't expecting and that it was wrong/undiscussed/some other sort of
problem.  Everyone's acting in good
faith - they're trying to do the right thing but somehow
communication doesn't quite occur.  What everyone (including me) needs to
try and do is to say "OK, that didn't quite work; how do we try and make it
work better next time?"  I'm sure that the answer to that last question
isn't choosing who can and who can't be part of the discussion.

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 hasn't happened 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 actually use and that have
> > a reasonable, community-oriented code of conduct. I have talked to 10X
> > more people about my `crossing` proposals outside of this mailing list
> > (in-p

Re: [Tagging] solving iD conflict

[Nick Bolten]

> Nick, making it personal also means making it about yourself. You've been
self referential numerous times: "My experience with this mailing list"

It doesn't, actually. "Making it personal" means unduly making it about
someone else, personally. Making them have a personal stake.

But even if it did mean, "it involves an individual in any way, including
vaguely sharing one's experience", which is how I'm interpreting this
claim, I'm confused about why this justifies the lack of decorum.

> If you come looking for an argument, the chances are you'll 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/2019 18:56, Nick Bolten wrote:
> >> But Nick, /you/ made it personal.
> > No, I didn't. I named nobody.
>
> Nick, making it personal also means making it about yourself. You've
> been self referential numerous times:
> "My experience with this mailing list"
>
> > And yet, this thread is devolving into personal attacks. I couldn't have
> > asked for a better demonstration of my points about decorum.
>
> If you come looking for an argument, the chances are you'll find one.
> Especially with these non specific accusations which few here can
> recognise.
>
> DaveF
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] solving iD conflict

[Nick Bolten]

> But Nick, /you/ made it personal.

No, I didn't. I named nobody. I kept it fairly vague. I made no references
to any threads. I've actually explicitly avoided making it personal.

And yet, this thread is devolving into personal attacks. I couldn't have
asked for a better demonstration of my points about decorum.

On Fri, May 24, 2019 at 10:50 AM Dave F via Tagging <
tagging@openstreetmap.org> wrote:

> On 24/05/2019 18:29, Nick Bolten wrote:
> > Notice the extent to which personalisms are being launched.
>
> But Nick, /you/ made it personal. I haven't seen any of the behaviour
> you claim. You probably need to grow some thicker skin.
>
> If you're looking for sycophantic agreement with any point you make,
> then this, or most other OSM forums probably isn't for you.
> Disagreements & discussive arguments are part & parcel of an open forum.
>
> DaveF
>
> ___
> 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] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Nick Bolten]

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 were
accepted, crossing=traffic_signals/uncontrolled/unmarked would become two
tags: crossing=marked/unmarked and crossing:signals=yes/no.

Both Tobias and Masteuz have made an interesting suggestions about
crossing=marked/unmarked, which is that it still has the problem of
declaring that a crossing has a "type" (marked or unmarked) whereas it
could be considered another attribute, just like having traffic signals.

To give background, I initially chose crossing=marked/unmarked because (1)
both are in use in the wild, (2) the schema is equally non-ambiguous, and
(3) if I had to decide on the "type" of a crossing, I'd separate those with
no indication of their presence aside from regionally-varying conventions
(which is currently mapped as crossing=unmarked) from all the rest. But
point 3 isn't completely true: a crossing that has only signals but no
clear ground markings is less abstract/"fictitious" than a crossing
established solely by convention, with no infrastructure saying where to
cross.

In contrast, crossing:markings=yes/no would let us avoid making decisions
about the "type" of crossing entirely. If it were swapped out for the
crossing=marked/unmarked proposal, it would result in this schema for
crossings:

crossing=no (for crossings that should be specifically called out as not
doable/allowed)
crossing:markings=yes/no
crossing:signals=yes/no
crossing_ref=* (unchanged)

There has also been the suggestion that crossing=* could be left unchanged,
and these two new tags added as alternatives. I like that this potentially
avoids conflict and therefore makes it easier to start mapping this data
separately, but think it would result in competing schemas and redundant
data.

So, what are you thoughts? Is crossing:markings=yes/no better than
crossing=marked/unmarked? Are there any downsides/upsides I've missed? If
crossing:markings were preferable, what should happen to the crossing=* tag?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

> What you mean by that? Edit wiki once it is useful, link back it at
mailing list, update if there is something wrong with it?

Yes, exactly! And sometimes the thing that's "wrong with it" is just that
it's vague, does not adequately address exceptions, or doesn't have enough
examples for people in various parts of the world to know whether it's
relevant to their infrastructure.

Is there a "gold standard" wiki page for a particular tag that could be
used to figure out what might be missing other pages and turn that into
action items?

On Fri, May 24, 2019 at 10:26 AM Mateusz Konieczny 
wrote:

> 24 May 2019, 18:56 by nbol...@gmail.com:
>
> Each of these steps could be improved by having better systems in place
> for communication and specification. For example: have wiki editing action
> items at the end of most discussions
>
> What you mean by that? Edit wiki once it is useful, link back it at
> mailing list, update
> if there is something wrong with it?
>
> (note: it is not necessary to reach agreement before doing this,
> documenting
> diverse opinions/situations is very useful)
> ___
> 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] solving iD conflict (was: pointlessly inflamatory title)

[Nick Bolten]

Notice the extent to which personalisms are being launched. I'm not going
to participate in that, aside to clarify that the quote regarding use cases
of crossings and their relevance to pedestrian safety and people with
disabilities was in response to both a personal accusation ("obsessive")
and several claims about how mapping these things don't matter, despite the
use cases I had repeatedly gone over. I felt that directness was necessary,
because that is the implication of these facts: (1) low vision individuals
need this information to navigate and pedestrians are safer at marked
crossings, and (2) it was repeatedly stated that mapping these things isn't
important.

They were asked as questions, and there was no response.

On Fri, May 24, 2019 at 10:18 AM Paul Allen  wrote:

> On Fri, 24 May 2019 at 18:04, Nick Bolten  wrote:
>
>> This is a pretty good example of some of that unhelpful behavior I
>> mentioned...
>>
>
> Projection much?
>
> There is a toxic habit that's far too common on this mailing list to
>> speculate about bad intentions and then state them as if they are fact. It
>> serves no purpose other than to divide and denigrate and has no place in a
>> community-oriented project.
>>
>
> YOU were the one who claimed, without evidence, that others had accused
> you of acting in bad faith.
> YOU MADE THAT CLAIM.
>
> I wondered why you had done so because, in another sub-thread, you implied
> that I was disagreeing
> with you because I hated people with visual impairments.  Here's the quote
> from that thread:
>
> Anyways, that's a strange way to frame "mapping something I don't care
> about". How is it obsessive? I've already listed several important use
> cases, so I will be blunt: do you think people with low vision are
> irrelevant and don't matter? Is this an ableist community? Do pedestrians
> getting struck by cars not matter? Is it okay that they die?
>
> That looks very much to me like you were demonizing those who disagreed
> with you.  Poisoning the
> well.  It sure looks that way.  Whether you intended it to or not.  It
> came across as you accusing me
> of hating the visually impaired, or at least not caring if they live or
> die.  People should ignore
> anything I say, because I hate the blind.
>
> If people have been accusing you of acting in bad faith (I've yet to see
> evidence of that) then I
> can understand why if that is how you typically interact with them.  But
> everybody is marching out
> of step except you, so lets have a moderated forum where you are the
> moderator.
>
> --
> 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

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

[Nick Bolten]

This is a pretty good example of some of that unhelpful behavior I
mentioned...

There is a toxic habit that's far too common on this mailing list to
speculate about bad intentions and then state them as if they are fact. It
serves no purpose other than to divide and denigrate and has no place in a
community-oriented project.

On Fri, May 24, 2019, 4:55 AM Paul Allen  wrote:

>
> On Fri, 24 May 2019 at 09:56, Simon Poole  wrote:
>
>>
>> I think if you investigate, you will find that invariably such complaints
>> (including the predictably, invariably going to be used,"toxic"), originate
>> with people that didn't get their way, or associates of them ("didn't get
>> their way" as in: there was a substantial body of opinions that disagreed
>> with what ever they were proposing).
>>
>
> And some of those people will then go on to say that a particular forum
> [where nobody agreed with
> them, because everybody else is marching out of step] needs to be replaced
> with a different type
> of forum.  A moderated forum.  It is never explicitly stated, but may be
> inferred, that they'd like
> those moderators to be people who agree with them, or for they,
> themselves, to actually be
> the moderators.
>
> For bonus points, they may state (without providing names or evidence)
> that people on the
> forum accuse them of acting in bad faith.  Which may be true, even though
> I don't recall
> seeing that particular accusation on this list while I've been here.  Or
> it may be subtly
> poisoning the well: those who disagree with me are obviously acting in bad
> faith because they
> accuse me of acting in bad faith [but no evidence of such accusations is
> provided].
>
> --
> 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

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

[Nick Bolten]

You make good points. Creating tools for editing OSM is a bit of a
nightmare already (we've had many students try and fail) before having to
grapple with tag decisions.

Here's what you have to do when figuring out how to implement most tags
beyond the few "easy" ones like highway=primary:

- Visit the wiki (you need to know about the wiki being there place to go).
Hope there's an entry (there might not be).

- Attempt to interpret the meaning of an almost certainly underspecified
schema.

- Look at some examples of it in use, hope they are representative.

- If you're so inclined, contact this list. Receive strong opinions (at
best) incompatible not just with one another, but the wiki and the use
cases found.

- Make people angry with your decision.

Each of these steps could be improved by having better systems in place for
communication and specification. For example: have wiki editing action
items at the end of most discussions

On Fri, May 24, 2019, 3:58 AM Florian Lohoff  wrote:

>
> Hola Nick,
>
> On Thu, May 23, 2019 at 03:59:17PM -0700, Nick Bolten wrote:
> > So far as I can tell, the topic on this mailing list (as it often is) is
> to
> > gripe about how the iD editor isn't listening to this mailing list (and
>
> You can broaden that up - All tools around OSM. Same applies hier to all
> editors and at least QA tools. As soon as you point your finger to
> something "This is broken - please fix" you interpret OSM data which
> is likely just a personal or partial view.
>
> I am running a lot of QA stuff and a lot of that is only my personal
> opinion and i am getting beaten with a stick about those things aswell.
>
> The more people use your tools the broader your consensus must be in
> interpreting data.
>
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

> iD is not a general topic here, but with the tendency of introducing new
tags via presets, sometimes even where there are established alternative
tags (...)

Sorry, I misstated my meaning. Instead of "the topic of this mailing list"
it should say, "the topic of this thread".

> I guess sooner or later, the iD presets will become a separate project,
where a group of people will have a say, and not just one (or now 2)
people, and then these discussions will likely go away, but again, it is
not something that takes up considerably much space here.

Without some systemic reforms, I anticipate that that will make things even
worse. Instead of sniping at developers, it will be sniping between
coalitions. The sniping shouldn't happen at all: we should keep it civil
and constructive.

On Fri, May 24, 2019, 2:24 AM Martin Koppenhoefer 
wrote:

>
>
> Am Fr., 24. Mai 2019 um 01:00 Uhr schrieb Nick Bolten :
>
>> So far as I can tell, the topic on this mailing list (as it often is) is
>> to gripe about how the iD editor isn't listening to this mailing list (and
>> sometimes on Github issues).
>>
>
>
> iD is not a general topic here, but with the tendency of introducing new
> tags via presets, sometimes even where there are established alternative
> tags, and the developer deciding on his own even with many different people
> suggesting the same changes in the Github issue tracker, and with the
> developer dismissing any significance for the community documentation (wiki
> and other), it is natural that from time to time it becomes a topic here.
> With contributors being mostly volunteers, it will often take some time
> until things are changed, until it itches sufficiently to start scratching.
> I guess sooner or later, the iD presets will become a separate project,
> where a group of people will have a say, and not just one (or now 2)
> people, and then these discussions will likely go away, but again, it is
> not something that takes up considerably much space here.
>
> 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] solving iD conflict (was: pointlessly inflamatory title)

[Nick Bolten]

> I think if you investigate, you will find that invariably such complaints
(including the predictably, invariably going to be used,"toxic"), originate
with people that didn't get their way, or associates of them ("didn't get
their way" as in: there was a substantial body of opinions that disagreed
with what ever they were proposing).

I've "gotten my way" in threads that had toxic elements before, so no, I
won't find that.

> If you are addressing a very diverse group, disagreement is the name of
the game.

Disagreement isn't one of the problems I listed. The closest is this:
receiving absolutely incompatible opinions that are presented as
authoritative and certain. They are a serious challenge to the usefulness
of this list. It requires you to disregard several positions - the claims
aren't really up for debate, as presented - and given the nonexistent
standards of decorum, that often goes poorly.

> PS: I think you owe us proof of this rather extraordinary claim > - You
will probably be insulted at some point, potentially sworn at.

I strongly prefer to not go after individuals (which is what that would
turn into), as that doesn't serve any purpose but division and pettiness.
If you ask privately I'd be happy to send you examples.

On Fri, May 24, 2019, 1:56 AM Simon Poole  wrote:

>
> Am 24.05.2019 um 00:59 schrieb Nick Bolten:
>
> > The talk ML might be a better spot for this, this topic has already
> strayed quite far from the original topic. (And maybe start the topic on a
> more positive prospect instead of with a rant ;-)
>
> So far as I can tell, the topic on this mailing list (as it often is) is
> to gripe about how the iD editor isn't listening to this mailing list (and
> sometimes on Github issues). I've listed some reasons as to why someone
> might not listen to this mailing list. Reasons that I've heard echoed many
> times in various venues...
>
> I think if you investigate, you will find that invariably such complaints
> (including the predictably, invariably going to be used,"toxic"), originate
> with people that didn't get their way, or associates of them ("didn't get
> their way" as in: there was a substantial body of opinions that disagreed
> with what ever they were proposing).
>
> If you are addressing a very diverse group, disagreement is the name of
> the game. People that can't with live that will tend to gyrate towards more
> controlled and selective environments, particularly if they can control the
> discourse as they can do for example on a github repo, or a slack channel.
> Not to mention that on any of the larger more diverse forums, that is any
> of the international, and topical mailing lists, forums, IRC channels, you
> will have a large selection of different discussion cultures, and will
> experience everything from people directly calling a spade a spade, to
> criticism being packaged in multiple layers of cotton wool.
>
> Simon
>
> PS: I think you owe us proof of this rather extraordinary claim > - You
> will probably be insulted at some point, potentially sworn at.
>
> On Thu, May 23, 2019 at 3:05 PM Tobias Zwick  wrote:
>
>> These are some valid points, and I also have some input to that, but are
>> you sure you want to discuss this on the tagging ML? The talk ML might be a
>> better spot for this, this topic has already strayed quite far from the
>> original topic. (And maybe start the topic on a more positive prospect
>> instead 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 after sending the message).
>> >
>> > OSM needs an alternative for community tagging discussions outside of
>> these mailing lists. Ones that people will actually use and that have a
>> reasonable, community-oriented code of conduct. I have talked to 10X more
>> people about my `crossing` proposals outside of this mailing list
>> (in-person, personal emails, slack, etc.) and the differences could not be
>> more stark:
>> >
>> > # My experiences with OSMers in other contexts:
>> > - Very friendly, all focused on making maps better, highly motivated to
>> donate their time to help others via the map.
>> > - Disagreements are pleasant. Both sides acknowledge the other point of
>> view and usually come around to a compromise.
>> > - There is interest in knowing more: lots of questions back and forth.
>> > - Objections are qualified and polite.
>> > - 10s-100s of people giving feedback on a single ide

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

[Nick Bolten]

> Every person on this mailing list participates in many of these kinds of
discussions (...)

I have never seen one where there was someone suggesting a change to a tag
and at least some of those negative bullet points didn't apply.

> I think you should attempt to apply a little of that "acknowledging the
other point of view" (...)

I understand becoming frustrated with repetition and bad data. That
frustration should be channeled into fixing the UX problem that leads to
it, such as discoverability of import documents. I don't understand the
habit of lashing out at new members and/or new ideas, given the goal of
making a community-focused project.

> That is often repeated and I guess most people can confirm that people
act differently in person than on mailing lists.

I've also communicated via direct emails and via slack. This is the only
place where it gets toxic almost immediately.

> if you go around telling everyone what a snake pit "the mailing lists"
are then people will either not join them, or join them just waiting to see
their expectations confirmed.

I've personally talked to more people who avoid the mailing lists,
particularly this one, than those who generally respond here. The sentiment
is popular and it's not great for community building.

> In general, our project isn't a top-down strictly managed project with a
controlled decision-making process. This means that many things have to
be discussed over and over, and the community generally doesn't speak with
one voice.

This is how it should theoretically work. I don't think it's how it
actually works. It's driven by editing software and targeted mapping
efforts, not mailing list discussions of which most mappers are unaware.

But I don't mind discussing things over and over - that wasn't one of the
negatives list.

> Now you're going off on a tangent. Passwords are not required at all to
use the mailing list.

Serious technical issues with the mailing list isn't a tangent, the topic
is mailing list vs. an editor's decisions. It undermines the credibility of
this mailing list when its use involves terrible security practices.
Registering for the mailing list, which is required for real-time
participation, sends passwords in plain text. This is a massive security
issue and the entire process feels unprofessional and dodgy. When I've
recommended subscribing to others, I always remind them of this problem.

> The current forum system works and has moderators and etiquette
guidelines (this depends on each sub-forum, they are not global).
Discoverability isn't much better than mailing lists IMHO.

Discoverability is very bad all over the place for OSM - there is a
desperate need for a "get involved" link on the landing page that orients
the community.

But discoverability is far better for the forums than here, as they are
crawled by search engines. Whenever I see someone suggest reviewing a
discussion from 9 months ago, I'm reminded of Douglas Adams: "It was on
display in the bottom of a locked filing cabinet stuck in a disused
lavatory with a sign on the door saying ‘Beware of the Leopard.'"

Anywho, I think the length of my replies have distracted from my point:
what is the goal of this mailing list and 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 mailing lists.
>
> It might; that doesn't invalidate points made on these mailing lists
> though!
>
> > # My experiences with OSMers in other contexts:
> > - Very friendly, all focused on making maps better, highly motivated to
> > donate their time to help others via the map.
> > - Disagreements are pleasant. Both sides acknowledge the other point of
> > view and usually come around to a compromise.
> > - There is interest in knowing more: lots of questions back and forth.
> > - Objections are qualified and polite.
> > - 10s-100s of people giving feedback on a single idea.
>
> Every person on this mailing list participates in many of these kinds of
> discussions, in addition to being on the mailing list (just in case you
> were thinking there were two different kinds of people, the friendly
> people and the mailing list people; this is not the case).
>
> > When I was mentoring a group of students a few years ago, several were
> > offended by the condescending and insulting responses they received on
> > this mailing list, all because they suggested making a coherent way of
> > combining existing tags into a pedestrian schema and doing a
> > carefully-vetted import.
>
> I think you should attempt to apply a little of that "acknowledging the
> other point 

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

[Nick Bolten]

> The talk ML might be a better spot for this, this topic has already
strayed quite far from the original topic. (And maybe start the topic on a
more positive prospect instead of with a rant ;-)

So far as I can tell, the topic on this mailing list (as it often is) is to
gripe about how the iD editor isn't listening to this mailing list (and
sometimes on Github issues). I've listed some reasons as to why someone
might not listen to this mailing list. Reasons that I've heard echoed many
times in various venues...

On Thu, May 23, 2019 at 3:05 PM Tobias Zwick  wrote:

> These are some valid points, and I also have some input to that, but are
> you sure you want to discuss this on the tagging ML? The talk ML might be a
> better spot for this, this topic has already strayed quite far from the
> original topic. (And maybe start the topic on a more positive prospect
> instead 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 after sending the message).
> >
> > OSM needs an alternative for community tagging discussions outside of
> these mailing lists. Ones that people will actually use and that have a
> reasonable, community-oriented code of conduct. I have talked to 10X more
> people about my `crossing` proposals outside of this mailing list
> (in-person, personal emails, slack, etc.) and the differences could not be
> more stark:
> >
> > # My experiences with OSMers in other contexts:
> > - Very friendly, all focused on making maps better, highly motivated to
> donate their time to help others via the map.
> > - Disagreements are pleasant. Both sides acknowledge the other point of
> view and usually come around to a compromise.
> > - There is interest in knowing more: lots of questions back and forth.
> > - Objections are qualified and polite.
> > - 10s-100s of people giving feedback on a single idea.
> >
> > # My experience with this mailing list:
> > - Quick to exasperate.
> > - You will be assumed to be coming to the table in bad faith.
> > - You will probably be insulted at some point, potentially sworn at.
> > - The same 8 or so people respond to posts out of a community of tens of
> thousands of people, companies, non-profits, etc.
> > - The odd situation of absolute certainty in completely incompatible
> opinions from those that do respond.
> > - Difficult for people to discover. How do we know that the opinions
> shared here are in any way representative of the community, given that so
> few discover + participate in it?
> > - Difficult to filter for relevance. Have to set up email filters and/or
> specialized search queries.
> > - Zero real synchronization with OSM editors, the only way people add
> data to the map. Blame doled out everywhere, but very little in the way of
> collaboration, no real venue for doing so (see previous bullet points).
> >
> > Focusing on the idea of being an "arbiter", does that sound like a good
> way to figure out which tags are good/acceptable?
> >
> > When I was mentoring a group of students a few years ago, several were
> offended by the condescending and insulting responses they received on this
> mailing list, all because they suggested making a coherent way of combining
> existing tags into a pedestrian schema and doing a carefully-vetted import.
> The import was so carefully-vetted that we later realized it wasn't even
> really an import, but this didn't stop there being several insulting
> accusations from several long-term OSMers on these lists. Those students
> were motivated by helping other people and spent literal months attempting
> to gather enough information from underspecified tagging standards and
> would have been put off the community entirely if it weren't for the
> project's momentum and much more productive and friendly interactions with
> local OSMers. I think it's probably a good thing that it's so hard to even
> know that there is a mailing list, as users have a negative experience.
> >
> > To boot, there are technical problems solved by virtually every other
> messaging system:
> > - Difficult to discover.
> > - Virtually impossible for new users to join recent discussions - they
> need to have subscribed to the list first.
> > - Discovering old discussions is difficult, requires some nerdy prowess.
> > - Terrible security practices. Passwords sent in plain text over email.
> No encryption. I was almost put off the mailing list entirely when I saw
> this. Completely unacceptable.
> >
> > Gripes aside, 

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

[Nick Bolten]

> Don't you think that an accusation without a proof (link to mailing list
archive where I can re-read the discussion that happened at that time)
makes your claims more substantial?

Yes, it would substantiate the claim. It would also increase tensions, so
I'm not going to dive into that unless 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 table in bad faith.
> > - You will probably be insulted at some point, potentially sworn at.
> > - The same 8 or so people respond to posts out of a community of tens of
> > thousands of people, companies, non-profits, etc.
> > - The odd situation of absolute certainty in completely incompatible
> > opinions from those that do respond.
> > - Difficult for people to discover. How do we know that the opinions
> shared
> > here are in any way representative of the community, given that so few
> > discover + participate in it?
> > - Difficult to filter for relevance. Have to set up email filters and/or
> > specialized search queries.
> > - Zero real synchronization with OSM editors, the only way people add
> data
> > to the map. Blame doled out everywhere, but very little in the way of
> > collaboration, no real venue for doing so (see previous bullet points).
> >
> > Focusing on the idea of being an "arbiter", does that sound like a good
> way
> > to figure out which tags are good/acceptable?
> >
> > When I was mentoring a group of students a few years ago, several were
> > offended by the condescending and insulting responses they received on
> this
> > mailing list, all because they suggested making a coherent way of
> combining
> > existing tags into a pedestrian schema and doing a carefully-vetted
> import.
> > The import was so carefully-vetted that we later realized it wasn't even
> > really an import, but this didn't stop there being several insulting
> > accusations from several long-term OSMers on these lists. Those students
> > were motivated by helping other people and spent literal months
> attempting
> > to gather enough information from underspecified tagging standards and
> > would have been put off the community entirely if it weren't for the
> > project's momentum and much more productive and friendly interactions
> with
> > local OSMers. I think it's probably a good thing that it's so hard to
> even
> > know that there is a mailing list, as users have a negative experience.
>
> Your criticism might have some true points and I am happy that is a bit
> more elaborated than a simple "mailing lists are bad and a toxic space".
> Don't you think that an accusation without a proof (link to mailing list
> archive where I can re-read the discussion that happened at that time)
> makes your claims more substantial?
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

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 bus halts, I'd say
> platform, but this is just a sidewalk.
> That we map such a node with public_transport=platform/bus=yes doesn't
> make it a platform. That's just convention since the PT v2 scheme appeared.
>
> Polyglot
>
> On Fri, May 24, 2019 at 12:20 AM Graeme Fitzpatrick 
> wrote:
>
>>
>>
>> On Fri, 24 May 2019 at 04:49, Dave F via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>>
>>> Platform should only be tagged when their is a *physical* object of a
>>> raise platform, not just an imaginary area of pavement.
>>>
>>
>> Sorry, but do you mean that this:
>> https://www.google.com/maps/@-28.0841684,153.4150288,3a,75y,46.69h,72.55t/data=!3m6!1e1!3m4!1s4hTF-eOoQp3yhcCIfyJelw!2e0!7i13312!8i6656
>> is *not* a public_transport=platform, which iD defines highway=bus_stop
>> as?
>>
>> If not, then what is it?
>>
>> Thanks
>>
>> Graeme
>> ___
>> 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] solving iD conflict (was: pointlessly inflamatory title)

[Nick Bolten]

> 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 lists. Ones that people will actually use and that have a
reasonable, community-oriented code of conduct. I have talked to 10X more
people about my `crossing` proposals outside of this mailing list
(in-person, personal emails, slack, etc.) and the differences could not be
more stark:

# My experiences with OSMers in other contexts:
- Very friendly, all focused on making maps better, highly motivated to
donate their time to help others via the map.
- Disagreements are pleasant. Both sides acknowledge the other point of
view and usually come around to a compromise.
- There is interest in knowing more: lots of questions back and forth.
- Objections are qualified and polite.
- 10s-100s of people giving feedback on a single idea.

# My experience with this mailing list:
- Quick to exasperate.
- You will be assumed to be coming to the table in bad faith.
- You will probably be insulted at some point, potentially sworn at.
- The same 8 or so people respond to posts out of a community of tens of
thousands of people, companies, non-profits, etc.
- The odd situation of absolute certainty in completely incompatible
opinions from those that do respond.
- Difficult for people to discover. How do we know that the opinions shared
here are in any way representative of the community, given that so few
discover + participate in it?
- Difficult to filter for relevance. Have to set up email filters and/or
specialized search queries.
- Zero real synchronization with OSM editors, the only way people add data
to the map. Blame doled out everywhere, but very little in the way of
collaboration, no real venue for doing so (see previous bullet points).

Focusing on the idea of being an "arbiter", does that sound like a good way
to figure out which tags are good/acceptable?

When I was mentoring a group of students a few years ago, several were
offended by the condescending and insulting responses they received on this
mailing list, all because they suggested making a coherent way of combining
existing tags into a pedestrian schema and doing a carefully-vetted import.
The import was so carefully-vetted that we later realized it wasn't even
really an import, but this didn't stop there being several insulting
accusations from several long-term OSMers on these lists. Those students
were motivated by helping other people and spent literal months attempting
to gather enough information from underspecified tagging standards and
would have been put off the community entirely if it weren't for the
project's momentum and much more productive and friendly interactions with
local OSMers. I think it's probably a good thing that it's so hard to even
know that there is a mailing list, as users have a negative experience.

To boot, there are technical problems solved by virtually every other
messaging system:
- Difficult to discover.
- Virtually impossible for new users to join recent discussions - they need
to have subscribed to the list first.
- Discovering old discussions is difficult, requires some nerdy prowess.
- Terrible security practices. Passwords sent in plain text over email. No
encryption. I was almost put off the mailing list entirely when I saw this.
Completely unacceptable.

Gripes aside, I have a suggestion: move these discussions to a real forum
system, properly organized around regional/topic-specific/tagging
discussions. It could be a revamped https://forum.openstreetmap.org/ or
something fancier and slack-like (like riot chat). Have actual moderators
and code of conduct. The current mode of communication is systematically
flawed.

On Thu, May 23, 2019 at 12:06 PM Mateusz Konieczny 
wrote:

> 23 May 2019, 18:32 by o...@westnordost.de:
>
> reverse this development.
>
> 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).
>
> I had to rewrite this last paragraph several times, but, well, I hope this
> does not come across the wrong way...
> it can certainly not continue like this, so ... why not interview him,
> honestly and with open outcome, how should the collaboration and
> communication in OSM happen in the future from his point of view? Would he
> rather feel relieved or rather feel betrayed if the gatekeeping
> (~deployment) is done by other people? Does he really feel alienated
> (because I assumed it) from the community and if yes, why? And most
> importantly, what would it take to reverse this?
>
> +1, though it would be tricky to find someone both interested in doing
> this, with time to do that,
> and not already involved in a poor way
> 

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

[Nick Bolten]

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 that
segment of infrastructure is and only choose one based on subjective
priorities: they should be able to clearly describe both simultaneously.

highway=platform effectively rules out highway=footway, hence the conflict.

I have never seen *=platform features consumed for any purpose other than
being a destination in routing software. Does anyone have examples of other
use cases?

On Thu, May 23, 2019, 10:50 AM Allroads  wrote:

> For me it is highway=platform, ID, is doing it wrong.
>
> In a discussion, I drawn out a visualisation.
>
> https://i.postimg.cc/wxJcG6bH/bushaltehaltekominvulling1.png
>
> Allroads.
>
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

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
> restrictions? I'd like to know how, as a data consumer, I should reliably
> interpret existing platforms without the tag added by iD.
>
> Please excuse the bad wording. I meant that even if platforms had the
> same access restrictions as footways, they should not additionally be
> tagged highway=footway, because this were redundant. But as platforms
> often have different access restrictions (e.g. you cannot enter w/o a
> ticket), adding highway=footway is conflicting.
>
> Regards
>
> Markus
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

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 example posted earlier is a good example where it seems an
awful lot like a footway and a platform at the same time. Perhaps the
platform should be a polygon and the path to and on it a footway?

On Thu, May 23, 2019, 9:56 AM Andy Townsend  wrote:

> On 23/05/2019 17:45, Tobias Zwick wrote:
> > "Redundant" is perhaps not the best way to describe the problem. I'd go
> about this like this:
> >
> > A "highway=footway" is a footway, a "public_transport=platform" is a bus
> stop (platform). These are simply two different things. They *share*
> certain properties, for example, they are accessible both by pedestrians,
> 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.
> >
> That's an excellent summary.  I can think of a few railway platforms
> that also form part of footpath routes, but must do not.  Having an
> editor automatically add "highway=footway" to all platforms devalues the
> work of all those who've used the tag explicitly in the past.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

So would it be fair to say that a linear *=platform implies foot=yes and
can be tagged with reasonable tags for a footway such as width, incline,
surface, tactile paving, etc?

On Thu, May 23, 2019, 9:46 AM Tobias Zwick  wrote:

> "Redundant" is perhaps not the best way to describe the problem. I'd go
> about this like this:
>
> A "highway=footway" is a footway, a "public_transport=platform" is a bus
> stop (platform). These are simply two different things. They *share*
> certain properties, for example, they are accessible both by pedestrians,
> 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:
> > 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 anyone name an instance where a linear transit
> platform is not a footway?
> >
> > On Thu, May 23, 2019, 12:49 AM Markus  <mailto:selfishseaho...@gmail.com>> wrote:
> >
> > I agree that adding highway=footway to platforms is not only
> > redundant, but (as pointed out by Michael) is bad because platforms
> > often have different access restrictions than highway=footway. iD's
> > validation rule should be removed.
> >
> > Regards
> >
> > Markus
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org <mailto: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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

That's not an example of a trick question, just a normal question with
clear implications. I'd be happy to see examples of linear platform
features that aren't footways and have my intuition proven incorrect.

Are there any other outdoor linear features with primary pedestrian access
that aren't 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 to know how, as a data consumer, I should
> > reliably interpret existing platforms without the tag added by iD.
> >
> > Taking a step back, can anyone name an instance where a linear transit
> > platform is not a footway?
>
> This reads like a trick question.
>
> - "All platforms are, in some sense, footways."
> - "So we should tag them as footways!"
>
> or
>
> - "Here's an example of a weird platform that certainly isn't a footway!"
> - "Aha, interesting! Clearly this shows the necessity of tagging the
> *other* 100,000 platforms as footways, to show the difference!"
>
> J
>
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

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 anyone name an instance where a linear transit
platform is not a footway?

On Thu, May 23, 2019, 12:49 AM Markus  wrote:

> I agree that adding highway=footway to platforms is not only
> redundant, but (as pointed out by Michael) is bad because platforms
> often have different access restrictions than highway=footway. iD's
> validation rule should be removed.
>
> Regards
>
> Markus
>
> ___
> 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

[Nick Bolten]

> crossing=traffic_signals
> crossing:markings=no

Ah, I see. Would you envision the only value for crossing:markings be "no",
or would it potentially have yes/no/{type}, where mappers use it at their
discretion - such as in this example?

On Mon, May 20, 2019 at 10:49 PM Martin 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 property for the crossing node.
>
> I'm not following, could you give an example?
>
>
>
> crossing=traffic_signals
> crossing:markings=no
>
> 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 - RFC (etc) for crossing:signals

[Nick Bolten]

> The core of the issue seems to be that there are two conflicting
mindsets: Mapping "types" of crossings versus having a "construction kit"
of several tags which each describe one facet of the crossing.

I agree, this is the central issue behind the tags being non-orthogonal:
crossing=* implies the "type" of crossing whereas the values often describe
(or are interpreted as describing) a "construction kit". The crossing "is
a" type (unmarked, uncontrolled, traffic_signals) vs. "has a" properties
(markings, signals, etc).

I'm open to the idea of crossing:markings=yes/no/* rather than
crossing=marked/unmarked.

> If we want to have "types of crossings" at all, it would be highly
unexpected to ignore the presence of traffic signals for that purpose.
> And the crossing=* key clearly seems to be intended for mapping the
type of the crossing. That meaning is suggested by the name of the key
itself, not just the current set of values, so I believe it's
counter-intuitive to turn it into just one of several equally important
orthogonal keys.

I agree that deciding the "type" to be markings is semi-arbitrary and
acknowledge that many think concepts like signals or "controls" take
precedent. These two proposals could have gone with
crossing=traffic_signals/unsignaled + crossing:markings=yes/no/* and still
solve the core issues.

> So what I would probably do is mix the two approaches instead of going
for a conceptually pure implementation. Use
crossing=unmarked/marked/traffic_signals for a basic classification of the
crossing's type, and then add orthogonal subtags like crossing:island=*,
crossing:marking=* etc. as needed.

I tend to prefer least-resistance / compromise options, and this sounds
like it's in that direction. If I'm understanding it right, these would be
taggable:

crossing=unmarked/uncontrolled/traffic_signals/no
crossing:markings=yes/no/*
crossing:signals=yes/no/*

One downside to allowing both approaches is the amount of redundancy in
tagging crossings: not only do we tag both the node on the street and a way
(if available), we can be tagging something like crossing=traffic_signals
and crossing:signals=yes/no/*, crossing:markings=yes/no/*. Personally, I
would never map or consume crossing=traffic_signals because it's frequently
unknowable what the mapper intended, so we'd have a system of competing
standards. I would also be tempted to convert crossing=* into the
crossing:* namespace tags whenever possible, due to the many problems
listed on these proposals.

But, for the sake of having an option, what do others think about this
approach? New 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 type? You make
> > a good point about the simplicity of avoiding a subtag for markings.
>
> Yes, this is pretty much what I'm suggesting. And I believe it would be
> an useful tag no matter whether we make crossing mapping fully
> orthogonal or just mostly orthogonal.
>
> Taking a step back to explain my thoughts on splitting off signals...
>
> The core of the issue seems to be that there are two conflicting
> mindsets: Mapping "types" of crossings versus having a "construction
> kit" of several tags which each describe one facet of the crossing.
>
> If we want to have "types of crossings" at all, it would be highly
> unexpected to ignore the presence of traffic signals for that purpose.
> And the crossing=* key clearly seems to be intended for mapping the type
> of the crossing. That meaning is suggested by the name of the key
> itself, not just the current set of values, so I believe it's
> counter-intuitive to turn it into just one of several equally important
> orthogonal keys.
>
> What else could we do with crossing=*? In theory, we could just get rid
> of it entirely, but realistically, that's not going to fly, and I'm not
> even sure if it would be desirable. People _do_ tend to mentally put
> things to categories, and describing the most common crossings with just
> one tag is certainly convenient.
>
> So what I would probably do is mix the two approaches instead of going
> for a conceptually pure implementation. Use
> crossing=unmarked/marked/traffic_signals
> for a basic classification of the crossing's type, and then add
> orthogonal subtags like crossing:island=*, crossing:marking=* etc. as
> needed. It lacks the elegance of full orthogonality, but covers all
> practical use cases.
>
> Tobias
>
> ___
> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

That is an interesting case!

Looking at mapillary, it looks like part of it is paved. I'm not sure
whether that makes it a footway or not, but it looks incredibly dangerous
to cross there:
https://www.mapillary.com/app/?lat=53.91808029997222=-1.164232900018=17.363583160262273=photo=Bn5q8Eay8Sar3ELAEaHXFg=0.5127641245746908=0.55074602568446=0

This is a case where I feel my own subjectivity comes into play when it
comes to mapping: do I map a potentially unsafe crossing (sometimes the
only one available for miles) and hope that data consumers contextualize it
properly (a multi-part unmarked crossing on a primary highway) or do I
dictate crossing=no / add notes? I don't feel confident in either option,
personally, and actually tend to just not map it and hope for the best.

On Mon, May 20, 2019 at 2:31 PM Graeme Fitzpatrick 
wrote:

>
>
> On Mon, 20 May 2019 at 20:58, Andy Townsend  wrote:
>
>>
>> Adding ways where people might think there ought to be ways (but there
>> aren't really) is certainly established.  As an example,
>> https://www.openstreetmap.org/way/691036735 is one that I did
>> yesterday.  Historically I suspect that there was a legal right of way
>> across here (and there might still be, although there is nothing
>> signed), and there is gap in the barrier that appears to have been
>> created to allow crossing, but I wouldn't try it unless you fancy
>> playing "human frogger".
>>
>
> Nice one Andy!
>
> Just wondering if that would be better as a description, or both note &
> description?
>
> Thanks
>
> Graeme
> ___
> 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

[Nick Bolten]

> It is?  I hadn't noticed.

Yes.

> I take a very different view, that crossing=traffic_signals says that the
crossing is controlled by traffic signals.  There may or may not be
markings.  Those markings may or may not be similar to markings at
crossings without traffic signals but, if the lights are functioning those
markings have no legal significance and do not determine rights of way.

This is still not true. Cars cannot occupy that space, per law, in my area.
I assume this is probably true in yours as well.

I'd be happy if everyone had this interpretation, however, because it would
make my job of arguing about orthogonality very easy.

> I, like some others here, think it rather obsessive of you to insist on
mapping what we consider to be an irrelevancy.

First, we already map this. It's what the tag crossing=uncontrolled means,
per the wiki: a marked crossing, like a crosswalk in the US. You have to
put aside this idea of what "controlled" and "uncontrolled" mean, they are
apparently irrelevant. Perhaps we should change the schema so this kind of
error stops happening...

Anyways, that's a strange way to frame "mapping something I don't care
about". How is it obsessive? I've already listed several important use
cases, so I will be blunt: do you think people with low vision are
irrelevant and don't matter? Is this an ableist community? Do pedestrians
getting struck by cars not matter? Is it okay that they die?

> The crossing is CONTROLLED by the lights and that is the important factor.

This is completely unstated in the tag definitions. It's not actually the
important factor, per the most official-ish sources we have. Clearly
absolutely everyone (including you) is confused about how to use these tags.

> Sure, if you can come up with something that isn't disruptive and has
other benefits, then it MAY be worth coming up with a tagging scheme that
allows
us to indicate whether a crossing controlled by lights also has markings.

I did. It's this proposal. You should check it out, it makes a
multi-pronged argument regarding the problems of this tag and benefits of
changing it. I'm sure the proposal could always be improved, and I'm very
interested in feedback, but continually rehashing inaccurate and myopic
misrepresentations isn't productive.

> At best, all I've seen indicates that maybe editors should make it
clearer to mappers if they change a crossing tagged as traffic signals to
one with markings that perhaps they're
using aerial imagery to undo what somebody has verified on the ground.

There are currently four headings pointing out problems with
crossing=traffic_signals, several follow-up arguments about disambiguating
the whole traffic_signals namespace, definitions of what the new schema
would be, and a simplification of mapping down to two straightforward
questions (extremely easy to support in an editor) vs. the current
confusing trade-off schema.

The example you list is worse than you've stated, though. The *original*
mapping can easily be from aerial imagery and state crossing=uncontrolled.
Because the crossing subtag is now populated, QA tools / Overpass Turbo
will no longer pick it up as unset and needing data. Only a thorough
in-person audit / broken use case will detect the error.

> I don't deny that such edits may be a problem, I'm not convinced your
proposal is the best solution.

I'm open to other strategies. What do you propose?


On Mon, May 20, 2019 at 5:53 AM Paul Allen  wrote:

> On Mon, 20 May 2019 at 06:53, Nick Bolten  wrote:
>
>>
>> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
> It is?  I hadn't noticed.  I take a very different view, that
> crossing=traffic_signals says that
> the crossing is controlled by traffic signals.  There may or may not be
> markings.  Those
> markings may or may not be similar to markings at crossings without
> traffic signals but,
> if the lights are functioning those markings have no legal significance
> and do not
> determine rights of way.
>
> I, like some others here, think it rather obsessive of you to insist on
> mapping what we
> consider to be an irrelevancy.  The crossing is CONTROLLED by the lights
> and that
> is the important factor.  Sure, if you can come up with something that
> isn't disruptive and
> has other benefits, then it MAY be worth coming up with a tagging scheme
> that allows
> us to indicate whether a crossing controlled by lights also has markings.
>
> At best, all I've seen indicates that maybe editors should make it clearer
> to mappers if
> they change a crossing tagged as traffic signals to one with markings that
> perhaps they're
> using aerial imagery to undo what somebody has verified on the ground.  I
> don't deny that
> such edits may be a problem, I'm not convinced your proposal is the be

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

[Nick Bolten]

> It is very common to see markings at traffic signal controlled crossings,
but I would not see them as a requirement, and I do not think it is written
anywhere that it should be.

I agree, and this is one of the criticisms I list for this tag. Every time
I have made this criticism - here or with a wider OSM group - several
people have chimed in to say that they've never seen a crossing with
traffic signals but no markings and thought it was a moot point. There's
one right now responding a bit condescendingly in another thread, in fact.

> From my understanding, it seemed not interesting for most mappers to
distinguish traffic light controlled markings from unmarked ones, and you
will likely have a hard time to convince them (as this thread shows) to
retag all crossings just because there may be exceptions or situations
where it may be relevant.

This is not the sole problem with the tag, so that is not a fair
characterization of this proposal. There is also no part of this proposal
asking anyone to remap their own past work. But I'll push back: as best I
can tell from old mailing list archives and the wiki, these tags did not
emerge from any attempt to map "interesting" things, let alone adequate
ones for pedestrians, but were simply intended to replace the UK-specific
zebra, pelican, toucan, etc tags. You can even see, "uncontrolled" morph
meanings ad hoc. Finally, I get several emails per month from
municipalities and civic tech groups that want to map these exact things,
and I have no legitimate schema to give them. I say this because there are
actually very few tagged crossings, despite the numbers or retagging
seeming impressive at first glance - they will be dwarfed in short order by
any real attempt to map these features.

> In your example it could even be interpreted as if there were some kind
of "markings" (different paving, designated pedestrian waiting area), but
moving forward, the next crossing does not, so we can safely assume it is a
situation that actually occurs.

Hmm, I'm not seeing any markings on the ground (on the street) that
distinguish the crossing location from the street at all.

> 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 property for the crossing node.

I'm not following, could you give an example?

Best,

Nick

On Mon, May 20, 2019, 12:54 AM Martin Koppenhoefer 
wrote:

>
>
> Am Mo., 20. Mai 2019 um 07:53 Uhr schrieb Nick Bolten :
>
>> Hello everyone, this is a late addition to this thread (I'll start a new
>> one soon after I improve the proposal page), but I want to give an example
>> of a crossing that has lights but no markings that is traversed by
>> (guessing) thousands of people per day:
>> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
>> Despite having a lot of interesting art, there is no way to distinguish the
>> crossing location from non-crossing locations via markings on the ground.
>>
>> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
>
> It is very common to see markings at traffic signal controlled crossings,
> but I would not see them as a requirement, and I do not think it is written
> anywhere that it should be. From my understanding, it seemed not
> interesting for most mappers to distinguish traffic light controlled
> markings from unmarked ones, and you will likely have a hard time to
> convince them (as this thread shows) to retag all crossings just because
> there may be exceptions or situations where it may be relevant.
>
> In your example it could even be interpreted as if there were some kind of
> "markings" (different paving, designated pedestrian waiting area), but
> moving forward, the next crossing does not, so we can safely assume it is a
> situation that actually occurs.
>
> 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 property for the crossing node.
>
> 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 - RFC (etc) for crossing:signals

[Nick Bolten]

> If you scroll down a bit, you'll find a map that shows that Pine St
between 4th & 5th Ave's is a "shared street without markings":
https://www.citylab.com/solutions/2015/03/6-places-where-cars-bikes-and-pedestrians-all-share-the-road-as-equals/388351/
which I guess should possibly be tagged in OSM as a highway=living_street?

The language on the SDOT page is very confusing! It's solely about bicycles
not having their own lanes and having to share space with cars, not about
pedestrians. For the CityLab page, that living street is several blocks
away on Bell St closer to 1st and 2nd. It's possible something has recently
changed, but I believe Pine is not a shared / a "living street" between 4th
and 5th.

> Not in iD!

> If you put in a crossing=marked than add that it has traffic signals,
then it immediately changes to a crossing=unmarked!

That does seem like a problem, though I'd suggest that if this tag were
adopted it'd be an easy fix on iD! As of the status quo, what should happen
when there are pedestrian signals re: markings is effectively undefined,
despite opinions on the mailing list. With something like crossing:signals,
tags for markings would never conflict with tags for signals.

Best,

Nick

On Sun, May 19, 2019 at 11:46 PM Graeme Fitzpatrick 
wrote:

>
>
> On Mon, 20 May 2019 at 15:53, Nick Bolten  wrote:
>
>> Hello everyone, this is a late addition to this thread (I'll start a new
>> one soon after I improve the proposal page), but I want to give an example
>> of a crossing that has lights but no markings that is traversed by
>> (guessing) thousands of people per day:
>> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
>> Despite having a lot of interesting art, there is no way to distinguish the
>> crossing location from non-crossing locations via markings on the ground.
>>
>
> That's an interesting one!
>
> Thought at first that it may have been a diagonal crossing
> https://en.wikipedia.org/wiki/Pedestrian_scramble, but after a bit more
> searching found this:
>
> https://www.seattle.gov/transportation/projects-and-programs/programs/bike-program/protected-bike-lanes/pike-pine-mobility-improvements
>
>
> If you scroll down a bit, you'll find a map that shows that Pine St
> between 4th & 5th Ave's is a "shared street without markings":
>
> https://www.citylab.com/solutions/2015/03/6-places-where-cars-bikes-and-pedestrians-all-share-the-road-as-equals/388351/
> which I guess should possibly be tagged in OSM as a highway=living_street?
>
> So, you're sort of correct in that there are no defined markings, but also
> sort of wrong because the pretty artwork are actually markings to show that
> there are no markings!
>
> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
> Not in iD!
>
> If you put in a crossing=marked than add that it has traffic signals, then
> it immediately changes to a crossing=unmarked!
>
> Thanks
>
> Graeme
> ___
> 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

[Nick Bolten]

Hello everyone, this is a late addition to this thread (I'll start a new
one soon after I improve the proposal page), but I want to give an example
of a crossing that has lights but no markings that is traversed by
(guessing) thousands of people per day:
https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
Despite having a lot of interesting art, there is no way to distinguish the
crossing location from non-crossing locations via markings on the ground.

This is topical, as crossing=traffic_signals is often claimed to imply
crossing=marked.

On Tue, May 7, 2019 at 2:08 PM Nick Bolten  wrote:

> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:signals
>
> Hello fellow tagging enthusiasts!
>
> This proposal suggests the deprecation of crossing=traffic_signals and
> replacing it with crossing:signals=yes, i.e. placing pedestrian
> signalization on a dedicated tag that is separate from crossing=* values.
>
> The current values for the crossing=* tag are not orthogonal:
> crossing=traffic_signals is not actually orthogonal to
> crossing=uncontrolled or crossing=unmarked, for example. This presents a
> significant challenge to understanding the meaning of these tags and in
> creating properly descriptive tags on map elements. For example, let's take
> three attributes of a pedestrian crossing: signalization for pedestrians,
> signalization for traffic, and markings on the ground. What do
> crossing=uncontrolled/unmarked/traffic_signals say about these scenarios?
>
> crossing=uncontrolled:
>   - signalization for pedestrians is undefined
>   - signalization for traffic *should* not exist, but due to confusions
> over the meaning of the tag, might.
>   - markings are implied, but due to confusions over the meaning of the
> tag, might not not.
>
> crossing=unmarked:
>   - signalization for pedestrians is undefined
>   - signalization for traffic is undefined
>   - there are no markings
>
> crossing=traffic_signals
>   - signalization for pedestrians: yes
>   - signalization for traffic is undefined
>   - markings are undefined
>
> So, you can see the problem: the values are describing completely
> different things and the rest is ambiguous.
>
> I'm interested in any/all feedback regarding this tag proposal! Thank you
> for your time!
>
> Best,
>
> Nick
>
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

> I’ve read that whole previous discussion, and from my point of view it
was just a whole bunch of completely useless noise, with everyone telling
you that you aren’t making sense and you ignoring it and bulldozing your
way forward.

Ah, and incidentally, I'd say I have the exact opposite problem: I reply to
just about every single thread, quoting just about everything and
attempting to take it into consideration.

Let's try to make this a productive discussion, not one laden with (for
some reason primarily German-speaking-originating) disdain.

On Sun, May 19, 2019 at 10:20 PM Nick Bolten  wrote:

> > if you are having trouble where people are “fixing” your mapping, then
> draw a way with no highway=* tag put crossing=no on it.
>
> Is this an established strategy? I'd be happy to promote it + update the
> wiki if it's communally supported. If it's not necessarily an established
> strategy, I'd also be interested in making a new thread about it in the
> hopes of making it one.
>
> On Sun, May 19, 2019 at 10:09 PM John Willis via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>>
>> On May 20, 2019, at 9:52 AM, Nick Bolten  wrote:
>>
>> Unfortunately, people will draw the crossing if there isn't negative
>> information there saying to stop doing that, e.g. crossing=no
>>
>>
>> if you are having trouble where people are “fixing” your mapping, then
>> draw a way with no highway=* tag
>>
>> put crossing=no on it. that should at least read as “mapped” to imagery
>> tracers out there.
>>
>> similar to demolished=* on a line mapped over a bridge visible on imagery
>> that has actually been destroyed.
>>
>> Javbw
>> ___
>> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

> I’ve read that whole previous discussion, and from my point of view it
was just a whole bunch of completely useless noise, with everyone telling
you that you aren’t making sense and you ignoring it and bulldozing your
way forward.

Well, so much for community discussion. I will make appeals to those
interested in hearing other points of view.

On Sun, May 19, 2019 at 10:09 PM  wrote:

> I’ve read that whole previous discussion, and from my point of view it was
> just a whole bunch of completely useless noise, with everyone telling you
> that you aren’t making sense and you ignoring it and bulldozing your way
> forward.
>
>
>
> *From:* Nick Bolten 
> *Sent:* Monday, 20 May 2019 10:48
> *To:* Tag discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] "Unambiguous crossings" proposals and related
> questions
>
>
>
> It's a little disappointing to see these points rehashed given the lengthy
> recent discussions, but at the risk of creating a new massive thread I'd
> like to clear some things up.
>
>
> ___
> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

> if you are having trouble where people are “fixing” your mapping, then
draw a way with no highway=* tag put crossing=no on it.

Is this an established strategy? I'd be happy to promote it + update the
wiki if it's communally supported. If it's not necessarily an established
strategy, I'd also be interested in making a new thread about it in the
hopes of making it one.

On Sun, May 19, 2019 at 10:09 PM John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
>
> On May 20, 2019, at 9:52 AM, Nick Bolten  wrote:
>
> Unfortunately, people will draw the crossing if there isn't negative
> information there saying to stop doing that, e.g. crossing=no
>
>
> if you are having trouble where people are “fixing” your mapping, then
> draw a way with no highway=* tag
>
> put crossing=no on it. that should at least read as “mapped” to imagery
> tracers out there.
>
> similar to demolished=* on a line mapped over a bridge visible on imagery
> that has actually been destroyed.
>
> Javbw
> ___
> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

Hey Markus,

This is a very good example that I somehow forgot to add to any of my
replies / the wiki. Thank you for reminding me!

There are certainly many crossings that have pedestrian signals but are
tagged with the flavor du jour of crossing=marked because the latter can be
mapped from aerial imagery and the former has to be verified on the ground.

On Sun, May 19, 2019 at 10:55 AM Markus  wrote:

> On Sun, 19 May 2019 at 18:32,  wrote:
> >
> > Personally, I can not remember having ever seen, in my whole life, a
> signal controlled pedestrian crossing that does not have road markings,
> excluding cases where there are temporarily no road markings at all because
> they haven't been painted yet after the road has just been laid down or
> resurfaced.
> >
> > [...]
> >
> > crossing=uncontrolled and crossing=zebra have been used a combined 1.25
> million times. In practical usage, they mean exactly the same thing, and
> they have widespread software support already. Trying to replace them with
> a 3rd value that still means exactly the same things is a classical case of
> https://xkcd.com/927/
>
> While it may be true that there aren't any signal controlled
> pedestrian crossing without road markings, the problem with
> zebra/marked using the same key as traffic_signals is that mappers
> (those that don't visit the place, don't have local knowledge and
> likely haven't read the documentation) see a marked crossing on the
> aerial imagery and tag it crossing=zebra/marked even if there are
> traffic lights -- sometimes they even retag a crossing=traffic_signals
> to crossing=zebra/marked. I've already corrected dozens of them, but
> there are constantly new ones being wrongly added or retagged. While
> crossing=unmarked/{uncontrolled|zebra|marked}/traffic_signals
> theoretically may work, it doesn't in practice. I think that only
> moving traffic lights and road markings to separate keys will solve
> this problem.
>
> Regards
>
> Markus
>
> ___
> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

> if you do not draw the ways for people to cross, then they don’t exist,
right?

Unfortunately, people will draw the crossing if there isn't negative
information there saying to stop doing that, e.g. crossing=no. I'd add
crossing=no to that particular place in addition to your recommendations.
This is a bit like the situation where mappers add buildings that don't
exist from aerial imagery and diligent local mappers have to keep deleting
them / adding notes / using a tagging scheme just to say, "this doesn't
exist".

If that crossing location is illegal, which I would hope it is simply due
to being so dangerous, even more reason to add crossing=no.

On Sun, May 19, 2019 at 5:02 PM John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
>
> On May 20, 2019, at 6:57 AM, Graeme Fitzpatrick 
> wrote:
>
> Draw the fence
>
>
>
> Draw the fence.
>
> access=no
>
>
> if you do not draw the ways for people to cross, then they don’t exist,
> right?
>
> where people have made narrow footpaths (without breaking barriers, such
> as paths over a hill between two formal ways), then highway=path
> surface=ground informal=yes is how I tag those, though this might not be
> correct.
>
> But in this instance, you are talking about a barrier being ignored and
> jumped. simply do not map the crossings.
>
> javbw.
> ___
> 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] "Unambiguous crossings" proposals and related questions

[Nick Bolten]

It's a little disappointing to see these points rehashed given the lengthy
recent discussions, but at the risk of creating a new massive thread I'd
like to clear some things up.

> "The "traffic_signals" namespace is used to describe both vehicular
traffic signals and pedestrian/bicycle traffic signals, to everyone's
confusion."
> This statement is simply completely factually wrong.
> a) traffic_signals is the *value* here, not the name of the tag

Yes, that was a silly typo/flub. It's been fixed.

> b) there are 2 distinct tags to describe the presence of traffic signals
for the road way and foot/cycle way:
> highway=traffic_signals for signals controlling traffic on the road
> crossing=traffic_signals for signals controlling crossing pedestrians

If we acknowledge the typo, this isn't actually a contradiction. It's still
the same value being used for both, everyone is still confused, and believe
it or not, many in the previous thread explicitly stated that
crossing=traffic_signals is not solely about signals controlling
pedestrians, but implies signals controlling street traffic as well.

> "To make matters worse, it forces mappers to choose between tagging a
crossing's markings, [...], or whether it has signalization."

> Personally, I can not remember having ever seen, in my whole life, a
signal controlled pedestrian crossing that does not have road markings (...)

Have you done an audit? It's easy to miss these things if you aren't
directly concerned about them. There are several right in downtown Seattle,
Washington by Westlake Park, if you want to see an example. Plenty of neat
designs on the ground, but none are actually saying where the crossing is.
I've seen the situation in New York and Montana, as well.

> And even if there should really be signal controlled crossings that on
purpose do not have any road markings, I would consider that to be
basically completely irrelevant (...)

I find this attitude surprising. Why not ask if anyone finds it relevant?
This map isn't just for any single person.

- People with low vision use crosswalk markings to help navigate.
- Marked crossings assist in establishing a pedestrian space where car
traffic should not stop (which is one of the reasons they are installed
even when there are signals).
- Marked crossings increase pedestrian safety.

I, and many others, want to know when a crossing is marked or not.

> Deprecating a tag that has been used almost 60 times and has
widespread software support, just to replace it with a different tag that
means exactly the same seems somewhat insane to me, and while I can't speak
for anyone else, I can guarantee to always vote no for this.

I would urge you to wait for responses before making up your mind.

As can be seen in the previous threads, none of the tags I've proposed mean
"the exact same thing" as what currently exists, because the meaning and
tagging of what exists is in no way agreed upon by even long-term expert
mappers. crossing=uncontrolled has the unfortunate reality of not actually
meaning "uncontrolled" and crossing="traffic_signals" says nothing about
markings (in addition to confusion about what it even describes about
signals).

Concerning the number of times the tag is used, consider that there are
33,000 marked crossings in my city (Seattle) alone. We have not mapped
anywhere near enough marked crossings/signaled crossings: they are
effectively unmapped for the vast majority of locations. Now is the perfect
time to deprecate any bad tags: there is intense interest in mapping these
typically unmapped features, but I can barely even tell people what to do
in terms of tags. I've also tried to figure out what data consumers even do
with the existing tags, particular those on nodes. I have found very few
uses, which would make sense given the shoddy coverage: you certainly can't
depend on them being mapped where they exist. Here's all that I know of:

- Adding a delay to car routing software, as the car might have to stop.

- Locally-scoped projects showing visual metaphors for "traffic signaled"
and "uncontrolled/marked/whatever" on a base map.

- A 3D renderer that shows continental crossings wherever
crossing=uncontrolled exists on a node.

I'm always interested to hear about more examples, but it's clear that
coverage is poor, which will limit applications.

> I can agree with this one, but it's essentially a non-issue as this has
already been done.

It's a successful example of orthogonalizing pedestrian crossing
information away from this catch-all namespace.

> crossing=uncontrolled and crossing=zebra have been used a combined 1.25
million times. In practical usage, they mean exactly the same thing, and
they have widespread software support already. Trying to replace them with
a 3rd value that still means exactly the same things is a classical case of
https://xkcd.com/927/

That comic is literally linked in the proposal about this very issue.

In practical usage, they clearly don't mean the 

Re: [Tagging] How to tag sidewalk slides

[Nick Bolten]

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
would be worth discussing.

There's two big benefits I can name right away:

- It becomes easier to incrementally map l to armchair map these features.
User A tags ramp=yes on a footways (armchair mappable), User B can then use
a QA tool and add incline=up/down (armchair mappable), user C can add
incline=a number (must map on-site).

- It becomes possible to distinguish infrastructure built as a ramp (like
this slide or a wheelchair ramp) from any other segment of footway that
just happens to be steep.

Does ramp=yes seem like an appropriate (hypothetical) tag for this
situation?

On Thu, May 16, 2019, 4:02 PM Alessandro Sarretta <
alessandro.sarre...@gmail.com> wrote:

> Hi everybody,
>
> I'm mapping various sidewalks and I'd like to tag the portion of the
> sidewalk that slides down from a higher level to the ground, and then maybe
> goes up again. This happens usually in correspondance with driveway
> entrances (how do you tag them?). You can see an example here
> https://wiki.openstreetmap.org/w/images/thumb/b/b9/Sidewalk_and_zebra-crossing.jpg/240px-Sidewalk_and_zebra-crossing.jpg
>
> For wheelchair accessibility it would be important to characterize it with
> an incline tag: when the incline value its e.g. >5% the accessibility can
> be considered limited, and so on.
>
> One of course could split the sidewalk for a 1 m section and assing a
> specific incline value to it; this might lead to a very fragmented way and
> sometimes it would be easier to simply add a node and assign an incline
> value to it. Even the simple information that there's a portion of the
> sidewalk not horizontal (without a specific value) can be useful.
>
> I've thought about using a node on a footway=sidewalk with
> *sidewalk=slide* + *incline= *or something similar.
>
> I thought also about using the tag kerb, but in this case it isn't a real
> intersection with the road, so it doesn't seem to be appropriate to me.
>
> Do you have any experience on that or suggestions?
>
> Thank you in advance,
>
> Ale
>
>
> ___
> 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

[Nick Bolten]

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 received about specific tagging strategies seem roughly in
line with how I'd map, although I shy away from crossing=traffic_signals
due to the various previously stated reasons, although I personally focus
on mapping ways over nodes. Not that there's anything wrong with adding the
same information to a node, it's just not my focus.

Were this and the other proposal about traffic_signals adopted, your
questions would be a bit easier to answer:

(1) Is the crossing marked? If so, crossing=marked. If not,
crossing=unmarked
(2) Does the crossing have a pedestrian light (that is synchronized with a
traffic-facing stop/go light)? crossing:*signals=yes (I am going to rework
the crossing:signals proposal to distinguish pedestrian from traffic).

The only exception is the path through a parking lot that you noted. I
think that's a case that could potentially use its own new tag of some kind
- a marked path through a shared pedestrian/car space. I wouldn't tag it as
anything other than highway=footway for now.

On Sun, May 12, 2019 at 1:50 PM Kevin Kenny  wrote:

> This discussion is leaving me pretty bewildered.
>
> Sometimes my bewilderment can be alleviated by considering concrete
> examples.
>
> On my walk yesterday, other than the implied crossing at every
> intersection (but see "don't map local law") I noted the following:
>
> 1. Combined foot/cycle crossing - a side path from a combined
> foot/cycleway onto a very lightly trafficked suburban street. Marked
> with signs bearing the silhouette of a bicycle about 50 m in advance
> of the crossing. No markings on the pavement. (This crossing is part
> of my daily commute. The street that it crosses is quite busy, and the
> sign with the bicycle silhouette has no apparent effect on the
> drivers. Pedestrians divide into the quick and the dead.)
>
> 2. Combined foot/cycle crossing - a combined foot/cycleway crossing a
> busy two-lane street at grade. Signage both ~50 m in advance and at
> the crossing. Flashing yellow lights (meaning 'proceed with caution')
> flank the sign at the crossing. The lights can by turned on by a
> pedestrian or cyclist pushing a button. Zebra-stripe pavement
> markings.
>
> 3. Zebra-stripe pavement markings at an intersection controlled by a
> 4-way STOP sign.
>
> 4. Zebra-stripe pavement markings at an intersection controlled by a
> traffic light, with no 'WAIT/WALK' pedestrian signals.
>
> 5. Zebra-stripe pavement markings at an intersection controlled by a
> traffic light, with 'WAIT/WALK' pedestrian signals, and a countdown
> timer giving the seconds remaining to cross.
>
> 6. The same, with the pedestrian or cyclist requesting the WALK signal
> by pressing a button.
>
> 7. Zebra-stripe pavement markings, together with a sign displaying the
> silhouette of school children, in the middle of a block in front of a
> school. This crossing may be supervised during school
> arrival/departure times.
>
> 8. Zebra-stripe pedestrian markings delineating the preferred footpath
> in a parking field, and running generally perpendicular to the parking
> aisles.
>
> And I'm now in confusion about how to tag any of them.
>
> ___
> 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

[Nick Bolten]

> hm, would you consider these traffic lights, or not? It basically depends
on this interpretation whether you should use a different tag or would use
crossing=traffic_lights If you decide for the latter it could still make
sense to add another tag for the specific crossing (sub)type.

Personally, if someone said, "look at that traffic light", I'd assume it
was a light that tells cars when to stop and go and I'd imagine red, amber,
and green lights. I would not think of warning signals as a traffic light,
so I'd need to visit the wiki and try to guess about what tag to use, if
any.

Let's say we did make another tag: crossing=warning_lights. We'd actually
have made the overall problem worse by adding a tag that doesn't describe
pedestrian signals or markings on the ground, forcing mappers to choose
between the types of information they can map.

After these discussions, my preference is for a unique tag for street
traffic signals at crossings:
crossing:street_signal=yes/no/traffic_lights/warning/*, with wording up for
debate.


On Sat, May 11, 2019 at 6:41 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 11. May 2019, at 01:42, Nick Bolten  wrote:
> >
> > Having trouble finding a good picture (I'll keep looking), but there are
> mid-block crossings where pedestrians can press an APS to turn on traffic
> warning lights - usually yellow in the US. Some of these crossings do not
> immediately give you those traffic warnings lights, but instead are tied to
> nearby traffic and turn on after a delay. When the lights turn on, there is
> some form of a pedestrian signal: sometimes the APS talks to you, sometimes
> there's a visual cue: lights turn on or a "walk" sign enables
>
>
> hm, would you consider these traffic lights, or not? It basically depends
> on this interpretation whether you should use a different tag or would use
> crossing=traffic_lights
> If you decide for the latter it could still make sense to add another tag
> for the specific crossing (sub)type.
>
> 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

[Nick Bolten]

t the actual meaning of "uncontrolled" creeps in. The
wiki is not actually describing an uncontrolled crossing, it's describing a
marked crossing, but every time there is a discussion of
crossing=uncontrolled everybody chimes in with their own ideas of what it
means for a crossing to be controlled. The OSM data is then punished when
mappers attempt to understand the term "uncontrolled": more transit
knowledge could actually lead to worse data.

> Ummm, we're into pedantic parsing again.  Yes, it's a crossing.  A
crossing that has lights controlling both vehicles and pedestrians.  To be
marked as crossing=traffic_signals it must be a crossing which has lights
controlling both.  Lights that may or may not be mounted on the same pole
but which operate in synchrony.

The distinction between "is a" and "has a" is very important for this tag,
it's why crossing=* is a mess. The values should be "is a", because they
are implicitly orthogonal: you either tag crossing=uncontrolled or
crossing=traffic_signals. The crossing "is" an uncontrolled crossing. The
crossing "is" a traffic_signal crossing. But this is wrong: those two
values are not truly orthogonal, they make statements about different
things. A crossing *has* ground markings. A crossing *has* traffic signals.
They are separate properties.

I don't know why this distinction is pedantic. Seems important to me.


On Sat, May 11, 2019 at 5:22 AM Paul Allen  wrote:

> On Sat, 11 May 2019 at 01:09, Nick Bolten  wrote:
>
>> > I would not expect to see something like that, in any of its regional
>> variations (green walking person/red stationary person in much of Europe)
>> without related lights controlling traffic.
>>
>> So, in the case of a pedestrian warning beacon, which does not control
>> traffic in the cases you've mentioned, how would you tag the crossing?
>> crossing=uncontrolled? Even thought it has pedestrian-facing lights *and*
>> lights intended to warn traffic about pedestrians?
>>
>
> If the light is purely a warning to both traffic and pedestrians, then
> it's not crossing=traffic_signals.
> If it controls both traffic and pedestrians (control as in indicating
> whether they should halt or
> proceed) then it's crossing=traffic_signals.  Your situation of warning
> lights for traffic strikes me as
> bizarre and could be argued either way.  Or maybe it needs
> crossing=insane_signals.
>
>
>>
>> There's another user in this thread who thinks the polar opposite and
>> that the lights directed at traffic are irrelevant. Who is correct? What
>> does the tag mean?
>>
>
> I think the clue is in the name: crossing=TRAFFIC_signals.  Also
> CROSSING=traffic_signals.  And
> crossing=traffic_SIGNALS.  It is a crossing for pedestrians which has
> signals for the traffic.  Of
> course, going by the name alone you could argue there are signals for
> traffic but not for pedestrians
> but that is handled as traffic lights plus crossing=uncontrolled.
>
>
>> This is making me think that my other proposal should be revised so as to
>> separate out pedestrian signals from street traffic signals entirely.
>> Something like crossing:pedestrian_signals=yes/no/(type) and
>> crossing:traffic_signals=yes/no/(type)
>>
>
> Problematic.  What would crossing:traffic_signals even mean other than
> traffic lights with an
> uncontrolled pedestrian crossing.
>
>>
>> > Not necessarily.  Most countries there probably is something, if only
>> tactile paving for the blind.
>>
>> I think I miscommunicated - I'm referring to that intersection in the
>> picture only, where the crossings are marked with the ladder pattern.
>>
>
> Going by what we have at present, it's traffic lights with an uncontrolled
> crossing.  Uncontrolled
> because nothing except common sense tells pedestrians when to cross.
> There are no lights
> telling them when they can and cannot cross.  There is no crossing guard.
> It's just a place
> where crossing is legal (in the US it may be illegal to cross where there
> are no markings; in
> the UK it's legal to cross without markings) and there also happen to be
> traffic lights
> controlling traffic alone.
>
> Earlier, the necessary conditions for crossing=traffic_signals were solely
>> (1) signals that control pedestrians and (2) signals that control street
>> traffic. But now, at this intersection, crossing=traffic_signals implies
>> markings? This is a contradiction. It is simply not possible for both to be
>> true. So you can see my dilemma in trying to use such a tag.
>>
>
> I don't see the markings as necessary.  They're a secondary element that
> may or may not be
> present

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I'd still classify that as crossing=traffic_signals.

Ah, now I'm super confused. I would've sworn that you'd recommend mapping
that as uncontrolled.

> The real world is too messy.  Can we map a fictional world instead?

People actually love doing that:
https://www.pcinvasion.com/wp-content/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 Bolten  wrote:
>
>> Having trouble finding a good picture (I'll keep looking), but there are
>> mid-block crossings where pedestrians can press an APS to turn on traffic
>> warning lights - usually yellow in the US. Some of these crossings do not
>> immediately give you those traffic warnings lights, but instead are tied to
>> nearby traffic and turn on after a delay. When the lights turn on, there is
>> some form of a pedestrian signal: sometimes the APS talks to you, sometimes
>> there's a visual cue: lights turn on or a "walk" sign enables.
>>
>
> Ugh!
>
> I'd still classify that as crossing=traffic_signals.  Because as well as
> controlling pedestrians it
> does signal to traffic.  An advisory signal rather than a controlling
> signal, but still a signal.  That's
> not like the Belisha Beacon on a Zebra that flashes whether or not there
> are any pedestrians
> there.
>
> That's not quite like the flashing amber signal near school crossings
> which are supervised by
> a crossing guard: the guard turns them on at the start of the shift and
> turns them off at the
> end of the shift, there may be nobody crossing from the time the driver
> sees them to the time
> the driver has cleared the crossing.  I can see an argument for including
> those if we include yours,
> but I doubt many people in the UK think of them as traffic lights.
>
> The real world is too messy.  Can we map a fictional world instead?
>
> --
> 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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I would not expect to see something like that, in any of its regional
variations (green walking person/red stationary person in much of Europe)
without related lights controlling traffic.

So, in the case of a pedestrian warning beacon, which does not control
traffic in the cases you've mentioned, how would you tag the crossing?
crossing=uncontrolled? Even thought it has pedestrian-facing lights *and*
lights intended to warn traffic about pedestrians?

There's another user in this thread who thinks the polar opposite and that
the lights directed at traffic are irrelevant. Who is correct? What does
the tag mean?

This is making me think that my other proposal should be revised so as to
separate out pedestrian signals from street traffic signals entirely.
Something like crossing:pedestrian_signals=yes/no/(type) and
crossing:traffic_signals=yes/no/(type)

> Not necessarily.  Most countries there probably is something, if only
tactile paving for the blind.

I think I miscommunicated - I'm referring to that intersection in the
picture only, where the crossings are marked with the ladder pattern.

>> If we tag that as crossing=traffic_signals, have we correctly and
consistently communicated all of that information?
> Maybe.  People are capable of misinterpreting anything.

Of course, but that's the same regardless of whether a tagging schema is
awful or ideal.

Earlier, the necessary conditions for crossing=traffic_signals were solely
(1) signals that control pedestrians and (2) signals that control street
traffic. But now, at this intersection, crossing=traffic_signals implies
markings? This is a contradiction. It is simply not possible for both to be
true. So you can see my dilemma in trying to use such a tag.

Keep in mind, all I want to describe is whether a crossing has markings and
whether it has pedestrian signals. That seems like something just about any
person on the street should be able to answer, but the schema makes it
difficult to tag.

> I would say that both pedestrians and traffic have to be controlled.
Controlled pedestrians and
uncontrolled traffic is insane.  Controlled traffic and uncontrolled
pedestrians is traffic lights.

Not according to most definitions of "controlled", in terms of traffic
lights. A stop sign is a form of traffic control. Also, someone in the
other thread claimed that dropped curbs were a control. Someone in this
thread says a marked crossing is a control. Nobody agrees on what a control
is in OpenStreetMap, so how can we ever trust data for "uncontrolled"? I'd
guess that almost nobody is using it for anything other than a delay on a
router (car might have to stop) or some generic visualizations of feature
density. They can't, not reliably.

> The pedestrian-facing lights and vehicle-facing lights don't even have to
be on the same pole, but they should be positioned such as to control the
pedestrians and traffic at a crossing and be operated in synchrony by the
same controller.  Together they constitute a single crossing.

I wholeheartedly disagree. A crossing is not the signals. A crossing is
where pedestrians cross the street. A crossing can *have* signalization:
signals are a property of a crossing. This is similar to how a crossing is
not an island and why crossing=island was a bad idea.

> Oh, and you can have two independent crossings within a few yards of each
other which handle one direction of traffic flow on a road with several
lanes (...)

As footways, I would map this as three elements: all are footway=crossing,
the central island is crossing: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 on the ground
>>
>> > Are there traffic signals which control BOTH traffic and pedestrians?
>> If so,
>> > crossing=traffic_signals.   If there are JUST road markings, no
>> crossing=traffic_signals.
>>
>> I interpret this to mean: the necessary condition for using
>> crossing=traffic_signals is that there are signals controlling both traffic
>> and pedestrians. If only one or the other, it is not a
>> crossing=traffic_signals.
>>
>
> That's how I intended it.  If it only controls traffic then it's ordinary
> traffic lights (regardless of
> whether people use it as a place to cross).  If it only controls
> pedestrians it's insane: "Yep,
> you can cross now, don't worry about those cars because there's nothing I
> can do to stop
> them."
>
>
> >> - A crossing might have lighted signals for pedestrians to cross
>>
>> > Define what you mean by lighted signals.  If you mean a Belisha Beacon
>> or something else that WARNS motorists that pedestria

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> you have still to show us a crossing with traffic lights only for
pedestrians :)

Having trouble finding a good picture (I'll keep looking), but there are
mid-block crossings where pedestrians can press an APS to turn on traffic
warning lights - usually yellow in the US. Some of these crossings do not
immediately give you those traffic warnings lights, but instead are tied to
nearby traffic and turn on after a delay. When the lights turn on, there is
some form of a pedestrian signal: sometimes the APS talks to you, sometimes
there's a visual cue: lights turn on or a "walk" sign enables.

Whether warning lights count as a "traffic signal" seems to be an issue of
contention. There's a theme!

> Crossing refers to a pedestrian (or bicycle) crossing, when there are
only traffic lights for the traffic on the road, but not for the crossing
traffic then there won’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:
> >
> > If only one or the other, it is not a crossing=traffic_signals.
>
>
> you have still to show us a crossing with traffic lights only for
> pedestrians :)
>
> Crossing refers to a pedestrian (or bicycle) crossing, when there are only
> traffic lights for the traffic on the road, but not for the crossing
> traffic then there won’t be a crossing tag.
>
>
> 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

[Nick Bolten]

as 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.
> Is there any unsyncronized crossing with the same traffic lights inside
> the crossing? Which drunken monkey design these crossings? How many people
> die in ?
>
> > 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
> veteran OSM mappers have stated that dropped curbs are a control).
> No. Control is something that sometimes says you if you are allowed or not
> to cross. A dropped curb says you always the same: nothing.
>
> All the things in this life can be ambiguos but uncontrolled means
> uncontrolled, unmarked means unmarked, and a traffic_signal is a
> traffic_signal.
>
> Best regards
> Health and crossings
> yopaseopor
>
>
> On Fri, May 10, 2019 at 12:46 AM Nick Bolten  wrote:
>
>> > 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
>&g

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

>> - A crossing might be marked on the ground

> Are there traffic signals which control BOTH traffic and pedestrians?  If
so,
> crossing=traffic_signals.   If there are JUST road markings, no
crossing=traffic_signals.

I interpret this to mean: the necessary condition for using
crossing=traffic_signals is that there are signals controlling both traffic
and pedestrians. If only one or the other, it is not a
crossing=traffic_signals.

>> - A crossing might have lighted signals for pedestrians to cross

> Define what you mean by lighted signals.  If you mean a Belisha Beacon or
something else that WARNS motorists that pedestrians cross here but does
NOT control traffic and pedestrians then it's not
crossing=traffic_signals.  A warning light is not a traffic signal.

In this case, I was thinking of a specific "walk/do not walk" lighted
signal.

>> - A crossing might be protected by a traffic light that tells traffic to
stop. That light might be at the crossing or at a street intersection.

> That's crossing=traffic_signals IF it also controls pedestrians.
Walk/Don't Walk ot Red/Green figures or whatever.  Otherwise it's just
traffic lights.  Even if people can cross there, it's still just traffic
lights because the crossing (by people) Isn't controlled, just the traffic
is.  Traffic has to stop when the lights tell them, the pedestrians take
their chances and are uncontrolled.

I take this to mean that the signals do not need to be colocated in order
to tag crossing=traffic_signals, such as in this scenario:
https://www.colchestervt.gov/ImageRepository/Document?documentID=185.

- There are markings on the ground
- There are pedestrian-facing signals
- There are traffic signals at the intersection controlling traffic

If we tag that as crossing=traffic_signals, have we correctly and
consistently communicated all of that information?

As an aside regarding the term "controlled", the OSM wiki doesn't actually
say any of this about whether it's traffic or pedestrians or both being
controlled. What it actually states is that crossing=uncontrolled is
equivalent to a marked crossing or "crosswalk". A marked crossing can have
or lack all forms of traffic signals that we've discussed.

>>> In any sane world, lights to control pedestrians also function as
lights to control traffic.

>> Then we live in an insane world! I'm not aware of any lights that
control both pedestrians and traffic - they are oriented in orthogonal
directions.

> *Sigh*  Was all this about pedantry?  The same interlocked mechanism
controls two sets of lights on the same pole, one set controls vehicular
traffic the other set controls pedestrians.  I didn't mean that both
pedestrians and motorists stare at exactly the same set of lights.

That's not pedantry, it's the precision that we need to describe crossings.
Are we mapping based on lights or a connected signal apparatus? That's an
actually important question. We should be able to say that clearly to new
mappers and embed it into mapping tools.

> I don't think we can let occasional errors by novice mappers define tags
for us.  If such errors are widespread then we need to introduce a
replacement scheme, encourage it for new use and manually replace 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:

> On Fri, 10 May 2019 at 21:03, Nick Bolten  wrote:
>
>> I still don't know when you think we should use
>> crossing=traffic_signals...
>>
>> - A crossing might be marked on the ground
>>
>
> Are there traffic signals which control BOTH traffic and pedestrians?  If
> so,
> crossing=traffic_signals.   If there are JUST road markings, no
> crossing=traffic_signals.
>
> - A crossing might have lighted signals for pedestrians to cross
>>
>
> Define what you mean by lighted signals.  If you mean a Belisha Beacon or
> something else that
> WARNS motorists that pedestrians cross here but does NOT control traffic
> and pedestrians
> then it's not crossing=traffic_signals.  A warning light is not a traffic
> signal.
>
> - A crossing might be protected by a traffic light that tells traffic to
>> stop. That light might be at the crossing or at a street intersection.
>>
>
> That's crossing=traffic_signals IF it also controls pedestrians.
> Walk/Don't Walk ot Red/Green
> figures or whatever.  Otherwise it's just traffic lights.  Even if people
> can cross there, it's still
> just traffic lights because the crossing (by people) Isn't controlled,
> just the traffic is.  Traffic has
> to stop when the lights tell them, the pedestrians take their chances and
> are un

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

I still don't know when you think we should use crossing=traffic_signals...

Imagine you're outside the UK. Pelican signals don't exist. No animal
signals, mythical or real, of any kind. There's just infrastructure:

- A crossing might be marked on the ground
- A crossing might have lighted signals for pedestrians to cross
- A crossing might be protected by a traffic light that tells traffic to
stop. That light might be at the crossing or at a street intersection.
- A crossing might be protected by warning lights to raise pedestrian
visibility

Which part(s) of that does crossing=traffic_signals describe?

> In any sane world, lights to control pedestrians also function as lights
to control traffic.

Then we live in an insane world! I'm not aware of any lights that control
both pedestrians and traffic - they are oriented in orthogonal directions.

> I can't see any sensible use case for lights that tell pedestrians they
can cross that do not also control traffic.  In the UK these usually
(always) look identical to "ordinary" traffic lights with the operational
exception of a protracted flashing amber to let pedestrians finish
crossing. From a motorist's perspective they are indistinguishable (at
first glance) from "ordinary" traffic lights.

Similar to you, I have yet to find an intersection with a pedestrian signal
that does not have some form of either warning or explicit traffic control
(but it could be either one), but I wouldn't rule it out based on my
experience alone. However, the existence of a traffic light doesn't imply
any other infrastructure: the crossing might lack pedestrian signals, its
own dedicated light near the crossing, and even any particular visual
markings indicating where to cross. Despite this, the
crossing=traffic_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 contexts? There are at least 3
>> types of lights and I've seen all of them referred to as "traffic lights",
>> even on UK government websites:
>>
>> - Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to
>> indicate that pedestrians should cross.
>>
>
> In any sane world, lights to control pedestrians also function as lights
> to control traffic.  I can't
> see any sensible use case for lights that tell pedestrians they can cross
> that do not also
> control traffic.  In the UK these usually (always) look identical to
> "ordinary" traffic lights with
> the operational exception of a protracted flashing amber to let
> pedestrians finish crossing.
> From a motorist's perspective they are indistinguishable (at first glance)
> from "ordinary"
> traffic lights.
>
> - The traffic lights for street traffic that are specifically associated
>> with a pedestrian crossing, as in the pelican example - the traffic light
>> pole also has all of these things: a pedestrian signal, a light for street
>> traffic (stop/go/etc), and there is generally an APS to request a crossing
>> signal.
>>
>
> This, rather than your first case, is all I've ever seen in the UK.
>
> - The traffic lights for street traffic that are not explicitly associated
>> with a particular crossing. The crossing is still protected by those
>> lights, there might even be an APS, but the traffic light is located at
>> highway=traffic_signals, i.e. the center of a street intersection.
>>
>
> If they ARE intended as a crossing then, in the UK, they'll be a pelican
> again, even if they're also
> controlling an intersection.  Not to be confused with ordinary traffic
> lights at an intersection which
> may not be intended for use as a crossing but tend to be used that way
> (because the traffic in
> one direction has been stopped, making crossing perhaps a little less
> difficult).
>
> As far as I can tell (at least in the UK) it boils down to either traffic
> lights that have nothing to do
> with pedestrians or traffic lights that also control pedestrians.
>
> --
> 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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

This all makes sense, but the question is: what does
crossing=traffic_lights mean given these contexts? There are at least 3
types of lights and I've seen all of them referred to as "traffic lights",
even on UK government websites:

- Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to
indicate that pedestrians should cross.
- The traffic lights for street traffic that are specifically associated
with a pedestrian crossing, as in the pelican example - the traffic light
pole also has all of these things: a pedestrian signal, a light for street
traffic (stop/go/etc), and there is generally an APS to request a crossing
signal.
- The traffic lights for street traffic that are not explicitly associated
with a particular crossing. The crossing is still protected by those
lights, there might even be an APS, but the traffic light is located at
highway=traffic_signals, i.e. the center of a street intersection.

The OSM wiki describes crossing=traffic_signals as, "Position this tag
where the crossing-traffic (pedestrian, bicycles) have their own traffic
lights." I still have no idea which of these things that is meant to apply
to. I wouldn't personally consider a intersection-centered traffic light to
be pedestirans' "own" traffic lights, but they have roughly the same
function and impact on pedestrian needs as a pelican crossing, in terms of
traffic. I've been told a few times, on this mailing list, that it does not
apply to pedestrian signals, but that's hard to reconcile with the fact
that pedestrian signals are frequently referred to as "traffic lights" in
many official government documents and guides and trying to understand what
in the world "their own traffic lights" means.

Personally, I think this suggests a need for a separate value or at least
tagging strategy to separate at least these two cases: signals directed at
pedestrians vs. signals directed at street traffic. If there is value in
knowing whether traffic signals are attached to the crossing in some way, I
wouldn't be against 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://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.
>>
>
> Yes, there are warning lights in the UK.  Zebra crossings on public roads
> have a flashing yellow
> globe on a pole (Belisha Beacon) to highlight that there is a crossing.
> But nobody refers to it as
> a traffic light.  Some crossings by schools have flashing yellow lights
> (in a similar sort of style
> to US railroad crossing lights) but they're not traffic lights either.
> Traffic lights control the flow
> of traffic by telling drives when they must stop and when they can go,
> they're not warnings that
> there is a crossing.
>
> We have crossings with lights that control both pedestrians and traffic,
> the Pelican (PEdestrian
> Light CONtrolled) crossing.  As far as motorists are concerned it looks
> like any other set of
> traffic lights except there's an additional flashing amber phase telling
> cars they can go if there
> are no pedestrians on the crossing.  As far as pedestrians are concerned
> it looks like traffic
> lights for motor vehicles but also has lights for the pedestrians (and a
> button, which may or
> may not do anything) for the pedestrian to let the lights know somebody is
> waiting to cross).
>
> I don't recall seeing (in the UK, in other countries it might be
> different) lights that control
> pedestrians but NOT traffic.  It doesn't seem to be a sensible idea.  A
> signal that tells pedestrians
> it's now OK to cross without telling motorists they should have stopped
> seems like a recipe
> for disaster.
>
> To summarize: in the UK there are traffic lights that control motor
> vehicles and there are traffic lights
> that control both motor vehicles and pedestrians; warning lights are not
> 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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> 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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> 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 - RFC (etc) for crossing:signals

[Nick Bolten]

> 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

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

[Nick Bolten]

> 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

[Nick Bolten]

> 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

[Nick Bolten]

> 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

[Nick Bolten]

> 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 - crossing=marked

[Nick Bolten]

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] Feature Proposal - crossing=marked

[Nick Bolten]

; 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 traffic lights
> pelican and panda is only with traffic lights .Pelican is the evolution of
> panda
> tigger means bicycle=designated and toucan means bicycle=yes.
> pegasus means horse=designated
>  (all of these are from U.K.)
>
> But there is no crossing=zebra or crossing=marked.
> I know some editor software and renders are very important for OSM, but
> doing whatever you want avoiding community consensus can generate these
> problems.
> Are you sure we need a new tagging 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:
>
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> 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 - RFC (etc) for crossing:signals

[Nick Bolten]

> However, it seems odd to "demote" traffic signals to a sub-tag when their
presence or absence is perhaps the biggest influence on the crossing's
overall character.

I agree that it's not ideal to have to make these kinds of choices about
"demoting". In case it's helpful, this is my original rationale:

1) To have properly orthogonal values for the crossing key, it should
describe one category of things, like markings or signals. This means
"demoting" all but one feature to other tags (hopefully namespaced) like
crossing:signals. Imagine if highway=primary originally implied 4 lanes as
well as "major, separated high-speed street" and only later did we have to
separate out highway=primary from lanes=4. We agree on this, just thought
it was an important point.

2) Which category should be used as the primary value of crossing? I went
with the marking because it is, by far, the most-tagged value:
uncontrolled/zebra/marked/unmarked account for 3 times as many tags as
traffic_signals.

> In comparison, it seems somewhat less important whether a signalled
crossing also has painted markings on the road. So I would suggest using a
separate tag for the markings instead. 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.

Would it be fair to say you're suggesting something along the lines of
crossing:marking=*, where * can be yes, no, or a marking type? You make a
good point about the simplicity of avoiding a subtag for markings.

Aside from frequency of tagging, the biggest reason I've prioritized
markings as the primary value is that marked crossings are starkly
different from unmarked ones from many different perspectives:

- 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".
- Marked crossings confer safety and right-of-way information to both
pedestrian and street traffic: this is a place where pedestrians can cross,
so watch out.
- Marked crossings are one of the few pedestrian spaces that can be
straightforwardly considered as a linear feature: it connects spaces across
a street.
- Marked crossings tend to have legal implications, as you note.

Thus, when someone asks me, "what type of crossing is this?", my gut
reaction is to say "a crosswalk" or "not marked", potentially followed up
by a marking type if applicable. A marked crosswalk is a real,
"on-the-ground" thing whereas unmarked is a workaround for needing to
representing and use 2D spaces as lines.

I'd be curious to find some survey data regarding the importance of
pedestrian features that included crosswalks and signals. I could've sworn
I knew of one, but am having trouble finding it.

Best,

Nick

On Tue, May 7, 2019 at 3:08 PM Tobias Knerr  wrote:

> On 07.05.19 23:08, Nick Bolten wrote:
> > This proposal suggests the deprecation of crossing=traffic_signals and
> > replacing it with crossing:signals=yes, i.e. placing pedestrian
> > signalization on a dedicated tag that is separate from crossing=* values.
>
> I agree with separating orthogonal characteristics of crossings into
> different tags. A single tag cannot easily express both the presence of
> traffic signs and the presence of markings.
>
> However, it seems odd to "demote" traffic signals to a sub-tag when
> their presence or absence is perhaps the biggest influence on the
> crossing's overall character.
>
> In comparison, it seems somewhat less important whether a signalled
> crossing also has painted markings on the road. So I would suggest using
> a separate tag for the markings instead. 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.
>
> Tobias
>
> ___
> 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

[Nick Bolten]

> 1) You cannot deprecate a tagging that is used 750k times
(crossing=uncontrolled) or 570k times (crossing=traffic_signals)

This proposal does not deprecate crossing=uncontrolled.

For the latter: why not? The tag is, in technical terms, garbage, and other
tags in relatively high use have been deprecated before.

> 2) please  define the terms you use.
> What is "signalization"?
> I know these terms: traffic signals, road marking (=horizontal traffic
signs), signs (=vertical traffic signs), but signalization?

Visual displays for the specified form of traffic. Signalization for
automotive traffic might be stop signs or stop lights. Signalization for
pedestrians might be a crossing signal / do not cross sign.

Best,

Nick

On Tue, May 7, 2019 at 2:47 PM Volker Schmidt  wrote:

> Two spontanous reactions
>
> 1) You cannot deprecate a tagging that is used 750k times
> (crossing=uncontrolled) or 570k times (crossing=traffic_signals)
>
> 2) please  define the terms you use.
> What is "signalization"?
> I know these terms: traffic signals, road marking (=horizontal traffic
> signs), signs (=vertical traffic signs), but signalization?
>
>
>
>
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_49271051233384562_m_3715203604143881037_m_5214136548138821738_m_4990119247789359937_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> crossing=uncontrolled:
>>   - signalization for pedestrians is undefined
>>   - signalization for traffic *should* not exist, but due to confusions
>> over the meaning of the tag, might.
>>   - markings are implied, but due to confusions over the meaning of the
>> tag, might not not.
>>
>> crossing=unmarked:
>>   - signalization for pedestrians is undefined
>>   - signalization for traffic is undefined
>>   - there are no markings
>>
>> crossing=traffic_signals
>>   - signalization for pedestrians: yes
>>   - signalization for traffic is undefined
>>   - markings are undefined
>>
>> So, you can see the problem: the values are describing completely
>> different things and the rest is ambiguous.
>>
>> I'm interested in any/all feedback regarding this tag proposal! Thank you
>> for your time!
>>
>> Best,
>>
>> Nick
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_49271051233384562_m_3715203604143881037_m_5214136548138821738_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:signals

Hello fellow tagging enthusiasts!

This proposal suggests the deprecation of crossing=traffic_signals and
replacing it with crossing:signals=yes, i.e. placing pedestrian
signalization on a dedicated tag that is separate from crossing=* values.

The current values for the crossing=* tag are not orthogonal:
crossing=traffic_signals is not actually orthogonal to
crossing=uncontrolled or crossing=unmarked, for example. This presents a
significant challenge to understanding the meaning of these tags and in
creating properly descriptive tags on map elements. For example, let's take
three attributes of a pedestrian crossing: signalization for pedestrians,
signalization for traffic, and markings on the ground. What do
crossing=uncontrolled/unmarked/traffic_signals say about these scenarios?

crossing=uncontrolled:
  - signalization for pedestrians is undefined
  - signalization for traffic *should* not exist, but due to confusions
over the meaning of the tag, might.
  - markings are implied, but due to confusions over the meaning of the
tag, might not not.

crossing=unmarked:
  - signalization for pedestrians is undefined
  - signalization for traffic is undefined
  - there are no markings

crossing=traffic_signals
  - signalization for pedestrians: yes
  - signalization for traffic is undefined
  - markings are undefined

So, you can see the problem: the values are describing completely different
things and the rest is ambiguous.

I'm interested in any/all feedback regarding this tag proposal! Thank you
for your time!

Best,

Nick
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dmarked

Hello, fellow tagging enthusiasts! At long last, and after many discussions
on a variety of fora, I am putting this proposal forward in the hopes of
getting feedback, making any necessary revisions, and then moving to a vote.

The motivation for changing how we tag pedestrian crossings has emerged
from the collective experience of many mappers and teachers of OSM mapping
(as well as developers of editors), where this is one of the primary
challenges to coherently mapping pedestrian features: crossing=* tags have
a ton of problems in terms of orthogonality, understandability by new and
veteran mappers alike, and semantic correctness (which also impacts
consumability). One of the primary confusions is the "uncontrolled" (and
"zebra") values, which are, in effect, intended to mean that a crossing is
"marked", but do not clearly communicate this fact to mappers, leading to
all kinds of data issues and difficulties in explaining mapping to
newcomers (and therefore getting good data).

While the proposal itself goes into detail about why crossing=marked is a
good idea and other tags are a bad idea, this is the short version:
  - crossing=* values are not truly orthogonal and this needs to be
addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are not
truly orthogonal descriptors. This proposal is part of a larger effort to
improve the values used for pedestrian crossings, but does not depend on
that effort.
  - There is fragmentation in tag usage for marked crossings between
"zebra" and "uncontrolled".
 - I believe that a significant portion of this fragmentation can be
attributed to the unconventional use of the term "uncontrolled", which is
technically incorrect, extremely jargon-y, and currently describes *two*
things whereas other values for 'crossing' describe just one.
  - crossing=marked is direct and clear about its meaning and use cases.
  - crossing=marked is already in use and supported by various editors,
including being the default in iD and an auto-filled option in JOSM.
  - crossing=marked has the potential for subtag uses, e.g. marked=zebra.
  - We can address fragmentation via machine edits and/or reviews using
MapRoulette.

The primary goal of this proposal is to create truly orthogonal,
descriptive, and intuitive tag values for markings on crossings. If related
proposals are also accepted, the only values used on crossings would be
marked/unmarked/no, with other attributes being namespaced tags
(crossing:island, crossing:signals, etc), but acceptance of this proposal
does not depend on those other proposals becoming accepted.

Please let me know any concerns you have regarding the impacts of this
proposal or semantics. I'd like to make any ambiguities clear and have the
proposal page be as thorough as possible.

Best,

Nick
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Handicap Parking Access Aisles

[Nick Bolten]

Hi all!

I think a value of "access_aisle" is entirely appropriate and that it makes
sense to be a footway, such as highway=footway + footway=access_aisle,
though if there's another new subtype that would be a catch-all for similar
features that would also make sense (e.g. footway=service). Access aisle
carries the same meaning in other English-speaking countries, including
UK-based governmental recommendations on blue badge spaces.

An access aisle is exactly the feature being described: the extra space
given to the side of a parking space for someone who needs more space to
exit. This is *not* solely for wheelchair users, it's also intended for use
by individuals using walkers or who need assistance exiting or entering a
vehicle, etc. I believe the purpose of this tag is so that any data
consumers can ask the question, "where are parking spaces with access
aisles?" and, "how do they connect to other foot ways?" Those same
consumers would probably want to know a width tag as well and possibly the
width of the parking space - it might warrant some research.

So, with that in mind:

- wheelchair=yes on a footway definitely doesn't describe an access aisle.
It means, "this mapper thinks a wheelchair user can use this footway",
which doesn't communicate anything to do with parking amenities.
wheelchair=* is also not that useful of a tag in the first place, because
wheelchair users disagree on what pedestrian features they care about on a
footway.

- wheelchair=designated is in a similar situation in that it doesn't
communicate that it's an access aisle, but a footway primarily intended for
wheelchair users, which also isn't true of an access aisle.

- footway=wheelchair_loading_aisle does communicate that it's a special
loading aisle, but has the same issue of restricting it's meaning to
wheelchair users.

I'm not sure what term would be a suitable alternative to access aisle,
since it'd need to have these meanings:

- It's a pedestrian space
- It's intended for disability access, which is widely defined and differs
between countries
- It's for passengers entering/exiting vehicles at a parking space.

Best,

Nick

On Thu, May 2, 2019, 8:59 AM Clifford Snow  wrote:

>
>
> On Thu, May 2, 2019 at 7:54 AM Tony Shield 
> wrote:
>
>> Hi
>>
>> It does appear that 'access aisle' is US and from watching the video and
>> your picture it is an integral part of a parking_bay or parking_lane for
>> disabled access. It follows that a parking bay or parking lane tagged for
>> disabled then it must follow the regulations of that country. For very
>> detailed mapping of such a bay or lane then making it clear that the
>> hatched area is for disabled users as part of the adjoining parking bay is
>> good, but please do not use words with a very wide meaning, please find a
>> way of limiting the meaning to disabled people - disabled_access_area is
>> good for me.
>>
> Tony you seem to have summarized what I've read in other posts, that
> access_aisle is too generic which would lead to people adding it to
> features that have nothing to do with wheelchair access. Once that happens,
> the tag will have lost its meaning.
>
> Since the area is intended for wheelchair access to vehicles, does
> highway=footway + footway=wheelchair_loading_aisle work better? It does
> away with needing to add a third tag, wheelchair=designated, and would work
> even if someone added wheelchair=designated.
>
> Best,
> Clifford
>
> --
> @osm_washington
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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] RFC - Feature Proposal - area of steps for pedestrians.

[Nick Bolten]

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, kerb=raised, and could have other relevant
kerb tags like kerb:height.

This would make it very easy to know what tags to use for virtually any
curb-like feature in OSM with non-trivial length: make it a curb line. This
would also dovetail with other curb line conventions, such as knowing which
side is higher (the side on the right of the way).

# Determining upper/lower steps + number of members

The example says you would set one step to role=lower and one to
role=upper. Does this mean that the relation effectively applies to a
single step? On a stairway, a single vertical part of a step could of
course serve as both upper and lower, so we'd need more information if a
single relation described the whole stairway.

As a follow-up, what about using the order of relation members, like how
bus routes do? This might make it easier to map whole stairways: order =
ascending (literally). You could then use the role to describe segments if
the stairway splits, though a role like role=1 might be off.

# one-to-one way nodes?

For mapping a step, the proposal says, "Create 2 ways, one for the upper
part of the steps, another for the lower. They should have the same number
of nodes and have the same direction."

I'm wondering why they need to have the same number of nodes. It seems to
me that the Queluz National Palace example would actually be impossible to
map as a single area this way, since it splits into two stairways at the
top. But I might be misunderstanding the proposal.

# In combination with one or more highway=steps ways

It's fairly complicated to route on areas, and this one in particular seems
even moreso. What would you think of recommending mapping both an area
(which is good for rendering/barriers/advanced routing) and one or more
highway=steps (which is good for routing + network analysis + attaching to
a building entrance) ways?

Best,

Nick

On Thu, Mar 28, 2019, 8:06 PM Warin <61sundow...@gmail.com> wrote:

> Hi,
>
> This one has been sitting for a long while! Still not certain about some
> aspects of it.
>
> See what you make of it.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps
>
>
> Discussion here for preference.
>
>
> ___
> 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] Mapping curb (kerb) lines as the home of curb, parking, etc information

[Nick Bolten]

> Unlike associatedStreet, which contains all street ways sharing the same
name and can thus contain networks of essentially unbounded complexity,
these relations should probably only span the stretch between two
junctions, though.

Agreed. This was something I had in mind but forgot to say out loud. This
might also help with naming, as it is very similar to the idea of a "block
face". Drawing from that name as inspiration, a potential "blockFace"
relation could be either "left" or "right" and only have to deal with one
set of amenities at a time (on the left or right side of the street). This
would cut down on the amount of features one would have to reference in a
single relation.

Re: kerb lines: you're right about potential duplication of data, but
similar to the sidewalks situation, I'm firmly in the camp that this data
doesn't get mapped with much specificity without its own intuitive home for
detail. The coverage for barrier=kerb / kerb=* on roads is pretty scanty
and definitely doesn't describe the actual curb interfaces for even a
single small town. For example, kerb:right is used 300 times according to
TagInfo, whereas I just looked at mapping kerbs around one block and found
at least 25 kerb changes on kerb:right alone. This tells me that the kerb
tag, when applied to roads, has not been mapped very specifically. tl;dr: I
could beat that tag count in about 30 minutes *and* create a bunch of great
data for pedestrian 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
> > various features that should be associated between streets and the
> > surrounding environment?
>
> That approach could work, yes – and it's one of the few practical
> options I can think of at the moment. (The other would be drawing an
> area:highway polygon around all the individual ways.)
>
> Unlike associatedStreet, which contains all street ways sharing the same
> name and can thus contain networks of essentially unbounded complexity,
> these relations should probably only span the stretch between two
> junctions, though.
>
> While I would want to cobble together a proof of concept implementation
> to be sure that I'm not overlooking anything, such a relation would
> probably to solve the issue from a data consumer point of view. Of
> course, it would have to actually be used by mappers to be helpful.
>
> > Just to clarify, the road can keep all of its same data as is currently
> > mapped. This would be an additional piece of information that tends to
> > go unmapped.
>
> In theory, the two approaches could peacefully coexist as long as tags
> for kerbs, parking:lane etc. on the street ways themselves (and
> highway=crossing nodes) remained available after drawing the separate
> ways – at the cost of duplication and therefore additional maintenance.
>
> There are some hurdles, though. Even mapping just sidewalks as a
> separate way tends to break stuff. For example, people understandably
> connect incoming footways only to the sidewalk way, not to the street
> way. So an application that filters out these separate ways, hoping to
> instead rely on tags on the street way, will find itself with missing
> connections to the pedestrian network.
>
> Of course, connecting the sidewalk to the highway with a relation would
> likely offer a solution to that issue, too.
>
> Tobias
>
> ___
> 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] Mapping curb (kerb) lines as the home of curb, parking, etc information

[Nick Bolten]

> Can we please first define a solution (e.g. a relation) for connecting
such separately mapped components of a road to the highway?

I agree, this is a very important issue and it happens for a lot of
different situations - a lot of different features that can and are mapped
separately would benefit from a street <-> separate feature mapping. This
is the incentive behind mapping streets, auto lanes, bus lanes, bicycle
lanes, sidewalks, verges, etc. on the street: the relationship query is
unnecessary, the information is shared in the way.

Stable IDs would help with this problem, but I haven't seen much traction
behind adding core features to data types. What would you think of a new
'associatedStreet'-style relation that would organize the various features
that should be associated between streets and the surrounding environment?
Example members (with no particular naming/role conventions in mind):

- The street way(s).
- Any separate bicycle way(s).
- Left sidewalk way(s)
- Right sidewalk way(s)
- Left curb(s)
- Right curb(s)

Other info that *might* benefit from either this or a similar relation:
- Building(s) / addresses (as France does)
- Greenways (trees / tree lines / verges)
- Traffic islands (a common use case for barrier=kerb ways
- Some street signs (some should probably be in a different relation
involving more than one way)

This is certainly a lot of members, and not all are necessary, but I think
there's value in traversing between these data in, as you mention, a
machine-readable way.

> This fundamental limitation really needs to be addressed before we
consider splitting roads into even more parallel ways.

Just to clarify, the road can keep all of its same data as is currently
mapped. This would be an additional piece of information that 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 (e.g. a relation) for connecting
> such separately mapped components of a road to the highway?
>
> Painting lines next to each other fails to express the important
> information that this kerb/sidewalk/cycleway is part of that highway
> over there. Such missing information may be easily guessed by a human
> viewer, but it's currently not available in a machine-readable form.
>
> This fundamental limitation really needs to be addressed before we
> consider splitting roads into even more parallel ways.
>
> ___
> 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] Mapping curb (kerb) lines as the home of curb, parking, etc information

[Nick Bolten]

I'm also a fan of the dedicated line, my primary interest being pedestrian
accessibility + QA-ability of such data.

I keep thinking, "hey, I'll go map a curb line!" and run into a related
issue: I can definitely map barrier=kerb and kerb=raised when one of those
exists along a path - could be near a sidewalk, could be a traffic island,
etc. But would it be an oxymoron to map barrier=kerb and kerb=flush (or
kerb=lowered)? I don't think I would call that a barrier. However, it is
definitely what happens to the curb along most city blocks - transitions
from raised to lowered to flush to rolled. I would find it much more useful
to know the curb state along a continuing line (set of ways) than to see a
bunch of disconnected kerb=raised lines or a kerb=raised line with kerb=*
nodes indicating a change (particularly since direction is ambiguous for a
node).

All of this is to say, 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:
> >
> > Putting aside the preexistence of barrier=kerb + kerb=* on lines, do you
> mean we should put kerb=* on a sidewalk line, a road line, or both?
>
>
> I would prefer a dedicated way for the kerb, and would not tag it on the
> road highway. Also using a node at the intersection of the kerb with the
> crossing footway/cycleway (at crossings) seems safe.
> Eventually it could be considered adding kerb information on a sidewalk
> way (as the lesser evil).
> On a road way the resulting fragmentation would be undesirable and the
> kerb information belongs more to the sidewalk than to the road way (IMHO).
>
> 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] Mapping curb (kerb) lines as the home of curb, parking, etc information

[Nick Bolten]

More detail means more information and barrier=kerb on ways has existed for
about a decade. I'm interested in hearing pros and cons of different
strategies, if anyone is interested.

On Mon, Mar 4, 2019 at 6:32 AM yo paseopor  wrote:

> It is the same story again and again.
>
> -First was the node and ways. And some classification . It was not enough
> -Second arrived relations. but when you want to specify more..it is not
> enough
> -Then it was other tags like classification, lanes, sidewalks...  it is
> not enough if you want to make all the details.
> -Then arrived the area mapping to make it more realistic. But only for
> some items as sidewalks.
> Congrats , now we need the detail of a kerb drawed as an area.
>
> I think best way at first is using the same tagging we have for kerb
> https://wiki.openstreetmap.org/wiki/Key:kerb
> https://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 8:13 PM Nick Bolten  wrote:
>
>> 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 short version is this: if we put kerb=* on a line and call it its own
>> feature, what's the best tagging schema to use and what kind of additional
>> information is appropriate? Personally, I'd like to use (and recommend) the
>> existing kerb=* tags around blocks and potentially add parking information.
>>
>> Potential mapping and data use cases:
>>
>> - Public parking data: curbs are already marked with parking / stopping
>> information, and when motor vehicles stop at a curb they are meant to
>> follow the local regulations regarding access. Curbs seem like a natural
>> place to store this information: you can split the way whenever the parking
>> situation differs or where there are dedicated parking slots. It is
>> attractive to associate streets with parking information, but if one were
>> to split street ways whenever parking information changed, every city block
>> would become an incomprehensible, split-up mess.
>>
>> - Streets as areas: there are a few schemas out there about mapping
>> streets and related features as areas, primarily for rendering purposes.
>> Mapping the curb is fully compatible with, and part of, these proposals,
>> and could provide a means of building up to fully mapping contiguous areas.
>>
>> - Pedestrian crossings. I would be very excited to map out kerb=* ways
>> around every block I see, because it makes QA (and even safe,
>> semi-automated edits) for pedestrian accessibility so easy. All a validator
>> has to do is check that a highway=footway crosses a kerb=* way and lacks
>> its own kerb=* node. This is similar to the validators already used in JOSM
>> and iD that check for things like a footway or street intersecting a
>> building, reminding users to use covered=* or tunnel=*.
>>
>> - Pedestrian islands. These are often just an assembly of raised curbs
>> intended to protect pedestrians that are doing a multi-part crossing of a
>> street or streets.
>>
>> - Opportunity to merge with + simplify micromapped stairs: what are
>> stairs but a series of carefully-raised "curbs"? I've seen various
>> proposals regarding how one might map large, beautiful, public stairways.
>> This is a whole can of worms, but the information in describing a physical
>> curb is essentially the same as describing any 'stuff on the right is
>> higher than stuff on the left' interface.
>>
>> Thoughts?
>> ___
>> 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