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

Jeffrey Warren warren at mit.edu
Thu May 7 00:46:36 BST 2009

Hi, Tels -

> > It's not been optimized yet, so loading is a little slow, but I'm
> optimistic
> > that it will scale.
> Based on my experience, I can tell you right away it won't scale :) Not to
> discourage you, but:
> * the amount of data is really huge. Throwing a few dozend megabyte XML or
> even
> JSON at the browser will bring it to its knees. Not to mention the data you
> need
> to render even a small city.
> * re-rendering everything takes a long time. You want to avoid that :)

I was actually talking about server-side load time. I'm running it off the
0.6 API, so it packs up XML, sends it to my server, i unpack, re-encode to
JSON, send to the browser, render. Obviously that's SUPER inefficient, so
I'm looking forward to cutting a lot of that out in the next week or so.

Actually, rendering in the browser's been pretty good - for example this
page loaded with no noticeable slowdown, and I haven't even begun


But you're right, it's a challenge. I'm impressed that you rendered a whole
city like Berlin - do you have some code online so I can see, or a
screenshot? I bet it looks great...

What I'm looking at now is:

a) rendering only some tags per zoom-level, so no rendering footpaths and
buildings as you zoom out... but that's dependent on the xapi, which I
haven't been able to fetch from reliably (help anyone?)

b) cutting the API out of the loop and running direct from a planet.osm, but
then you can't use it to view live edits, like you can here:

c) trying to serve partial polygons... I'd like to try plotting only every
3rd or 10th node... do the polygons collapse? Can i cull nodes in a more
intelligent way? Someone on this list or geowanking pointed to a company
that can serve lower-res polys over an API. I'm sure folks have worked on
this in tile systems, so if you know anything about it and are willing to
share, I'm all ears. This becomes really relevant as you zoom out... don't
want to render every node for the coast of Argentina, for example.

d) oh, and localStorage. I've partially implemented that but haven't had
much testing... other work... ugh. So caching on a few levels, basically.

What strategies have you employed, if you're willing to share?

Also agreed that GSS is not technically spectacular - the driving motivation
is that it is legible to those new to mapping, being CSS-like. So really an
adoption decision, though the JavaScript-ability of it is a nice bonus -
dynamic rules are fun.

Anyways, I'm excited to hear you've been working on this kind of stuff too.
I'm happy to collaborate or just share information, the whole codebase is
at http://code.google.com/p/cartagen/.


> My app has already quite a few optimizations, and it still chokes at big
> cities
> like Berlin or London. However, I am confident that things can be improved
> :)
> (Browser limitations non-withstanding. Single-threaded dead-slow JS and
> incomplete Canvas spec without dashe I hate thee... :(
> Regarding the rule sets and CSS:
> I've already considered adding a different rule-set (just to show that it
> can be
> done). However, from a technical viewpoint, that is not that spectacular.
> As long
> as the renderer is flexible enough to handle the wanted features, it
> doesn't
> really matter in what format the rules are (CSS, GSS, JSON, XML, you name
> it) or
> where they come from (hard-coded, web, URI, user input), as long as you can
> load,
> parse and convert them, it can display them.
> In my eyes the much bigger impact is that you no longer need different sets
> of
> tiles or tile providers - just the data and the rules to display it and the
> map
> can morph in real-time from mapnik to cyclemap to whatever-you-want. And
> one more
> button click and the user can save it locally. That's at least my vision I
> work
> towards :)
> All the best,
> Tels
> _______________________________________________
> 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/20090506/4e65b15b/attachment.html>

More information about the dev mailing list