[OSM-talk-nl] [OSM-dev] conversion AND data

[Artem Pavlenko]

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/talk-nl/attachments/20070730/1b50fb40/attachment.htm>