[Imports] [Import] Infrastructures and Village boundaries of Surabaya City (Indonesia- East Java region)

Kevin Kenny kevin.b.kenny+osm at gmail.com
Mon Sep 26 18:13:20 UTC 2016


Wow, for once Frederik and I agree on something having to do with an import!

(I'm teasing, of course.)

Even better than "remove the object from the import list so you don't
create a duplicate" is "conflate the objects so that you get the best
information from both sources." But we all knew that:  conflation >
avoidance > duplication.

Conflation is more work, though, and usually needs at least consultation
with the local mapper. That's what I did on a recent project to make sure
that the State Parks in New York were all there - using the laborious
process of reconstructing their boundaries from the tax rolls. If I saw a
substantial difference in the park boundary between what the tax rolls
showed and what was in OSM, I got in touch with the mapper who put the park
boundary there in the first place. In every single case, the response from
the local mapper was that they were tracing differences in landcover from
orthophotos, and they welcomed boundaries from a more authoritative source.
All the rest of the data (that is to say, the tagging) - the local mapper's
information would win out over the "official" information unless I could
verify personally that the "official" version was correct. (For well over
half the state parks, nobody had mapped them yet..)  I didn't call this one
an 'import' because all edits were applied manually, using carefully
selected data from the tax parcels and a lot of manual patchwork to make
the boundaries coherent.

It's fairly safe to automate conflation only if you can prove (generally
through an object's version history) that the object you're destroying was
the result of an earlier import, and you have a reasonably comprehensive
understanding of how the earlier import was done. I did a lot of that with
the reimport of the "New York DEC Lands" file - replacing old information
with new, and in some cases then reapplying changes that the locals had
made.

Now, having done a couple, I'll concur with Frederik that imports are
insanely difficult to get right, generally an order of magnitude more work
than the proponent expects.


On Mon, Sep 26, 2016 at 12:18 PM, Frederik Ramm <frederik at remote.org> wrote:

> Dewi,
>
> On 09/26/2016 07:26 AM, Dewi Sulistioningrum wrote:
> > The source data and permission letter for data license from government
> > disaster in East Java.
>
> I can't see the permission letter?
>
> I have looked at the infrastructure import web page and I think you
> should perhaps add a sentence like "if you find that there is already a
> node or building mapped in OSM, remove that object from the import list
> so you don't create a duplicate" or so.
>
> Best
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> 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/20160926/a7423af8/attachment.html>


More information about the Imports mailing list