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. 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. hendrik _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
