Modify

Opened 5 months ago

Closed 5 months ago

Last modified 2 months ago

#18528 closed defect (wontfix)

Do not warn about untagged way ouside download area (Was: Do not warn about untagged way with positive id and incomplete parents)

Reported by: skyper Owned by: team
Priority: normal Milestone:
Component: Core validator Version: latest
Keywords: template_report untagged way download area Cc:

Description

What steps will reproduce the problem?

  1. Have an untagged way with positive id but with incomplete parents. E.g 373802514
  2. Run validator

What is the expected result?

No warning as the parents of the way are not downloaded, yet.

What happens instead?

A warning: Untagged ways

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

Right now, download area is used to determine whether all parents are downloaded but maybe we need an additional register for parents.
I have to admit that I often use "download parents" and there for my download area is often small or not even existing but I would like to have some validator tests run if all parents have been downloaded and not depend on download area.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-01-05 23:29:48 +0100 (Sun, 05 Jan 2020)
Revision:15644
Build-Date:2020-01-06 02:30:57
URL:https://josm.openstreetmap.de/svn/trunk

Attachments (0)

Change History (24)

comment:1 Changed 5 months ago by stoecker

Resolution: wontfix
Status: newclosed

There is no such thing as a parent in the OSM datastructure. There only exist child elements. Getting the parent works only via checks if the element is child of another. Thus what you request is impossible.

comment:2 in reply to:  1 Changed 5 months ago by skyper

Resolution: wontfix
Status: closedreopened

The primary goal of this ticket is to get rid of this warning in cases where it produces a lot of false positives. Well, seems we need to use download area once again.

Replying to stoecker:

There is no such thing as a parent in the OSM datastructure. There only exist child elements. Getting the parent works only via checks if the element is child of another. Thus what you request is impossible.

I thought about caching/saving the information of the checks once they have been run but that is another ticket.

comment:3 Changed 5 months ago by stoecker

Resolution: wontfix
Status: reopenedclosed

The goal of the ticket does not change the facts.

comment:4 in reply to:  3 Changed 5 months ago by skyper

Replying to stoecker:

The goal of the ticket does not change the facts.

So, do I need to change the description to point to outside download area instead of missing parents or how are you going to accept it ?

comment:5 Changed 5 months ago by stoecker

It is simply not possible to know that a way has a "missing parent". So what you request is impossible. Or do you simply want to exclude ways outside of the downloaded world? This is possible. But it should not be necessary, as JOSM does not download any objects without the references, except you use special downloads like object download or overpass api.

comment:6 in reply to:  5 Changed 5 months ago by skyper

Replying to stoecker:

It is simply not possible to know that a way has a "missing parent". So what you request is impossible. Or do you simply want to exclude ways outside of the downloaded world? This is possible. But it should not be necessary, as JOSM does not download any objects without the references, except you use special downloads like object download or overpass api.

Yes, the test should be only run if at least one node with positive id is inside the download area. There are many actions where I get into situations with ways with "missing parents" like merge or in my case downloading parents of a node used by more than one way, though you might call all these actions special.

comment:7 Changed 5 months ago by stoecker

Please describe your workflow. Both cases you said should not result in missing parent information.

comment:8 in reply to:  7 Changed 5 months ago by skyper

Replying to stoecker:

Please describe your workflow. Both cases you said should not result in missing parent information.

Merge is Ok but merge selection not.

download parents:

  1. Download https://www.openstreetmap.org/#map=23/47.98882574432272/7.829098540568695
  2. Select nodes 2470778989 and 426862869
  3. Select middle nodes Alt+Shift+E (utilsplugin2)
  4. Download parent ways/relations
  5. Run validator
  6. Two warnings: Untagged ways (way 373802514 and way 373802513)

comment:9 Changed 5 months ago by GerdP

I can reproduce your results. I agree with Dirk that JOSM cannot know that the way is the member of a relation in this case.
I wonder why you don't zoom to the selected nodes and use download area in step 4.
On the other hand we can probably change the test for untagged ways so that it ignores ways outside the download area.

