large mechanical edit, is_in added

Hello,

I found a larger mechanical edit:
https://www.openstreetmap.org/changeset/44075647

seems to me that is_in was added. Is this the tagging we want?
is_in is deprecated since years as we have admin boundaries as polygons.

https://wiki.openstreetmap.org/wiki/Key:is_in

Any suggestions on how to handle this edit? Revert or keep?
Here details had been removed:
node 1684727085

Stephan

In principle, if its depreciated, then it should be reversed… but having read the Wiki, it may be important to some.
So, in fairness … Im going to sit on the fence on this one :confused:
Russ

Hi Stephan and All,

I’ve thought for a long time that there should be some standard way to enter this data, based on Name-Subdistrict-District-Province-Postal Code. Just like a letter address. Country and continent seem silly. This scheme would be unique to Thailand.

If we could work this out, I could add a lot of data to the map.

I have so far entered about 5000 place names (from Mishari’s Thai government data base) from 14 provinces. Possible twice that, as for each school name I usually name a village or a wat (All verified by OSM approved sources). I could just as well have entered the other database names (subdistrict-district-province-postal code). Is this data we want on the map database? It’s metadata, and doesn’t appear on the map.

Is there any easy way I could copy and paste a row in the database to the OSM editor key? I often think I’m wasting an opportunity here. But I work on a very low level. See road, draw road. To do this manually is too tedious.

As for mechanical entries, I think all large first edits should be vetted.

Regards, Tom

I’d suggest a revert plus a block by DWG because he **deleted **data.
The user not only change addr:country to is_in:country_code, but also removed more detailed data like addr:district, addr:province, addr:subdistrict (see e.g. https://www.openstreetmap.org/node/1190931227/history ).

There are some additional comments on the specific changeset.

Let alone the lost details: What is the tagging scheme we want to have? Is the “lost” detail maybe already there as part of administrative boundaries?

Administrative boundaries are certainly the way to go instead of duplicating this detail to each and every POI node.

So do we want to have Amphoe, etc being part of the place tags at all? And if so, better addr or is_in keys?

Beginning of 2014 we had a similar discussion. is_in sounded suitable as a transition technology to move towards admin boundaries:
https://forum.openstreetmap.org/viewtopic.php?id=23755

So nearly four years later: What do we now consider state of the art?

“State of the art”: I guess everyone will define it differently.
A year ago I mapped some houses in the village I live nowadays. I added addr:housenumber and addr:street tags (because the latter is not always easy to determine near junctions), but not further address tags, since I thought they are redundant.
A few months later, another mapper added addr:city, addr:country. addr:postcode, addr:suburb
And for Germany, we have high-quality boundary data…

Since that 2014 thread, I haven’t been adding any lower-level admin boundaries, and I don’t think anyone else has been working on them. It felt pretty pointless to reinvent the wheel and create everything from scratch, especially when such data is already publicly available from the government (though not currently in an oSM-compatible licence, AFAIK). Any energy spent mapping admin boundaries from textual descriptions could probably be much more effectively spent figuring out how OSM could make use of the official data.

So we sort of agree that mapping addr:city, is_in:city, etc is redundant and we don’t want to have it, right?

Problem still being that data is not offered in a quality or license which allows it for us to have it in OSM.

So how to deal with the initially mentioned mass edit? Some details might have been lost. I can’t tell how severe that is. Should we revert it? Or just keep it as both ways of tagging are not considered ideal and will be obsolete in the hopefully not that distant future when we have proper boundary data?