[Talk-us] US Trunk road tagging

[MoiraPrime]

Presently multiple mappers in the US northeast are working together to reclassify highways in the region that go by the previous trunk classification into one that isn't based on physical characteristics but instead on the importance of the road. This kind of work though is focused on long range routes though, and obviously inside large cities are different. The work is being discussed on \#local-us-northeast in the OSM.us Slack.


Sent from ProtonMail mobile




\-------- Original Message --------
On May 6, 2021, 2:35 PM, Minh Nguyen < minh at nguyen.cincinnati.oh.us> wrote:
Vào lúc 21:41 2021-05-05, Adam Franco đã viết:
> At this point I'm thinking of the
> highway=trunk,primary,secondary,tertiary,unclassified,residential values
> as simply funny labels for descending numerical values of
> connectivity-importance. I'm now on board with the position that only
> motorway implies any physical characteristics.
Whoever came up with the original admin\_level=\* framework was brilliant:
by starting out using only even numeric values, it became possible for
some regions to slot in odd values, ensuring a rough consistency across
regions while accommodating important distinctions peculiar to a
particular region. If the admin\_level=7 slot weren't waiting to be used,
I don't know what Ohio and Indiana would've done about townships.
That said, we know from the many discussions over the years about census
and electoral boundaries that a single hierarchy isn't flexible enough
for OSM's diverse use cases. admin\_level=\* works in part because the key
is secondary to the boundary=\* key that indicates the nature of the
boundary. With highway=\*, we have only a single hierarchy, so we argue
about whether it should be based on functional or physical
characteristics or some arbitrary mishmash of both. A more complete
analogy for roads would be, for example, highway=road road\_level=4
access\_control=limited.
Some of the use cases I mentioned in \[1\] would need to avoid a
hypothetical road\_level=\* key in favor of something else, some
combination of expressway=\* or access\_control=\*, width=\*, maxspeed=\*,
and highway=motorway\_junction (which, after all, isn't limited to
motorways). That's fine, but it would place a premium on complete
coverage of these tags, on top of all the work it would be required to
migrate existing data, editors, and data consumers off of the current
highway=\* keywords. All told, it would be the most ambitious, invasive
change we make to OSM since the license changeover. Are we stuck between
that and endless trunk debates, or are there other solutions?
\[1\] https://lists.openstreetmap.org/pipermail/talk-us/2021-May/021023.html
\--
minh at nguyen.cincinnati.oh.us
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Talk-us mailing list
Talk-us at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20210506/6a525593/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - EmailAddress(s=MoiraPrime at pm.me) - 0x0E8CEA74.asc
Type: application/pgp-keys
Size: 697 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20210506/6a525593/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20210506/6a525593/attachment-0001.sig>