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 -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
