@chilly:

The load on the API server is not as big as you think, because the data is cached. Actually, all the tile render severs needs to fetch the data once, too, so my scheme doesn't introduce more load on the API server then they do - one actually needs to fetch the data to render it. (In fact, I'd say the API server is more loaded from all the editors than from my mpa display.) The only difference is how often you update your cached version and what data you deliver to the client.

"Even if you choose to ignore some features at lower zoom levels you will still get all the data."

This is not true, one can request subsets of the data. I haven't done this for now for two reasons: simplicity of the implementation, and because some of the documented accesses to the XAPI server didn't actually work and I run out of time to toy around. But technically, for a lower zoom level one only needs to extract some data (like highways and borders), thus reducing the load on the API server considerably.

(Currently, the data fetched from the cache server is reduced depending on zoom level).

As for render speed: My renderer is not really optimized yet.

As for your comment: "but some things are best tried then abandoned" - I gather that you haven't grasped that the AJAX rendered map is a completely new way to see the map - you can customize it at the client side in completely new ways that a "prerender tile" scheme will never be able to deliver.

"Smooth zooms and pans" are not really helping when all you want is a map drawn without landuse at zoom level 14 ;)

To all: It is still quite beta, so please bear with the bugs and problems :)

@Chaos99: Yeah, the "each error gets it's own alert" was an oversight, I should have tested it more. Fixed it now to display this only once. Also, I don't have any means to test Safari at all so I am developing blind for it.

As for the actual text, lots of browsers simple skimp and just skip parts of the specification, like drawing text to canvas :( I need to find a way around that.

@kearast: IE7 doesn't like a "," as the last element in lists and I forgot that the compressor doesn't take them out. As said above, I can't test with IE (easily) so that is a bit of a problem. It seems to work in IE8, tho and should work in IE7 again next revision. (Minus the "no fillText()" problem above).

@chilly: Why do you think so?

Currently each "move" on the map changes the URL by appending the location on the hash via "#lon=....&lat=...&zoom=...". This means the browser thinks you jumped to a new URL each time, and thus the back button doesn't bring you really back to the page you visited before.

It doesn't bring you back to the last location either, because I forgot to add a watchdog for the location hash - will be fixing this in the next version :)

Btw, what browser and OS did you use?

Thanx for the feedback!

Die Luftbilder sind nicht unbedingt genau(er) - durch Verzerrungen oder einfach nur Fehler können die gegenüber der Wirklichkeit verschoben sein.

Normalerweise sollte dein GPS die Wirklichkeit genauer erfassen - allerdings ruinieren hier schlechte Empfangsbedinungen und/oder schlechter Empfänger auch das Ergebniss mal schnell. Die Genauigkeit von GPS liegt ja im besten Fall bei 1..2m, eher schon mal bei 4m - und bei zwei dichtbeieinander liegenden Weg und schmalen Bach können die Tracks schon mal auf der "falschen seite" sein.

Die Karte sollte natürlich dann immer noch mal kontrolliert werden - wenn im realen Leben die Straße schnurgeradeaus geht, aber dein Track leicht im Zickzack dann sollte die Karte natürlich einen Strich haben :)

Am Ende kann man das nicht genau sagen, es braucht halt etwas Gespür, eine Karte zu zeichnen, die einerseits genau ist, andererseits aber auch "einfach" genug, um in der Kartenansicht nicht zu verwirren. Hoffe das hilft :)

Die wget Idee ist sehr nett, aber macht mir trotzdem Bauchschmerzen:

* geht nur mit Internet (hat man ja nicht überall :)
* Ich bin eher konservativ mit updaten, und tue das eher erst, wenn der Vorteil durch die neue Version den Nachteil der Gefahr des "ooops" überwiegt - alles natürlich nur subjektiv :)

Unter Ubuntu liegt das Startscript übrigens unter /usr/bin/josm.