[OSM-dev] c-programmer at your command

Hendrik Siedelmann hendrik.siedelmann at googlemail.com
Sat Feb 9 11:12:26 GMT 2008


> There is a piece of GIS-translation Open Source software that is
> currently head of the horde.
 ... (Good Points but) ...
> So, if you are well at home in C and C++, maybe you would like to
> consider joining the OGR/GDAL team to get OSM as a solid and reliable
> data adapter?
> My knowledge on OGR is excelent as a user, not as a programmer. But my
> bet would be on OGR when I would have the skills to join them.
Sadly I only know c and not c++ . And have neither the time nor will
to learn it at the moment. But OGR and it's drivers seem to be written
in c++.

> > 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
> >
> postGIS, definitly!
I wanted to set up postgresql on my pc, Importing the nodes went fine,
but creating an index on the node-ids flooded my hd and I run out of
space. Also the simple feature set/postgis seem to inlcude quite some
overhead (extra ids, 64bit coordinates), so I turned away from it.

I hate he fact that the hardware gets faster and faster, but thanks to
script languages and bloat software gets slower, faster than hardware
gets faster.

> > - unified osm to svg converter
> >
> Why only stick with svg when OGR opens up a whole lot of data formats
> for you?<http://www.gdal.org/ogr/ogr_formats.html>
I don't like having to many formats around, svg is a standard, and has
good chances to bew usable on mobile devices.

> > - ... something else I could do?
> >
> I think that routing is the way to enhance OSM for the near future.
> There is an implementation of Dijkstra algorithm for postGIS
> <http://www.cartoweb.org/cwiki/PgdijkstraWin32>
> But it would be good to set up a good algorithm that is more general and
> based on binary files rather then database tables, thus optimizing data
> access.
> People are already working on using OSM with qGIS for routing
> <http://blog.qgis.org/?q=node/73> check it out!
Looks like too much work, And I don't have any ideas about routing.

> > 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.
> >
> This is one of the main issues in my opinion too. Therefor good
> translation software needs to be made to get OSM data into a routing
> optimized binary file structure with r-tree functionality?
> > 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.
> >
> Beziers are a major problem in ALL gis file formats. So if you come up
> with a solution there is a great future for you.
> > Well thats it for now.
> > Here is the database I coded for now (better dont't look at it ;) ):
> > http://minimi.dyndns.org/mkdb33.c.bz2
> > 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:
> > http://minimi.dyndns.org/48.78x9.12.svg.bz2
> >
> > hendrik
> >
> >
> Good luck and welcome to the team!
> > _______________________________________________
> > dev mailing list
> > dev at openstreetmap.org
> > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev

I'll try to put up a osmarender c version and develop a lightweight DB
as part of that.


More information about the dev mailing list