Opened 10 years ago
Closed 10 years ago
#9514 closed defect (fixed)
Improve auto-generated changeset source tags
Reported by: | ukandystreet | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 14.01 |
Component: | Core | Version: | |
Keywords: | Cc: |
Description
[6565] introduced a source tag on changesets that is automatically populated from the currently open layers. This has caused the following issues:
- People like myself who do not wish to set a source tag must now remember to manually remove it every time we upload a changeset. Please consider adding a pref (upload.source.autogenerate or similar) to allow us to disable this new feature.
- An auto-generated source tag is indistinguishable from one that has been manually created. This is a problem because the auto-generated tag records what sources might have been used but most data consumers will be expecting a record of which sources were used. If an additional tag was set (source:autogenerated=yes/no perhaps?) then data consumers would be able to assess how much confidence to place in the contents of the source tag.
Attachments (0)
Change History (14)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Since I was wondering where these strange source= values came from I was searching for an open ticket before creating one one my own and found this.
tl;dr:
Like the OP I'd prefer the source-field to behave like the comment field: by default empty and additional easily to fill from the history by the drop-down list.
But I cannot understand why the OP prefers to leave source= blank. Does he have to hide something?
Explanations
My issues with the behaviour of the value field for source=* are:
- auto fill fills the value field with German tags even though I'd prefer English values when mapping outside of Germany. If I'd use some parts of the auto suggested value I'd have to remove the German and add the English part
- auto fill fills the value field with tags I don't want to use since they aren't true
Example: right now I have loaded two gpx files, some geotagged images, Bing Aerial Imagery and a file with self collected POI converted to OSM data.
Depending on the POI I either just place it either right or left to the highway and upload it (source=survey) or I'd map e.g. a fuel station with a building, a roof and highway service (source=survey; Bing Aerial Imagery)
In both cases I have to remove "Georeferenzierte Bilder" from the string (or select an other previously used one) Mostly I could have done with the value used with the upload before but auto fill resets the string all the time.
The source to this changeset did slip me and thus is wrong: not one of the "Georeferenzierte Bilder" I used...
- auto fill creates duplicate entries when some sources are used twice (like two layers of geotagged images)
- Another issue: it is not uncommon in my use cases that I use several more map layers to compare Bing to historic maps. In this case the source field would overrun the limit of allowed characters in the value...
comment:3 by , 10 years ago
To clarify for those that have asked - I don't add a source
tag on the changeset because I add it to the individual data elements instead. I consider this to have two main advantages:
- It doesn't require any interested parties to second guess which one of the half a dozen sources listed on the changeset relates to an individual tag on a particular element.
- Anyone who obtains a data extract can also identify the source without needing to take additional steps. If you put the source on the changeset then you'd need to pull the history to work out which changeset added the tag and then cross-reference that with the
source
tag on the changeset.
I wouldn't mind JOSM's new auto-complete feature so much if it took its cues from the source tags on the data being uploaded but as it stands I'm accidentally uploading changesets with fictitious source
tags and that can't be a good thing. :(
comment:4 by , 10 years ago
From 9484#comment:3:
I'm annoyed by the fact this source tag gets overwritten by all the names of the imagery layers I'm using EACH AND EVERY time I'm uploading. Couldn't it stay with the source tag I set there myself for the duration of the session? It's not because I have an imagery layer loaded, that I used it for my modifications since the last upload. (I'm only using Bing when moving outside of the area for which I haven't better more recent imagery, but I still keep Bing there (invisible) so I can quickly switch it on, when I need to move out of my comfort zone)
This is what happened 2 weeks ago and it was very convenient.
Polyglot
comment:5 by , 10 years ago
Milestone: | → 14.01 |
---|
comment:6 by , 10 years ago
Since I prefer to put the source tags on changesets instead of on individual objects, I was very happy to see that it became a lot more convenient to add them in the upload dialog. Filling those values automatically is unfortunately a step backwards in my opinion. As it doesn't reflect reality
Two weeks ago, I could mostly leave the source the same, since I'm doing much the same from one session to another.
Polyglot
follow-up: 12 comment:7 by , 10 years ago
I personally have no preference concerning pre-filling the source
field or not, but we'd need some criterion whether/when to do it.
For instance, we could pre-fill the field for non-experts only. For experts, the question would be then whether to use the previous value (being valid for edits for 4h, as the comment
tag) or leave it empty.
comment:8 by , 10 years ago
I, like many others i suppose, frequently upload to a changeset that is already open and for which I already set a source. Now it gets reverted to this auto-generated source EVERY TIME i do an upload. So I have to change it back to what I entered EVERY TIME. If I forget this (since I already entered it on the upload before) my source is overwritten with a sometimes not-so-meaningful auto-generated one.
I consider this specific behavior a bug. And it vote +1 for adding a pref to allow disabling the auto-generation.
comment:9 by , 10 years ago
Priority: | minor → normal |
---|
No need to further stress that the current behaviour is undesired. Instead, please help to resolve the open questions from comment:7.
A preference entry is surely a way to achieve this, but maybe we can figure out a better criterion.
follow-up: 11 comment:10 by , 10 years ago
Sorry for being such an ungrateful bunch :-)
I liked it when it was prefilled with the previous value. TABbing to it, after filling out the CS comment and selecting another recently used value worked quite nicely.
If the expert user left it blank and chose not to be reminded about empty source tags, it can simply remain empty.
For non experts, it's a bit tricky. They may not even realise what it means or where those auto filled tags come from, which dilutes its usefulness. Especially if they are like me and they have many source layers open, which they didn't necessarily used during that session. (When people will start to use the possibility to save sessions, the effect of this will be amplified)
Back when I was mapping from GPX files, those files had cryptic names or timestamps as names. As a source tag, I simply used "survey" when mapping from a GPX.
When I was still putting source on objects, I used Bing2011 to indicate the freshness of the imagery. I believe trying to implement automating that would be a hard nut to crack...
Don-Vip: there is no such thing as unanimous consensus in the OSM world... But I do think there is a tendency to put metadata on the CS instead of on the objects.
Polyglot
comment:11 by , 10 years ago
Replying to Polyglot:
For non experts, it's a bit tricky. […] Especially if they are like me and they have many source layers open […]
Do non-experts edit using many layers?
Back when I was mapping from GPX files, those files had cryptic names or timestamps as names. As a source tag, I simply used "survey" when mapping from a GPX.
GPX layers are listed as "survey" already in the source
field.
comment:12 by , 10 years ago
Replying to simon04:
For experts, the question would be then whether to use the previous value (being valid for edits for 4h, as the
comment
tag) or leave it empty.
No matter what logic is used to determine whether and what to pre-fill, we should keep it the same for source
and comment
, because it is likely that if the comment of a new changeset is the same as the previous one then the same applies to the source and vice versa.
comment:13 by , 10 years ago
I noticed that after resolving conflicts the CS comment is blanked out (and the source reset to the layer names, but we already knew that). This problem was solved a few months ago, but now it seems to be back.
My source comments are more stable than my CS comments.
Sources:
De Lijn;AGIV
AGIV
Bing
CS comments:
stops for line xx added
routes for line xx added
added missing street names from AGIV WMS
etc
Point 2 is a good idea, but why do you remove
source
on purpose ? I thought this tag on changesets resulted from an unanimous consensus.