Hi, I noticed that some service=shared_driveway got retagged as service=driveway. If you disagree with service=shared_driveway, can you pick one of the other tagging schemes at osm.wiki/Tag:service%3Ddriveway#Pipestems or omit service=*? Some renderers and routers intentionally omit driveways, but they still need to show or route along these shared driveways because there are decision points along them.

Also, thanks for finally completing Warren County’s townships!

Hi, note that place=* tags intentionally don’t correspond to official designations as cities and villages, because they have to be harmonized globally or at least nationally. osm.org/changeset/163881091 changes South Lebanon back to a place=village. The boundary relation already indicates the official designation via border_type=city. For more information:

osm.wiki/Ohio/Map_features#Places
osm.wiki/United_States/Tags#Places
https://community.openstreetmap.org/t/toward-a-national-system-for-functionally-classifying-populated-places/113674

Every member way of the Cary boundary relation has a name=* like “Town of Cary / Town of Apex” or “Town of Cary, Inner Boundary”. Is there a quirk of local law that calls for this naming practice, or was it only for convenience while doing this alignment work? Can we remove the names and the boundary=administrative tags from these ways? They interfere with geocoding, causing Nominatim (for example) to think each ring of the multipolygon geometry is a boundary in its own right.

Source was a survey back in November.

Changeset 163139172 moves U.S.A. to short_official_name=*, which appears to be in use as well.

U.S. is the preferred abbreviation of United States in American English. U.S.A. is the preferred abbreviation of United States of America, which is much more common overseas. Domestically, native speakers only use United States and U.S. in most contexts. U.S.A. only occurs for nationalistic emphasis, like at political rallies or sporting events.

Conventional abbreviations for countries and states in English aren’t defined by governments. Instead, dictionaries and style guides like the AP Stylebook (yes, the one that now includes guidance about a certain gulf) and Chicago Manual of Style include rules about these abbreviations and when to use them. These style guides differ on whether to include periods or not, even depending on context.

Within the U.S. federal government, the Government Publishing Office has its own GPO Style Manual, which specifies U.S.A. as a conventional abbreviation for United States of America, but notably the guide itself consistently uses U.S. throughout as an abbreviation of United States, even though it isn’t listed. Nevertheless, this style manual is only used in legal and administrative publications. [1]

The GPO dropped conventional state abbreviations decades ago in favor of ISO/ANSI/FIPS/USPS codes. On the state boundary relations, we’re putting those codes into dedicated keys or ref=*, reserving short_name=* for conventional abbreviations.

Wikipedia has a good overview of the various authorities for English style. [2]

I was considering swapping the short_name and alt_short_name keys, but I have no idea which one users are more likely to search for. Mainly I just wanted to correct the “U.S.A” which was missing a period. Unlike in some other languages, the last letter of an initialism needs a period too. But now that you mention it, we should list both U.S. and U.S.A. in short_name, since I don’t think
alt_short_name is a recognized key.

[1] https://www.govinfo.gov/content/pkg/GPO-STYLEMANUAL-2016/pdf/GPO-STYLEMANUAL-2016.pdf#page=261
[2] https://en.wikipedia.org/wiki/Wikipedia:Identifying_and_using_style_guides

Reverted in changeset 163109297.

Reverted in changeset 163109177.

Please remember to square the corners of buildings that you draw by hand. You can press the Q key to square corners quickly.

Sorry, I didn’t realize I was getting in the middle of things. Another mapper reached out to me and asked me to take care of Vietnamese.

> Is Vịnh Mexico more common than Vịnh México?

It’s complicated. Vietnamese spelling of foreign place names is notoriously unstandardized, mostly a matter of personal preference. This goes for both the country and the gulf. In Vietnam, Mê-hi-cô is probably the most common “formal” name, being preferred by the government and in educational materials. However, in the U.S., the preferred formal name is Mễ Tây Cơ or Mễ. At this point, neither country understands the other country’s name at all. In both countries, Mexico is very common informally because it’s mutually intelligible and easier to type. Wikipedia’s approach is to use the Spanish name verbatim, which feels more learned: México.

Any of these names could reasonably be the name:vi=* on Mexico, but it’s currently México, so I guess the gulf could also use this spelling.

Fixed the Vietnamese name in osm.org/changeset/161870600

Thanks for fixing it! By the way, Caltrans apparently hasn’t updated a different sign further up that refers to the road by the old name. (That sign is also unusual for the dyadic fraction. Hadn’t seen that before.)

[1] https://www.mapillary.com/app/?pKey=932214371489044

Yeah, sounds like they would’ve removed it anyways. I don’t think Caltrans tracks turnout names as anything particularly formal, other than in project specifications, so we can just remove the name if there’s no sign.

It came from a sign a quarter mile north that appeared in Mapillary [1] and KartaView [2] as late as 2019. Mapillary also has imagery from two years ago, but I can’t tell if the sign was removed or buried under the snow.

[1] https://www.mapillary.com/app/?pKey=489650309015635
[2] https://kartaview.org/details/2057238/9024
[3] https://www.mapillary.com/app/?pKey=199678662548755

osm.org/changeset/160372474 moves this information back to the original Marion County relation; see https://community.openstreetmap.org/t/incorrect-indianapolis-city-limits/122928

Undone in osm.org/changeset/160372474 ; see https://community.openstreetmap.org/t/incorrect-indianapolis-city-limits/122928

The source was https://web.archive.org/web/20241117171033/https://www.caltrain.com/location/stanford-stadium as well as https://www.caltrain.com/news/caltrain-will-provide-big-game-service-cal-vs-stanford-saturday for the fact that northbound trains stop at the southbound platform.

Fixed in osm.org/changeset/160045907

Thanks for your response. I agree that conflating so many real-world features into one node makes it difficult to choose a single Wikidata tag, GNIS feature ID, or FCC ID to put on the node. In my opinion, that’s a sign that collapsing everything down to a node wasn’t a good idea.

I started a discussion on the forum so we can get more feedback on my short-lived experiment:

https://community.openstreetmap.org/t/colocated-broadcast-antenna-structures-nodes-inside-an-area/122626

In retrospect, I think there should’ve been some attempt to engage on a solution before deliberately deleting what clearly had more attention lavished on it than the average GNIS-imported mast. The wiki is not gospel; we can get the community to accept an updated approach, but examples of that approach are necessary for the sake of discussion.

I appreciate that you’ve been quite active in cleaning up our coverage of broadcast infrastructure, but if you happen to run across any other examples of this micromapping, would you mind preserving it until we come to a consensus on how to move forward? Thank you for understanding.