[Imports] Zaatari Imports

Paul Norman penorman at mac.com
Thu Nov 28 08:39:20 UTC 2013

I had missed this message, and since there haven't been any proposed
updates, so it slipped my radar


It sounds like unosat:acquisition_date is unnecessary and safe to remove.


How do you plan to conflate with buildings in OSM which are not from the
UNOSAT source? Why can you not use the same conflation logic for buildings
in OSM that are from UNOSAT?


Keep in mind that 

-          some buildings that were imported have been deleted from OSM and
should not be reimported

-          buildings have been mapped independently of UNOSAT


From: Mikel Maron [mailto:mikel_maron at yahoo.com] 
Sent: Wednesday, October 30, 2013 1:30 PM
To: Paul Norman; 'Jason Remillard'
Cc: imports at openstreetmap.org
Subject: Re: [Imports] Zaatari Imports


"unosat:acquisition_date" is the date of satellite imagery acquisition in
which the structure was first noted.

"unosat:event_code" uniquely identifies the humanitarian event. In this
case, it will be the same for all data acquired of Zaatari refugee camp. 

"unosat:objectid" is an identifier used by unosat for each structure.


The event_code and objectid together form an external primary key. The data
in acquisition_date is unnecessary to retain.


I'm ok to reform this as source:pkey=unosat:{{event_code}}:{{objectid}}, or
something similar. As long as there's a reference to the external primary
key, then the conflation will work fine.


If that's a way to go, then let's form a consensus, and next time I update
data from Unosat (which should be within a month), I can clean up the tags.




ps I might be a little slow to respond sometimes, on paternity leave right


* Mikel Maron * +14152835207 @mikel s:mikelmaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20131128/f1cc486e/attachment.html>

More information about the Imports mailing list