Hi-

It kind of undermines the distinction between trunk and primary if trunks can go nowhere. There's more or less nothing in the Keewenaw, and surely the downtown portion of US 45 in Ontonogan isn't a major route between significant cities?

Is the idea that all us routes must be trunk, or that if any piece of a route is trunk the whole thing must be?

It seems that some number of these are culvert crossings that had a layer=1 on the highway, for example osm.org/way/827126779 . I've just adjusted several in an area several miles on a side.

I only checked several of the ways, there are more than a couple that do not have surface information, which lead me to believe that no survey was done on those ways.

Seems a different prep workflow might make sense if the survey isn't going to follow shortly after the removal.

I simply didn't correct the existing tagging (you'll see that it is also present on your edit to version 13 and also earlier versions).

I guess there's an argument that I shouldn't have removed the tiger:reviewed tag, but I think it's pretty okay to remove that if the geometry, classification and name are reasonable.

Hi-

The 'name' tag is for proper names of individual things. A well known tree with a special name would get the tag, but the type of tree should go in the genus and species related tags. If you want the common name available in OSM, it could go in the "species:en" tag.

Thanks,

Max

Yeah, there's not really one standard, people do it both ways. That's why I explained my reasoning.

There's not another established way to capture the separate opening hours and things like the drive through (where places may sell a couple non pharmacy items in addition to prescriptions through the window but certainly not anything from the store).

People not going to SS Marie will cut over to US 2, it's the actual trunk road.

These changes should have started with a good wholistic plan for the region, not just been thrown into the data to be fixed.

This is silly. M 35 isn't a more important route than US 2.

Please discuss changes like this on a mailing list or whatever before carrying them out.

Sorry, hit the button too fast. An example: osm.org/way/669491244

You also added a source= tag there without making any substantive changes to the way. That's not a good approach.

Please don't overwrite more specific values of building= with building=yes.

Hi-

The convention for addr:state is the 2 letter postal abbreviation.

There is a search to select feature in the Java based editor that makes it pretty straightforward to address a change like is needed here. Happy to walk you through how to do it, or alternatively, I can carry out the changes myself.

Max

Hi-

The convention for addr:state is to use the two letter postal abbreviation. It's not a big issue, just wanted to give you a heads up before doing anything.

Max

Hi, there's a widely used tag for sections, osm.wiki/Tag:cemetery%3Dsector (I've changed them here, just explaining the change).

I have no idea what I might have been thinking.

Anyway, I fixed it to make sense.

Hi, I just changed a fair number of addresses from Az to AZ (looks like a typo on some changesets) and came across a few duplicates, like osm.org/way/979395140

Since you appear to be familiar with the area, figured I would flag it to your attention.

I did get rather frustrated with you, because you were completely uncommunicative and were doing make-work that generated make-work. My initial messages were probably blunt too, because that's the way I am.

The problem is that a "standard" isn't a local thing, it should align with wider practice, which is easy to demonstrate that your choices of refs have not: http://overpass-turbo.eu/?Q=%5Bbbox%3A%7B%7Bbbox%7D%7D%5D%0A%5Bout%3Acsv(highway%2C%20name%2C%20ref)%5D%3B%0Away%5Bhighway%3Dprimary%5D%5Bref~%22BL%7CBusiness%22%5D%3B%0Aout%3B&C=36.50081;-81.09833;8

(Move the map to an area of interest and click "Run". It's written to match way refs with "BL", "BUS" or "Business" in them, outside of the areas you edit, Business is the overwhelming result.)

The MDOT classification is useful information, but there's not a fixed, objective mapping between MDOT classifications and OSM highway tag values, so it's just information.

In OSM, the physical characteristics can be encoded directly, the "highway" tag does not necessarily need to account for them. So we can do things like evaluate whether short stretches of road are truly different in kind from adjoining longer stretches, or if they are just overbuilt for no apparent reason.

The MDOT classification could also be recorded in an additional tag, it doesn't need to be mapped in some absolute fashion to the value chosen for the highway tag.

As a collaborative project, instead of each mapper flipping the classification to their preferred estimation the second they see something they don't like, there can be some discussion and consensus, and things will work out fine.