Proposal talk:Changeset tags

url:<lan>

the tag url should specify the language of the explanation or example url:en, url:de...

Yes, good idea ! sletuffe 21:29, 21 October 2012 (BST)

key:url seems to be deprecated. We should use key:website.--Marc Framboisier 07:34, 25 October 2012 (BST)

The website=* tag is more to link to the website you can find information about an OSM object, in the case of changeset, we might link to a blog page, an email, a wiki page or maybe other, I think it is a little wider than "website". But url=* might be a little to generic, but to be honnest, I don't care, I watch at the statistics and found that url was more used than website. sletuffe 10:31, 25 October 2012 (BST)

edit_type

Merge of the 'bot', 'revert', 'automated' tags in one tag :"edit_type" which may take the following values bot, revert:<reverted_changeset>, automated, manual_drawing as proposed.

The changeset page allready recommand using bot=yes, and since I don't know if that was allready used, I choose to keep compatibility. For revert and automated that make sense however. For the edit_type=revert:<reverted changeset id> I'm unsure if that syntax is easier to handle than 2 tags : edit_type=revert + reverted_changeset=<changeset id> ? sletuffe 21:36, 21 October 2012 (BST)

I don't like "type" as much as "edit_type" which is clearer, but as seen is the current statistics usage, "type" is allready used ~500 times, and compatibility matter more to me than "good looking words" I prefere type tto edit_type for the exact same purpose. sletuffe 08:51, 23 October 2012 (BST)

I don't like key with a general name like 'type', instead of one general key with multiple value I prefer a few specific key with specific value. The edit type/purpose is already recorded in the comment, the only missing edit information is knowing if it's a manual or an automated/robot edit (which is covered by the bot=yes). FranciscoDS 17:31, 22 October 2012 (BST)

The main goal of Sletuffe is specifying a few degrees in automation

• bot : there is no human check,
• automated : kind of bot mass changes with a few human checks,
• import : you have external vector data, import them in JOSM, cross check them with bing and your local knowledge, also add tags
• tracing : you draw a map or add tags with an external source (mainly raster image or aerial images)
• survey : your edit is only based on your own kownledge and visit of the aera your are mapping

--Marc Framboisier 20:47, 22 October 2012 (BST)

automated is not really meant for "kind of bot", it is more when you use JOSM and then mass change a tag to another and you don't have checked elements one by one. You will end having a created_by=JOSM but it is still automated somehow. bot=yes is really when you have used (and/or created) a special program for special tasks, it's even more prone to large scale errors in case something goes wrong and it is nice to have a tag so people can focuss on it and check is it does things right.

Note that "type=import" + "bot=yes" is perfectly valid : it is an import of external data, done by a bot ;-) Even "type=tracing" + "bot=yes" could exist. (Even If I'm really unsure about what result to expect !)

sletuffe 08:51, 23 October 2012 (BST)

Survey and local knowledge

Do we need to distinguish survey and local knowledge ?

• survey = I've been there and I watch closely what's on site, for this case the date should be mandatory ?
• local knowledge = long time ago I was there but I remember only some bit of information

FranciscoDS 17:31, 22 October 2012 (BST)

I don't care much, I think most people will keep on not adding anything where they are using survey/gpx. But nothing should be mandatory in those cases. Mandatory tagging should only be used in fewer possible exceptions (like when the risk is high that people make mistake, like with a bot doing world scale edits) sletuffe 08:57, 23 October 2012 (BST)

About source and source:*=*

I think it's better to include the multiple source used in the edit session with different and specific key :

• source:aerial=bing, wms or whatever background layer
• source:gpx=local, api if a GPS trace have been loaded locally or download from OSM
• source:fix=osmi, keepright, osmose, etc ... the name of the QA tools from which the remote control have been clicked

All those source can be identified by software by knowing the layer used during an editing session and having an origin id string when using a remote control. FranciscoDS 17:31, 22 October 2012 (BST)

The source tags above sound good, maybe we should add source:vector_data instead of 'source' alone.--Marc Framboisier 20:47, 22 October 2012 (BST)

Well, why not. But sometimes the source:x tags have been used this way : In source:x=bla, bla is the source used to record tag x. source:ref=survey means that the ref=* tags was recorded with source survey. Then you might have : source:geometry=* source:name=* source:tourism=* etc. So, for gpx, aerial used source, I'd still prefer the form : type=tracing + source=bing or, I you want to be even more explicit : type=tracing+source_type=aerial+source:geometry=bing+source:<tag>=survey sletuffe 17:13, 23 October 2012 (BST)

yes source:geometry is better --Marc Framboisier 07:15, 24 October 2012 (BST)

source:url=*

Might be a good idea to have source:url=* (or source:url:*=* for language) for data imports? That link will be in the wikipage, but it might be good to keep a note of it in the database (if someone wanted it machine readable or has a copy of it but not the wiki). DFyson (talk) 23:18, 21 December 2016 (UTC)

a "fixes" tag?

If the changeset fixes another changeset, perhaps it should have a "fixes" tag, with the id of the previous changeset. -- SwiftFast (talk) 15:06, 23 May 2017 (UTC)