#10582 closed defect (fixed)
task manager square has validation warning "Nodes duplicating parent way tags"
Reported by: | Harry Wood | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 14.10 |
Component: | Core validator | Version: | tested |
Keywords: | template_report ignore | Cc: |
Description
What steps will reproduce the problem?
- Open a task square from http://tasks.hotosm.org into JOSM. This uses JOSM remote control, and loads a square shaped way which has 'josm/ignore=true' tag set on it.
- Click 'validate' to validate the stuff people have been mapping.
What is the expected result?
validation should apply only to the data people have been mapping.
What happens instead?
The validator reports it has found four warnings: "Nodes duplicating parent way tags".
Please provide any additional information below. Attach a screenshot if
possible.
Repository Root: http://josm.openstreetmap.de/svn Build-Date: 2014-07-28 22:35:35 Last Changed Author: Don-vip Revision: 7347 Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b URL: http://josm.openstreetmap.de/svn/trunk Last Changed Date: 2014-07-29 00:32:15 +0200 (Tue, 29 Jul 2014) Last Changed Rev: 7347 Identification: JOSM/1.5 (7347 en) Mac OS X 10.9.4 Memory Usage: 212 MB / 910 MB (77 MB allocated, but free) Java version: 1.7.0_67, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM VM arguments: [-Djava.library.path=/Applications/JOSM.app/Contents/MacOS, -DLibraryDirectory=/Users/harrywood/Library, -DDocumentsDirectory=/Users/harrywood/Documents, -DApplicationSupportDirectory=/Users/harrywood/Library/Application Support, -DCachesDirectory=/Users/harrywood/Library/Caches, -DSandboxEnabled=false, -Xmx1024m, -Dapple.laf.useScreenMenuBar=true, -Dcom.apple.macos.use-file-dialog-packages=true, -Dcom.apple.macos.useScreenMenuBar=true, -Dcom.apple.mrj.application.apple.menu.about.name=JOSM, -Dcom.apple.smallTabs=true] Dataset consistency test: No problems found Plugin: buildings_tools (30485) Plugin: fieldpapers (b49dadd) Plugin: geotools (30569) Plugin: imagery_offset_db (30534) Plugin: jts (30416) Plugin: measurement (30641) Plugin: notes (v0.9.4) Plugin: opendata (30508) Plugin: openstreetbugs (30413) Plugin: poly (30495) Plugin: reverter (30521) Plugin: utilsplugin2 (30460)
Attachments (0)
Change History (21)
comment:1 by , 10 years ago
Milestone: | → 14.10 |
---|
comment:2 by , 10 years ago
Keywords: | ignore added |
---|
comment:3 by , 10 years ago
follow-up: 5 comment:4 by , 10 years ago
Question is why should we support tags like josm/ignore=true at all? Why don't they simply use a different layer for such information, as it is designed?
comment:5 by , 10 years ago
Replying to stoecker:
Question is why should we support tags like josm/ignore=true at all
I don't like it either but we already support it since version... r106:
for (OsmPrimitive osm :primitives) { if (osm.get("josm/ignore") != null) { continue; } ... }
(wow I almost never went so far in JOSM history).
Hence I was thinking about skipping validator tests completely if this tag is added, as they are not uploaded. Other option would be to drop support for this tag. But current situation is not good (ignored at upload but not in validator).
comment:6 by , 10 years ago
Hence I was thinking about skipping validator tests completely if this tag is added, as they are not uploaded. Other option would be to drop support for this tag. But current situation is not good (ignored at upload but not in validator).
Drop it (probably creating a validator ERROR when it is found). We have better methods nowadays (like the noupload layers).
comment:7 by , 10 years ago
I found a discussion about the way this works from the Task Manager's end here: https://github.com/hotosm/osm-tasking-manager2/issues/251 We may need some cross-project collaboration to figure out the best solution here, but yes it seems like forcing it onto a new layer would be better.
comment:9 by , 10 years ago
Replying to Don-vip:
Please use upload prohibition flag at layer level.
That means to open the .osm file in an external editor and in the second line change upload='true'
to upload='false'
, or is there another way?
comment:10 by , 10 years ago
The flag can be toggled with a right click on layer. Maybe remote control must be enhanced to allow creation of private layers too.
follow-up: 12 comment:11 by , 10 years ago
There was no toggle for me. I found out that I need to set data.layer.upload_discouragement.menu_item
in advanced preferences to true
. However, default is false
for this key.
comment:12 by , 10 years ago
Replying to Klumbumbus:
There was no toggle for me. I found out that I need to set
data.layer.upload_discouragement.menu_item
in advanced preferences totrue
. However, default isfalse
for this key.
Yes, these menu options are hidden. Was looking for them last week. How about offering them as default in expert mode ?
follow-up: 20 comment:14 by , 10 years ago
The task manager used to add the bounding square to a separate layer, and it did properly set the upload=false flag on the layer. The problem we had was that even with this people sometimes accidentally uploaded the bounding squares anyway. I think it would happen if they merged their layers together and ignored the warning at that point (not knowing what it meant).
We later changed to the josm/ignore system and that has worked much better ever since, I don't think I have seen any squares uploaded accidentally since this change. My suggestion would be to simply amend the validator code to not warn on this as it is a useful feature, not just for the validator, but for other uses as well. Unless there is some other good way of preventing upload of these bounding squares (and the upload=false thing has already been shown not to work reliably enough) then I would not recommend dropping this feature.
-AndrewBuck
comment:15 by , 10 years ago
Some statistics:
At the moment there is 478 times josm/ignore in the osm database according to taginfo: http://taginfo.openstreetmap.org/keys/?key=josm%2Fignore#overview
These are 122 squares with 356 nodes (some squares share one node, this is why there are not 122*4=488 nodes).
overpass turbo shows the squares: http://overpass-turbo.eu/?w=%22josm/ignore%22=%22true%22+global&R
follow-up: 17 comment:16 by , 10 years ago
Looking at the ones returned by that turbo query, it looks like all of the squares being added are due to newer versions of josm, presumably ones since this was changed.
comment:17 by , 10 years ago
Replying to AndrewBuck:
Looking at the ones returned by that turbo query, it looks like all of the squares being added are due to newer versions of josm, presumably ones since this was changed.
Yes. They are all created after [7599]. See this query: http://overpass-turbo.eu/s/5uV (change the date in the first line to 2014-10-16 and you get the 122 squares.)
comment:18 by , 10 years ago
I presume that people copy the square to the working layer, because it is better visible than if it is in a separate layer. I also worked this way when I worked a bit on such a project (http://tasks.poole.ch/job/63).
Is it not possible to skip the "Nodes duplicating parent way tags" test only for the tag combination josm/ignore=true
?
comment:19 by , 10 years ago
It would be perfect if the Remote API allowed us to import a gpx layer and set its colour.
As Harry-Wood was saying, to show the mapping boundary, we need a way of saying to JOSM launch this layer and make it immutable, un-uploadable, un-editable and pink.
comment:20 by , 10 years ago
Replying to anonymous:
I would not recommend dropping this feature.
It's way too late, sorry.
Replying to Stereo:
to show the mapping boundary, we need a way of saying to JOSM launch this layer and make it immutable, un-uploadable, un-editable and pink.
Please open a new enhancement ticket for this, we'll see how to improve the situation.
comment:21 by , 10 years ago
Some users had uploaded a fair amount of mess, as Klumbumbus pointed out with the overpass turbo query. I guess that must have happened in the time between JOSM developers dropping this feature, and Task Manager developers changing the website to use some other solution (gpx fudge solution)
Just to let you know I've just deleted all of that mess
I can imagine three different approaches to fix this:
The third solution is more complicated, but I suppose it might be considered the best solution. Not sure.