<div dir="ltr">Thanks for the feedback. Four issues arose:<div><br></div><div>1. it's nowadays better to put source and source:date on the changeset instead of the nodes and ways</div><div><div>2. the changeset should have the text import and source</div>
</div><div>3. it's better not to use ref:bag<br></div><div>4. it's better not to use bag:function</div><div><br></div><div>I took these matters back to the others in the Dutch community for reconsideration. In short: we agreed on 2 and 4 for which the Wiki importpage has been updated, we disagreed on 1 and 3. Let me explain the latter two.</div>
<div><br></div><div>Source and source:date on the nodes and ways. We decided not to go for that because we need a simple method (that is: using the info on nodes and ways without deepdigging to get to the source and its date) for updating purposes. A big difference with the AND import is that that was a one-time only import. The BAG data, by law used obligatory among the entire Dutch government, is being updated daily in a strict datamodel, continuously releasing free updates every month. The Dutch community has the intention on using this updated info. For example for a single building update in a new development area and thereby having a new source:date for that single building. It's also somewhat friendlier to non-tech mappers, because it's easier to filter the already imported BAG data in an area from the non-imported parts. See also the previous comment by Bas.</div>
<div><br></div><div>Ref:bag. There is indeed a risk that ref:bag will never be used, just like the AND tags from the 2007 import which I remove every time I work in an area. On the other hand, there is also a likely opportunity that the ID of the building might become interesting in the foreseeable future. At the moment it's our only reference to the building. Since we already change the original BAG data (simplication and validating on a.o. crossing ways and duplicated nodes) the X/Y info will be altered. There is a chance that new open data on the height of buildings might be available within a few years time, which could be nice for updating the buildings for 3D purposes. Another use might be semi-automated feedback to the Dutch Cadastral Office as they have shown an early interest in cooperating with OSM.</div>
<div>The (very likely) risk that mappers might break the ref:bag on merging, copying or splitting of buildings is acceptable, because it's inherent to the open model of OSM. We'll also use the Dutch forum as much as possible for any mapper to get information on the BAG , which could mitigate this risk a bit.</div>
<div><br></div><div>Cheers, Johan</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/28 Sebastiaan Couwenberg <span dir="ltr"><<a href="mailto:sebastic@xs4all.nl" target="_blank">sebastic@xs4all.nl</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/28/2013 09:24 PM, Dan S wrote:<br>
> 2013/11/28 Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>>:<br>
>> Hi,<br>
>><br>
>> On 28.11.2013 20:32, Johan C wrote:<br>
>>> The info on the import can be found<br>
>>> here: <a href="https://wiki.openstreetmap.org/wiki/BAGimport" target="_blank">https://wiki.openstreetmap.org/wiki/BAGimport</a><br>
>><br>
>> It is no longer usual to tag individual objects with "source".<br>
><br>
> You mean for imports in particular, right? I often have manual editing<br>
> sessions with multiple sources (e.g. my gps trace, the bing aerial and<br>
> my local knowledge), and so there's a good reason why many people<br>
> might apply different source tags to objects even within a single<br>
> changeset.<br>
<br>
</div>This is similiar to how we intent the import process to look like. Not a<br>
strictly mechanical import, but having easy access to the buildings and<br>
addresses in JOSM to assist in mapping the area. It's common to want to<br>
adjust the surrounding roads based on the satellite imagery and GPS<br>
traces while working on the buildings and addresses in the area, add<br>
additional POIs, etc.<br>
<br>
Tagging objects with its respective source seems appropriate in this<br>
case. Were the import fully automated using only the changeset seems<br>
more appropriate.<br>
<br>
Kind Regards,<br>
<br>
Bas<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</div></div></blockquote></div><br></div>