Hi,
Let us notice that, unlike my message, your replies do not comment the
*reasons* for source tags location.
I say:
* the wiki instructions say to put sources in the objects
* it needs fumbling to see changeset sources (is it fair to the author?)
* only source in objects can be used in overpass queries
* it's a user hassle having to split his changes so that the objects
correspond to source
* seen otherwise, it's attaching the source to the object or to a
mixed bag container
Starting from the wiki sentence I commented, the reason for changeset
sources is that other persons do it.
This is, of course not a valid reason unless saying why they do it and
if it is appropriate.
I seem to read that those persons live in the imports list.
It is conceivable that a bulk import use changeset sources if their
visibility and queriability is unimportant.
Bulk imports are one shot operations that do not involve general mappers
and are a thing done afterwards.
Isolated changes and operations like BusCo *do* involve the general mappers.
The BusCo operation is *not* a one shot import but is providing a
BusCo.osm file that contains the data for general mappers to copy,
correct and update OSM with manually. Work already done is, now and in
future updates, expunged from BusCo.osm and the obvious way to do that
is to put a source=BusCo yyyy-mm in its objects. overpass will select
objects having found their way to OSM and they will be deleted by ID
from BusCo.osm.
Regarding a DB size argument, the overhead of multiple split changes
makes the changeset sources more space consuming.
Other comments inline...
On 2014-06-26 18:17, Jo wrote :
> 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.
That is suggesting that every user did it a different way and making
sure that an overpass query will not be able to use that data.
Inserting source=BusCo 2014-4 in the BusCo.osm is exactly the opposite.
> 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
Those who have understood, please raise a hand.
Alternatively:
- put source=BusCo 2014-4 in the object the users copy from the
BusCo.osm file (or its tags if the object already exists)
- overpass query "source=BusCo 2014-4 ...", get their ref ID and used to
expunge done work from BusCo.osm
> 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.
Your preferences are not the only ones.
> 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.
If the BusCo data needs corrections, the OSM data could be different and
right and the update could be undetected.
By definition, the source=BusCo 2014-4 method is reliable.
This cooperator is perfectly astounded to read the last phrase here for
the first time and to find no mention of it here
<http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources/TEC#Indiquer_la_source>.
>
>
> Jo
>
>
> 2014-06-26 14:21 GMT+02:00 Dan S <danstowell+...@gmail.com
> <mailto:danstowell+...@gmail.com>>:
>
> 2014-06-26 12:44 GMT+01:00 André Pirard <a.pirard.pa...@gmail.com
> <mailto: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.
>
I have no understanding problem. But that phrase has a meaning problem.
Normally, these pages contain instructions how to tag and not a
chronicle of the taggers' doings.
So, according to the above, it might say that, if of very limited
importance, source tags can be put on changeset if it's a bulk and one
shot import. Not let believe that it's a general case. A link to "more
information" is always welcome as you can see.
Please correct it.
BTW, I don't feel JOSM>File>Upload appropriate: asking without any
explanation for changes that are not bulk an apparently single source
when there may be a dozen objects with possibly several sources each.
>
>
> While doing so may be appropriate to for huge bulk imports, I
> don't think it's always, even generally, the case.
>
>
> I agree.
>
Try to convince Jo.
>
>
>
>
> 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
>
André.
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
