Remove global `source` field for presets?

[tordans]

Our fields are recommendations for mappers to consider adding the given data to the OSM object when known to the mapper and applicable to the given case.

I don't think the source field that we have a global preset is a good fit given this recommendation.

My understanding of the history https://wiki.openstreetmap.org/wiki/Key:source is, that we used to use it on OSM objects but nowadays it is discouraged in favor of a source tag on the changeset.

I like the fact, that it does expose existing data which I helps when updating data to also check the source field. I found many cases when history source fields are present and I can remove them once I update the data.

However, having the field is also a nudge to mappers to (still) add it to OSM objects. This issues is inspired by the recent discussion in Every Door Zverik/every_door#871 .
The UI in EveryDoor is a bit different from iD in the sense that once I expand the field list to include more fields (the moreFields) the source field is listed more prominently with possible values.

[Zverik]

I agree to this. The tag I think is even set to auto-delete in some editors.

[mnalis]

I agree to this. The tag I think is even set to auto-delete in some editors.

JOSM validator does suggest removing them, for example (via a simple click on "Fix" button)...

Now, I occasionally (e.g. when imagery and other datasets disagree) do set source=* on specific things I change, e.g. to make it clear that that specific element was really surveyed (I add check_date=* too in such cases), and in those cases I ignore JOSM validator warning and add them. That however happens rare enough, and 99.9%+ of my changes do not include source=* tag on elements, but only in changesets.

That being said, I agree that nowadays it is no longer a good idea for having source= offered as global field (iD / Every Door / Vespucci etc. users can still add the tag manually in rare situations its use might be warranted; but no preset is needed IMHO).

[1ec5]

However, having the field is also a nudge to mappers to (still) add it to OSM objects. This

It’s currently a non-default field, which is another way of saying it’s optional. We have a lot of optional fields that don’t make sense to fill in in every case or even many cases.

Unfortunately, the schema doesn’t really differentiate between optional fields that are a good idea versus optional fields that are only there to expose something that’s already tagged. It would be great to have something like unsearchable presets but for fields.

Incidentally, per-element sources are one of the few big differences in OHM’s tagging schema. OHM’s iD fork leans heavily on this field, to the point that that fork has completely overwritten it with something different: OpenHistoricalMap/iD#217 OpenHistoricalMap/iD#222 OpenHistoricalMap/iD#223. Along the way, we discovered that the per-element field is tied to the Sources field that appears in iD’s save panel, so if we change anything about it, we may need to keep a copy around for changesets.

[maro-21]

I support hiding or removing the source tag.

Source= on objects is problematic because:

• we don't know which tags it refers to [that's why source:key=* tags are better].
• when editing an object, many people don't see it and leave it, and they could have used another source

Sometimes it could be correct, such as on the amenity=bench added in the forest, which cannot be seen in aerial imagery because the trees obscure. But even in such cases source:geometry would be better, even if it's a node.

Instead, let's promote the use of source:key=*, such as source:geometry, source:name.

OpenHistoricalMap/iD#217

This is what I really want to have in iD!

[tordans]

Unfortunately, the schema doesn’t really differentiate between optional fields that are a good idea versus optional fields that are only there to expose something that’s already tagged. It would be great to have something like unsearchable presets but for fields.

Yes, that would be the alternative to removing the field. I thought about it but it would create quite a bit of complexity and I don't think the field is important enough to keep it.

…we discovered that the per-element field is tied to the Sources field that appears in iD’s save panel, so if we change anything about it, we may need to keep a copy around for changesets.

I thought I remembered that as well but did not find any reference to that here in the repo. It might be something that is defined in the iD codebase?

---

…Instead, let's promote the use of source:key=*, such as source:geometry, source:name.

That should be a different discussion IMO that we need to have in the iD repo. There is similar discussion around check_date:key hidden in openstreetmap/iD#8884 (comment)

Update: There is also openstreetmap/iD#9453

[1ec5]

…we discovered that the per-element field is tied to the Sources field that appears in iD’s save panel, so if we change anything about it, we may need to keep a copy around for changesets.

I thought I remembered that as well but did not find any reference to that here in the repo. It might be something that is defined in the iD codebase?

Sort of – iD explicitly adds the source field, but the field is still defined here in id-tagging-schema:

https://github.com/openstreetmap/iD/blob/4d78e80ea14db944c2ffcf7fdb9e04e6939525c2/modules/ui/changeset_editor.js#L36

[tordans]

I created openstreetmap/iD#10936 to discuss and track the change that are needed in iD