Hi, 2008/2/8, Robert (Jamie) Munro <[EMAIL PROTECTED]>: > Hendrik Siedelmann wrote: > > 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 > > If I were going to do that, my aims would be: > > 1. Small enough and simple enough to work on embedded devices such as > phones. > 2. Efficient DB lookups by location and for routing. > 3. Efficient updating with the hourly dumps. > 4. Mapnik driver YES! Very lightweight is the goal, perhaps with a binary excahnge format. Never Looked at the hourly dumps, but as the database is fast, updating should be fast too. Lookups by location is what I have the DB designed for but not routing.
> > - unified osm to svg converter > > SVG output from mapnik might be useful, for Mapnik, but not that useful > for us. Something on the web to make a vectorised PDF map for printing > would also be nice. Hmm, thats in the direction svg export from osm. I think tehre are already tools fo SVG to ps/pdf. > > - ... something else I could do? > > Do you have a symbian mobile phone? Look at WhereAmI. > > Something I've been wanting to do is process all the GPS co-ordinate > data and see how far away it is from roads already entered, then How much data are all gps tracks? > > 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. > > Routing, editing and tagging. But they don't have to be split in your > database if you have a better way. It's been suggested in the past that > only nodes that are either tagged or form a junction need to be kept in > the nodes table. Other nodes that just make the in-betweens of the ways > could be stored separately. Thats my idea, nodes that are never used outside ways will never be requested for somthing else. > > 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? > > Would be a good idea, but early on there were patent questions over it, > so we didn't go in that direction. You could try writing code to > simplify stretches of "other nodes" into a nearest bezier curve, and > show us the results. How much data can you save? How good do the maps < > > look. > Robert (Jamie) Munro > > > > > Another idea I had is to look at the GPX data, find parts of it that are > not near existing roads, and highlight them on a map, so that people can > vectorise them. Again two jobs for a fast Database plus gps tracks. hendrik _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
