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

2011-02-18 Thread Nick Whitelegg
anks for the replies, got some useful ideas. Nick -Nic Roets wrote: - To: Tim Teulings From: Nic Roets Date: 17/02/2011 07:23PM Cc: dev@openstreetmap.org Subject: Re: [OSM-dev] OSM formats optimised for client-side vector rendering? On Thu, Feb 17, 2011 at 7:02 PM, Tim Teulings wrot

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

2011-02-17 Thread Samat K Jain
On Thursday, February 17, 2011 03:20:30 AM Nick Whitelegg wrote: > 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 > applica

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

2011-02-17 Thread Jukka Rahkonen
Nick Whitelegg wrote: >>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 an

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

2011-02-17 Thread Nic Roets
On Thu, Feb 17, 2011 at 7:02 PM, Tim Teulings wrote: > There is always a > trade of :-/ Absolutely. I think Nick refers to mobile users, in which case the tradeoffs are (a) the time of the user (b) mobile bandwidth (c) processing power, i.e. must the user buy a faster phone to run the app (d) RAM

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

2011-02-17 Thread Tim Teulings
Hello! 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 No, as for the reason other people already have mentioned. For libosmscout (clientside *offline* map rendering) the data format requires: * A

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

2011-02-17 Thread Nick Whitelegg
>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. >

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

2011-02-17 Thread Nick Whitelegg
k -jywar...@gmail.com wrote: - To: Igor Brejc From: Jeffrey Warren Sent by: jywar...@gmail.com Date: 17/02/2011 01:11PM Cc: Nick Whitelegg , dev@openstreetmap.org Subject: Re: [OSM-dev] OSM formats optimised for client-side vector rendering? yes, for the record, in Cartagen the limitat

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

2011-02-17 Thread Jeffrey Warren
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 on

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

2011-02-17 Thread Igor Brejc
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

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

2011-02-17 Thread Nick Whitelegg
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 O