[OSM-dev] c-programmer at your command

Hendrik Siedelmann hendrik.siedelmann at googlemail.com
Sat Feb 9 10:55:29 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.
Looking at the rules files it looks doable (to make it simple). I will
simply split the osm to database part and the svg export. The rules
file seem to only specifiy filtering and styling in one, Just text
will propably get complicated.

> > 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?
Well editing can still treat multiple nodes at one point as a single
point, the will just be split in the DB. To routing: I have no clue
how it's done at the moment, but doing routing from a standard databse
should never be fast, instead a special routing data set could be
created. Because the routing engine does only need he topology, which
means connections and the length/time to travel between those
connections, but not all the segments and details inbetween.


More information about the dev mailing list