Modify

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#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?

  1. 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.
  2. 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 Changed 3 years ago by Don-vip

Milestone: 14.10

comment:2 Changed 3 years ago by Don-vip

Keywords: ignore added

comment:3 Changed 3 years ago by Harry Wood

I can imagine three different approaches to fix this:

  • That specific test for "Nodes duplicating parent way tags" could be made to ignore the josm/ignore=true tagged nodes
  • Validator could be made to ignore (all tests) anything with josm/ignore=true tag set on it'. Is this problematic if somebody accidentally connects something to a ignored node? ...well maybe that's a problem anyway because it won't be uploaded!
  • No change to the validator, but the task manager mechanism could be changed to not set josm/ignore=true on the corner nodes of these squares. And then this mechanism within JOSM would need to change. The logic would need to be: if nodes do nothing but have a parent way which has josm/ignore=true tag on it ...then we don't upload those nodes (safe to assume we didn't intend to upload four untagged nodes)

The third solution is more complicated, but I suppose it might be considered the best solution. Not sure.

comment:4 Changed 3 years ago by stoecker

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 in reply to:  4 Changed 3 years ago by Don-vip

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 Changed 3 years ago by stoecker

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 Changed 3 years ago by Harry Wood

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:8 Changed 3 years ago by Don-vip

Resolution: fixed
Status: newclosed

In 7599/josm:

fix #10582 - drop support of undocumented tag josm/ignore. New deprecation test in mapcss tagchecker, with new fix resolution that deletes the object. Please use upload prohibition flag at layer level.

comment:9 in reply to:  8 Changed 3 years ago by Klumbumbus

Replying to Don-vip:

Please use upload prohibition flag at layer level.

That means to open the .osm file in an external text editor and in the second line change upload='true' to upload='false', or is there another way?

Last edited 3 years ago by Klumbumbus (previous) (diff)

comment:10 Changed 3 years ago by Don-vip

The flag can be toggled with a right click on layer. Maybe remote control must be enhanced to allow creation of private layers too.

comment:11 Changed 3 years ago by Klumbumbus

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.

Last edited 3 years ago by Klumbumbus (previous) (diff)

comment:12 in reply to:  11 Changed 3 years ago by skyper

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 to true. However, default is false for this key.

Yes, these menu options are hidden. Was looking for them last week. How about offering them as default in expert mode ?

comment:13 Changed 3 years ago by Stereo

HOT uses the josm/ignore=true tag to show the limits of challenges.

comment:14 Changed 3 years ago by anonymous

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 Changed 3 years ago by Klumbumbus

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

comment:16 Changed 3 years ago by 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.

comment:17 in reply to:  16 Changed 3 years ago by Klumbumbus

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 Changed 3 years ago by Klumbumbus

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 Changed 3 years ago by Stereo

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 in reply to:  14 Changed 3 years ago by Don-vip

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 Changed 3 years ago by Harry Wood

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

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.