On Feb 8, 2008 11:54 AM, SteveC <[EMAIL PROTECTED]> wrote: > I agree OSM in OGR is good but doesn't osm2pgsql -> OGR -> anything > also work?
Not really - as osm2pgsql needs PostGIS which is a bitch to install & it relies on a defined attribute set, which is optimised for rendering. > > > 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 > -- Nick Black -------------------------------- http://www.blacksworld.net _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
