[OSM-talk] multipolygon source tags preferred method

Jochen Topf jochen at remote.org
Tue Mar 28 07:25:43 UTC 2017

On Mon, Mar 27, 2017 at 10:41:38AM +0200, Jochen Topf wrote:
> On Mon, Mar 27, 2017 at 03:56:43PM +1000, nwastra wrote:
> > I am unsure what is the preferred way or best practice to tag the source for multipolygons.
> > I currently put the source on the relation with all the rest of the tags, and only adding tags to individual ways or inner polygons if they are also part of a seperate entity like a fence or a body of water. I also include the source with the uploaded change-set. This would seem to be ok when adding a new mp relation.
> > 
> > Should the source also be added to all the individual ways that make up the outer and inner boundaries of each polygon? 
> > Is this also the preferred way when adding a new large mp relation that does not currently exist?
> >   
> > When replacing individual ways or splitting and altering part of a way with updated data, adding the new source tag to those new ways would seem best practice or is it sufficient to added the source to the change-sets alone?
> > 
> > Is the most sensible way to initially add the source tags to the relation and change-set upload alone and from then on as individual parts are amended, to add the source to just the updated/corrected ways and the change-set on upload?
> > 
> > I have not come across guidance for this on the wki yet.
> Putting the sources on the objects has been deprecated for a while. The
> source should be put on the changeset only. If you are doing edits that
> involve several different sources, it is best to split the changes up
> into different changesets. Of course this is not always possible, then
> you can also put several sources in the changeset source tag.
> Adding the source to the objects was deprecated, too fined-grained
> source tagging simply doesn't make much sense. We can not track every
> source for every node, way, or relation or the parts of them for every
> tiny change that somebody does. In the end most data will have multiple
> sources and figuring out what came from what can only be done going
> through the changeset tags, not by looking at the tags on the data
> itself.

I probably shouldn't have used the word "deprecated", because there is
no mechanism in OSM do deprecate anything. This is more "common
practice" really. Martin has already described why source tags on
objects don't work well. In theory they might or might not be a good
idea, but in practice we have seen in OSM that they don't work. The
source tag is just not updated in a way that makes it useful. Since we
introduced changesets, we can do better: We put the actual data into OSM
objects, but the meta-data that describes the why and how of the mapping
we put into the changesets. (I didn't know that iD doesn't allow you to
set the source on the changesets as somebody mentioned. If that is true,
I see this as a shortcoming of iD that should be fixed.) This has the
added benefit of putting the meta-data that is seldomly used on the
changesets keeping the actual OSM objects lean and mean.

Now regarding the splitting up of changesets for different sources. If
you are doing different things this absolutely makes sense and, I would
argue, is even necessary to be able to add good changeset comments,
which you should always do. So if you come back from a mapping survey
and add the data you collected outside with source "survey" and then go
to a different part of the planet and add a few things from "bing",
those should be two changesets. Of course, if you add the geometry of a
road from Bing and the name from your survey, it makes total sense to
add the source "bing;survey" or something like it.

As always, there are few hard-and-fast rules in OSM. That's good because
everbody can decide for themselves which arguments they find convincing
and which advice to follow. So if you want to keep adding "source" tags,
that's fine, too.

Jochen Topf  jochen at remote.org  https://www.jochentopf.com/  +49-351-31778688

More information about the talk mailing list