[OSM-dev] c-programmer at your command

Frederik Ramm frederik at remote.org
Thu Feb 7 23:50:02 GMT 2008


> 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
> - unified osm to svg converter

Surely you know Osmarender and have looked at what it does? It
delivers excellent results and any SVG renderer would proably have to
stand up to a comparison here. 

Personally I'd very much like to have an Osmarender replacement that
uses the same style files but uses a simpler technique to get from OSM
to SVG, ideally producing SVG that can be processed by efficient SVG
renderers. While I wouldn't personally be opposed to a plain old C
implementation this might not be the best way since again it would
attract less developers than something done in a scripting language.

In this department (rendering), I think what we need most is not a
cool renderer pulled off by a genius programmer, we'd rather need a
plain simple renderer that everybody can work with.

> 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.

That would be ok for read-only rendering purposes, but not for routing
or read-write purposes because you need to know the topology. If two
ways intersect in your scenario, and the user clicks and moves the
intersection point, what would happen? If two ways intersect in your
scenario, how would the routing engine know wheter there's actually a
connection between the two at that point?


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'

More information about the dev mailing list