Modify

Opened 4 weeks ago

Closed 4 weeks ago

Last modified 4 weeks ago

#17504 closed enhancement (fixed)

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

Reported by: mkoniecz Owned by: team
Priority: normal Milestone: 19.03
Component: Core validator Version:
Keywords: template_report is_in Cc:

Description (last modified by 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

Attachments (1)

taghistory.png (90.4 KB) - added by Don-vip 4 weeks ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 4 weeks ago by mkoniecz

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

comment:2 Changed 4 weeks ago by mkoniecz

Description: modified (diff)

comment:3 Changed 4 weeks ago by mkoniecz

Description: modified (diff)

comment:4 Changed 4 weeks ago by Don-vip

Milestone: 19.03

comment:5 Changed 4 weeks ago by Don-vip

Keywords: is_in added

comment:6 Changed 4 weeks ago by Don-vip

Resolution: fixed
Status: newclosed

In 14917/josm:

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

comment:7 Changed 4 weeks ago by 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.

comment:8 Changed 4 weeks ago by 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.

comment:9 Changed 4 weeks ago by GerdP

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

comment:10 Changed 4 weeks ago by 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

Last edited 4 weeks ago by mkoniecz (previous) (diff)

Changed 4 weeks ago by Don-vip

Attachment: taghistory.png added

comment:11 Changed 4 weeks ago by Don-vip

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


comment:12 Changed 4 weeks ago by 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...

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.