<div dir="ltr"><div dir="auto">Just a quick note that the prototype only has primary and above loaded in, although there's a few secondary roads that got incidentally added via editing when we pulled in certain routes. The intent of the demo was specifically focused on differentiating motorway/trunk/primary and to keep the file sizes small for collaboration.<div dir="auto"><br></div><div>Your observations that primary and below deserve a stronger focus is well noted. So far we've focused on trunk simply because it seems to be the most broken and needed an interstate definition. Feedback/collaboration welcome on how to craft definitions for the lower classes. The wiki talk page[1] and github issue tracker[2] are probably the best collaboration spaces for folks that don't use Slack.</div><div><br></div><div>Wiki page with draft definitions:</div><div>[1] <a href="https://wiki.openstreetmap.org/wiki/United_States/Highway_classification">https://wiki.openstreetmap.org/wiki/United_States/Highway_classification</a><br></div><div><div><br></div><div>Github repo where we're hosting the data files and demo scripts:</div><div>[2] <a href="https://github.com/ZeLonewolf/us-highway-classification-demo">https://github.com/ZeLonewolf/us-highway-classification-demo</a><br></div><div><br></div><div><br></div><div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 14, 2021, 8:13 AM Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.com</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"><br>
"Brian M. Sperlongano" <<a href="mailto:zelonewolf@gmail.com" rel="noreferrer" target="_blank">zelonewolf@gmail.com</a>> writes:<br>
<br>
> I've been working with a group of mostly Northeast mappers (shout out to<br>
> aweech, Zeke Farwell, adamfranco, Rassilon, ZLima12, Kevin Kenny &<br>
> compdude) to develop new highway classification standards[3] that we're<br>
> hoping can evolve into replacement highway classification standards. The<br>
> new guidelines that we've drafted emphasize road importance and through<br>
> connectivity, to ensure that map renders at lower zoom levels can<br>
> appropriately show long-distance road connectivity between population<br>
> centers.<br>
<br>
In general I think what you are proposing is a good thing. I guess part<br>
of it is separating the three concepts physical, functional, and usage<br>
metrics, and part of it are two arguments about which of those<br>
primary/secondary/ and so on should be controlled by, and then how<br>
rendering decisions (both color and whether to show are made. Given the<br>
problem of how the default render has more influence than it should, I<br>
can see the point that making the adjustment by<br>
primary/secondary/etc. classification is the only viable path.<br>
<br>
> [3] <a href="https://wiki.openstreetmap.org/wiki/United_States/Highway_classification" rel="noreferrer noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/United_States/Highway_classification</a><br>
<br>
I do think that what I view as the previous consensus that trunk be<br>
physically "almost motorway but not quite" is an important concept, and<br>
certainly should be tagged and arguably renders should show it. But I<br>
don't think it's necessary that it control highway=trunk. I see the<br>
proposal basically says that near cities, if it isn't the old defintion<br>
physically, it shouldn't be trunk, but trunk can be used for physically<br>
lesser roads that are still a big deal. US 20 in Wyoming might be a<br>
good example. So I like that part of the proposal.<br>
<br>
What's missing is how to use secondary and tertiary.<br>
<br>
We used to have a notion that in MA, all state routes were at least<br>
secondary. I think that continues to make sense in most cases but I<br>
don't know how that lines up with the labeling below.<br>
<br>
> While developing these guidelines, we discovered that the MassGIS<br>
> "functional classifications" mapped quite nicely to functional highway<br>
> classifications, however, the "trunk" classification was under-used<br>
> compared to its place in the hierarchy. This is likely the result of a<br>
> 9-year old MassGIS road classification mapping which did not map anything<br>
> to trunk. On review of the current mappings, we believe that the following<br>
> mappings make sense:<br>
><br>
> F_Class 2 -> highway=trunk<br>
> F_Class 3 -> highway=primary<br>
> F_Class 5 -> highway=secondary<br>
<br>
and what about tertiary/unclassified?<br>
<br>
> In many cases, the mappings above are already implemented in the map, and<br>
> some would need to be changed. There are a small number of outliers to<br>
> this mapping that we may want to consider documenting as exceptions, such<br>
> as local routes through Fitchburg and in the Plymouth area that are<br>
> probably more appropriately mapped lower than trunk.<br>
<br>
I wonder how much of that is a bug in the MassGIS data. (I think<br>
really this is MassDOT data made available via MassGIS.)<br>
<br>
> In order to "try before you buy", we've stood up a temporary prototype<br>
> render[4] to demonstrate what the regional road network would look like if<br>
> we adopted these changes in highway classification. This stripped-down<br>
> render shows only roads, boundaries, and city names, and is rigged to<br>
> suppress rendering of primary and below until higher zooms, so you can<br>
> better see the motorway/trunk road network.<br>
<br>
When I look at this, I see<br>
<br>
> The prototype render has implemented highway reclassifications for four New<br>
> England states only: NH, VT, MA, and RI. In addition, Washington State has<br>
> also been reclassified in this prototype. Note that these changes are ONLY<br>
> in this prototype and not in the live map at <a href="http://osm.org" rel="noreferrer noreferrer" target="_blank">osm.org</a>, and you can compare<br>
> the two maps side by side to see the difference.<br>
><br>
> [4] <a href="http://74.97.52.189:6789/openstreetmap-carto/#8/41.965/-71.084" rel="noreferrer noreferrer" target="_blank">http://74.97.52.189:6789/openstreetmap-carto/#8/41.965/-71.084</a><br>
<br>
I went to look near me, and the zoom 8/9 look good. The road from<br>
Gardner to Keene NH being trunk is interesting as I don't think of that,<br>
but I can easily believe that it's a big deal at the 50 km scale, an<br>
indeed I have personally used it to drive to mid Vermont. So that seems<br>
positive.<br>
<br>
At zoom 10 I see primary pop in, and much of that is ok but it seems<br>
kind of strange. Near Marlboro, the bit about the Rt 85 connector and<br>
85 up to 62 and west beyond 495 qualifying but not 62 to Bedford doesn't<br>
make sense.<br>
<br>
Going to zoom 11, I don't see 117 and 62 appear, and they should.<br>
Certainly these should be secondary; they are very important when<br>
driving to 5 towns away, but not important when driving from Boston to<br>
Worcester.<br>
<br>
I think either the illustration doesn't show what I want to see, or I am<br>
misunderstanding it. I wonder if it's possible to show all roads with<br>
proposed changes, with the scale-dependent visibilty that the default<br>
scale now has?<br>
<br>
Or perhaps this is only meant to show what counts as primary, and the<br>
rest is to be figured out? If so, I don't mean to complain about it.<br>
<br>
My big comment is that the proposal doesn't address<br>
tertiary/unclassified. Two separate thoughts:<br>
<br>
1) I've long thought that there should be an idea, which really is<br>
aligned well with what you are proposing, that e.g. tertiary should<br>
mean something like "tertiary is a road thought of as 'the way from<br>
here to there' relative to two places (defined broadly) that have<br>
about 10000 people each". Or maybe some smaller number, or maybe that<br>
number floats with density. Basically in MA, roads that are the main<br>
paths between towns, at the Central Mass town scale.<br>
<br>
2) In the UK, they have this "Unclassified" notion. That never made<br>
sense to me until I drove there. Their A/B/C are really functional<br>
classifications; some A roads are like small US Highways (everything's<br>
narrow but I'll ignore that). By the time you get to C, they are very<br>
minor. I really remember only one U road, and it went from a very<br>
small town through a tiny village (cows in the road almost) back to<br>
the main road. The main road into to the village was a C. The U road<br>
was one lane and you'd have to back up to a passing place if you met<br>
another car -- but we didn't. Still, it had a number. (I can't find<br>
this now).<br>
<br>
Here, we sort of have "if it doesn't merit tertiary or higher, call it<br>
residential if it has houses, and unclassified if not", and that<br>
doesn't really make sense. The UK "unclassified" is really a formal<br>
designation and probably should have been "quartiary". In the US,<br>
whether roads have houses is kind of random and not all that<br>
correlated.<br>
<br>
So I tend to want to get rid of highway=residential, replace it with<br>
highway=local (meaning any legal road that you don't use to get from<br>
here to there, only to get to a particular place that is part of<br>
here), and use highway=unclassified from "how to get from one part to<br>
10kish-town to another part, or perhaps "how to get from a 1k place to<br>
a different 1k place". Once arriving that that, given avoiding churn,<br>
I want to just drop the "houses" part of residential, and say that<br>
highway=residential means what I said about above highway=local.<br>
<br>
> Would the Massachusetts mapping community support adopting this MassGIS<br>
> functional class mapping, either with or without documented exceptions?<br>
> For anyone that wants to get involved with this effort more deeply,<br>
> collaboration is welcome, and we continue to discuss and work out the kinks<br>
> on Slack, in channel #local-us-northeast .<br>
<br>
I think this is heading to something I could support pretty strongly.<br>
Hopefully my comments made sense.<br>
<br>
(It's unfortuante that this is on Slack; I don't think open data<br>
projects should use proprietary platforms.)<br>
</blockquote></div>