I agree OSM in OGR is good but doesn't osm2pgsql -> OGR -> anything also work?
On 7 Feb 2008, at 23:50, Milo van der Linden wrote: > 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 >> [email protected] >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev >> >> > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev > have fun, SteveC | [EMAIL PROTECTED] | http://www.asklater.com/steve/ _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
