Re: [OSM-talk] more OSM coming soon
On Thu, Jun 18, 2009 at 10:56 PM, Ivo van den Maagdenbergivo.vdmaagdenb...@gmail.com wrote: What the reason is that I would get the 404.png is not fully clear to me. Glad that it's working for you. For an explanation of the above, it's not actually the tileserver that ever returns the 404.png. It's the javascript that controls this, and if the javascript can't get a tile for some reason, it swaps in the 404.png. So because your browser was blocking those tile requests, the javascript showed you the more osm soon picture. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
2009/5/13 Jon Burgess jburgess...@googlemail.com On Wed, 2009-05-13 at 22:12 +0100, Thomas Wood wrote: 2009/5/13 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com: Hi Folks, This is some sort of quality of service question. Half of all the tiles on http://www.openstreetmap.org render as 'more OSM coming soon'. I want to know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable hardware) The tiles display this in the case of network troubles where the server isn't reachable, they're also displayed if the tile hasn't yet been rendered (and is present on the server's disk) and when it's not possible to render on the fly. Otherwise, the tile is added to the render queue and should be available at some point shortly in the future. Showing OSM to a friend that has not seen 'the Map' does not give a good impression this way. A solution is to implement some sort of double buffering where the old tiles are kept for display until the new one has properly rendered? Well, that's maybe impossible, but it would improve the responsiveness of the http://www.openstreetmap.org at the moment. I believe this is already the case. There is a cache of tiles which is used when the rendering can not keep up. The weekly planet import is running at the moment and I have temporarily turned of the re-rendering of tiles so you will only seeing tiles from the cache right now. I'm in the middle of making some updates to the server to migrate the cached tiles and rendering database to an external disk array which will speed things up quite a bit. All the old tiles should still be available, but the live rendering probably won't restart until some time tomorrow. Strange thing, after a month things seem not to have improved much on the frontpage for openstreetmap, with respect to the number of tiles being rendered at a fairly reasonable place and zoom-level like: http://www.openstreetmap.org/?lat=51.91lon=-0.23zoom=7layers=B000FTF In my browser it currently shows 4 out of 12 renderd tiles ... more OSM coming soon. As mentioned before, I would like to raise some concern to have at least rendered tiles available at all times. Especially now, it seems things are broken to a noticable extent. Is there something to do about this? Maybe not flush previous rendered tiles until they are actually rerenderd on an another disklocation and when the new tile is ready, copy it over the old tile to keep the update fairly unnoticable. Then again, I am just guessing how the rendering takes place, so this approach might be totally unpractical. Looking trough the openlayer code reference by the map page, the tiles seem to come from var noname = new OpenLayers.Layer.OSM(NoName, [ http://a.tile.cloudmade.com/; + nonamekey + /3/256/, http://b.tile.cloudmade.com/; + nonamekey + /3/256/, http://c.tile.cloudmade.com/; + nonamekey + /3/256/ Maybe there is a known bottleneck in infrastructure that makes the tiles fail to be rendered? Bye, Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
2009/6/18 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com var noname = new OpenLayers.Layer.OSM(NoName, [ http://a.tile.cloudmade.com/; + nonamekey + /3/256/, http://b.tile.cloudmade.com/; + nonamekey + /3/256/, http://c.tile.cloudmade.com/; + nonamekey + /3/256/ Closer inspection and attention :/ reveals that the main tiles come from http://a.tile.openstreetmap.org/ and http://b.tile.openstreetmap.org/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Thu, 2009-06-18 at 20:26 +0200, Ivo van den Maagdenberg wrote: 2009/6/18 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com var noname = new OpenLayers.Layer.OSM(NoName, [ http://a.tile.cloudmade.com/; + nonamekey + /3/256/, http://b.tile.cloudmade.com/; + nonamekey + /3/256/, http://c.tile.cloudmade.com/; + nonamekey + /3/256/ Closer inspection and attention :/ reveals that the main tiles come from http://a.tile.openstreetmap.org/ and http://b.tile.openstreetmap.org/ Ah... if you consistently see 1 in every 3 tiles as missing then chances are that you may have fallen into a common trap. Try opening each of the following links: http://a.tile.openstreetmap.org/0/0/0.png http://b.tile.openstreetmap.org/0/0/0.png http://c.tile.openstreetmap.org/0/0/0.png If you get an error or a blank image on one of those then chances are that at some point you have asked your browser to 'block images from this server'. It is quite easy to select this option by mistake. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
had the same troubles in firefox at some point. some tiles loaded some didn't. other browser worked so it was clearly not server problem Check the Content - Load images automatically settings, this solved my troubles On Thu, Jun 18, 2009 at 11:17 AM, Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com wrote: 2009/5/13 Jon Burgess jburgess...@googlemail.com On Wed, 2009-05-13 at 22:12 +0100, Thomas Wood wrote: 2009/5/13 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com: Hi Folks, This is some sort of quality of service question. Half of all the tiles on http://www.openstreetmap.org render as 'more OSM coming soon'. I want to know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable hardware) The tiles display this in the case of network troubles where the server isn't reachable, they're also displayed if the tile hasn't yet been rendered (and is present on the server's disk) and when it's not possible to render on the fly. Otherwise, the tile is added to the render queue and should be available at some point shortly in the future. Showing OSM to a friend that has not seen 'the Map' does not give a good impression this way. A solution is to implement some sort of double buffering where the old tiles are kept for display until the new one has properly rendered? Well, that's maybe impossible, but it would improve the responsiveness of the http://www.openstreetmap.org at the moment. I believe this is already the case. There is a cache of tiles which is used when the rendering can not keep up. The weekly planet import is running at the moment and I have temporarily turned of the re-rendering of tiles so you will only seeing tiles from the cache right now. I'm in the middle of making some updates to the server to migrate the cached tiles and rendering database to an external disk array which will speed things up quite a bit. All the old tiles should still be available, but the live rendering probably won't restart until some time tomorrow. Strange thing, after a month things seem not to have improved much on the frontpage for openstreetmap, with respect to the number of tiles being rendered at a fairly reasonable place and zoom-level like: http://www.openstreetmap.org/?lat=51.91lon=-0.23zoom=7layers=B000FTF In my browser it currently shows 4 out of 12 renderd tiles ... more OSM coming soon. As mentioned before, I would like to raise some concern to have at least rendered tiles available at all times. Especially now, it seems things are broken to a noticable extent. Is there something to do about this? Maybe not flush previous rendered tiles until they are actually rerenderd on an another disklocation and when the new tile is ready, copy it over the old tile to keep the update fairly unnoticable. Then again, I am just guessing how the rendering takes place, so this approach might be totally unpractical. Looking trough the openlayer code reference by the map page, the tiles seem to come from var noname = new OpenLayers.Layer.OSM(NoName, [ http://a.tile.cloudmade.com/; + nonamekey + /3/256/, http://b.tile.cloudmade.com/; + nonamekey + /3/256/, http://c.tile.cloudmade.com/; + nonamekey + /3/256/ Maybe there is a known bottleneck in infrastructure that makes the tiles fail to be rendered? Bye, Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
2009/6/18 Apollinaris Schoell ascho...@gmail.com had the same troubles in firefox at some point. some tiles loaded some didn't. other browser worked so it was clearly not server problem Check the Content - Load images automatically settings, this solved my troubles Very hard to spot, but for some reason the c.tile.openstreetmap.org had made it in exactly the browsers config area you mention, to not load automatically. I removed it and everything properly loads. 12/12. What the reason is that I would get the 404.png is not fully clear to me. Anyways, case closed. Thanks! Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
ff has some shortcuts or gestures. clicking lot and fast and you won't recognize the change in settings ... On 18 Jun 2009, at 14:56 , Ivo van den Maagdenberg wrote: 2009/6/18 Apollinaris Schoell ascho...@gmail.com had the same troubles in firefox at some point. some tiles loaded some didn't. other browser worked so it was clearly not server problem Check the Content - Load images automatically settings, this solved my troubles Very hard to spot, but for some reason the c.tile.openstreetmap.org had made it in exactly the browsers config area you mention, to not load automatically. I removed it and everything properly loads. 12/12. What the reason is that I would get the 404.png is not fully clear to me. Anyways, case closed. Thanks! Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] more OSM coming soon
Hi Folks, This is some sort of quality of service question. Half of all the tiles on http://www.openstreetmap.org render as 'more OSM coming soon'. I want to know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable hardware) Showing OSM to a friend that has not seen 'the Map' does not give a good impression this way. A solution is to implement some sort of double buffering where the old tiles are kept for display until the new one has properly rendered? Well, that's maybe impossible, but it would improve the responsiveness of the http://www.openstreetmap.org at the moment. I am not 100% sure if this list is the most appropriate place to post and apolgise for hogging the wrong list with my concerns. Kind regards, Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Wed, 2009-05-13 at 22:12 +0100, Thomas Wood wrote: 2009/5/13 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com: Hi Folks, This is some sort of quality of service question. Half of all the tiles on http://www.openstreetmap.org render as 'more OSM coming soon'. I want to know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable hardware) The tiles display this in the case of network troubles where the server isn't reachable, they're also displayed if the tile hasn't yet been rendered (and is present on the server's disk) and when it's not possible to render on the fly. Otherwise, the tile is added to the render queue and should be available at some point shortly in the future. Showing OSM to a friend that has not seen 'the Map' does not give a good impression this way. A solution is to implement some sort of double buffering where the old tiles are kept for display until the new one has properly rendered? Well, that's maybe impossible, but it would improve the responsiveness of the http://www.openstreetmap.org at the moment. I believe this is already the case. There is a cache of tiles which is used when the rendering can not keep up. The weekly planet import is running at the moment and I have temporarily turned of the re-rendering of tiles so you will only seeing tiles from the cache right now. I'm in the middle of making some updates to the server to migrate the cached tiles and rendering database to an external disk array which will speed things up quite a bit. All the old tiles should still be available, but the live rendering probably won't restart until some time tomorrow. If you really must see an image which has not been rendered, the export tab should still produce an image for you. Jon I am not 100% sure if this list is the most appropriate place to post and apolgise for hogging the wrong list with my concerns. Kind regards, Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
2009/5/13 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com: Hi Folks, This is some sort of quality of service question. Half of all the tiles on http://www.openstreetmap.org render as 'more OSM coming soon'. I want to know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable hardware) The tiles display this in the case of network troubles where the server isn't reachable, they're also displayed if the tile hasn't yet been rendered (and is present on the server's disk) and when it's not possible to render on the fly. Otherwise, the tile is added to the render queue and should be available at some point shortly in the future. Showing OSM to a friend that has not seen 'the Map' does not give a good impression this way. A solution is to implement some sort of double buffering where the old tiles are kept for display until the new one has properly rendered? Well, that's maybe impossible, but it would improve the responsiveness of the http://www.openstreetmap.org at the moment. I believe this is already the case. I am not 100% sure if this list is the most appropriate place to post and apolgise for hogging the wrong list with my concerns. Kind regards, Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] more OSM coming soon
I've been getting a lot of tiles with the 'more OSM coming soon' message on Mapnik, both yesterday and today at various zoom levels. The tiles appear quickly rather than after a long delay as occasionally happens. Is anyone else seeing this? Does it need attention? cheers, Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
This is the weekly re-import of the data, when the render daemon is stopped for the duration. Shaun On 26 Mar 2009, at 11:45, Chris Hill wrote: I've been getting a lot of tiles with the 'more OSM coming soon' message on Mapnik, both yesterday and today at various zoom levels. The tiles appear quickly rather than after a long delay as occasionally happens. Is anyone else seeing this? Does it need attention? cheers, Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
Thanks, though I can't say I've noticed it before. cheers, Chris - Original Message From: Shaun McDonald sh...@shaunmcdonald.me.uk To: Chris Hill chillly...@yahoo.co.uk Cc: Talk OSM talk@openstreetmap.org Sent: Thursday, 26 March, 2009 12:00:04 Subject: Re: [OSM-talk] more OSM coming soon This is the weekly re-import of the data, when the render daemon is stopped for the duration. Shaun On 26 Mar 2009, at 11:45, Chris Hill wrote: I've been getting a lot of tiles with the 'more OSM coming soon' message on Mapnik, both yesterday and today at various zoom levels. The tiles appear quickly rather than after a long delay as occasionally happens. Is anyone else seeing this? Does it need attention? cheers, Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Thu, Mar 26, 2009 at 12:00 PM, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: This is the weekly re-import of the data, when the render daemon is stopped for the duration. I'm not entirely sure that it is, especially since I'd have expected it to restart yesterday morning (or maybe this morning - again, not sure when Jon does things). But looking at the munin graphs [1] I can see that the eth0 load is high, the CPU has been flat out earlier today, and the load average is spiking pretty high too. Mod_tile has a load average cutout where it stops trying to render tiles in the few seconds it normally gives renderd to respond (hence the usual few seconds before the coming soon logo appears. When that threshold is exceeded, mod_tile responds immediately with a 404 (and the osm.org Javascript shows the coming soon logo straight away). I don't know what the threshold is on tile.openstreetmap.org So a fair amount of speculations - the server is busy, but not that much more busy than it normally gets during the week, and I think it's triggering the mod_tile overload protection. Cheers, Andy [1] http://munin.openstreetmap.org/openstreetmap/tile.openstreetmap.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Thu, 2009-03-26 at 14:43 +, Andy Allan wrote: On Thu, Mar 26, 2009 at 12:00 PM, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: This is the weekly re-import of the data, when the render daemon is stopped for the duration. I'm not entirely sure that it is, especially since I'd have expected it to restart yesterday morning (or maybe this morning - again, not sure when Jon does things). But looking at the munin graphs [1] I can see that the eth0 load is high, the CPU has been flat out earlier today, and the load average is spiking pretty high too. There was a spike in the number of Apache threads and render daemon crashed when it used up all 1024 available file descriptors. I have known about this for a while, the render daemon has hit this a couple of times over the past year. I have restarted the process with the ulimit on the descriptors raised to 4096. Longer term I think I either need rethink how we handle 1k Apache connections or make the process increase the descriptors itself. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
