On 8 Feb 2008, at 12:29, Nick Black wrote: > 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
Hmm.. apt-get install > & > it relies on a defined attribute set, which is optimised for > rendering. True. It would be great to improve osm2pgsql to support user defined schemas. Artem > > >> >> >> 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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
