Modify

Opened 10 years ago

Closed 7 years ago

Last modified 4 years ago

#6381 closed enhancement (fixed)

Ask for source tag in changeset/upload (and nag if empty)

Reported by: olejorgenb Owned by: team
Priority: minor Milestone: 13.12
Component: Core Version:
Keywords: upload, changeset Cc:

Description (last modified by simon04)

Depressingly few people employ the source tag, at least in my area.

Maybe a nag, or at least having a dedicated textbox in the upload dialog, could help? If not for the purpose of forcing people to use the tag, then for helping people that do remember adding it.

When a changeset is closed there is no way back, and then you are left with tagging all elements, which is annoying, and have slightly different semantics. (ie. for changed, not new elements)

Attachments (2)

2013-11-17-204656_488x456_scrot.png (17.9 KB) - added by simon04 8 years ago.
6381.patch (15.6 KB) - added by simon04 8 years ago.

Download all attachments as: .zip

Change History (32)

comment:1 Changed 10 years ago by olejorgenb

Description: modified (diff)

comment:2 Changed 10 years ago by anonymous

Source should be tagged to the elements, not the changeset, for what I hope should be obvious reasons.

comment:3 in reply to:  2 Changed 10 years ago by stoecker

Replying to anonymous:

Source should be tagged to the elements, not the changeset, for what I hope should be obvious reasons.

Your obvious reasons are not so obvious and contrary to the suggestion of OSM in general and also in contrast to the experiences of the past.

comment:4 Changed 10 years ago by olejorgenb

Source should be tagged to the elements, not the changeset, for what I hope should be obvious reasons.

Obvious for which reasons? Lack of tools that infers the keys and coordinate sources from changesets (*)? A changeset having edits with different sources? From what I see there is currently no real conscious of what is best practice..

Either way.. a nag could also be issued if a percentage of the elements edited is missing a source tag or something similar so let's move the discussion of OSM 'policies' away from the JOSM tracker :)

(*) The absence of something like this is another shortcoming of JOSM regarding source management. (Maybe this is hard / requires lots of api calls?)

Last edited 10 years ago by olejorgenb (previous) (diff)

comment:5 Changed 10 years ago by anonymous

The obvious reason being that a changeset may contain objects from different sources: a road pulled from a GPS trace, a footpath and some buildings from Bing, the names taken from OS Locator, etc. I trust nobody's going to suggest that such a small edit should be committed using three changesets, because that way lies madness.

comment:6 Changed 9 years ago by simon04

Description: modified (diff)

I put a source to the changelog if (most of) the data originates from one source. I suggest to a textfield in commit dialog below of the description textfield. Users see the possibility to add such a tag and may or may not enter one. However, they are not forced to.

Changed 8 years ago by simon04

Changed 8 years ago by simon04

Attachment: 6381.patch added

comment:7 Changed 8 years ago by simon04

Summary: Add a nag for missing source tag on changeset/upload[Patch] Add a nag for missing source tag on changeset/upload

Two years later …

comment:8 Changed 8 years ago by simon04

Summary: [Patch] Add a nag for missing source tag on changeset/upload[Patch] Ask for source tag in changeset/upload (and nag if empty)

comment:9 in reply to:  7 ; Changed 8 years ago by skyper

Replying to simon04:

Two years later …

Thanks a lot.

Is there a history for previous used source strings ?
Thought we have a ticket about it but I did only find #4181.

comment:10 in reply to:  9 Changed 8 years ago by simon04

Replying to skyper:

Is there a history for previous used source strings ?

Yes, however there's no link to the source value of nodes/ways/relations.

comment:11 Changed 8 years ago by nesol

It's good to have a distinct source tag field, to remember people to put at least the sources they used into the changeset meta data.
In some countries the local OSM communities do suffer from people that do upload data from illegal sources.
So this should also work as a reminder to attribute the sources and not using data from sources not allowed in OSM.

To emphasize this even more, it would be great if the upload dialogue window could link to the distinct wiki pages.
The word comment could hyperlink to the following wiki page:
http://wiki.openstreetmap.org/wiki/Good_changeset_comments

The word source could hyperlink to this wiki page:
http://wiki.openstreetmap.org/wiki/Key:source

If it's possible to use a language specific links, the link could even be localized and point to the wiki page of the same language JOSM is configured to.
Regions having specific problems with illegal data being uploaded, could put a box in the "source-tag" wiki page stating sources allowed and not allowed in OSM.

comment:12 Changed 8 years ago by simon04

In 6401/josm:

see #6381 - Ask for source tag in changeset/upload

comment:13 Changed 8 years ago by simon04

Summary: [Patch] Ask for source tag in changeset/upload (and nag if empty)Ask for source tag in changeset/upload (and nag if empty)

To be discussed:

  • Does current nagging of empty source= suffice?
  • How to best implement (language aware) links to the OSM wiki? Can UrlLabel used for inline text (i assume not)?

comment:14 Changed 8 years ago by nesol

Does current nagging of empty source= suffice?

