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?

You’re right, I must’ve duplicated that one, forgot it, and duplicated it again as a starting point for the next medallion. Thanks for your vigilance. Fixed in changeset 146532532.

Thanks, that’s definitely an improvement. I retagged the POI in changeset 146205486.

Since the linked proposal mentioned hotels, I wonder if I should also use it for a dormitory lounge like osm.org/node/8562709678 . I’ve previously used amenity=clubhouse, but that tag got co-opted by a more literal meaning of “club house” that got rejected. It seems closer to a layperson’s definition of a “lounge” than a “clubhouse” anyhow.

Looks like the individual ways got added to the I-11 superrelation instead of the northbound and southbound route relations. They need to be moved to these relations:

osm.org/relation/14104671
osm.org/relation/14104672

Other than highway=motorway, the highway=* key does indicate a functional classification of sorts, just not necessarily the classifications that Caltrans has determined using the FHWA’s framework. There are various reasons for this, including different incentives like funding levels.

There is a separate osm.wiki/Key:HFCS key for indicating the official FHWA/Caltrans functional classification of a given road. Mainstream renderers and routers don’t use it yet, but that’s because the mappers who added most of this data are no longer active within the project. You could help to revive this form of mapping, at least here in California, where we can copy from DOT maps without infringing on copyright.

The choice to depart from FHWA/Caltrans functional classification is not mine or willkmis’s, but rather that of the project as a whole. If you disagree, you need to take this up with the wider community on the forum: https://community.openstreetmap.org/c/communities/us/78 . Otherwise, your work is inevitably going to get undone by passers-by in a matter of weeks, but much more haphazardly than the systematic tagging that willkmis did.

The Trunk Road preset’s lack of a bike lane field is a simply an oversight. Please report issues like this in https://github.com/openstreetmap/id-tagging-schema/issues . Thanks!

Thanks for looking into amenity=lounge. I agree we need a tag for lounges – not just for airport lounges, but also for less exclusive lounges, like at train stations. That said, judging from http://morganhillbowl.com/strixe.html , I think this one might be better described as a sports bar.

There was never a solid consensus about consistently using highway=trunk to denote an expressway. In 2022, the project decided that expressway=yes is the tag for an expressway, not highway=trunk, at least in the U.S.

Thanks!

https://community.openstreetmap.org/t/large-scale-change-of-traffic-sign-to-traffic-sign-id/107508

Looks like the GitHub authentication option was removed in https://github.com/OpenHistoricalMap/issues/issues/389 because it wasn’t set up correctly and no one had been asking for it.

I’d keep “JT Express” in old_name and any other defunct attributes you think are still relevant in disused:*=* tags.

I think it should be feasible for OHM to support more login providers besides OpenID. Feel free to file a request at https://github.com/OpenHistoricalMap/issues/issues .

JT Express used to have “Jimbo’s and Tengu Sushi” in their logo, in small type. Come to think of it, that would make it more of a strapline=*, since probably no one referred to it by that name. I’ve also added name:etymology=* per your suggestion.

There aren’t any hard-and-fast rules about how to name a chronology relation – it’s basically whatever you’d call the historical account if you were to write an article about it. So sometimes I go with the most recent name; other times the name by which it was best known.

Mergers and splits can get tricky. Since the JT Express relation also serves as a chronology for the pre-merger Jimbo’s, I’ve added that as an alt_name. In general, though, I’ve used a POI’s membership in two different chronology relations to indicate a merger.

There could be a chronology relation to track the occupants of a storefront over time. I haven’t gotten around to making them for most of the shops I’ve mapped, but I had a bit of fun with this one: https://www.openhistoricalmap.org/relation/2749168

https://www.openhistoricalmap.org/changeset/103779 maps the history of this space, including Jimbo’s and Tengu Sushi that merged into JT Express and the upcoming Spread. I think we can safely remove the data about JT Express from OSM now; nothing actually supports the date suffix tags, despite what some wiki pages recommend.

Moved to OpenHistoricalMap in https://www.openhistoricalmap.org/changeset/103581

Someone should probably start a forum discussion eventually about whether flag:type is even necessary on features that already have flag:wikidata, since Wikidata’s flag items convey these distinctions a lot better. It’s not as though a national flag is automatically larger or less worn out than a regional one.