6
2

Some newly drawn buildings have just turned up on my local map and the source key has not been added. As buildings are rare in our location I've checked out buildings and other features in London and Munich and found this to be common. If I check an author's edit I note that often the source is mentioned in the comment. Is stating the source in the edit comment an alternative to adding the source key to the properties of the feature?

asked 27 Feb '11, 16:35

chrisboucher's gravatar image

chrisboucher
91134
accept rate: 0%


Generally putting the source on an object is not the best way to do it, as it creates a lot of entries that the next user would potentially have to modify when modifying the object. E.g. if there is a building and you are then attaching a usage or other amenity which occupies the building you won't be able to derive this information from aerial imagery. The better approach is to use changeset comments for source information. This requires that you group your edits into changesets with the same source though, but it ensures that the information is set where it applies to: to the edit.

permanent link

answered 27 Feb '11, 17:37

dieterdreist's gravatar image

dieterdreist
3.6k113466
accept rate: 3%

When I have been using Bing imagery for building outlines, I use the tags source:shape=Bing for the outline and source=survey for the address detail etc

permanent link

answered 03 Mar '11, 12:22

netman55's gravatar image

netman55
31115
accept rate: 0%

I've already read that adding the source on a changeset is an intesting solution for multi-sourced objects properties. But you can edit objects using aerial imagery and physical survey, and the problem is the same.

I've not found a clear and complete solution on documentation, but what is possible is:

  • use multi-source value by using a semicolon as a separator, for example source=bing;survey either on the object or on the changeset
  • for changeset sourcing solution: use strictly only one source per changeset. It may be sometimes difficult, but improve the traceability
  • for object sourcing solution: specify the source for each tag, considering that the default "source" is for the nodes. For example: source=bing for the nodes and source:name=survey
permanent link

answered 28 Feb '11, 13:06

NicolasDumoulin's gravatar image

NicolasDumoulin
3.3k42256
accept rate: 13%

edited 01 Mar '11, 10:02

Jonathan%20Bennett's gravatar image

Jonathan Ben...
8.2k1785108

Multiple values are not a problem for the source key (you can also use freetext with "and" because this is mainly a message to the following mappers). Still it is really not that simple adding a detailed source. E.g. for Bing the imagery in my area is different (age/alignment/season) in Z18/19 and Z20. We also have no method to keep trace with Bing updates or changes. Personally I don't feel that this is an important information anyway: either the object is OK or it is wrong in which case I would correct it. Exceptions might be hq-imports from official sources and dates e.g. for population.

(28 Feb '11, 15:06) dieterdreist

Putting the source on the changeset may be easier for you, but I think it makes it harder to trace back the source of particular bits of information as the object undergoes multiple changes. It also requires additional API calls (multiple GET /api/0.6/changeset/#id for every changeset in the history of every object you download).

For me, when I tag source=[imagery provider] this means that all the information came from this source.

If I want to combine multiple sources I make this clear using something like,

source=survey
source:location=[imagery provider]
source:[key]=[value]
...

This way you can explicitly tag the source of any tag using source:[key] I use source:location=[...] to mean the source of the coordinates of the nodes in this way. I also use source=[...] to mean either the source of all the tags with no individual source tag, or the source of knowing that this feature exists roughly at this location.

Using source=[provider1];[provider2];... can be problematic as it isn't always clear which parts came from provider1 and which provider2.

permanent link

answered 05 Mar '11, 22:42

aharvey's gravatar image

aharvey
5082813
accept rate: 22%

putting the source to the changeset is not only easier for you, it is also easier for the other mappers. If you look at the currently provided method from osm to lookup the history of an object: http://www.openstreetmap.org/browse/way/12345685/history

you can see that it is much easier to look at the changeset comments then to rely on the different tags.

When would you remove the source tag? Objects in OSM are not static nor should they be. They are continuously modified and each of this modifications, often performed just on a fraction of an object, may have their own source.

(06 Mar '11, 16:28) dieterdreist

I can see why that might make sense, but if you put the source on the changeset then you can't use multiple sources. eg. you may make multiple changes to a multiple objects in one changeset, you can't put all 4 different source tags in the changeset tags.

The source would be removed if the source changes. eg. if it was previously source:location=landsat, and the location of the object was improved from high-res imagery, upon the change, the tag would get changed to source:location=provider. The source tag tied to another tag for an object doesn't imply that you can't use a different source.

(19 Mar '11, 10:14) aharvey
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×68
×26
×17
×11

question asked: 27 Feb '11, 16:35

question was seen: 5,287 times

last updated: 19 Mar '11, 10:14

powered by OSQA