Modify

Opened 10 months ago

Closed 10 months ago

Last modified 3 months ago

#18530 closed enhancement (fixed)

upload dialog: support validator and notes layers as source tag

Reported by: skyper Owned by: team
Priority: normal Milestone: 20.01
Component: Core Version:
Keywords: template_report upload changeset source Cc: taylor.smock

Description (last modified by skyper)

From #18522
skyper 18522#comment:3:

Additionally:

  • Notes and Validator layers are not supported.

taylor.smock 18522#comment:4:

...
@skyper: The latter (notes and validator layers) could be easily added. They just have to @override the getChangesetSourceTag method.

What steps will reproduce the problem?

  1. Have validator and notes layer active and a data layer with changes
  2. Upload data
  3. In upload dialog click on "just once" to automatically obtain source from active layers

What is the expected result?

Notes; Validator

What happens instead?

no cs source tag

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 (1)

18530.patch (992 bytes) - added by taylor.smock 10 months ago.
Minimal patch (does not check if Validator/Notes layer have actually been used since last upload)

Download all attachments as: .zip

Change History (9)

comment:1 Changed 10 months ago by skyper

Description: modified (diff)
Summary: upload dialog: support validator and notes layersupload dialog: support validator and notes layers as source tag

comment:2 Changed 10 months ago by skyper

Description: modified (diff)

Changed 10 months ago by taylor.smock

Attachment: 18530.patch added

Minimal patch (does not check if Validator/Notes layer have actually been used since last upload)

comment:3 Changed 10 months ago by taylor.smock

The only issue I see from adding them as sources is that it is possible for someone to (for example) run a validator check somewhere, fix one or two issues, and then go somewhere else, with the validator layer still visible. I thought about integrating some checks for that, but that would require (a) more work and (b) a full validation run every upload, comparing the old issues with the new issues, and adding the source only if old issues were fixed.

Furthermore, with respect to the validator, it is entirely possible to turn off the layer (I do this, since I often have the informational level enabled, which is a lot of noise).

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

Replying to taylor.smock:

The only issue I see from adding them as sources is that it is possible for someone to (for example) run a validator check somewhere, fix one or two issues, and then go somewhere else, with the validator layer still visible. I thought about integrating some checks for that, but that would require (a) more work and (b) a full validation run every upload, comparing the old issues with the new issues, and adding the source only if old issues were fixed.

Sounds like at lot of work.
Could be the same with gpx layers.
I have a similar scenario for imagery layers: Map some place with e.g. Bing. Upload. Go to other area. Activate other imagery on top of Bing. Map. Upload. Bing would be still added though the layer was always hidden under the other imagery layer.

Furthermore, with respect to the validator, it is entirely possible to turn off the layer (I do this, since I often have the informational level enabled, which is a lot of noise).

All layers can be deactivated/deleted in advance of upload.

In the end, it is up to the user to check the values.

comment:5 Changed 10 months ago by Don-vip

Resolution: fixed
Status: newclosed

In 15654/josm:

fix #18530 - upload dialog: support validator and notes layers as source tag (patch by taylor.smock)

comment:6 Changed 10 months ago by Don-vip

Milestone: 20.01

comment:7 in reply to:  4 Changed 10 months ago by taylor.smock

Replying to skyper:

Replying to taylor.smock:

The only issue I see from adding them as sources is that it is possible for someone to (for example) run a validator check somewhere, fix one or two issues, and then go somewhere else, with the validator layer still visible. I thought about integrating some checks for that, but that would require (a) more work and (b) a full validation run every upload, comparing the old issues with the new issues, and adding the source only if old issues were fixed.

Sounds like at lot of work.
Could be the same with gpx layers.
I have a similar scenario for imagery layers: Map some place with e.g. Bing. Upload. Go to other area. Activate other imagery on top of Bing. Map. Upload. Bing would be still added though the layer was always hidden under the other imagery layer.

Furthermore, with respect to the validator, it is entirely possible to turn off the layer (I do this, since I often have the informational level enabled, which is a lot of noise).

All layers can be deactivated/deleted in advance of upload.

In the end, it is up to the user to check the values.

The user should check the values, but not every user does. As far as intermittent sources go, I'd prefer to not automatically populate the source tag. For example, MapWithAI shouldn't autopopulate the source tag unless something has been added since the last upload. It makes it easier and more accurate, since if someone forgets (looks at self), they are not indicating that they used a source, when they didn't.

But yes, deciding programmatically that a source is needed is a lot more work (you have to store something somewhere, and get notified on uploads, and hope the user is uploading everything, and so on).

As far as your example with Bing goes, that is very much true. I think I thought about trying to do some detections on whether or not an imagery layer was visible, but decided it wasn't worth it, along with storing the imagery id in each Command so that I could ignore cases where Bing was a layer, but wasn't actually used.

comment:8 Changed 3 months ago by Klumbumbus

See #19241 for a partly revert.

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.