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:


[6565] introduced a source tag on changesets that is automatically populated from the currently open layers. This has caused the following issues:

  1. 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.
  1. 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 Don-vip, 10 years ago

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.

comment:2 by malenki, 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.

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?

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 ukandystreet, 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:

  1. 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.
  2. 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 simon04, 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.


comment:5 by simon04, 10 years ago

Milestone: 14.01

comment:6 by Polyglot, 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.


comment:7 by simon04, 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 CaptainCrunch, 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 simon04, 10 years ago

Priority: minornormal

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.

comment:10 by Polyglot, 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.


in reply to:  10 comment:11 by simon04, 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.

in reply to:  7 comment:12 by CaptainCrunch, 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 Polyglot, 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.

De Lijn;AGIV

CS comments:

stops for line xx added
routes for line xx added
added missing street names from AGIV WMS

comment:14 by simon04, 10 years ago

Resolution: fixed
Status: newclosed

In 6654/josm:

fix #9514 fix #9484 fix #9502 - Upload dialog: make source field behave like comment field, provide link "obtain from current layers" to insert current layers in field, display Bing layer as "Bing"

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.