yes, for the record, in Cartagen the limitation was that JavaScript cannot read XML, so my fork of the Rails port generates JSON instead ( https://github.com/jywarren/openstreetmap-website). But there is a parsing step where the node, way, and relation IDs are used to reference them all together once they are imported as JavaScript objects. This is expensive but only performed upon import. This also allows for knockout of duplicate areas of import and such, and for reconnecting relations across vector tile boundaries. On import Cartagen also calculates way area. And if you try reassembling way/node/relation references on the server side & on the fly, your system will slow to a crawl.
So there are lots of advantages to logically separating raw data from efficiently renderable data. Jeff On Thu, Feb 17, 2011 at 7:24 AM, Igor Brejc <[email protected]> wrote: > Hi, > > There are two different things here: > > - A format for efficiently transmitting & storing OSM data in the > memory > - A data model for efficient rendering. > > These are not the same, they serve different purposes and usually if you > want memory efficiency, you'll loose out on the rendering speed side. In > Maperitive I keep these things separate, and the data structures for > rendering are quite different from the OSM data model. Handling > multipolygons, for example, requires transforming the OSM data model into > something more useful for rendering (i.e. polygons with holes). And there > are other kinds of relations which are too expensive to reconstruct each > time you want to update the screen map. > > Another example: when Maperitive renders residential roads (or any other > kind of way, for that matter), it first constructs a graph of these roads to > be able to better place labels, shields etc. This is done only once and then > reused while the map is alive (or until the rendering stylesheet changes). > > On the other hand, loosing node references would make it almost impossible > to construct such a graph. So I think you still need the base OSM model > somewhere - keeping just x,y coords is not enough (well, for Maperitive > anyway). > > Igor > > On Thu, Feb 17, 2011 at 11:20 AM, Nick Whitelegg < > [email protected]> wrote: > >> Hi, >> >> Much of the stuff I'm working on or have been recently involves loading >> OSM data from file or the web, and rendering it client side (e.g. WebGL OSM >> viewer and an augmented-reality app for walkers which I'm just starting work >> on now). Because of this, my server (OSM PostGIS-based) provides OSM data >> not in the standard .osm format, but in a rendering-optimised format with >> ways consisting of a series of x,y coords rather than node references, e.g.: >> >> http://www.free-map.org.uk/ws/trsvr.php?x=4079&y=2740&z=13 >> >> However I'm wondering if there is any consensus on a "standard" OSM data >> format optimised for vector rendering. There seems to be the OSM Mobile >> Binary Protocol though by the looks of things, that's only used in one >> application: the Symbian app "whereami". So does everyone just use their own >> or are there any formats used by multiple apps? >> >> Thanks, >> Nick >> >> _______________________________________________ >> dev mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/dev >> >> > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev > >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
