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

Jeffrey Warren warren at mit.edu
Thu Feb 17 13:11:01 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.

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/8fdb70f2/attachment.html>


More information about the dev mailing list