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