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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
