I've been reading import proposals on the imports list for a while now and
the recommendation I keep seeing there is to add source tags on the
changesets, which is what I started since several months now. So now that
I'm preparing the osm file for BusCo, I'd prefer to simply add the
instruction to the importers to add source on the changeset upon uploading,
instead of adding it to each and every of 30000 objects and that's only for
half of a small country. On the northern side there are another 400000.

Of course, if the person performing the import wants to add source to all
the objects they add they can simply do  Ctrl-a to select all objects, add
source=whatever and save the file after downloading it.

What I'd suggest to do to make it clear to which object a source tag from
the changeset belongs is, transfer the  stops from the calculated layer to
the working layer, give them all a nudge to where they belong and change
the surrounding objects according to the aerial imagery. Then when done, do:

Ctrl-f
modified highway=bus_stop

then Upload selection, with source=TEC, Bing2011

Then perform a general upload for all the rest with source=Bing2011

My preference is to not add a date to TEC, it will always be the latest
version that was available when the upload was performed anyway.

There are other ways to check whether a stop needs to be updated
(comparison with current data downloaded with Overpass API) This procedure
is already in place, with output going to a wiki page, with links that can
be clicked in a convenient way to edit with JOSM remote control.


Jo


2014-06-26 14:21 GMT+02:00 Dan S <danstowell+...@gmail.com>:

> 2014-06-26 12:44 GMT+01:00 André Pirard <a.pirard.pa...@gmail.com>:
>
>  Hi,  I wonder if this phrase without an explanation link
>> <http://wiki.openstreetmap.org/wiki/Key:source> contains appropriate
>> instructions (or just press news):
>>
>> *Since the introduction of changesets these tags are often added as
>> changeset <http://wiki.openstreetmap.org/wiki/Changeset> tags rather than
>> in the features themselves.*
>>
>> It sounds like ("rather than") source tags in objects must now be
>> replaced by source tags in changesets.
>>
>
> Hi Andre,
>
> The sentence says changeset tags are "often" used in preference, and in
> your restatement you have converted "often" to "must now be replaced by".
> That is a massive difference, and I feel you've misread. I think the
> sentence in the wiki strikes the correct balance.
>
>
>
>> While doing so may be appropriate to for huge bulk imports, I don't think
>> it's always, even generally, the case.
>>
>
> I agree.
>
>
>
>>  Suppose an osm file built from version 2014_04 of BusCo bus stops data.
>> The OSM contributors are invited to copy each object to OSM and to check
>> the data, esp. coordinates.
>> Should:
>>
>>    - this file's objects contain source=BusCo 2014-04 (ISO date)
>>     - or the contributor be requested to add that tag to the changesets
>>    for each and every update
>>
>> In the first case, the tagging will be done without mistakes and the
>> source will be very apparent on the main OSM Web map not only for the
>> reader to see but also for overpass to filter which data belongs to BusCo
>> and even which is not yet at the latest update.
>>
>> In the mistake prone, second case, the mapper will be asked to force
>> himself in different updates for BusCo and for other necessary updates that
>> he will inevitably meet in the process, and the net result of that hassle
>> will be a misplaced source tag with regard to visibility and overpass.
>>
>> Which is the best method? Or is there another one?
>>
> I personally would say that your changeset source tags should only list
> the sources that have been used to make the changes you have made. In other
> words, your option 2 shouldn't be recommended. In the case you give, I
> would recommend to leave object source tags as they are, and add changeset
> tags listing any extra sources that the contributor used for their changes.
> I know this feels odd because the "total" source of the OSM data ends up
> split between object and changeset, but I think it's acceptable way to
> progress, and it definitely remains possible for a machine ot calculate the
> "total sources list".
>
>  I think that changeset source tagging is only appropriate to mechanical
>> imports and that the above phrase should say so or link to some reading
>> that does.
>>
>
> I disagree. When I do edits using a single source, it makes a lot of sense
> to put the source tag on the changeset. When I do edits using multiple
> sources, it makes a lot of sense to put the source tags on the objects.
>
>
>
>> It seems strange to have to split updates one per object so that the
>> correct source tags are present on each when they could equivalently and
>> more appropriately be on the object itself.
>> Typical, compared to the variety of object source tags format, is this
>> scarce instruction in changeset
>> <http://wiki.openstreetmap.org/wiki/Changeset>:
>>
>>
>>    - source <http://wiki.openstreetmap.org/wiki/Key:source>=* – specify
>>    the source for a group of edits
>>
>>  Typically, "source for" does not say "source of" what.  Of the objects
>> or of the edits as a whole import?
>>
>
> Good spot. So the text needs improving. I've edited the sentence to try
> and improve it. Obviously I've edited it using my own understanding of the
> consensus idea of the tag, so if I'm wrong let's just keep improving it :)
>
> Dan
>
>
> _______________________________________________
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to