[Imports] Zaatari Imports
remillard.jason at gmail.com
Sun Oct 13 01:17:42 UTC 2013
Normally, I would ask for 3 weeks of discussion for your
imports/automated edit, look at the code, and would certainly complain
about those tags.
The primary identity of any given object used for automated updates is
by definition a bit fuzzy, nothing can change that.. If many people
were editing this data by hand, it is an absolute certainty that those
unosat tags would be deleted, copied, and otherwise mangled by normal
manual mapping activities. Ultimately the most robust conflation logic
for OSM uses the location, shape, and native OSM tags of the features
to form an identity. Given that we still don't have good tools for
updating OSM against external data, your work is time sensitive, and
providing critical services that are probably not available outside of
OSM, you should just do what you think is best on the external id
On Fri, Oct 11, 2013 at 11:08 AM, Mikel Maron <mikel_maron at yahoo.com> wrote:
> Paul got in touch, with questions about the recent imports in Zaatari
> refugee camp. Mea culpa for not raising the imports on this list.
> Description of the project and process is at.
> Pual says "The biggest concern is the tags. Tags like
> unosat:acquisition_date, unosat:event_code and unosat:objected need to be
> discussed on the list."
> These tags are present to help with conflation (which we've now done twice
> successfully). UNOSAT will continue to periodically update their analysis,
> and need to identify what has previously been imported from their data.
> Looking again, unosat:acquisition_date is not necessary to retain in OSM,
> but unosat:event_code and unosat:objectid are needed to uniquely associate
> these features with UNOSAT data.
> Interested to hear any feedback on this.
> ps Note, I might be absent from discussion at short notice for paternity
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
> Imports mailing list
> Imports at openstreetmap.org
More information about the Imports