>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.
One has to remember though that if you're using an OSM PostGIS database the raw data already is stored in a "renderable" format, i.e. a series of points and lines, so converting this to OSM format could not actually be done easily because links between ways and nodes are not stored. Nick [email protected] wrote: ----- To: Igor Brejc <[email protected]> From: Jeffrey Warren Sent by: [email protected] Date: 17/02/2011 01:11PM Cc: Nick Whitelegg <[email protected]>, [email protected] Subject: Re: [OSM-dev] OSM formats optimised for client-side vector rendering? 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