I think it's ok this way. If someone really wants to do something wrong he will do it anyway. If source would be absolutely mandatory he would just put anything into the source field. I think it's perfect the way it is.

How to best implement (language aware) links to the OSM wiki? Can UrlLabel used for inline text (i assume not)?

If it's very difficult to implement, then just link to the English wiki page. A user can switch to the desired/available language there.
Another possibility would be simply adding the language string (eg. DE:) to the link:
http://wiki.openstreetmap.org/wiki/DE:Key:source
The language string could be read from the language setting of JOSM.
Disadvantage would be that someone using a language in JOSM where the according wiki page is not translated to, would receive an empty wiki page.
But on the other side this should encourage people translating these two wiki pages in many different languages quickly.

comment:15 Changed 8 years ago by Don-vip

One more related thing on changeset uploads I think we should follow iD on the usage of this key:
http://wiki.openstreetmap.org/wiki/Key:imagery_used

comment:16 Changed 8 years ago by nesol

The question is if another key should be added (Key:imagery_used) to the changeset upload dialogue, or if the source tag should simply be used as something that corresponds loosely to the imagery_used of iD?
For example the layers loaded in JOSM before pressing upload, could be preloaded into the source key field of the upload dialogue with the user still having the possibility to change them.

I for example, when mapping in Tirol, use different layers within the same mapping session: (eg. Bing, geoimage.at, Tiris DGM, Tiris DOG), when mapping from a MTB tour I will have a GPS layer and a georeferenced photo layer additionally. I switch between them with Alt+1,2,3... very often during the mapping session.
So at the moment I put all these layers comma separated into the source tag.

So the question is, if the WMS/TMS layes should really be separated into imagery_used and the rest put into the source tag?
Personally I think filling in two fields upon upload is ok. But having even one more? It may even be difficult to decide where to put eg. GPS. Should GPS go into the source or the imagery_used?

JOSM is a more professional editor with more possibilities (image layers...) than iD, so I don't know if a 1:1 usage of imagery_used is the best thing to do?

comment:17 Changed 8 years ago by simon04

In 6408/josm:

fix #9349 - see #6381 - fix intermixing of changeset source and comment

comment:18 Changed 8 years ago by simon04

In 6409/josm:

#fix 9348 - see #6381 - source= for changeset falsely reported as empty

comment:19 Changed 8 years ago by MHohmann

With the current implementation JOSM issues a (pretty annoying) warning whenever the new "source=" textbox is left empty, even if it is intentionally left empty. Is there a way to disable this behavior? If not, I would hereby request to fix this in the code / implementation.

comment:20 Changed 8 years ago by simon04

This feature or bug (depending on the view point) is open for discussion (see my comment:13). We could:

  1. Make this generic empty key/value warn dialog to remember the decision (with the disadvantage that one might overlook a real "error" in the changeset tags)
  2. Add a designated warn dialog for an empty comment (similar to the current one on missing/short changeset comment) and restrict the generic empty key/value warn dialog to tags other than source and comment.

I feel that 2. might be a good choice.

comment:21 Changed 8 years ago by MHohmann

Yes, 2. sounds fine to me as well.

As there may be users who wish to see a warning also for missing source, one could show a designated warn dialog also for empty source, but leave it to the user whether it is displayed or not (i.e. "[X] Don't show this warning again." and / or some setting in the general program settings dialog).

comment:22 Changed 8 years ago by simon04

In 6419/josm:

see #6381 - display specific, ignorable dialog on empty changeset source

comment:23 Changed 8 years ago by simon04

In 6424/josm:

see #6381 - fix #9373 - upload dialog: make source input behave similar as comment input (concerning enter/focus)

comment:24 Changed 8 years ago by anonymous

Here's another suggestion which I forward from a discussion in the German OSM forum:

When ignoring the warning dialog, one could have three different options:

  • Show warning again next time.
  • Don't show warning for the current session.
  • Never show warning again.

With the current (and IMHO quite good) implementation one already has the first and last option.

comment:25 in reply to:  24 Changed 8 years ago by simon04

Replying to anonymous:

Since the code for this dialog is being used at several places and this suggestion is not directly related to a changeset source, I created a separate ticket: #9394

comment:26 Changed 7 years ago by simon04

Resolution: fixed
Status: newclosed

Deployed as tested version.

comment:27 Changed 7 years ago by RicoElectrico

This is quite a good idea. But there are no preset values, and from my experience this means a potential mess! Please add at least the most common ones (knowledge, survey, Bing).
Later, it can be upgraded to suggest something based on current layers (own or downloaded traces/waypoints, geotagged photos, WMS/TMS). If it's there, it should be non-annoying and useful.

comment:28 Changed 7 years ago by simon04

I created #9484 since this ticket has already been closed.

comment:29 Changed 7 years ago by Don-vip

Milestone: 13.12 (6502)

comment:30 Changed 4 years ago by stoecker

Milestone: 13.12 (6502)13.12

Milestone renamed

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.