[Imports] Dutch addresses and buildings import from BAG

Johan C osmned at gmail.com
Sat Nov 30 22:42:00 UTC 2013

Thanks for the feedback. Four issues arose:

1. it's nowadays better to put source and source:date on the changeset
instead of the nodes and ways
2. the changeset should have the text import and source
3. it's better not to use ref:bag
4. it's better not to use bag:function

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.

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.

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.
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.

Cheers, Johan

2013/11/28 Sebastiaan Couwenberg <sebastic at xs4all.nl>

> On 11/28/2013 09:24 PM, Dan S wrote:
> > 2013/11/28 Frederik Ramm <frederik at remote.org>:
> >> Hi,
> >>
> >> On 28.11.2013 20:32, Johan C wrote:
> >>> The info on the import can be found
> >>> here: https://wiki.openstreetmap.org/wiki/BAGimport
> >>
> >> It is no longer usual to tag individual objects with "source".
> >
> > You mean for imports in particular, right? I often have manual editing
> > sessions with multiple sources (e.g. my gps trace, the bing aerial and
> > my local knowledge), and so there's a good reason why many people
> > might apply different source tags to objects even within a single
> > changeset.
> This is similiar to how we intent the import process to look like. Not a
> strictly mechanical import, but having easy access to the buildings and
> addresses in JOSM to assist in mapping the area. It's common to want to
> adjust the surrounding roads based on the satellite imagery and GPS
> traces while working on the buildings and addresses in the area, add
> additional POIs, etc.
> Tagging objects with its respective source seems appropriate in this
> case. Were the import fully automated using only the changeset seems
> more appropriate.
> Kind Regards,
> Bas
> --
> GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20131130/640e8305/attachment.html>

More information about the Imports mailing list