[OSM-talk] Import of buildings in Chicago

[Frank Steggink]

On 27-5-2012 20:58, Ian Dees wrote:
> On Sun, May 27, 2012 at 1:53 PM, Alan <grunthos503 at yahoo.com 
> <mailto:grunthos503 at yahoo.com>> wrote:
>
>
>     I object.
>
>     An ID tag is highly useful for future reconciliation and/or
>     synchronization later.  And the "chicago:" namespace is, in my
>     opinion, definitely the correct way to do it, because it clearly
>     defines the scope of the id.  The chicago:building_id should stay.
>        Not including it is "dumping data" into OSM; including it is
>     enabling collaborative use.
>
>
> I've searched for a reliable way of doing this for years and have yet 
> to find anything worthwhile.
>
> Leaving the external ID on the objects doesn't really help when others 
> remove or split the shape later on. On the other hand, they don't hurt 
> anything...
>
I tend to think that keeping the ID has no use. As Ian mentioned, users 
can (and will) edit the data, so those features become split, merged 
together, or erased. The way OSM 'works' makes it really hard to deal 
with the ID's. There is also the principle that imports should not 
override user-contributed data, so (I assume that) a part of the 
building won't be imported at all. That will leave the set of ID's in 
the OSM DB in an incomplete state, which makes it much less useful.

Updates, if done at all, could better be done by using geographical 
matching. It would be great to have some generic tools with which an 
external datasource can be compared with OSM. This will generate a set 
of changeset files: one with matching features, one with modified 
features, one with 'new' features (not existing in OSM), one with 
'deleted' features (features which only exist in OSM). Then the user 
taking care of the import would only need to look at the latter three, 
to judge what has happened, and manually apply the changes he wishes.

In the Dutch community we've been discussing this a while ago, because 
all buildings in the Netherlands are available in a high quality PD 
dataset, called BAG (Basisregistratie Adressen and Gebouwen: base 
registration of adresses and buildings). Ironically, exactly the reason 
this dataset is existing and freely available, it makes it not worth 
while the effort to import this into OSM, and impose the burden of 
updating it onto ourselves. It is much more convenient to take OSM 
without buildings (and addresses) and merge this with the other dataset.

Frank