[Imports] Import Proposal - Los Angeles County Land Use

Jason Remillard remillard.jason at gmail.com
Wed Oct 2 23:32:22 UTC 2013


Hi Aaron,

Hopefully we can avoid turning this feedback cycle into a big pile of mush
for you!

I would not be against hardcoding conflation logic for the GNIS nodes and
sending everything else to a real editor for conflation. Let the user click
on the node, pull in just the feature id, discard the rest of the gnis:*
tags, ask the user which name to keep.  It really could be that simple. If
you see "other" tags on the gnis node that were not part of the import, you
can send people to JOSM. It would be safe, is hopefully not too hard, and
would cover 95% of the conflation that needs to be done for these imports.

If you use PostGIS, you can automate all of the data prep, I just finished
this import. It has example code.

https://github.com/jremillard/osm-import-toolkit/tree/master/examples/massMissingPonds

Thanks
Jason.




On Wed, Oct 2, 2013 at 10:38 AM, Aaron Lidman <aaronlidman at gmail.com> wrote:

> Conflation: Yeah that was probably the most time consuming part of
> preparing this data, it just involved too many other applications and
> moving data around a lot, I'll have to give it some thought. I was thinking
> about building a simple script for doing conflation more automatically.
> (specify desired osm tags/type + source data, it removes everything that
> overlaps those tags) Or maybe I should build more of that functionality
> into OSMLY for detecting overlapping data and presenting some kind of error?
>
> Tags: I'm going to build functionality for merging geometry to get gnis
> tags as the other guys have brought up. Not sure how I could make it
> compare tags for possibly multiple items in a meaningful way. Is there
> anything like what you're imagining in JOSM or elsewhere I can get an idea
> from?
>
>
> On 10/2/13 5:04 AM, Serge Wroclawski wrote:
>
>> Aaron,
>>
>> I think this is really great, really smart, innovative and awesome
>> work generally.
>>
>> The direction you're going is exactly along the trajectory that we're
>> moving as a community, using the combination of people and tools and
>> trying to figure out how to use them both where they can do the best
>> job. As we do this, we're all going to have new ideas and tools, and
>> as people try things out, we'll see where it goes.
>>
>> So kudos for taking this on, and kudos for developing a new workflow,
>> with a new tool to help.
>>
>> All that said, I have a few questions, and a couple of concerns.
>>
>> My main concern is one you've already addressed, which is scope. Since
>> your workflow is so new, would it be possible to start with only a
>> single feature, show that it works, and then move on to another?
>>
>> My second concern is updating the data. While many of the features you
>> list don't change annually, they do change over time, and so some
>> thought on the future would be really good. This is where some
>> conflation tools can come into play.  How about just considering the
>> work it would take to do an update of the data, possibly even using
>> the same tools and community effort?
>>
>> And now a question...
>>
>> Your tool does a great job at helping users compare the geometry of
>> two features. How does it do about tag preservation? For example, if
>> the mapped feature has less good geometry, but better tags, will that
>> be shown somewhere?
>>
>> Thanks,
>>
>> - Serge
>>
>>
>
>
> ______________________________**_________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.**org/listinfo/imports<https://lists.openstreetmap.org/listinfo/imports>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20131002/6e295285/attachment-0001.html>


More information about the Imports mailing list