[OSM-talk] how long does it take from edit to slippy map?

Dirk-Lüder Kreie osm-list at deelkar.net
Fri Feb 23 23:57:43 GMT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frederik Ramm schrieb:

> tiles at home is quite efficient, but it is handicapped (at the moment) by 
> a database overload ("too many mysql connections", broken images in the 
> slippy map, sometimes willing renderers can't even be assigned a job 
> from the queue because the database is unavailalbe). Also, once 
> tiles at home has distributed your rendering request(s) to clients, it has 
> no control about what they do. If one of the clients gobbles up the 
> request but the upload is broken (or the machine went offline by the 
> time there is data to upload), then your request may sit in the "being 
> rendered" queue for quite some time, and you can't even re-request it.

This is not really true, you can re-request a tile the moment a renderer
has picked it up (yes that'd be silly, but it's possible).

> If you want a particular tile re-rendered, it doesn't hurt to trigger 
> rendering through the tile browser or informationfreeway.org, or even 
> (if you're a Unix user) do what I do when I have made a lot of changes 
> to the Karlsruhe map:
> 
> for x in 2142 2143 2144
> do
>      for y in 1405 1406 1407
>      do
> 	wget -qO /dev/null "http://dev.openstreetmap.org/~ojw/NeedRender/?x=$x&
> y=$y&priority=1&src=fred_rendering_karlsruhe"
>      done
> done

I'd use "wget -qO -" instead of "wget -qO /dev/null" so I can see wether
the requests worked.

> (modify according to your needs, and of course do that only if you have 
> actually changed something, not from a cron job!)

That's very important, automatic requesting should be done *very*
carefully. It's easy to accidentally break things for others, even if
your request alone won't it might when combined with all the other requests.

Dirk-Lüder "Deelkar" Kreie

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF3392FUbODdpRVDwRAnQBAKCbVSC7VZHQsyf9DENu4zDNgVC2VgCgzaen
YjZjPi4ukSsWx/1K6Vh0fQg=
=4PLS
-----END PGP SIGNATURE-----




More information about the talk mailing list