[OSM-dev] [OSM-talk-nl] conversion AND data
Artem Pavlenko
artem at mapnik.org
Mon Jul 30 14:55:28 BST 2007
Hi Marc,
I want to convert _all_ NL data into .osm so I disabled bounds
checking. 2AND runs forever and takes lots of memory :(
Did you manage to convert the whole dataset?
I'm using latest v5.
Regards
Artem
On 29 Jul 2007, at 21:39, Marc Kessels wrote:
> latest version (v5) is online at http://www.kessels.name/and2osm/
>
> this one seems to result in a proper output of the data, including all
> waterways and their islands (which were causing problems see mail
> below
> from Jon).
>
> only remaining "urgent" item is that some AND nodes (~800, so about
> 0.05%) have more than one ID. this might give problems for one-way
> streets. have to check whether this is a real problem or not.
>
> greetz,
> Marc
>
>
> On Sat, 2007-07-28 at 19:03 +0200, Marc Kessels wrote:
>> On Sat, 2007-07-28 at 17:47 +0100, Jon Burgess wrote:
>>> On Sat, 2007-07-28 at 17:55 +0200, Marc Kessels wrote:
>>>> Hi Jon,
>>>>
>>>> thanks for your feedback. At this moment no aggregation of roads
>>>> is done
>>>> in my code. Apparantly that is really required for good
>>>> rendering. I
>>>> will start to have a look at that.
>>>>
>>>> I also found several bugs in the code, so please download
>>>> version 3 from
>>>> http://www.kessels.name/and2osm/
>>>> It now also includes a bounding box, for faster conversion of a
>>>> problamatic area.
>>>>
>>>> greetz,
>>>> Marc
>>>
>>> Hi,
>>> I've just tried version 3. Initially I thought there was a problem
>>> becuase ig genreated lots of errors and finished in a few seconds
>>> but it
>>> looks like you've just got a tiny bounding box. It took me a
>>> while to
>>> find the data on the map :-)
>>>
>>> There is an example of where an area isn't closed properly in
>>> this data.
>>> See the park in the S-W corner: leisure=park, AND=10000013. This
>>> has a
>>> long N-S segment joining it to another area instead of being closed.
>>>
>>> I'd be tempted to use the libavl binary tree. It should be more
>>> maintainable in the long term, for an example see
>>> http://trac.openstreetmap.org/browser/applications/rendering/
>>> mapnik/all_tiles/C
>>> About the only thing you need to do is link against bst.[ch] and
>>> write
>>> the comparison function. All the tree management and searching is
>>> taken
>>> care of for you. libavl also provides other more advanced
>>> variants of
>>> the binary tree which can be dropped in with just a few lines of
>>> code
>>> change.
>>>
>>> Jon
>>>
>> Hi,
>>
>> well, those errors were just reminders to the things that need
>> fixing:
>> some nodes (having a ND_ID) in the AND data appear to be a way (or
>> area). This would result in a problem: to which point does the ID
>> belong
>> to...
>>
>> second problem: some (lat,lon) coordinates appear as different nodes
>> having a different ID, so an easy lookup is not possible for checking
>> the direction of a one-way street (which is not always the
>> direction of
>> the and-shape...).
>>
>> third problem: one-way streets have to be corresponding to the
>> from-ID
>> and to-ID and not to the shape direction (requires reversing
>> segments,
>> etc).
>>
>> compared to that, merging of ways is only a tiny problem...
>>
>> I have to leave now for a party, so feel free to submit a patch
>> for the
>> b-tree improvement. That was source-code I was looking for!
>>
>> greetz,
>> Marc
>>
>>
>>
>>
>> _______________________________________________
>> Talk-nl mailing list
>> Talk-nl at openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
Artem Pavlenko
http://mapnik.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070730/1b50fb40/attachment.html>
More information about the dev
mailing list