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

Tels nospam-abuse at bloodgate.com
Sat May 9 12:53:20 BST 2009


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 
IIRC)

* 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090509/c3131ff7/attachment.pgp>


More information about the dev mailing list