Hi, Tels -<div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">> It's not been optimized yet, so loading is a little slow, but I'm optimistic<br>

> that it will scale.<br>
<br>
Based on my experience, I can tell you right away it won't scale :) Not to<br>
discourage you, but:<br>
<br>
* the amount of data is really huge. Throwing a few dozend megabyte XML or even<br>
JSON at the browser will bring it to its knees. Not to mention the data you need<br>
to render even a small city.<br>
* re-rendering everything takes a long time. You want to avoid that :)<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Actually, rendering in the browser's been pretty good - for example this page loaded with no noticeable slowdown, and I haven't even begun optimizing:</div><div><br></div><div><a href="http://www.flickr.com/photos/jeffreywarren/3476532351/">http://www.flickr.com/photos/jeffreywarren/3476532351/</a></div>
<div><br></div><div>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... </div><div>
<br></div><div>What I'm looking at now is:</div><div><br></div><div>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?)</div>
<div><br></div><div>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: <a href="http://vimeo.com/4435969">http://vimeo.com/4435969</a></div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>What strategies have you employed, if you're willing to share?</div>
<div><br></div><div><div>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.</div>
<div><br></div></div><div>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 <a href="http://code.google.com/p/cartagen/">http://code.google.com/p/cartagen/</a>. </div>
<div><br></div><div>Best,</div><div>Jeff</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
My app has already quite a few optimizations, and it still chokes at big cities<br>
like Berlin or London. However, I am confident that things can be improved :)<br>
<br>
(Browser limitations non-withstanding. Single-threaded dead-slow JS and<br>
incomplete Canvas spec without dashe I hate thee... :(<br>
<br>
Regarding the rule sets and CSS:<br>
<br>
I've already considered adding a different rule-set (just to show that it can be<br>
done). However, from a technical viewpoint, that is not that spectacular. As long<br>
as the renderer is flexible enough to handle the wanted features, it doesn't<br>
really matter in what format the rules are (CSS, GSS, JSON, XML, you name it) or<br>
where they come from (hard-coded, web, URI, user input), as long as you can load,<br>
parse and convert them, it can display them.<br>
<br>
In my eyes the much bigger impact is that you no longer need different sets of<br>
tiles or tile providers - just the data and the rules to display it and the map<br>
can morph in real-time from mapnik to cyclemap to whatever-you-want. And one more<br>
button click and the user can save it locally. That's at least my vision I work<br>
towards :)<br>
<br>
All the best,<br>
<br>
Tels<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
</blockquote></div><br></div>