On 8 Feb 2008, at 11:54, SteveC wrote: > I agree OSM in OGR is good but doesn't osm2pgsql -> OGR -> anything > also work? >
Of course, it does. > 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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
