[Tilesathome] "No data here" (New client version "Newcastle")

[Brent Easton]

Hi Dirk,

Understand all you are saying, but by committing your changes to SVN, your changes have become live already.

Many people just update from svn every day or so and use whatever is committed.

People are updating there clients with your changes now, and since the default is to request lowzoom requests, then
they will be starting to request lowzoom tiles, failing, re-requesting etc.  which is only going to makes things much worse.

Regards,
Brent.


*********** REPLY SEPARATOR  ***********

On 19/11/2007 at 10:25 PM Dirk-Lüder Kreie  wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Brent Easton schrieb:
>>> The server now does not hand out z8 jobs unless explicitly requested,
>>> for now.
>> 
>> How does this work?
>
>In theory the client advertises the Layers it can render (set through
>LayersCapability in layers.conf) and the server assigns it a layer or
>layerset to render the job in.
>So if the tile from the jobqueue is z8 the server tells the client to
>render it as "lowzoom" layer and if it's z12 then the server tells the
>client to select "default" and "maplint" layers.
>Currently the serverside is a workaround hack and expects the
>capabilities of a client to be exactly "default,maplint,lowzoom" or else
>it will fall back to the old method of the client layers that are
>configured. (Parameter "Layers" in layers.conf)
>
>So if you still only want to render highzoom, set LayersCapability and
>Layers to "default,maplint" and if you only want to render lowzoom set
>both to "lowzoom".
>
>If you want the serverside queue to determine what you render the
>"Layers" setting is of no consequence, and the LayersCapability must be
>set to "default,maplint,lowzoom" (like currently in svn)
>
>>> Didn't think the XAPI problems were this severe. The reports seemed to
>>> indicate it only happened once in a while.
>> 
>> Completely braindead all day yesterday and appears no better today. 
>> 
>> According to 80n, coincides with move of omxapi hosting to DEV server
>and consequent onset of performance issues. Bad timing I guess :)
>
>I hope this gets better, because if this change gets live we need a
>beefier OSMXAPI than before, because the t at h network will catch up on
>lowzoom backlog.
>
>
>- --
>
>Dirk-Lüder "Deelkar" Kreie
>Bremen - 53.0952°N 8.8652°E
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.7 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFHQf9DFUbODdpRVDwRArxCAKCPh13p0bXgQeyFQj5hLwZ1ohsy+QCfbkwO
>2TpHsJUd882qi6BYBkEge10=
>=C6IH
>-----END PGP SIGNATURE-----
>
>
>-- 
>No virus found in this incoming message.
>Checked by AVG Free Edition. 
>Version: 7.5.503 / Virus Database: 269.16.0/1139 - Release Date: 19/11/2007 12:35 PM


____________________________________________________________
Brent Easton                       
Analyst/Programmer                               
University of Western Sydney                                   
Email: b.easton at uws.edu.au