There is a mass deletion of address data in California happening right now by one user, which is vandalism. This causes great harm.This is causing significant damage.
Tags affected by this user, which they are simply deleting without discussion:
is_in:country_code, is_in:iso_3166_2, is_in:state, is_in:state_code, place
This damage must be undone as soon as possible.
Here’s a link to this user, and almost all of their recent edits are damaging to California addresses:
The is_in:** tags are old tagging and can be safely removed.
There are also many cases where place is used incorrectly.
Can you give an example of a specific edit which is problematic?
The
is_in:**tags are old tagging and can be safely removed.
This is not true and deletion of that data is a big mistake. Who decided about “safely removed“? There is no any public discussions about it.
Also you have to study this article about Place tag:
The simplest and easiest way would be if that user returned everything that incorrectly deleted.
Sigh.
@Necessarycoot72 is doing cleanup of boundary relations in California. They may be using the US boundary tagging QA checker, which I personally authored and announced two years ago, to fix some of the 1,355 validator findings in California.
I reiterate again – the is_in series of tags are cruft that the US community has been systematically removing from the database for year. The place tag should not be used on administrative boundary relations in nearly all cases – the border_type tag is used to denote the type of boundary. This is the opinion of the US community, which has discussed these issues ad nauseum. I am not new here.
This is not vandalism. This is good, high quality cleanup that needs to be done, and the best thing we can do is to not hassle @Necessarycoot72 while they get on with it.
Can you give an example of a specific edit which is problematic? And explain why you think so?
If “almost all of their recent edits are damaging to California addresses” would be true (at least in your judgment) doing so would be easy for you.
is_in is worthless in areas where boundary relations exist and I’m pretty certain the whole US is covered. Maybe you should read your wiki links😉
You link page with
As of March 2019, JOSM recommends deleting this tag and all its variations[1] as no longer needed.
that links to #17504 (consider is_in:continent for automatic dropping or validator warning with autofix removal) – JOSM
(I originally suggested removal of only one subtag, but it morphed into more general removal and discussion thereof)
That page also has talk page at Talk:Key:is in - OpenStreetMap Wiki which publicly discusses cleanup, with some posts dating back to 2010.
Anyway, thanks for the feedback everyone. I wasn’t aware of the local discussion about the is_in tag. But for me, using place on relations of cities or villages is more important. I’ve been using it for years in different countries, and it’s been fine. My daily world maps for Garmin devices conveniently show which place belongs to which populated region for the last 15 years. Now I’ve discovered that this is “illegal” in the US. Despite the fact that Wiki doesn’t contradict the idea of having a place with an administrative boundary on a relation or polygon. Could someone please give me a more detailed answer on why deleting the place tag is the right thing to do?
PS: I always adhere to the belief that there are no unnecessary tags worth deleting. If you don’t need it, just don’t use it.
Linking specific edit you find problematic and pointing specific objects would be useful, if you wish to discuss edit you are not happy about.
(also, letting know the author of the edit about discussion)
There are a huge number of edits to remove the place tag.
https://www.openstreetmap.org/user/Necessarycoot72/history
My main concern is the edits with the comment “Removed place from *”.
Several links to the problematic changesets:
https://www.openstreetmap.org/changeset/175785611
https://www.openstreetmap.org/changeset/175785605
https://www.openstreetmap.org/changeset/175785598
https://www.openstreetmap.org/changeset/175785591
https://www.openstreetmap.org/changeset/175785586
https://www.openstreetmap.org/changeset/175785586
https://www.openstreetmap.org/changeset/175785586
https://www.openstreetmap.org/changeset/175785583
And so on.
Here are a couple of pictures to help you visualize how this impacts my customers who are used to receiving my fresh free navigation maps every day.
Before:
After:
I tend to agree with @ValentinAK that the removal of the place tags is problematic here. These relations are boundary=census which might make sense as local tagging in the US but has no global agreed upon meaning. The place tag on the other hand is a world-wide accepted generic tag, which can be used by data-users that don’t want to dig into the detailed history of 250 countries to figure out what tags to use to find the area of a place.
By all means, do add the border_type to capture the fine nuances of US place structures but please leave the place tag untouched, so that the OSM data set remains usable on a global scale.
Nothing is “illegal” (that’s a bit of a silly term on a collaborative map project), but conventions that we have come to with discussions over time.
Can you be a bit more specific about what isn’t working with your world maps project? I have personally removed thousands of duplicated place tags in favor of border_type on boundaries over the course of several years (based on quite a few community discussions that this is wrong tagging), and this is the first I’ve heard that there is an issue.
(Edit: in particular, what assumptions/tagging your software is expecting to see)
You may have missed the many discussions on this (such as the last one a year ago), but the accepted convention for this is actually boundary=statistical + border_type=census_designated_place.
It also works perfectly fine in Nominatim, as can be seen in this query of Towson, Maryland (both the city population center, and the CDP show up perfectly fine in the search results).
@ValentinAK can you edit the thread title and initial post? Vandalism is rather about malicious destruction intended to make OSM worse.
Not for “someone else made an edit and I disagree with them”
A plurality of users, based on its dramatic decline since 2014. Advances in geocoding have rendered the key rather irrelevant.
Actually looking at the changes made in the “problematic” changesets you’ve listed makes it clear why place tags on admin boundaries in the US are so fraught to begin with. Take for example Changeset: 175785591 | OpenStreetMap , which removed place=city from the Del Rey Oaks relation. I grew up in northern California and I’ve never heard of Del Rey Oaks, population 1500, so it’s weird that it was a place=city, which are supposed to be the most prominent places in the state!
Of course, it’s not a place=city by OSM standards. Just look at the node, which is tagged as place=village and has been since it was added in 2007. But the admin area was added as a place=city in 2009 and has been tagged as such ever since, through a couple of type permutations.
This sort of mismatched tagging is common across California and the US. It presumably arises from a simple fact: Del Rey Oaks is a city! Just look at its website: https://www.delreyoaks.org/, proudly proclaiming it the City of Del Rey Oaks. That’s because all incorporated municipalities (admin_level=8) in California are legally called “cities” (or “towns”, they’re synonyms under California law). The fact that our laws use the same words as OSM uses for its place hierarchy but with different meanings has led to widespread errors similar to this that have been a lot of trouble for the US community to solve. Luckily, after much discussion, we have another tag: border_type, that can store this information so place doesn’t have to.
Just as another random example from the list you sent: Changeset: 175785611 | OpenStreetMap removed place=hamlet from a CDP where the node is tagged place=suburb, another mismatch. In my opinion, both these edits are correct: these places don’t neatly correspond to their borders or what sort of border they are, so place tags should go on the nodes, as documented on the wiki: Key:place - OpenStreetMap Wiki . Ideally, the nodes and any boundaries they roughly correspond to could be related with a label role too, that’d be a good project for someone.
Long story short, if you were relying on place tags on borders in the US, you were probably already processing bad data. I’m still not totally sure what your map sample is trying to show, but if it’s an attempt to show urbanized areas then you’ll likely need additional processing anyways, coloring in any CDP that happens to have a place tag will probably lead to weird results.
Hi, since this post is about me, I’ll just say a little bit about my workflow to make sure everyone understands what I’m doing.
As ZeLonewolf said, I am using their QA checker. I forked it, and I am running locally as to update the list of tasks to do. I also updated it to use the 2025 census data rather than the 2024 data on the GitHub.
I’ve been doing what is recommended in the checker, but also removing is:in as I knew that was a useless tag in a well mapped country like the US.
As for my changeset comments, I use the better-osm-org userscript (forum page about it) osmtags-editor extension that allows me to edit tags on the main OSM page without having to load iD, making it vastly simpler and faster to quickly make tag edits. The user script auto generates the changeset comment, I didn’t think there was a problem with those comments, but if there is any push back I’ll stop using it and recommend someone post the same grievance to the dev.
The only thing that gave me pause while doing this was the removal of 237602, as it’s a pretty large relation. The QA checker said it didn’t exist, and checking the census list proved that.
Changeset: 175786742 | OpenStreetMap
created_by=Osm.Org Tags Editor
You are a little confused, you are using GitHub - Zverik/osmtags-editor: An extension that adds an "edit tags" button to every object on osm.org
p.s. There is a tag editor in my script, but it is a little hidden and appears after executing an Overpass request or Drag’n’Drop an .osm file.
Yes you’re right. My bad, I’ve been using both for so long that they kinda geld together to me. Either way, both tools are very cool and recommend anyone using iD to also use them.
To clarify, tags like place=city and place=town are still perfectly legitimate in the U.S. The longstanding, widely accepted convention involves both populated places and their jurisdictional boundaries:
place=* point at the common-sense center of town: downtown plaza, origin of the street grid, etc. As a rule of thumb, it would be wherever a map would anchor a point label, but not necessarily the geographic centroid of the city limits.label.border_type=* based on the legal title. For an administrative boundary, also add admin_level=* based on the number of administrative boundaries that contain it.Step 2 is very important. A geocoder needs an explicit link between the place point and boundary relation. Otherwise, the geocoder wouldn’t know how to reconcile the two features, because the correspondence between place=* and border_type=* or admin_level=* is wildly different in each state, let alone each country. Unfortunately, we still have a lot of free-floating place points to add to boundary relations.
Conversely, as long as the place point and boundary relation have redundant place=* tags, renderers have to contend with problems like redundant labels. To avoid problems with both geocoders and renderers, the usual advice among U.S. mappers is to remove place=* from the boundary relation when adding the place point to the boundary relation.
@Chris_Lawrence’s 2007 TIGER boundary import applied place=* and border_type=* to boundary relations by converting the jurisdiction’s legal title to snake_case.[1] In other words, these values have nothing to do with the populated place’s importance or population, as one would expect by reading the documentation for place=* in state, national, or global guidelines. By and large, these place=* tags remain untouched except to the extent that we’ve been replacing them with border_type=*.
We still have 1,662 contradictions between place=* tags on boundary relations and their members, but that’s a lot less than we did even earlier this year. (The heavy concentration in Maine might be a symptom of incorrect links between townships and populated places across New England.)
As far as I can tell, the removal of these often contradictory place=* tags improves the accuracy of Nominatim results. Nominatim is capable of associating places based on the label role anyways.
It looks like your cartographic approach is to shade in built-up areas, using incorporation as a crude proxy for urbanization. You wouldn’t want to shade in, for instance, the barely populated bayous on the eastern end of New Orleans, just because they happen to be in an incorporated area by some quirk of history. If your maps are specific to the U.S., you’d get much better results by converting the Census Bureau’s urban areas shapefile and using that as an underlay. The census urban areas are based on block-level housing density, so they’re much more accurate and informative for this purpose.
Lines 79 and 89 of polyshp2osm.py. ↩︎
