changeset/150279295 reverts this changeset due to incorrect replacement of refs with names and introduction of a bogus one-way street.

There is no consensus yet about whether a roadway’s name=* can refer to a route number, but there is broad agreement that it is incorrect to replace a ref=* tag with name=*, especially based on TIGER. See https://community.openstreetmap.org/t/names-are-not-refs-vs-some-names-are-based-on-refs/109995

changeset/150278166

Reverted in changeset/150277583.

Reverted in changeset/150278020. Placing route numbers in name=* is controversial, but in any case route numbers belong in ref=*.

There is no consensus yet about whether a roadway’s name=* can refer to a route number, but there is broad agreement that it is incorrect to replace a ref=* tag with name=*, especially based on TIGER. See https://community.openstreetmap.org/t/names-are-not-refs-vs-some-names-are-based-on-refs/109995

changeset/150277655

Restored in changeset/149362992.

I think this relation should be restored to a much older version: relation/3839665/history/23 The hundreds of versions since then had individual roadways as members, mostly in Vietnam. I think that’s why it got into a bad state and eventually got deleted.

Ah, thank you for the clarification. Are mappers in India distinguishing between expressway (motorway) as a highway classification and the National Expressway system? As far as I know, the National Highway system also includes some expressways, but there would be no way to know this from how a route like this is tagged, other than to guess that “NH” on the way ref refers to a National Highway.

Hi, was the change from network=IN:NH to IN:NE intentional? The ways all have ref tags that are still prefixed with NH, and I wasn’t aware that a National Expressway could have such a large number. Would this route number be signposted in Roman numerals like the other NEs?

Reverted in changeset/148611921.

https://community.openstreetmap.org/t/tagging-counties-and-planning-regions-in-connecticut/109799

This changeset is being discussed on the forum:

https://community.openstreetmap.org/t/mapping-strip-malls-buildings/109813/12

I was also suspicious of whether this import came from GNS, but it doesn’t have any record of a populated place here. The closest one is a “Ban Ni Kô” that probably refers to the village just to the west.

Thanks for resolving note/363185. At the time, I also reached out to Kapis, the mapper who imported this and thousands of other places in Vietnam in changeset/128575.

Since it had been several years since the import, we were both unsure where the data came from, but he suggested that it might have been from CIREN by permission. If so, then we’d be able to find the data in https://geoportal-stnmt.tphcm.gov.vn/ to confirm.

Other mappers have noted the low quality of this import, so we might want to organize some sort of audit.

I’m pretty sure this was actually a poorly formatted attempt at tagging the rest of the street address. The addresses are located on đường số 22 (street number 22) off of đường Tăng Nhơn Phú (Tang Nhon Phu street).

https://community.openstreetmap.org/t/tagging-counties-and-planning-regions-in-connecticut/109799

Sorry for the delayed response. I don’t think you’d be able to tell a curb from a painted line in 3DEP. Anyhow, you’re right, these are clearly just red painted lines, judging from Bing Streetside imagery. Fixed in changeset/147958271.

Oh nice, I was worried I’d have to start a whole discussion about doing this, but you took care of it already.

Are you sure boundary=political is the best tag for the counties? As I understand it, that tag is for things like congressional districts and electoral wards, which so far we’ve refrained from mapping. As far as I can tell, Connecticut’s vestigial counties don’t have any electoral purpose either. Rather, they remind me of England’s ceremonial counties, which appear to be tagged as boundary=ceremonial. But I think there’s more momentum behind boundary=historic for this sort of thing.

For the new planning region boundaries, the names of the COGs should be in operator=*, not official_name=*, and I think border_type=planning_region would be less confusing. The planning region is the service area of the COG, not the COG itself. By analogy, we don’t tag Australia as official_name=Government of Australia.

I would concede that a junction relation is inessential for a minor, unnamed roundabout such as this. However, I don’t think this mapping style is completely superfluous.

Again, the only reason I bothered creating a relation here is that I had to split the closed way into five ways for accurate routing. It’s already difficult enough to convince mappers of the need to split these nice round ways into little pieces; the ability to group them back together as *one feature* provides a little consolation. Thus, a junction relation is recommended for complex roundabouts like turbo roundabouts. [1]

Furthermore, many roundabouts have an identity of their own. Without a relation, I guess the alternative would be something like roundabout:name=*, roundabout:ref=*, roundabout:wikipedia=*, and so on. If the “one feature” principle really applies in this case, then we should really be having this discussion about man_made=bridge and man_made=tunnel.

I agree with you that relations come with some maintenance overhead in general, but unless you can explain how you were personally inconvenienced by this relation, I think we have much bigger fish to fry. There are still plenty of “route” relations representing non-routes, and right here at this very intersection are some examples of unnamed informal landuse areas that we no longer glue to roadways as a rule.

[1] osm.wiki/Special:PermanentLink/2603707#How_to_get_accurate_geometry

This roundabout cannot be represented by a single closed way because of the routes that traverse it only partially. Including the entire roundabout in one of these routes would inaccurately indicate a loop (and also cause some editors to scramble the member order). Since there’s still only one roundabout despite the multiple ways, I’ve added the ways to a junction relation. Junction relations haven’t been documented formally, but there are a few proposals related to it, including osm.wiki/Proposal:Junction

In theory, a data consumer could use a junction relation to more reliably determine the extent of the junction, but I figured there isn’t any harm in keeping this relation around even if it isn’t actively being used. I’m curious what you’re referring to in terms of complexity and maintenance – did something change about this roundabout that required a change?