Hi, > There is a piece of GIS-translation Open Source software that is > currently head of the horde. ... (Good Points but) ... > 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. Sadly I only know c and not c++ . And have neither the time nor will to learn it at the moment. But OGR and it's drivers seem to be written in c++.
> > 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! I wanted to set up postgresql on my pc, Importing the nodes went fine, but creating an index on the node-ids flooded my hd and I run out of space. Also the simple feature set/postgis seem to inlcude quite some overhead (extra ids, 64bit coordinates), so I turned away from it. I hate he fact that the hardware gets faster and faster, but thanks to script languages and bloat software gets slower, faster than hardware gets faster. > > - 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> I don't like having to many formats around, svg is a standard, and has good chances to bew usable on mobile devices. > > - ... 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! Looks like too much work, And I don't have any ideas about routing. > > 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 I'll try to put up a osmarender c version and develop a lightweight DB as part of that. hendrik _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
