[Tagging] RFC: pedestrian crossing as an area

Thu Jan 13 22:13:32 UTC 2022

Certainly an approach similar to the bridge or highway may sometimes be
useful.
But in any case we should also map some footways/cycleways/foo-cycle-ways
within those outlines for use by routers.

Apart from that we could apply all the tools that apply to street ways also
to crossing ways, like the lanes= and :lanes= schemes for separate, but
adjacent foot-cycle-crossings. With that you could easily handle tags like
width, surface, ecc.
I have not done it yet with that level of details, but the tools are
available already.

On Thu, 13 Jan 2022 at 22:57, Minh Nguyen <minh at nguyen.cincinnati.oh.us>
wrote:

> Vào lúc 09:01 2022-01-13, Brian M. Sperlongano đã viết:
> > My gut reaction is that pedestrian crossings can be adequately modeled
> > as a center line and width (similar to roads with width and/or lane
> > tagging).  While mappers are free to innovate and come up with new ways
> > to map in increasingly greater detail and specificity, I think that the
> > "approved" tag that ends up on the wiki after an approved proposal sends
> > a specific signal to mappers.  And that signal is not just "this is the
> > community recommendation on how to tag X" but also, and the point I want
> > to express here, that "feature X should be mapped".
> >
> > I feel that a pedestrian crossing areas (in US English I'd describe this
> > as "the area of a crosswalk") fits into a category that's increasingly
> > described as "nano mapping".  I seem to recall somebody proposed to tag
> > the area of individual road markings - the dashes and arrows and so
> > forth painted on the road, and I see this as a similar "nano" feature.
> > I'm confident that there are plenty of other things left to map in the
> > world before we need people individually tracing painted road markings
> > just to keep busy, so there should be no rush to apply that green
> > "Approved" label.
>
> In practice, the "Approved" status doesn't dictate anyone's personal
> priority in mapping or consuming a tag. It's sort of a protection
> against a mapper getting bogged down by arcane tag design questions when
> all they want to do is map something they see. It would be a different
> story if, say, an editor were to color-code all the tags in the UI by
> their approval status.
>
> If we want the status to carry more weight on a personal level, we'd
> have to conduct a review of the wiki's historical approvals to achieve
> some sort of editorial balance. There are a *lot* of cultural and
> lingustic assumptions about priorities baked into in our tagging system,
> especially if you filter it by nonorganic criteria like approval status.
> But an audit of approved tags would be a big project and for
> questionable benefit, considering that there are other ways to influence
> mapper behavior, and data consumers have their own motivations beside
> maximally hewing to the wiki.
>
> Regarding the proposal at hand, I don't think pedestrian crossing areas
> are as blue-sky as they might've seemed three or four years ago. When
> this topic came up on this list last May, I gave some examples of
> crosswalks in parking lots of big box stores, which have to be
> represented as multiple crossing nodes for topological reasons. [1] It
> would be nice to visually collect them into a single geometry, not
> unlike how we visually associate the various components of a bridge
> using a man_made=bridge area.
>
> Enough pedestrian infrastructure has been mapped that it's only natural
> for some mappers to want to go into more detail, especially for edge
> cases that aren't as straightforward as a buffered centerline.
> Proprietary road datasets in some regions like Japan have long featured
> this kind of detail, and it's starting to become more common among
> global datasets too.
>
> Our standards as a project have been trending towards more detail for
> years. For a sense of perspective, the legend on osm.org still says
> building=* is only for "significant buildings" [2], a line unchanged
> since 2009 [3], but tell that to anyone who's ever participated in a
> building import. It wasn't too long ago that private driveways were only
> mapped in exceptional cases, and U.S. mappers were actively engaged in
> deleting driveways that had been accidentally imported from TIGER, but
> then Amazon Logistics came along.
>
> None of this means a novice mapper would be hounded for not mapping a
> crosswalk as an area, even if we approve a tag for it. But it would
> proactively ensure that, when someone does get carried away mapping
> crossing areas, they're less likely to make a shortsighted decision in
> how to tag them.
>
> It's interesting that you bring up road markings. Several years ago,
> someone added thousands of solid stopline markings to my city. It was
> frustrating, but mostly because they used a poor tag on many of them,
> creating work for the rest of us. (To their credit, they did follow
> through with a mass retagging.) The road_marking=* key may be
> underdocumented and "highly experimental", but its relatively
> straightforward documentation is better than nothing. [4]
>
> [1] https://lists.openstreetmap.org/pipermail/tagging/2021-May/061481.html
> [2]
>
> https://github.com/openstreetmap/openstreetmap-website/blob/c34ed1e3706020c59aa8dc70ece41c36a8a30930/config/locales/en.yml#L2193
> [3]
>
> https://github.com/openstreetmap/openstreetmap-website/commit/079b9fed845b429436c5e84c221154b64c500103
> [4] https://wiki.openstreetmap.org/wiki/Key:road_marking
>
> --
> minh at nguyen.cincinnati.oh.us
>
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220113/8baba7ac/attachment-0001.htm>