Work on http://bloodgate.com/map/ continues and it is shaping up nicely :)
Also found a bit of time to map further ways near Ochtendung.
OpenStreetMap
Work on http://bloodgate.com/map/ continues and it is shaping up nicely :)
Also found a bit of time to map further ways near Ochtendung.
Discussion
Comment from andrewpmk on 23 April 2009 at 23:06
The back button is broken. Can you fix it?
Comment from Tels on 24 April 2009 at 06:21
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!
Comment from Chaos99 on 24 April 2009 at 07:13
Doesn't work on Safari(MacOS10.4). Brings up a lot of dialog boxes stating the browser does not support textFill() (about 20 of them) which you have to click away. It completely hangs the browser in the meantime.
While this may be a browser bug, you may want to make in fail in a more pleasant way.
Comment from kaerast on 24 April 2009 at 09:24
It's certainly nice to see somebody working on an alternative to OpenLayers. I don't have time to do a full test, but straight away I can tell you it fails in IE 7 (object expected on line 15)
Comment from chillly on 25 April 2009 at 17:31
I'm not sure that fetching data from the API for rendering in a browser in real time is a good idea at all.
Comment from Tels on 26 April 2009 at 15:15
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?
Comment from chillly on 26 April 2009 at 16:36
I don't think fetching the data is a good idea because of the huge load you impose on the API server - which is our most important server. The other ways of displaying the map render tiles once for each zoom level (some on demand) and then deliver that from a store of these tiles (often using AJAX in OpenLayers). This reduces the impact on the API server to an acceptable level. Using your system if many people all want to view Amsterdam they will each make a massive request of the API server, all asking for the same or similar data which will probably overload it. At lower zoom levels (about 14 and below) the waiting time for the API data is already very long.
The rendering time also grows exponentially as you zoom out as the area covered by the visible map is four time larger the previous zoom level, so you have to extract four times as much data from the API server. Even if you choose to ignore some features at lower zoom levels you will still get all the data.
I think it is great that people try new things - but some things are best tried then abandoned. Why not try using AJAX in new ways using the tile servers, such as smooth zooms and pans.
Comment from Tels on 27 April 2009 at 07:08
@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 ;)