[OSM-dev] c-programmer at your command

Artem Pavlenko artem.mapnik at googlemail.com
Fri Feb 8 12:33:09 GMT 2008

Hello Milo,

> 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.

Have you got the numbers? How much larger? Sounds like my dad  
stronger then your dad kind of thing :)

> 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!
> My knowledge on OGR is excelent as a user, not as a programmer.

Milo, sorry to pick on this, but '... not as a programmer... ' is  a  
key here.


> 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
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev

More information about the dev mailing list