#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 )
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)
Change History (32)
comment:1 by , 14 years ago
| Description: | modified (diff) |
|---|
follow-up: 3 comment:2 by , 14 years ago
comment:3 by , 14 years ago
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 by , 14 years ago
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?)
comment:5 by , 14 years ago
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 by , 13 years ago
| 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.
by , 11 years ago
| Attachment: | 2013-11-17-204656_488x456_scrot.png added |
|---|
by , 11 years ago
| Attachment: | 6381.patch added |
|---|
follow-up: 9 comment:7 by , 11 years ago
| 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 by , 11 years ago
| Summary: | [Patch] Add a nag for missing source tag on changeset/upload → [Patch] Ask for source tag in changeset/upload (and nag if empty) |
|---|
follow-up: 10 comment:9 by , 11 years ago
comment:10 by , 11 years ago
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 by , 11 years ago
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:13 by , 11 years ago
| 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
UrlLabelused for inline text (i assume not)?
comment:14 by , 11 years ago
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 by , 11 years ago
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 by , 11 years ago
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:19 by , 11 years ago
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 by , 11 years ago
This feature or bug (depending on the view point) is open for discussion (see my comment:13). We could:
- 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)
- 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
sourceandcomment.
I feel that 2. might be a good choice.
comment:21 by , 11 years ago
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).
follow-up: 25 comment:24 by , 11 years ago
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 by , 11 years ago
comment:27 by , 11 years ago
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:29 by , 11 years ago
| Milestone: | → 13.12 (6502) |
|---|
Source should be tagged to the elements, not the changeset, for what I hope should be obvious reasons.