[OSM-dev] OSM formats optimised for client-side vector rendering?

Nick Whitelegg Nick.Whitelegg at solent.ac.uk
Thu Feb 17 14:02:07 GMT 2011


>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


-----jywarren at gmail.com wrote: -----
To: Igor Brejc <igor.brejc at gmail.com>
From: Jeffrey Warren 
Sent by: jywarren at gmail.com
Date: 17/02/2011 01:11PM
Cc: Nick Whitelegg <Nick.Whitelegg at solent.ac.uk>, dev at openstreetmap.org
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 <igor.brejc at gmail.com> 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 <Nick.Whitelegg at solent.ac.uk> 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
 dev at openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev
 

 
_______________________________________________
 dev mailing list
 dev at openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev
 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20110217/eba92193/attachment-0001.html>


More information about the dev mailing list