[OSM-dev] Cartagen - client-side vector based map renderer, dynamic maps

Graham Jones (Physics) grahamjones at physics.org
Sat May 9 20:10:10 BST 2009

I have been thinking about how to do real time rendering for a little while
(but unlike you guys, I haven't had chance to actually do anything....one

The way I was planning on dealing with the problem of too much data at low
zoom levels wast to extend the idea of the tile data server (
http://wiki.openstreetmap.org/index.php/OJW%27s_tile_data_server), but
simplify the data on the server before it is passed to the client (this will
have to be done in advance because real time will be difficult...

The approach I was thinking of taking was to reduce the number of nodes by
recognising that each tile is only a 256x256 pixel area, so if two nodes
share the same pixel, merge them.
You would also prune out any ways that are less than 1 pixel long (this will
get rid of a lot at low zoom levels - you could probably be even more
vicious than this without losing anything).
You would probably prune out some of the points of interest too (e.g. bus
stops, park benches) that are irrelevant at low zoom levels, but this would
depend on what you are going to do with the data.

I accept that doing this will preclude you writing an editor, because the
data you receive will be very different to that in the real database.

As I say, this is just an idea - I haven't tried it yet, but I think it
would help with the 'rendering a whole city' problem.  Of course there is a
lot of pre-processing to be done, but it doesn't sound much worse than
rendering tiles into raster images.

If this sounds vaguely useful to anyone I could move it up my list of things
to do.....


2009/5/9 Tels <nospam-abuse at bloodgate.com>

> Moin,
> On Friday 08 May 2009 22:09:17 you wrote:
> > Great, this is a good discussion. I've put up a wiki page with some
> > of the things we've covered, with pros/cons. I hope we can continue
> > to talk about our approaches and as we optimize for different
> > problems post some of it back up here:
> > http://code.google.com/p/cartagen/wiki/FeatureTradeoff
> >
> > I put in what I could gather about Temap, but feel free to update and
> > add more pros and cons... this is just my thought process so far. We
> > might also add a "status" column so we can annotate what we learn
> > from each approach.
> Ah, interesting. Since I don't have a google account, I reply here
> instead:
> * Server-side proxy and filter   Yes     ?
> Temap has a server side proxy and filer, called "osmapi" and it is
> running at http://bloodgate.com/cgi-bin/osmapi :)
> * loading data live & direct from an API server
> Makes editor possible: I think that editing would be even possible if
> you do not load live from the API server, because you could: A:
> instruct the proxy to bypass its cache and reload from the API server
> again, and then upload the changes back to the proxy, which in turn
> uploads to the API server. (Due to cross-domain security the JS cannot
> talk to the API server directly unless a bit of JS is served from
> there, too. (There is a possibility, but it only works in Firefox 3.5
> * Pruning datasets before handing to JavaScript
> Under cons "Looses important metadata" - I would say "non-important
> metadata". The only real con is that if you need that metadata (f.i.
> for editing), you need to download it for the features the user wants
> to touch and edit. Or in other words, you do not need to download
> every "FIXME" and "attribution" just to render the map, but when the
> user inspects features, you need the data.
> Like the live-loading above, I think basically it will boil down to
> hybrid approaches. E.g. you load the bulk in a pruned way from the
> proxy, but if the user wants to change a street, you download the data
> for that street directly and 100%, then upload the change.
> * Serve reduced polygons for lower zoom levels
> I would add "unclear how much it speeds things up". I might be that the
> entire coastline of Europe is less data than lets say the inner parts
> of Washington DC :)
> * use localStorage to persist a cache in the browser
> Again, I don't see what localStorage adds over the traditional browser
> cache - if I download 7.3,50.4,7.4,50.4.json.gz it will get cached and
> the browser will fetch it from the cache next time (when the server
> says the data is not too old). That automatically limits the storage
> (user settable!), validates the freshness of the data etc. The
> traditional cache is very good at solving these things, so implementing
> it manually in localstorage seems like re-inventing the wheel to me.
> (You can prove me wrong, tho :)
> Con: Doesn't work in all browsers (which ones do have it btw?)
> * Request plots filtered by tag          Yes     ?
> temap does this, it loads reduced datasets for zoom level 11, and for 10
> and below. When you zoom in, it loads the full data set. (What it
> doesn't is reduce the dataset, once you have a certain level of data,
> zooming out will just reduce the data during rendering by skipping
> things. That's because I figured that pre-filtering the data client
> side would be as much as work as jus skipping parts. However, that
> might be able to be improved upon.
> In summary I would also like to add that all these
> various "pre-computation" and "caching" strategies are quite nice and
> helpful, but they are also all "premature" optimizations in the sense
> that I'd first get it to work at all, then toy around reducing the
> work. E.g. rendering labels on a canvas is problem that is not solved
> in all browsers, and no matter how much or little you cache, it won't
> change the fact that Opera 9.6 has no labels on the map :(
> Btw, jeffry:
> > > > > * There is a talk I proposed for State of the Map and I don't
> > > > > want to spoil everything before :)
> > > >
> > > > yes, me too! so if you want to discuss off-list that's fine.
> > >
> > > Heh, you have a talk scheduled, too? :) That sounds like fun :)
> Will you be at the conference? :)
> All the best,
> Tels
> --
>  Signed on Sat May  9 13:37:44 2009 with key 0x93B84C15.
>  Get one of my photo posters: http://bloodgate.com/posters
>  PGP key on http://bloodgate.com/tels.asc or per email.
>  "Build a man a fire, and he'll be warm for a day. Set a man on fire,
>  and he'll be warm for the rest of his life."
>  -- Terry Pratchett
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev

Dr. Graham Jones
Hartlepool, UK
email: grahamjones139 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090509/c94947f2/attachment.html>

More information about the dev mailing list