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@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
_______________________________________________
dev mailing list
[EMAIL PROTECTED]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Artem Pavlenko
http://mapnik.org
_______________________________________________
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
