<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
A short summary of my thoughts and a reply.<br>
<br>
source:XXX=* describes an object attribute, not a change
attribute, and should hence be an object tag.<br>
To benefit from overpass queries based on source:XXX=*, it <b>must</b>
be an object tag.<br>
Forcing mappers to split changes so that each part has appropriate
source tags and to repeat the same source tags for different
versions is a real hassle and is no improvement at all over object
tags.<br>
<br>
A bulk import totally complete in one operation may put a <b>confidential</b>
source in changeset, but...<br>
<br>
In the example case of a set of objects being checked and copied
by mappers from a BusCo-yyyy-mm.osm file to update OSM, it is
necessary that the copied objects contain a copied source tag
containing the date yyyy-mm of the new version. Let's call this
witness the <b>update marker.</b> By querying the update marker
with that date, overpass can build the list of objects that are
already mapper-processed and that can be expunged from the
BusCo-yyyy-mm.osm remaining-to-do-file.<br>
<br>
Replies inline...<br>
<br>
On 2014-06-30 18:40, Jo wrote :<br>
</div>
<blockquote
cite="mid:CAJ6DwMDe16HKTdYCpfsyGPM8fUz_UZyU5HxL2mSsg+tMFE0W5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Just like everybody else I started several years ago by
adding source tags on the objects themselves.<br>
</div>
<div><br>
The whole reason why the imports list says source tags
belong on the changeset has something to do with an import
of millions of buildings in France, each and every one
with:<br>
<br>
</div>
source=cadastre-dgi-fr source : Direction Générale des
Impôts - Cadastre. Mise à jour : 2013<br>
<br>
</div>
To avoid this kind of clutter in the future, I read all the
time on that list source tags should go on the changesets and
I agree, even if it complicates things a bit. </div>
</div>
</blockquote>
The number of bus stops in Wallonia is much much less than the
houses and other features of France.<br>
They're even a tiny fraction of the other source tags that the
mappers must use in the same region.<br>
Once again, if the French Cadastre don't mind a confidential source
mention, the answer is in my previous message: a tagset source is
all-right for a bulk, robotized, one shot import import, thing done,
OSM update, but not for BusCo piecewise, mapper-made, update needing
a marker.<br>
<br>
Only by curiosity: 1000 × that source=... line compression ratio:
zip: 262, bz2: 1600, xz: 2718 !!!<br>
I've seen ADN like Y1 Y2 Y3 Y2 Y3 Y1 on the French border with ways
more recent than their nodes ;-)<br>
<blockquote
cite="mid:CAJ6DwMDe16HKTdYCpfsyGPM8fUz_UZyU5HxL2mSsg+tMFE0W5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Having the source on the objects doesn't work either,
anyway.<br>
</div>
</div>
</blockquote>
It does work and it's the good way to achieve what's wanted.<br>
<blockquote
cite="mid:CAJ6DwMDe16HKTdYCpfsyGPM8fUz_UZyU5HxL2mSsg+tMFE0W5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>If you insist on putting them on the objects, take the
prepared osm file. Select all objects, and add the source tag
you like. For a detailed description on how to do so, see my
previous message. Apparently things seem too complicated or
unwieldy when described in too much detail.<br>
</div>
</div>
</blockquote>
No need to explain me how to do that, I made a complete osm file
myself.<br>
<blockquote
cite="mid:CAJ6DwMDe16HKTdYCpfsyGPM8fUz_UZyU5HxL2mSsg+tMFE0W5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Don't expect other people to do so as well.<br>
</div>
</div>
</blockquote>
That is indeed the worst way. Or the best way to have missing or
unrecognizable source tags.<br>
That is indeed why that tag must be copied from the *.osm source
file like said in my previous message. <br>
<blockquote
cite="mid:CAJ6DwMDe16HKTdYCpfsyGPM8fUz_UZyU5HxL2mSsg+tMFE0W5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>OFF topic, sorry...<br>
</div>
<div><br>
</div>
<div>Since not all the stops will have source tags, another
system will be needed to know where there is still work to be
done.<br>
</div>
</div>
</blockquote>
???<br>
That is indeed why that tag must be copied from the *.osm source
file like said in my previous message. <br>
Should some mapper somehow fail to copy the update marker, the bus
stop will remain in to-do state in the osm file and the problem will
be spotted that way.<br>
<blockquote
cite="mid:CAJ6DwMDe16HKTdYCpfsyGPM8fUz_UZyU5HxL2mSsg+tMFE0W5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>This is not very complicated. Every bus/tram stop has a
ref. Compare the refs, compare the other tags. If not present,
the object is still new. If the other tags differ, the object
needs updating, either upstream or downstream.<br>
</div>
</div>
</blockquote>
Once again, what I said is not very complicated indeed.<br>
If some OSM tag and the corresponding *.osm tag differ, we cannot
determine if it is because the tag was not copied or because the
*.osm data is incorrect and the mapper made a correction of it.<br>
Hence, the update marker is necessary in the object tags to witness
that the update was processed.<br>
That doesn't prevent checking mandatory equality of, for example,
the "ref", but data like the name of the stop is subject to user
correction.<br>
<br>
If all the new incoming tags match the OSM tags, and moreover if
they match the previous update, one can sensibly say that the
incoming update may be expunged and only the marker automatically
updated.<br>
<blockquote
cite="mid:CAJ6DwMDe16HKTdYCpfsyGPM8fUz_UZyU5HxL2mSsg+tMFE0W5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>I do have a system in place which does this. The whole
import process is still in a setup phase, which is why you
didn't find information about it on that French page yet.
Anyway, once the upstream data and the data from an Overpass
Query is in a PostGIS DB, it's not very hard to analyse it to
one's heart content and create reports for the wiki with
clickable links so they can be opened with JOSM or Merkaartor
by remote control.<br>
</div>
</div>
</blockquote>
If I continue to like to make quality contribution, I'll be eager to
see that. I congratulate you in advance.<br>
But remember the source=BusCo yyyy-mm tag, else your system will hit
you in the back.<br>
<br>
Best regards,<br>
<br>
<table>
<tbody>
<tr>
<td>André.</td>
</tr>
</tbody>
</table>
<br>
<blockquote
cite="mid:CAJ6DwMDe16HKTdYCpfsyGPM8fUz_UZyU5HxL2mSsg+tMFE0W5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<br>
</div>
<div>Jo<br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-06-30 15:44 GMT+02:00 André Pirard
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:A.Pirard.Papou@gmail.com" target="_blank">A.Pirard.Papou@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi,<br>
<br>
Let us notice that, unlike my message, your replies do
not comment the <b>reasons</b> for source tags
location.<br>
I say:<br>
<ul>
<li>the wiki instructions say to put sources in the
objects</li>
<li>it needs fumbling to see changeset sources (is it
fair to the author?)</li>
<li>only source in objects can be used in overpass
queries<br>
</li>
<li>it's a user hassle having to split his changes so
that the objects correspond to source</li>
<li>seen otherwise, it's attaching the source to the
object or to a mixed bag container</li>
</ul>
Starting from the wiki sentence I commented, the reason
for changeset sources is that other persons do it.<br>
This is, of course not a valid reason unless saying why
they do it and if it is appropriate.<br>
I seem to read that those persons live in the imports
list.<br>
<br>
It is conceivable that a bulk import use changeset
sources if their visibility and queriability is
unimportant.<br>
Bulk imports are one shot operations that do not involve
general mappers and are a thing done afterwards.<br>
<br>
Isolated changes and operations like BusCo <b>do</b>
involve the general mappers.<br>
The BusCo operation is <b>not</b> 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.<br>
Regarding a DB size argument, the overhead of multiple
split changes makes the changeset sources more space
consuming.<br>
<br>
Other comments inline...<br>
<br>
On 2014-06-26 18:17, Jo wrote :<br>
</div>
<div class="">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>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.<br>
<br>
</div>
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.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
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.
<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>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:<br>
<br>
</div>
Ctrl-f<br>
</div>
modified highway=bus_stop<br>
<br>
</div>
then Upload selection, with source=TEC, Bing2011<br>
<br>
</div>
Then perform a general upload for all the rest
with source=Bing2011<br>
</div>
</div>
</blockquote>
</div>
Those who have understood, please raise a hand.<br>
Alternatively:<br>
- put source=BusCo 2014-4 in the object the users copy
from the BusCo.osm file (or its tags if the object already
exists)<br>
- overpass query "source=BusCo 2014-4 ...", get their ref
ID and used to expunge done work from BusCo.osm
<div class="">
<blockquote type="cite">
<div dir="ltr">
<div>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.<br>
</div>
</div>
</blockquote>
</div>
Your preferences are not the only ones.
<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div> </div>
<div>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.<br>
</div>
</div>
</blockquote>
</div>
If the BusCo data needs corrections, the OSM data could be
different and right and the update could be undetected.<br>
By definition, the source=BusCo 2014-4 method is reliable.<br>
This cooperator is perfectly astounded to read the last
phrase here for the first time and to find <a
moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources/TEC#Indiquer_la_source"
target="_blank">no mention of it here</a>.
<div class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div> </div>
<div><br>
</div>
<div><br>
</div>
Jo<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-06-26 14:21 GMT+02:00
Dan S <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:danstowell+osm@gmail.com"
target="_blank">danstowell+osm@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">2014-06-26 12:44
GMT+01:00 André Pirard <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:A.Pirard.Papou@gmail.com"
target="_blank">A.Pirard.Papou@gmail.com</a>></span>:
<div> <br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi, I wonder if <a
moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Key:source"
target="_blank">this phrase
without an explanation link</a>
contains appropriate instructions
(or just press news):<br>
<blockquote type="cite"><b>Since the
introduction of changesets these
tags are often added as <a
moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Changeset"
title="Changeset"
target="_blank">changeset</a>
tags rather than in the features
themselves.</b></blockquote>
It sounds like ("rather than")
source tags in objects must now be
replaced by source tags in
changesets.<br>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>Hi Andre,<br>
<br>
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.<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
I have no understanding problem. But that phrase has a
meaning problem.<br>
Normally, these pages contain instructions how to tag and
not a chronicle of the taggers' doings.<br>
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.<br>
Please correct it.<br>
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. <br>
<div class="">
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
While doing so may be appropriate to
for huge bulk imports, I don't think
it's always, even generally, the
case.<br>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>I agree.<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
Try to convince Jo.
<div class=""><br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> <br>
</div>
<div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Suppose an osm file built from
version 2014_04 of BusCo bus stops
data.<br>
The OSM contributors are invited to
copy each object to OSM and to check
the data, esp. coordinates.<br>
Should:<br>
<ul>
<li>this file's objects contain
source=BusCo 2014-04 (ISO date)<br>
</li>
<li>or the contributor be
requested to add that tag to the
changesets for each and every
update</li>
</ul>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>Which is the best method? Or is
there another one? <br>
</p>
</div>
</blockquote>
</div>
<div>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".<br>
<br>
</div>
<div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
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.<br>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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.<br>
<br>
</div>
<div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
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.<br>
Typical, compared to the variety of
object source tags format, is this
scarce instruction in <a
moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Changeset"
title="Changeset" target="_blank">changeset</a>:<br>
<blockquote type="cite">
<ul>
<li> <tt
style="background-color:#dde;white-space:pre-wrap"
dir="ltr"><a
moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Key:source"
title="Key:source"
target="_blank">source</a>=*</tt>
– specify the source for a
group of edits </li>
</ul>
</blockquote>
Typically, "source for" does not say
"source of" what. Of the objects or
of the edits as a whole import?<br>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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 :)<span><font
color="#888888"><br>
<br>
</font></span></div>
<span><font color="#888888">
<div>Dan</div>
</font></span></div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
<span class="HOEnZb"><font color="#888888">
<table>
<tbody>
<tr>
<td>André.</td>
</tr>
</tbody>
</table>
</font></span><br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>