[OSM-dev] c-programmer at your command

Hendrik Siedelmann hendrik.siedelmann at googlemail.com
Thu Feb 7 22:18:18 GMT 2008


This Project is great, and so I thought I'd like to help. As I do not
own a GPS-device the only possibility is to lend my programming skills
in the c language.

For now I already have some (ugly) code that parses an osm file and
loads the ways into an r-tree, to allow fast lookup of areas. I also
added some first svg export.

But befor I begin developing something that someone else has already
done, what Is needed the most:
- fast Database as a backend for osm-based applications
- unified osm to svg converter
- ... something else I could do?

Also I have (of Course ;) ) some notes to make his Project even better:

Why do nodes and ways have to be split? This makes working with osm
data pretty complicated, as it requieres a database to work with, and
just to get the data of one way requires many node lookups, which is
slow, especially if osm data would be use on handheld devices.
Couldn't nodes simply be identified by their coordinates? This would
also require less memory.

Bezier curves. They are currently added via post-processing, which
means suboptimal results, the mapper has little influence on the
appearence and there are basically no memory savings. Instead of
adding a rounding tag which does not solve most of these issues, what
about deriving the bezier curves from original data?
Gps-Tracks a series of points, and propably also most of the other
sources of map data? (I don't know). So if the mapper simply specifies
that the points between two points in the track form a way, then we
could derive static sets of (bezier-) map data. And route calculations
and so on can be done on the original simple data.

Well thats it for now.
Here is the database I coded for now (better dont't look at it ;) ):
When started it reads from a file "map_p" in the working dir, which
could be a pipe from a decompressor. The program writes data to
"/tmp/osm/" so be sure to create this directory!
After the import is finished, the Program will ask for
latitude/longitude pairs and then dump a svg file named "place.svg" in
the working dir.
The program is slow at the moment, so better test with a small
dataset. I chose ther Germany extract of the planet dump.

Here is such an svg dum:


More information about the dev mailing list