[OSM-talk-be] CRAB Import Tool

[Marc Gemis]

You could also make a csv file with the diffs and open that with the
OpenData plugin in JOSM. (see my presentation at ESI  on import VMM
monitoring stations )
But of course that requires people to install this plugin.

or you could add all changes in such a way that they are also added to the
tool that Ben proposes.


m


On Wed, Oct 23, 2013 at 10:13 AM, Glenn Plas <glenn at byte-consult.be> wrote:

> On 2013-10-22 20:53, Kurt Roeckx wrote:
>
>> On Mon, Oct 21, 2013 at 10:45:22PM +0200, Kurt Roeckx wrote:
>>
>>> On Mon, Oct 21, 2013 at 10:06:03PM +0200, Kurt Roeckx wrote:
>>>
>>>> I really see no good reason not to add those IDs at this point.
>>>> I don't see the harm in them.  I can only see them being useful.
>>>>
>>> I would actually want to propose a different import strategy:
>>> - Add the CRAB IDs to all existing addresses in Flanders
>>> - Import the rest or large parts of CRAB in one big import
>>>
>> So after feedback on this, I want to propose that instead of
>> actually importing this that we provide the data that this import
>> tool would generate in such a way that it's easy for people to
>> take the data and import it themself, potentially after fixing
>> things.
>>
>> This would make it easier to improve the import tool after getting
>> feedback of what it generates wrong.
>>
>
> If you could export to OSM format , that would be awesome.   Like in the
> way Overpass does this.
>
> In pseudo:
>
> - get data from osm (assuming here , the data is partial, so lets say,
> everything with an 'addr' tag in your field of view.)  , the same effect
> you have when exporting a certain key using overpass.
> - get data from crab, craft is as such (preparse it) to facilitate merging
> with osm data set.
> - Make the diff, but create an OSM compliant xml (with meta data,
> otherwise you won't be able to create a changeset from it)
> - open the changeset with JOSM, verify, correct, validate and push.
>
> So, truthfully, I think a tool like you envision is still interesting and
> the more we do, the better and less manual JOSM work to do.  But we need to
> do chunks of it, we should do this for small area's.    it's also easier to
> (later on) fix things that went wrong yet unnoticed, that way you don't
> have to deal with huge changesets finding that single node on page 450
> (ever tried paging through changesets using the site ? ;-) .   Even a
> perfect full import in one go would give us headaches later.  It keeps
> things managable
>
> I think it's great you want to do this, I'm just not too positive about
> the success and it's not that I doubt your skills, it's that I doubt we'll
> be able to cover all exceptions that you usually run into in a decent
> timeframe.    The problem is not so much the bulk of perfect tagged stuff ,
>   but the ones that need special treatment.   It could turn out to be a
> bigger job than anticipated right now.
>
> Glenn
>
>
>
>
> ______________________________**_________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.**org/listinfo/talk-be<https://lists.openstreetmap.org/listinfo/talk-be>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20131023/0eaebaa5/attachment.htm>