[OSM-dev] c-programmer at your command

Milo van der Linden mlinden at zeelandnet.nl
Thu Feb 7 23:50:46 GMT 2008


Hello Hendri (and list)

There is a piece of GIS-translation Open Source software that is 
currently head of the horde.
It mainly consists of two pieces:
- OGR; for translating from an to all kind of GIS formats (including 
shape files and postGIS)<http://www.gdal.org/ogr/>
- GDAL; for raster files warping, georeferencing and 
translating.<http://www.gdal.org/>

OGR/GDAL is solid and extremely active. Their community is even larger 
then the OSM community consisting mostly of GIS professionals.
I have been posting messages to the GDAL/OGR development team to get OSM 
as a recognized datasource integrated in their software.

Why?

Mainly because adding OSM data format to OGR would open up the vault of 
ALL available GIS formats to get your OSM data into!

I know there is an OSM2PostGIS and attempts have been made to create 
stable OSM2SHP conversion software, but adding it to OGR would realy 
speed up things.

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.


Hendrik Siedelmann schreef:
> Hello,
>
> 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
>   
postGIS, definitly!
> - 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>
> - ... 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!
> 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
>
>   





More information about the dev mailing list