Speed limits measured in miles per hour must have the suffix “mph”; otherwise, they’re interpreted as kilometers per hour.

(Coming here from a brief discussion in OSMUS Slack.) The discussions about COGs on that wiki talk page may not be 100% applicable to this case, since the MPO function is only one of Metro’s functions. Unlike every other COG or MPO, Metro has at the very least an electoral boundary.

That said, I’d argue that Metro still fits neatly within the definition of a special district. Special districts defy boundary=administrative’s rigid admin_level hierarchy. For example, according to https://www.oregonmetro.gov/sites/default/files/2020/02/19/JurisdictionRegional.pdf, the Metro boundary has a complex relationship with the Hillsboro and Tigard city boundaries. Such complex relationships are also common with admin_level=7 townships in some Midwestern states, but they are the rule rather than the exception when it comes to special districts.

You’re right that boundary=administrative isn’t strictly limited to “full governments”, but data consumers have come to expect boundary=administrative relations to represent the principal political subdivisions of the containing boundary=administrative. While one may consider a given location in Portland to lie within the Metro boundary for some purposes, it would be a stretch to say that Portland is subordinate to Metro in general.

There have been some experiments with tagging other kinds of special districts, such as relation/9992727 and relation/6534979 for school districts, but I’d hope it isn’t common to overload boundary=administrative for this purpose. I agree that boundary=MPO is an inadequate tag for this boundary. Since Metro serves multiple distinct purposes, perhaps it’s time to coin a new boundary=special_district tag. We could probably find enough existing special district experiments in OSM to justify a wiki page about them.

Also, you probably noticed that the access road was replaced by one just a couple yards over to the east. In the future, please consider adding the replacement road. After all, a missing road is worse than a misaligned one.

OK, changeset/105516179 replaces junction=roundabout with junction=circular, which is more general, but keeps the circular way to retain that level of detail.

Hi, please don’t replace properly mapped roundabouts (even minor traffic calming roundabouts) with the traffic_calming=island tag. Oversimplifying the roundabout creates ambiguity about the relationship of the roadway to the objects inside the island, such as node/6511629050 .

Hi, these stubs are already built, not just proposed. It’s important to map these stubs as one-ways; otherwise, when a driver hears a voice instruction for this roundabout, the exit count will be off by one. This situation occurs frequently in areas that are being built in phases, so I’d suggest sharing this information with your colleagues. In the meantime, I reverted these changes in changeset/105110930. Thank you for your attention to this matter.

This was based on the SCCProperty2 layer tagged on this changeset. Normally when I encounter a building with individual units in that layer, I add points for each of the units and then tag some of them with the information from the SDP dataset. That way we aren’t left with a false sense of having completed the per-unit mapping of the building.

In this case, it does look pretty messy. I wonder if the layer incorporated a combination of different data sources, none of which accurately positioned the units within the building. Since the data is suspect, we can remove it in favor of a proper survey.

This changeset incorrectly changed San Francisco into a speed limit enforcement relation. I changed San Francisco back into an administrative boundary in changeset/103293987, but if you had intended to add a speed limit enforcement relation for N. Five Points Rd., you may want to go back in and try again with a brand new relation. Let me know if you need help with that.

That was the general sentiment a long time ago, when we were daunted by the challenge of mapping every road and meanwhile found it annoying that imported TIGER roads often misclassified driveways as through roads. (If I’m not mistaken, at the time, the map legend in the right sidebar even said that the building polygons were only for “important” buildings.) These days, OpenStreetMap has evolved to consider any driveway and building important enough for inclusion in the database.

You can use http://revert.osmz.ru/ to revert this changeset before someone comes along and creates a conflicting edit (which most likely would recreate some of the driveways). If there’s already a conflicting edit by the time you get to it, just ask and one of us can help you out with it.

Years-old mailing list threads can still be useful for context on perennial debates in OpenStreetMap, but it’s best to take them with a grain of salt and ask around for second opinions. You can subscribe to that mailing list at https://lists.openstreetmap.org/listinfo/talk-us/ or ask the larger U.S. community in OSMUS Slack (https://slack.openstreetmap.us/ ).

Fixed in changeset/8195579319.

Campos is the owner’s last name, not the Spanish word for “camp site”.

This changeset overwrote intentional differences between Wikidata labels (which are optimized for page titles) and OSM name tags (which are optimized for map labels and, in some cases, place more weight on on-the-ground usage). Some of these changes have since been undone, but the rest of the changes may need review – similar to what happened to the place POI and boundary for Washington, D.C.

Some of the addresses in this batch wound up getting assigned to garages or carports instead of houses.

bridge_ref was far and away the more common tag until this year, well after I uploaded this changeset:

http://taghistory.raifer.tech/#***/bridge:ref/&***/bridge_ref/

The mention of bridge:ref at bridge=*#The_building_number is somewhat obscure, so I was unaware that the less common key was the one that was documented.

I changed bridge_ref to bridge:ref in changeset/100879804.

Yeah, it’s an awkward situation to be sure. To complicate matters, at least one of these locations actually closed for good a few months ago, but we hadn’t gotten around to retagging it until now.

Thanks for taking a look. I see your point, but I’m hesitant to tag ghost signs with the name key because a data consumer could look at the combination of that key and addr:housenumber or shop (as in shop=vacant) and make it look too much like a shop by the name Fry’s. If I were to add a name, it would be to the effect of “Former Fry’s”; I’ve done that on occasion to brownfields that are commonly referred to by their former uses.

My understanding is that, due to the pandemic, these store closings are more abrupt than they normally would be. If there were a liquidation sale or service-only period, it might make sense to keep tagging them as shop=electronics but set opening_hours=closed. I may be wrong though.

Thanks for taking care of that, lonvia. Wikidata’s label quality is high in some languages but poor in others. Quite unlike OSM, most of the QA work there happens along linguistic lines rather than by geography. So IP concerns aside, any panlingual introduction of labels from Wikidata can be messy, as we saw here.

If the route number isn’t signposted, you could ignore the route number for the purpose of road classification. It somewhat surprises me that the route number isn’t signposted in this case, because West Virginia tends to signpost every road number all the way down to HARP driveways.

The wiki page doesn’t require every county road to be tertiary; it’s just a rule of thumb. There are exceptions for sure. In my experience, the majority of fractional county roads would reasonably qualify for tertiary since they don’t dead end, but one that does probably should be unclassified or residential.

Thank you for your explanation. I agree that the website:vi tag was unnecessary, so I left that change alone.

Regarding the name, even though there are language-suffixed name tags, the main name tag is still important as an indication of the primary name that a user will encounter in reality regardless of their language preference. For example, a navigation application may display the actual signposted name instead of the localized name, to facilitate wayfinding. Since no approved tag indicates the signposted language, removing one of the names from the name tag does lose information.

This business was only problematic because it has two equally prominent names in a bilingual neighborhood. If you asked me to keep only the more commonly used name or only the more important language, I honestly wouldn’t be able to decide. Fortunately, it’s a relatively rare situation even in this neighborhood. But there are plenty of cases where the English name is only slightly less prominent than the non-English name. I would argue that we shouldn’t bias the name tag towards English just because English is the most widely spoken language in the country.

Anyhow, I don’t mean to give you a hard time about this edit from long ago. I just wanted to make sure you were aware that there are reasons to want name to be set to multiple values.