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

Marc Kessels marc at kessels.name
Sat Jul 28 18:03:36 BST 2007


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







More information about the dev mailing list