Hi, > 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? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
