[OSM-dev] c-programmer at your command
hendrik.siedelmann at googlemail.com
Sat Feb 9 11:24:28 GMT 2008
2008/2/8, Robert (Jamie) Munro <rjmunro at arjam.net>:
> 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
> 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.
More information about the dev