comment:10 in reply to:  9 ; Changed 5 months ago by skyper

Replying to GerdP:

I can reproduce your results. I agree with Dirk that JOSM cannot know that the way is the member of a relation in this case.

I know that in this case JOSM does not know the memberships of a way.

I wonder why you don't zoom to the selected nodes and use download area in step 4.

I was only interested in the parents of the nodes as I intended to only modify these nodes of the way which was already downloaded. I did not want to modify any other ways, not downloaded yet, nor their child nodes.

On the other hand we can probably change the test for untagged ways so that it ignores ways outside the download area.

Yes.

But we miss some cases where this test and some other are save to run. (See e.g. #17970 which was not completely fixed)

If you go one step further in my example and download the parents of the two untagged ways this test should be save to run on them.

I just thought JOSM could be smarter and keep information about knowledge of completeness of parents. Like all objects download with normal download but also the objects where the parents were explicitly downloaded, already, by other download tasks.
I know this would be needed to be stored in another list and would consume more memory.

comment:11 in reply to:  10 ; Changed 5 months ago by GerdP

If you go one step further in my example and download the parents of the two untagged ways this test should be save to run on them.

Sure, you can do that with another "download parent", still I think it is much easier to download the area.

I just thought JOSM could be smarter and keep information about knowledge of completeness of parents. Like all objects download with normal download but also the objects where the parents were explicitly downloaded, already, by other download tasks.
I know this would be needed to be stored in another list and would consume more memory.

I don't understand what you mean here. Do you think about a recursive download of parents? Like "download the parents of a node" and remember the list as list 0, then download the prents of the objects in list 0 and store them in list 1, then download parents of list 1 and .... until a download returns no new elements? That certainly would produce more work for the server than a simple download of the area.

comment:12 in reply to:  11 Changed 5 months ago by skyper

Replying to GerdP:

If you go one step further in my example and download the parents of the two untagged ways this test should be save to run on them.

Sure, you can do that with another "download parent", still I think it is much easier to download the area.

This is only an example. I have similar working flow with larger areas, especially with ways running diagonal (NE-SW and NW-SE) the download area can get huge. I am simply not interested of the rest and the more I download the more memory is consumed even with filter hidding most.

I just thought JOSM could be smarter and keep information about knowledge of completeness of parents. Like all objects download with normal download but also the objects where the parents were explicitly downloaded, already, by other download tasks.
I know this would be needed to be stored in another list and would consume more memory.

I don't understand what you mean here. Do you think about a recursive download of parents? Like "download the parents of a node" and remember the list as list 0, then download the parents of the objects in list 0 and store them in list 1, then download parents of list 1 and .... until a download returns no new elements? That certainly would produce more work for the server than a simple download of the area.

No, I simply think of one list of object where we know for sure that all the parents are downloaded.
All objects downloaded with normal download action and download object with referrers action plus the one download parents action was run on would be on the list. Maybe, some OverPass queries could be added but only if we are sure for good.
I do not intend any further server communication but only store the information more precisely per object then only using download area.

Download area works for cases where we need information about objects near by but it is only a simple helper for many issues. Please, think about actions like deleting a node outside download area or cutting a way outside download area or even the problem when moving a way/node from completely outside download area into download area.

comment:13 Changed 5 months ago by GerdP

Ah, OK, so with your example steps the selected nodes would be added to the list of objects for which parents are known.
Or, probably better, we could store this information in a bit flag for each object.
BUT the two untagged ways wouldn't be in this list because we don't know the parents of those two ways.
So, the additional flag would not solve the problem mentioned in this ticket.

comment:14 in reply to:  13 ; Changed 5 months ago by skyper

Replying to GerdP:

Ah, OK, so with your example steps the selected nodes would be added to the list of objects for which parents are known.
Or, probably better, we could store this information in a bit flag for each object.
BUT the two untagged ways wouldn't be in this list because we don't know the parents of those two ways.
So, the additional flag would not solve the problem mentioned in this ticket.

It would, as the test would be not be run on them as they do not have the flag.

comment:15 Changed 5 months ago by stoecker

I tried your example (GerdP BTW, when you tested this why didn't you find issue fixed in r15665? :-) and I think this workflow is non-standard and not recommended.

If this workflow should be more standard, then OSM-API should support getting parents much better than it does now. Otherwise I rather find it a feature than an error that validator warnings pop up if the actively work outside download bounds.

Last edited 5 months ago by stoecker (previous) (diff)

comment:16 in reply to:  14 Changed 5 months ago by GerdP

Replying to skyper:

Replying to GerdP:

Ah, OK, so with your example steps the selected nodes would be added to the list of objects for which parents are known.
Or, probably better, we could store this information in a bit flag for each object.
BUT the two untagged ways wouldn't be in this list because we don't know the parents of those two ways.
So, the additional flag would not solve the problem mentioned in this ticket.

It would, as the test would be not be run on them as they do not have the flag.

Yes, if we change the test (and many more) to use the new flag ;)

comment:17 in reply to:  15 ; Changed 5 months ago by GerdP

Replying to stoecker:

I tried your example (GerdP BTW, when you tested this why didn't you find issue fixed in r15665? :-) and I think this workflow is non-standard and not recommended.

If this workflow should be more standard, then OSM-API should support getting parents much better than it does now. Otherwise I rather find it a feature than an error that validator warnings pop up if the actively work outside download bounds.

Not sure. Is about the first step? When I try to download the link as an url I get a error popup with r15625.
But I first opened it in the browser and used the edit button to load the data into JOSM.

comment:18 in reply to:  17 Changed 5 months ago by stoecker

Replying to GerdP:

But I first opened it in the browser and used the edit button to load the data into JOSM.

Buuh. You're using other software than JOSM. Shame on you :-)

comment:19 Changed 5 months ago by GerdP

@Skyper: Adding and using such a new flag is lots of work, changing the "untagged way" test to ignore ways outside of the download area is rather easy. Since this ticket has the wontfix status I will not produce a fix for it unless Dirk changes his mind.
Besides I think I'd prefer to suppress all validator messages for objects outside of the download area if possible.

If you are more interested in the bigger work reg. the new flag maybe open a new ticket with a subject like "JOSM should store and use the information that parents where downloaded", but I doubt that anybody will do this work. We already have lots of flags and it is very difficult to understand how each of them influences the results of a validator check, a new flag is likely to cause more trouble.

comment:20 in reply to:  19 Changed 5 months ago by stoecker

Replying to GerdP:

Besides I think I'd prefer to suppress all validator messages for objects outside of the download area if possible.

There are reasons which clearly speak for this approach. OTOH making stuff outside the download area too user friendly has drawbacks as it makes these workflows much easier to use. I think we should leave it like it is.

comment:21 Changed 5 months ago by GerdP

I think a warning or error message "forces" users to edit objects. If we don't show those messages a user might not be tempted to work outside of the download area. Another advantage might be that the ContinousDownload plugin is more usable. I disabled it because a double click on validator message often takes you far away from the downloaded area.

OTOH we might simply not allow to edit outside the download area. Not sure how to realize that. Something like a check if a node is added outside the download area or move from or to this forbidden area and if yes, ignore the action and show a notification.
We already have something like that when you try to add or move a node outside of planet.

comment:22 Changed 5 months ago by skyper

Keywords: download area added
Resolution: wontfix
Status: closedreopened
Summary: Do not warn about untagged way with positive id and incomplete parentsDo not warn about untagged way ouside download area (Was: Do not warn about untagged way with positive id and incomplete parents)

Well, I changed the summary to get rid of the warning in the same manner as similar situations.

Probably, gonna come back to the flag subject in another ticket.

comment:23 Changed 5 months ago by stoecker

Resolution: wontfix
Status: reopenedclosed

comment:24 in reply to:  22 Changed 2 months ago by skyper

Replying to skyper:

Probably, gonna come back to the flag subject in another ticket.

Let's give it a try, see #18959.

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.