[Tilesathome] Cutover to new server? When?

[Florian Lohoff]

On Fri, Jul 11, 2008 at 12:46:02PM +0200, Martijn van Oosterhout wrote:
> On Fri, Jul 11, 2008 at 12:29 PM, Florian Lohoff <flo at rfc822.org> wrote:
> > On Fri, Jul 11, 2008 at 06:53:13AM +0200, spaetz wrote:
> >> Lower priority items:
> >> - Reimplement tileset complexity measure.
> >
> > As an idea concerning the complexity measure - Could the number of
> > objects be simply used? E.g. the client downloads the data via the api
> > and simply counts points and ways e.g:
> 
> Err, what's wrong with the existing complexity measure which does
> exactly that. Well, it scales it to a number 0..15 but that's about
> it.

Have you had a look at the complexity distribution?

Complexity 5
http://tah.openstreetmap.org/Tiles/info.php?x=2134&y=1348&z=12

Complexity 6
http://tah.openstreetmap.org/Tiles/info.php?x=2141&y=1357&z=12

Complexity 7
http://tah.openstreetmap.org/Tiles/info.php?x=2143&y=1357&z=12

Complexity 8
http://tah.openstreetmap.org/Tiles/info.php?x=2143&y=1354&z=12

Complexity 9
http://tah.openstreetmap.org/Tiles/info.php?x=2145&y=1352&z=12

Complexity 10
http://tah.openstreetmap.org/Tiles/info.php?x=2099&y=1354&z=12

So i have a hard time finding something above 10 and below 5.

Breaking down an infinite number of objects into in finite scale
will always have its problems.

Just the examples above make a difference between 100MByte needed and
probably something like 4-10GByte needed.

A more finegrained and more deterministic resource requirement would be
appreciated.

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20080711/9b113e95/attachment.pgp>