Modify

Opened 5 years ago

Last modified 4 years ago

#17874 new enhancement

Propose to change landuse=reservoir to natural=water+water=reservoir

Reported by: mkoniecz Owned by: team
Priority: normal Milestone:
Component: Core validator Version:
Keywords: template_report landuse reservoir natural water Cc:

Description (last modified by mkoniecz)

What steps will reproduce the problem?

  1. Tag landuse=reservoir area
  2. Select it
  3. Run validator

What is the expected result?

Upgrade to natural=water + water=reservoir is proposed.

Note reservoir_type - https://taginfo.openstreetmap.org/keys/reservoir_type#values

For example reservoir_type=sewage that should not be changed to natural=water

What happens instead?

Nothing.

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

Currently both landuse=reservoir and natural=water + water=reservoir are widely used for tagging reservoir water area.

landuse=reservoir is more confusing due to using landuse value and may be easily misunderstood to mean "entire area used to maintain reservoir" like most other landuses, and include for example also dam.

It is also more problematic for data consumers as to show water areas one needs in addition to natural=water query also for landuse=reservoir and other.

Encouraging natural=water + water=reservoir will not be problematic for non-broken data consumers as currently they anyway need to support it - it is a widely used tagging scheme, and dual tagging with landuse=reservoir is rare (below 3% https://taginfo.openstreetmap.org/tags/water=reservoir#combinations ).

landuse=reservoir is more popular but large part of difference is in node tagging and caused by imports - see https://user-images.githubusercontent.com/899988/60383077-c001ce00-9a6c-11e9-9aa8-ed43c7851a36.png

In recent years natural=water + water=reservoir seems to be more popular among mappers (though maybe it would change after excluding mappers that are not actually selecting tagging scheme that is used)

Note that there was a recent heated discussion about this upgrade rule in ID, see https://github.com/openstreetmap/iD/issues/6589

I participated in this discussion and based on my research (done to check whatever iD is making undesirable tag 'upgrades') I concluded that in this case tag migration is desirable.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-07-01 21:59:18 +0200 (Mon, 01 Jul 2019)
Build-Date:2019-07-02 01:30:51
Revision:15201
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15201 en) Linux Ubuntu 16.04.6 LTS
Memory Usage: 461 MB / 869 MB (267 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 (34977)
+ PicLayer (35030)
+ buildings_tools (34982)
+ continuosDownload (82)
+ ejml (34908)
+ geotools (34908)
+ imagery_offset_db (34908)
+ jts (34908)
+ log4j (34908)
+ measurement (34977)
+ reverter (34999)
+ todo (30306)

Validator rules:
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/deprecated.mapcss
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/unnecessary.mapcss
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/combinations.mapcss

Last errors/warnings:
- E: Failed to locate image 'presets/vehidle/restriction/toll_gantry.svg'
- W:  Toll gantry: Could not get presets icon presets/vehidle/restriction/toll_gantry.svg
- W: No configuration settings found.  Using hardcoded default values for all pools.

Attachments (0)

Change History (17)

comment:1 by mkoniecz, 5 years ago

Description: modified (diff)

comment:2 by skyper, 5 years ago

landuse and water are different and (can) exist at the same time. Problem is the misuse of landuse instead of water but user need to check manually before fixing/changing the tags.

comment:3 by mkoniecz, 5 years ago

Note that (mis)use of landuse=reservoir for water areas is so common that in map styles it is presented as water area.

Including internal JOSM style.

Wiki defines https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir as "Man made body of stored water."

Maybe it should be used this way, but basically nobody is doing this. I would say that it is too late for changing meaning of this tag.

comment:4 by Klumbumbus, 5 years ago

Previous josm ticket #8759.

comment:5 by tomas, 5 years ago

  1. landuse=reservoir is more popular not because of some incorrectly added nodes, but because it is original water tagging scheme used for much longer than new scheme introduced by Ilya. It would be even more popular if not iD which from the very beginning did not allow tagging landuse=reservoir thus giving unfair advantage statistic-wise to new water scheme.
  1. New scheme is only changing NAMES of well established tags. It does not introduce any new classes or reclassify anything. Therefore it has no advantage only breaks existing code and text materials without any benefit.
  1. Switching to new scheme would also mean removing other original OpenStreetMap tags which go together: landuse=basin, waterway=riverbank etc.
  1. This would make a very bad precedent showing that tagging of very popular objects in OpenStreetMap can be changed by new people without doing any thinking about data consumers and without a good reasons.
  1. Names of tags are not significant, in order to map correctly mapper would have to read wiki anyway. STABILITY is much more important.

comment:6 by mkoniecz, 5 years ago

"Therefore it has no advantage"

I am OK with other considering things as "easier to find all water areas", "no longer using landuse key for water area" as unimportant, but "no advantage" is simply untrue.

comment:7 by anonymous, 5 years ago

To have an objective "advantage" we need to have an objective (and accepted) criteria based on which we are judging on usefulness of a tag.
As well as compare it with some rate of prominence so that it would be harder to change tags which are used more often (water tags should be very difficult to change because only some art maps will not be using them, but bench backrest colour tags should be easy to change because they would rarely be used).

Think about highway tag which has an incorrect name and probably incorrect routing (why together with path? why then not together with railway?) but nobody is going to change it because it is already used in too many places.

comment:8 by Don-vip, 5 years ago

Keywords: landuse reservoir natural water added

comment:9 by mkoniecz, 5 years ago

To have an objective "advantage" we need to have an objective (and accepted) criteria based on which we are judging on usefulness of a tag.

Obvious criteria is whatever it is hard/easy for mappers to collect useful and correct data. With some small importance given to how easy for data consumers and various software is to process tags.

Given that it allows to reduce confusion ("no longer using landuse key for water area") and is one step closer to mapping all water (except oceanic waters) as natural=water, making easier to find all water areas and making tagging scheme more consistent I am planning to implement this.

If any of JOSM developers is against merging such patch - please let me know.

in reply to:  9 comment:10 by tomas, 5 years ago

Obvious criteria is whatever it is hard/easy for mappers to collect
useful and correct data. With some small importance given to how
easy for data consumers and various software is to process tags.

This is not abstract/objective "criteria".

It is in no way "easier" for mappers to collect data. Note that the whole idea of tagging everything blue as natural=water does not finish with eradicating landuse=reservoir, it also involves waterway=riverbank which is nowhere close of being replaced with natural=water even with forced pushing by OSM Poi Editor (iD).

It is very inconvenient for data consumers when data schemas change, especially for such prominent objects as waterbodies. Trying to give understanding of classification by names of tags is futile and probably gives false hope: it is impossible to fully describe a class in two words. That is why most data consumers (and professional GIS) use codes (like gc1, dh5), that way you are forced to look the value up in a classification where you will find a full description with detailed explanation on usage.

This whole idea of changing water schemas is only interesting to geeks, it makes not IT sense. Anybody with at least a fraction of IT experience (coding is not IT experience) will tell you that such a change is stupid. Think: why we do not change "highway" tag? For the same reason original OpenStreetMap water schema should NOT have been allowed to be duplicated. How this geeky suggestion managed to slip through is another question for another audience.

one step closer to mapping all water (except oceanic waters) as
natural=water, making easier to find all water areas and making
tagging scheme more consistent I am planning to implement this.

It is again just a geeky wish which has nothing in common with IT, data consumers and cartography. If somebody wants to find all "blue water" without classification, somebody is missing a point, as there is a very good reason why we have separate classifications for different types of waterbodies. And if somebody has problems with doing a search with OR condition - then even coding is too hard for them.

comment:11 by zelonewolf@…, 4 years ago

Note that as of 12/13/20:
The iD editor maintains the change to natural=water + water=reservoir
The total count of water=reservoir way/relation tags now exceeds landuse=reservoir way/relation tags (332K vs 331K)

We should strive to have a consistent data model that consumers can use in a consistent way, without having to research a laundry list of edge cases "water means water, except in these instances, land means water." As such, I support this ticket.

I ask that we please refrain from the use of insulting language in this thread, e.g.: "only interesting to geeks", "such a change is stupid", "even coding is too hard for them". It is not helpful.

comment:12 by anonymous, 4 years ago

Mappers should decide which one is better, not coders of editors.
JOSM as the main editor of OpenStreetMap should remain democratic.

in reply to:  12 comment:13 by stoecker, 4 years ago

Replying to anonym:

Mappers should decide which one is better, not coders of editors.
JOSM as the main editor of OpenStreetMap should remain democratic.

JOSM is not and will not be democratic. If you want to influence JOSM start contributing.

I'll never understand why people assume they have the right to decide something only because they use a software for free.

comment:14 by mkoniecz, 4 years ago

Description: modified (diff)

comment:15 by anonymous, 4 years ago

Will my patch to propose change of water=reservoir to landuse=reservoir be accepted? I can do that.

JOSM has always been and hopefully WILL remain democratic and good example on liberal behaviour of editor.

comment:16 by mkoniecz, 4 years ago

JOSM has always been and hopefully WILL remain democratic

Posting that as anonymous after being told that "JOSM is not and will not be democratic" by one of JOSM developers (see https://josm.openstreetmap.de/timeline?from=2020-12-17&daysback=400&authors=stoecker&changeset=on&repo-josm=on&repo-osm=on&sfp_email=&sfph_mail=&update=Update ) is quite ridiculous.

comment:17 by tomas, 4 years ago

Sorry, trac is timing out a lot and I didn't change username on successful commit of comment.
My question stands: will my patch to change water=reservoir to landuse=reservoir be accepted?

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from team to the specified user.
Next status will be 'needinfo'. The owner will be changed from team to mkoniecz.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.
The owner will be changed from team to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.