consider is_in:continent for automatic dropping or validator warning with autofix removal

[mkoniecz]

What steps will reproduce the problem?

1. Create node with is_in:continent=Eurasia
2. Run validator

What is the expected result?

Validator offers to remove it as unwanted or this tag is listed at ​https://wiki.openstreetmap.org/wiki/Discardable_tags

What happens instead?

Nothing

Please provide any additional information below. Attach a screenshot if possible.

Note that this tag is highly dubious, as both division Earth landmass into continents( ​https://en.wikipedia.org/wiki/File:Continental_models-Australia.gif ) and boundaries between continents( ​https://en.wikipedia.org/wiki/Boundaries_between_the_continents_of_Earth ) are mostly subjective and unverifiable.

OSM is not a place to map multiple unverifiable models of global-sized objects. And adding tens of thousands of is_in:continent to various objects is the worst way to do this.

This proposal (especially discardable tag part) appeared during discussing ​https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_is_in:continent_in_USA - see ​https://lists.openstreetmap.org/pipermail/talk-us/2019-March/019332.html

Is it something that requires discussion on talk/tagging mailing list or is removableness of this tag self-evident?

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-03-19 01:06:07 +0100 (Tue, 19 Mar 2019)
Build-Date:2019-03-19 02:30:51
Revision:14904
Relative:URL: ^/trunk

Identification: JOSM/1.5 (14904 en) Linux Ubuntu 16.04.6 LTS
Memory Usage: 427 MB / 869 MB (210 MB allocated, but free)
Java version: 1.8.0_201-b09, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

Plugins:
+ OpeningHoursEditor (34867)
+ buildings_tools (34904)
+ continuosDownload (82)
+ imagery_offset_db (34867)
+ measurement (34867)
+ reverter (34917)
+ todo (30306)

Validator rules:
+ ${HOME}/Desktop/tmp/unnecessary.validator.mapcss

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.
- W: Failed to add ${HOME}/Desktop/tmp/unnecessary.validator.mapcss to tag checker
- W: java.nio.file.NoSuchFileException: ${HOME}/Desktop/tmp/unnecessary.validator.mapcss

[Don-vip]

In 14917/josm:

fix #17504 - deprecate is_in globally / is_in:* for nodes and ways

[GerdP]

I don't understand this change. The is_in tag is widely used and I've never heard that it should not be used. For me it is just not the best possible way to tag the information.

[Don-vip]

is_in makes no sense in a geographical database. I think it is time to drop it and rely on relation boundaries only.

[GerdP]

But your test doesn't check if the corresponding relation exists.

[mkoniecz]

is_in history as I know it:

Initially in early stages of OSM mapping borders was unfeasible but people were interested in allowing reverse geocoding (and marking that say London is within UK rather than France).

They used is_in tag family to achieve this (it is unclear how many data consumers actually used this data).

Later borders were mapped allowing to get information where any point is located (its country etc) without using is_in tag. As result such tags are duplicates of mapped borders.

Current reason for keeping it are as follows

• tradition - it was always there should be still kept
• People using OSM database for caching their reverse geocoding results
• easier access to a location information during armchair mapping that jumps across the world
• opposition to mechanical edits that would remove it and noone is interested in a manual removal
• no active mappers within given area, OSM is not changing in any way, what includes is_in tags
• in theory there may be regions where is_in tags are present but borders are not mapped. I am not aware about such places.

I do not consider any of above (except last one) as valid reason for keeping in_in* tags, and last one is as far as I know no longer applying anywhere.

Still, for example in Poland my automated is_in removal edit received support to remove is_in:country and equivalents, without unanimous support for removal is_in:province and just today I was discussing in one of my changesets with someone who was convinced that using OSM database as cache for their data processing is valid use for tags.

is_in:continent removal requested in this ticket was intended as the first step toward is_in* removal so I am not going to protest, but I am not sure is there consensus for is_in full scale elimination (that is why I proposed removal of just is_in:continent as something clearly unacceptable).

But your test doesn't check if the corresponding relation exists.

Is there any place with valuable information in is_in tags not duplicating boundary data (not things like is_in:continent)?

See also:

​http://blog.imagico.de/social-engineering-in-openstreetmap/

​https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/removing_is_in_duplicating_borders_of_Poland_-_is_in:country,_is_in%3DPoland,_is_in%3DPolska,_is_in:country_code

​https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_is_in:continent_in_USA

[Don-vip]

Previous attempts were already made to get rid of these tags. Up to editors to give the final blow.

[GerdP]

OK, my thought was that we have a lot of areas where boundaries are not yet complete. Maybe I am wrong. Let's see what happens...

[maraf]

This fix went to far.
In Poland is_in:village is still the only way to denote which hamlet belongs to which village as many villages don't have bounderies.

[Don-vip]

@wiktorn: what do you think is best for this issue in Poland?

[Klumbumbus]

Replying to maraf:

the only way to denote which hamlet belongs to which village as many villages don't have bounderies.

Don't you use addr:city on the address and a place node for the city it belogs to then?

[maraf]

Replying to Klumbumbus:

Replying to maraf:

the only way to denote which hamlet belongs to which village as many villages don't have bounderies.

Don't you use addr:city on the address and a place node for the city it belogs to then?

I'm not sure what you mean. I was referring to nodes like this one: ​https://www.openstreetmap.org/node/3009762477

[Klumbumbus]

Replying to maraf:

I'm not sure what you mean. I was referring to nodes like this one: ​https://www.openstreetmap.org/node/3009762477

Ah yes, I misunderstood and mixed it up with address nodes. However in this case the boundary is available!? ​https://www.openstreetmap.org/relation/5436280

[maraf]

Replying to Klumbumbus:

Ah yes, I misunderstood and mixed it up with address nodes. However in this case the boundary is available!? ​https://www.openstreetmap.org/relation/5436280

For some villages it is possible to draw boundaries based on old data - which is the case. This maybe correct or not.

Here is example of a village without boundary - ​https://www.openstreetmap.org/node/31916491 - and its official hamlet - ​https://www.openstreetmap.org/node/3009730431

[anonymous]

Superfluous is better than incomplete in practically every field, and certainly in information stores.

Until there's a single well-defined lookup method for determining where each mappable entity is located both logically and physically, and that method always works, then for my part the more lookup methods the better.

At present I'm spending time I can't easily spare writing and running filters on a copy of the planet file, trying to normalise all the idiosyncratic keys that exist, many of them with uncorrected typos that increase the workload. Keys such as "is_in" are harder to get wrong than, e.g., "addr:country" which some might enter as "addr_country" or "place:country", "place_country", "addr:place:country", et almost-unbounded cetera.

Anyhow, that's my tuppence ha'p'ny.

[anonymous]

place:country is used 4 times worldwide

addr_country 0 times worldwide

Is it because you fixed it all or is it because the problem is not existing in practice?

Note that addr:country is anyway not worth tagging anyway as it duplicates country boundaries.