[Talk-us] [Talk-us-newyork] Highway classification guidelines for New York State

Eric Patrick txemt1 at gmail.com
Mon Sep 13 10:59:02 UTC 2021


>
> Though functional classified roads (not by number of lanes of something)
> are very useful.


Number of lanes doesn't determine the functional classification of a road,
though.

As far as I can tell, no mainstream OSM-based router directly penalizes
> a road based on its highway=* value per se. If it lacks a maxspeed=* tag
> and real-time or historical traffic data is unavailable or unsupported,
> then the router would assume a speed limit based on the highway=* value.
>  From what I've seen, these assumptions are usually wrong for... just
> about everywhere.


There's no direct penalty between the highway levels, it's just how they're
assigned as a value. Highway=0, trunk=5, primary=10, etc. The only direct
penalty will come when a value=-1. By assigning a value to those roads in
that order, a hierarchy is being created as to which road is more
important.

 But as elegant as FHWA functional
> classification may be on its own, shoehorning it into the existing
> highway=* tagging scheme would not be as clean as using a dedicated key
> like HFCS=*, because highway=* was originally designed by non-Americans
> who had no idea about the FHWA's specific functional classifications and
> it has come to be used by data consumers who also couldn't rely on FHWA
> definitions.


IF the HFCS= tag did more than be a label, that would work wonders. I also
understand the original designation of highways by the outsiders who didn't
know about American highway systems, but I believe we can use what they
designed, we can use in different terms. A trunk road will function the
same between countries, but the definition may vary. The British have a
definition of a trunk road. The road meets this quality, or is assigned as
such because of XYZ reason, which works for them. A trunk road definition
for America (or any other country for that matter), may be "Primary
Arterial roads are trunk roads." The only thing being changed is the
definition. The trunk road is out there and is coded as such, we're just
looking to change the definition between different countries.

Other Principal Arterials also came up back in May in a discussion about
> correlating the National Highway System to highway=trunk. It's worth
> consideration as a starting point, but I'm pretty sure we'd need to
> distinguish between urban and rural principal arterials. When I looked
> into it for California, I found that this one functional class includes
> a wide variety of roads with starkly different levels of accessibility
> and mobility, even within a single urban area. [3]


I've never really seen a difference between urban and rural arterials in
regards to classification when looking at a map. I've seen the difference
on the ground in regards to a PA being a 2 lane highway in the backwoods of
Georgia vs a 6 lane highway through the middle of downtown Atlanta. That's
the only major difference I've seen.

Sidenote, I haven't seen California's functional classification system.
I've studied Texas, Florida, Georgia, Oklahoma, and Rhode Island's
functional classification system.

On Mon, Sep 13, 2021 at 6:08 AM Mateusz Konieczny via Talk-us <
talk-us at openstreetmap.org> wrote:

>
>
>
> Sep 13, 2021, 10:43 by minh at nguyen.cincinnati.oh.us:
>
> Vào lúc 16:47 2021-09-12, Eric Patrick đã viết:
>
> I have a thought regarding trunks in regards to functional classification,
> and this is going to come from a different viewpoint. Why not make Primary
> Arterials trunk roads, from a coding standpoint. They're coded lower than a
> motorway, but higher than everything else. Any GPS system will use the
> highest coded route, with the fewest penalties, they can get to between
> points A and B. I understand that in doing this, a lot of downtown areas
> will look like a sea of red, due to the density of the Primary Arterials
> within those areas (cue Brian's groan about this).
>
>
> As far as I can tell, no mainstream OSM-based router directly penalizes a
> road based on its highway=* value per se. If it lacks a maxspeed=* tag and
> real-time or historical traffic data is unavailable or unsupported, then
> the router would assume a speed limit based on the highway=* value. From
> what I've seen, these assumptions are usually wrong for... just about
> everywhere.
>
> bicycle-focused and foot-focused ones often try to avoid large roads,
> highway=track is often avoided (though maybe it would not be described as
> a road).
>
> Functional classification isn't going for looks, though, it's going for
> function. The states have spent a lot of time and effort since FC was first
> introduced about a decade ago.
>
>
> OK, but is it a good fit? The highway=* key (other than highway=motorway)
> is defined as indicating the road's importance in the road network. [1]
> That sounds vaguely functional. But the ultimate goal of this key is indeed
> "going for looks", and optimal routing behavior, because OSM data is
> primarily used by renderers and routers.
>
> Though functional classified roads (not by number of lanes of something)
> are very useful.
>
> When I was designing new road style for OSM Carto it was quite irritating
> that in many regions
> people used highway=trunk for "double carriageway road" or "designated as
> expressway".
>
> It made basically impossible to have decent rendering on lower zoom levels
> that would show
> basic structure of a road network.
> _______________________________________________
> 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/20210913/41afb376/attachment-0001.htm>


More information about the Talk-us mailing list