From SCHUTP at AGR.GC.CA  Thu Sep  7 12:26:08 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Thu, 7 Sep 2006 15:26:08 -0400
Subject: [tiling] FOSS4G BOF/sprint?
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE2F39@onncrxms3.agr.gc.ca>

I think any such scheme should have "mandatory" and optional
scales/tilings.  

Without a lot of thought let me propose a starting point, so we can
argue about it.  I favour having a tiling derived from an initial layer
of tiles that each cover one "square" degree of latitude and longitude.
Here is the tile situated immediately NE of the equator and the prime
meridian:

<lowerCorner>0 0</lowerCorner><upperCorner>1 1</upperCorner>

Mandatory additional tile layers would be created by applying a scale
factor of 2, and at the same time quartering each tile from the level
above, eg:

<lowerCorner>0 0</lowerCorner><upperCorner>0.5 0.5</upperCorner>
and
<lowerCorner>0 0</lowerCorner><upperCorner>0.25 0.25</upperCorner>
and 
<lowerCorner>0 0</lowerCorner><upperCorner>0.125 0.125</upperCorner>
...

Tiling at smaller scales would extend this pattern in the other
direction:

<lowerCorner>0 0</lowerCorner><upperCorner>2 2</upperCorner>
<lowerCorner>0 0</lowerCorner><upperCorner>4 4</upperCorner>
<lowerCorner>0 0</lowerCorner><upperCorner>8 8</upperCorner>
<lowerCorner>0 0</lowerCorner><upperCorner>16 16</upperCorner>
<lowerCorner>0 0</lowerCorner><upperCorner>32 32</upperCorner>
<lowerCorner>0 0</lowerCorner><upperCorner>64 64</upperCorner>

Optional tile layers would be created as intermediate layers that don't
nest completely, by splitting the difference between two adjacent
mandatory tilings. E.g.:

<lowerCorner>0 0</lowerCorner><upperCorner>0.75 0.75</upperCorner>

Scale is somewhat meaningless, because the images should be produced in
a geographic (lat/long) projection.  Tiles should be produced at a
resolution of 96dpi, with 256 x 256 pixels.

Cheers, Peter.


-----Original Message-----
From: tiling-bounces at lists.eogeo.org
[mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Raj Singh
Sent: Thursday, August 17, 2006 12:18 PM
To: Steven M. Ottens; Chris Holmes
Cc: tiling at lists.eogeo.org
Subject: Re: [tiling] FOSS4G BOF/sprint?

Can we get a head start on this prior to FOSS4G? In previous
conversations
we've identified the need for a global tiling scheme and map scales as
primary requirements. Would anyone like to propose such a scheme and/or
scales?

--Raj



From pspencer at dmsolutions.ca  Thu Sep  7 14:02:49 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Thu, 7 Sep 2006 17:02:49 -0400
Subject: [tiling] FOSS4G BOF/sprint?
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE2F39@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE2F39@onncrxms3.agr.gc.ca>
Message-ID: <B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>

I had a couple of thoughts on this subject.

First, we could adopt the Google approach, which is to start at a  
tile that fits the entire world.  Google uses a mercator projection  
(that can be replicated in proj.4) and slightly reduced latitudes  
(87.something) to fit the world onto a single 256x256 tile and zoom  
levels at a factor of 2 from that.  This turns out to be very  
intuitive and convenient for servers and clients ...  In an epsg:4326  
projection, this would mean either two tiles at that scale or one  
tile with blank areas in the top/bottom half.

Second, we could choose an arbitrary scale (say 1) and center point  
(say 0,0) and just go in multiples of two up/down from that.

I definitely think we need to set a DPI (96).  Tile size is actually  
less important, at least from a client perspective, as long as the  
servers support the same scales.  A tiling server just needs to  
advertise what tile size(s) it supports and enough other metadata to  
allow clients to request and render tiles.

Paul

On 7-Sep-06, at 3:26 PM, Schut, Peter wrote:

> I think any such scheme should have "mandatory" and optional
> scales/tilings.
>
> Without a lot of thought let me propose a starting point, so we can
> argue about it.  I favour having a tiling derived from an initial  
> layer
> of tiles that each cover one "square" degree of latitude and  
> longitude.
> Here is the tile situated immediately NE of the equator and the prime
> meridian:
>
> <lowerCorner>0 0</lowerCorner><upperCorner>1 1</upperCorner>
>
> Mandatory additional tile layers would be created by applying a scale
> factor of 2, and at the same time quartering each tile from the level
> above, eg:
>
> <lowerCorner>0 0</lowerCorner><upperCorner>0.5 0.5</upperCorner>
> and
> <lowerCorner>0 0</lowerCorner><upperCorner>0.25 0.25</upperCorner>
> and
> <lowerCorner>0 0</lowerCorner><upperCorner>0.125 0.125</upperCorner>
> ...
>
> Tiling at smaller scales would extend this pattern in the other
> direction:
>
> <lowerCorner>0 0</lowerCorner><upperCorner>2 2</upperCorner>
> <lowerCorner>0 0</lowerCorner><upperCorner>4 4</upperCorner>
> <lowerCorner>0 0</lowerCorner><upperCorner>8 8</upperCorner>
> <lowerCorner>0 0</lowerCorner><upperCorner>16 16</upperCorner>
> <lowerCorner>0 0</lowerCorner><upperCorner>32 32</upperCorner>
> <lowerCorner>0 0</lowerCorner><upperCorner>64 64</upperCorner>
>
> Optional tile layers would be created as intermediate layers that  
> don't
> nest completely, by splitting the difference between two adjacent
> mandatory tilings. E.g.:
>
> <lowerCorner>0 0</lowerCorner><upperCorner>0.75 0.75</upperCorner>
>
> Scale is somewhat meaningless, because the images should be  
> produced in
> a geographic (lat/long) projection.  Tiles should be produced at a
> resolution of 96dpi, with 256 x 256 pixels.
>
> Cheers, Peter.
>
>
> -----Original Message-----
> From: tiling-bounces at lists.eogeo.org
> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Raj Singh
> Sent: Thursday, August 17, 2006 12:18 PM
> To: Steven M. Ottens; Chris Holmes
> Cc: tiling at lists.eogeo.org
> Subject: Re: [tiling] FOSS4G BOF/sprint?
>
> Can we get a head start on this prior to FOSS4G? In previous
> conversations
> we've identified the need for a global tiling scheme and map scales as
> primary requirements. Would anyone like to propose such a scheme  
> and/or
> scales?
>
> --Raj
>
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling

+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+





From adoyle at eogeo.org  Thu Sep  7 15:11:21 2006
From: adoyle at eogeo.org (Allan Doyle)
Date: Thu, 7 Sep 2006 18:11:21 -0400
Subject: [tiling] FOSS4G BOF/sprint?
In-Reply-To: <B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE2F39@onncrxms3.agr.gc.ca>
	<B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>
Message-ID: <739E65C5-4AD1-4F9E-A4C0-099C77549409@eogeo.org>

Is there a time slot for this already? I'm arriving on Sunday so  
Monday and Tuesday are great for me. I'm not going to be there on  
Friday.

	Allan

On Sep 7, 2006, at 17:02, Paul Spencer wrote:

> I had a couple of thoughts on this subject.
>
> First, we could adopt the Google approach, which is to start at a
> tile that fits the entire world.  Google uses a mercator projection
> (that can be replicated in proj.4) and slightly reduced latitudes
> (87.something) to fit the world onto a single 256x256 tile and zoom
> levels at a factor of 2 from that.  This turns out to be very
> intuitive and convenient for servers and clients ...  In an epsg:4326
> projection, this would mean either two tiles at that scale or one
> tile with blank areas in the top/bottom half.
>
> Second, we could choose an arbitrary scale (say 1) and center point
> (say 0,0) and just go in multiples of two up/down from that.
>
> I definitely think we need to set a DPI (96).  Tile size is actually
> less important, at least from a client perspective, as long as the
> servers support the same scales.  A tiling server just needs to
> advertise what tile size(s) it supports and enough other metadata to
> allow clients to request and render tiles.
>
> Paul
>
> On 7-Sep-06, at 3:26 PM, Schut, Peter wrote:
>
>> I think any such scheme should have "mandatory" and optional
>> scales/tilings.
>>
>> Without a lot of thought let me propose a starting point, so we can
>> argue about it.  I favour having a tiling derived from an initial
>> layer
>> of tiles that each cover one "square" degree of latitude and
>> longitude.
>> Here is the tile situated immediately NE of the equator and the prime
>> meridian:
>>
>> <lowerCorner>0 0</lowerCorner><upperCorner>1 1</upperCorner>
>>
>> Mandatory additional tile layers would be created by applying a scale
>> factor of 2, and at the same time quartering each tile from the level
>> above, eg:
>>
>> <lowerCorner>0 0</lowerCorner><upperCorner>0.5 0.5</upperCorner>
>> and
>> <lowerCorner>0 0</lowerCorner><upperCorner>0.25 0.25</upperCorner>
>> and
>> <lowerCorner>0 0</lowerCorner><upperCorner>0.125 0.125</upperCorner>
>> ...
>>
>> Tiling at smaller scales would extend this pattern in the other
>> direction:
>>
>> <lowerCorner>0 0</lowerCorner><upperCorner>2 2</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>4 4</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>8 8</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>16 16</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>32 32</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>64 64</upperCorner>
>>
>> Optional tile layers would be created as intermediate layers that
>> don't
>> nest completely, by splitting the difference between two adjacent
>> mandatory tilings. E.g.:
>>
>> <lowerCorner>0 0</lowerCorner><upperCorner>0.75 0.75</upperCorner>
>>
>> Scale is somewhat meaningless, because the images should be
>> produced in
>> a geographic (lat/long) projection.  Tiles should be produced at a
>> resolution of 96dpi, with 256 x 256 pixels.
>>
>> Cheers, Peter.
>>
>>
>> -----Original Message-----
>> From: tiling-bounces at lists.eogeo.org
>> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Raj Singh
>> Sent: Thursday, August 17, 2006 12:18 PM
>> To: Steven M. Ottens; Chris Holmes
>> Cc: tiling at lists.eogeo.org
>> Subject: Re: [tiling] FOSS4G BOF/sprint?
>>
>> Can we get a head start on this prior to FOSS4G? In previous
>> conversations
>> we've identified the need for a global tiling scheme and map  
>> scales as
>> primary requirements. Would anyone like to propose such a scheme
>> and/or
>> scales?
>>
>> --Raj
>>
>>
>> _______________________________________________
>> tiling mailing list
>> tiling at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/tiling
>
> +-----------------------------------------------------------------+
> |Paul Spencer                           pspencer at dmsolutions.ca   |
> +-----------------------------------------------------------------+
> |Applications & Software Development                              |
> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
> +-----------------------------------------------------------------+
>
>
>
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling

-- 
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org




From cholmes at openplans.org  Thu Sep  7 15:21:55 2006
From: cholmes at openplans.org (Chris Holmes)
Date: Thu, 07 Sep 2006 18:21:55 -0400
Subject: [tiling] FOSS4G BOF/sprint?
In-Reply-To: <B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE2F39@onncrxms3.agr.gc.ca>
	<B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>
Message-ID: <45009B83.7090503@openplans.org>

I think the google approach makes good sense, start with one 256x256 
tile of the whole earth and go with factors of 2 from there.

Could you explain DPI Paul, and what the relevance is here?

I think tile size is still important, since it allows better caching on 
the server side.  I suppose if you had a true 'tiling server' it 
wouldn't matter as much, since the tile server would have the full image 
stored at the zoom levels and it could divide it up as it likes.  But my 
big interest this is primarily being able to have a way to strap tiling 
and caching on to existing WMS services.

I agree that a 'tiling server' could be a valuable thing, and would 
allow better display of labels and more control.  I think perhaps we 
might have 2 tiling 'profiles'?  One a best practices of how to make 
dynamic WMS requests such that the server can cache and different 
clients will get the benefits of the cache, and one a tiling server that 
would only respond to the set tiles.  The advantage of the former is 
that it doesn't take a spec revision and someone else other than the 
main provider could do the cache (I know the openlayers guys have done 
some of this, have ka-map cascade jpl and bluemarble with caching goodness).

If we have a single 'best practices' of 256x256 tiles and clients use 
that as default then I don't think we would even need something added to 
WMS capabilities - ie there'd be no 'preferred tile size', since all 
would know it's 256x256.  But I do think in the future it'd be nice 
those that did tile at least let others know, and could also advertise 
other tile sizes supported.

(thanks Peter for kicking off the conversation, I'd been meaning to and 
kept letting it slip)

best regards,

Chris

Paul Spencer wrote:
> I had a couple of thoughts on this subject.
> 
> First, we could adopt the Google approach, which is to start at a  
> tile that fits the entire world.  Google uses a mercator projection  
> (that can be replicated in proj.4) and slightly reduced latitudes  
> (87.something) to fit the world onto a single 256x256 tile and zoom  
> levels at a factor of 2 from that.  This turns out to be very  
> intuitive and convenient for servers and clients ...  In an epsg:4326  
> projection, this would mean either two tiles at that scale or one  
> tile with blank areas in the top/bottom half.
> 
> Second, we could choose an arbitrary scale (say 1) and center point  
> (say 0,0) and just go in multiples of two up/down from that.
> 
> I definitely think we need to set a DPI (96).  Tile size is actually  
> less important, at least from a client perspective, as long as the  
> servers support the same scales.  A tiling server just needs to  
> advertise what tile size(s) it supports and enough other metadata to  
> allow clients to request and render tiles.
> 
> Paul
> 
> On 7-Sep-06, at 3:26 PM, Schut, Peter wrote:
> 
>> I think any such scheme should have "mandatory" and optional
>> scales/tilings.
>>
>> Without a lot of thought let me propose a starting point, so we can
>> argue about it.  I favour having a tiling derived from an initial  
>> layer
>> of tiles that each cover one "square" degree of latitude and  
>> longitude.
>> Here is the tile situated immediately NE of the equator and the prime
>> meridian:
>>
>> <lowerCorner>0 0</lowerCorner><upperCorner>1 1</upperCorner>
>>
>> Mandatory additional tile layers would be created by applying a scale
>> factor of 2, and at the same time quartering each tile from the level
>> above, eg:
>>
>> <lowerCorner>0 0</lowerCorner><upperCorner>0.5 0.5</upperCorner>
>> and
>> <lowerCorner>0 0</lowerCorner><upperCorner>0.25 0.25</upperCorner>
>> and
>> <lowerCorner>0 0</lowerCorner><upperCorner>0.125 0.125</upperCorner>
>> ...
>>
>> Tiling at smaller scales would extend this pattern in the other
>> direction:
>>
>> <lowerCorner>0 0</lowerCorner><upperCorner>2 2</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>4 4</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>8 8</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>16 16</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>32 32</upperCorner>
>> <lowerCorner>0 0</lowerCorner><upperCorner>64 64</upperCorner>
>>
>> Optional tile layers would be created as intermediate layers that  
>> don't
>> nest completely, by splitting the difference between two adjacent
>> mandatory tilings. E.g.:
>>
>> <lowerCorner>0 0</lowerCorner><upperCorner>0.75 0.75</upperCorner>
>>
>> Scale is somewhat meaningless, because the images should be  
>> produced in
>> a geographic (lat/long) projection.  Tiles should be produced at a
>> resolution of 96dpi, with 256 x 256 pixels.
>>
>> Cheers, Peter.
>>
>>
>> -----Original Message-----
>> From: tiling-bounces at lists.eogeo.org
>> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Raj Singh
>> Sent: Thursday, August 17, 2006 12:18 PM
>> To: Steven M. Ottens; Chris Holmes
>> Cc: tiling at lists.eogeo.org
>> Subject: Re: [tiling] FOSS4G BOF/sprint?
>>
>> Can we get a head start on this prior to FOSS4G? In previous
>> conversations
>> we've identified the need for a global tiling scheme and map scales as
>> primary requirements. Would anyone like to propose such a scheme  
>> and/or
>> scales?
>>
>> --Raj
>>
>>
>> _______________________________________________
>> tiling mailing list
>> tiling at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/tiling
> 
> +-----------------------------------------------------------------+
> |Paul Spencer                           pspencer at dmsolutions.ca   |
> +-----------------------------------------------------------------+
> |Applications & Software Development                              |
> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
> +-----------------------------------------------------------------+
> 
> 
> 
> 
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
> 
> !DSPAM:1003,45008eb3239531365099012!
> 

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20060907/9008c156/attachment.vcf 

From pspencer at dmsolutions.ca  Thu Sep  7 17:05:43 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Thu, 7 Sep 2006 20:05:43 -0400
Subject: [tiling] FOSS4G BOF/sprint?
In-Reply-To: <45009B83.7090503@openplans.org>
References: <783BB96C25B79249A236DF62F559D6A501EE2F39@onncrxms3.agr.gc.ca>
	<B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>
	<45009B83.7090503@openplans.org>
Message-ID: <B23C41BE-83FC-4277-A14C-F086420300E8@dmsolutions.ca>

DPI is only important when it comes to calculating scale, I think,  
although I could be wrong on that :)

I'm looking forward to having this moved forward!

Cheers

Paul

On 7-Sep-06, at 6:21 PM, Chris Holmes wrote:

> I think the google approach makes good sense, start with one  
> 256x256 tile of the whole earth and go with factors of 2 from there.
>
> Could you explain DPI Paul, and what the relevance is here?
>
> I think tile size is still important, since it allows better  
> caching on the server side.  I suppose if you had a true 'tiling  
> server' it wouldn't matter as much, since the tile server would  
> have the full image stored at the zoom levels and it could divide  
> it up as it likes.  But my big interest this is primarily being  
> able to have a way to strap tiling and caching on to existing WMS  
> services.
>
> I agree that a 'tiling server' could be a valuable thing, and would  
> allow better display of labels and more control.  I think perhaps  
> we might have 2 tiling 'profiles'?  One a best practices of how to  
> make dynamic WMS requests such that the server can cache and  
> different clients will get the benefits of the cache, and one a  
> tiling server that would only respond to the set tiles.  The  
> advantage of the former is that it doesn't take a spec revision and  
> someone else other than the main provider could do the cache (I  
> know the openlayers guys have done some of this, have ka-map  
> cascade jpl and bluemarble with caching goodness).
>
> If we have a single 'best practices' of 256x256 tiles and clients  
> use that as default then I don't think we would even need something  
> added to WMS capabilities - ie there'd be no 'preferred tile size',  
> since all would know it's 256x256.  But I do think in the future  
> it'd be nice those that did tile at least let others know, and  
> could also advertise other tile sizes supported.
>
> (thanks Peter for kicking off the conversation, I'd been meaning to  
> and kept letting it slip)
>
> best regards,
>
> Chris
>
> Paul Spencer wrote:
>> I had a couple of thoughts on this subject.
>> First, we could adopt the Google approach, which is to start at a   
>> tile that fits the entire world.  Google uses a mercator  
>> projection  (that can be replicated in proj.4) and slightly  
>> reduced latitudes  (87.something) to fit the world onto a single  
>> 256x256 tile and zoom  levels at a factor of 2 from that.  This  
>> turns out to be very  intuitive and convenient for servers and  
>> clients ...  In an epsg:4326  projection, this would mean either  
>> two tiles at that scale or one  tile with blank areas in the top/ 
>> bottom half.
>> Second, we could choose an arbitrary scale (say 1) and center  
>> point  (say 0,0) and just go in multiples of two up/down from that.
>> I definitely think we need to set a DPI (96).  Tile size is  
>> actually  less important, at least from a client perspective, as  
>> long as the  servers support the same scales.  A tiling server  
>> just needs to  advertise what tile size(s) it supports and enough  
>> other metadata to  allow clients to request and render tiles.
>> Paul
>> On 7-Sep-06, at 3:26 PM, Schut, Peter wrote:
>>> I think any such scheme should have "mandatory" and optional
>>> scales/tilings.
>>>
>>> Without a lot of thought let me propose a starting point, so we can
>>> argue about it.  I favour having a tiling derived from an  
>>> initial  layer
>>> of tiles that each cover one "square" degree of latitude and   
>>> longitude.
>>> Here is the tile situated immediately NE of the equator and the  
>>> prime
>>> meridian:
>>>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>1 1</upperCorner>
>>>
>>> Mandatory additional tile layers would be created by applying a  
>>> scale
>>> factor of 2, and at the same time quartering each tile from the  
>>> level
>>> above, eg:
>>>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.5 0.5</upperCorner>
>>> and
>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.25 0.25</upperCorner>
>>> and
>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.125 0.125</upperCorner>
>>> ...
>>>
>>> Tiling at smaller scales would extend this pattern in the other
>>> direction:
>>>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>2 2</upperCorner>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>4 4</upperCorner>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>8 8</upperCorner>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>16 16</upperCorner>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>32 32</upperCorner>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>64 64</upperCorner>
>>>
>>> Optional tile layers would be created as intermediate layers  
>>> that  don't
>>> nest completely, by splitting the difference between two adjacent
>>> mandatory tilings. E.g.:
>>>
>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.75 0.75</upperCorner>
>>>
>>> Scale is somewhat meaningless, because the images should be   
>>> produced in
>>> a geographic (lat/long) projection.  Tiles should be produced at a
>>> resolution of 96dpi, with 256 x 256 pixels.
>>>
>>> Cheers, Peter.
>>>
>>>
>>> -----Original Message-----
>>> From: tiling-bounces at lists.eogeo.org
>>> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Raj Singh
>>> Sent: Thursday, August 17, 2006 12:18 PM
>>> To: Steven M. Ottens; Chris Holmes
>>> Cc: tiling at lists.eogeo.org
>>> Subject: Re: [tiling] FOSS4G BOF/sprint?
>>>
>>> Can we get a head start on this prior to FOSS4G? In previous
>>> conversations
>>> we've identified the need for a global tiling scheme and map  
>>> scales as
>>> primary requirements. Would anyone like to propose such a scheme   
>>> and/or
>>> scales?
>>>
>>> --Raj
>>>
>>>
>>> _______________________________________________
>>> tiling mailing list
>>> tiling at lists.eogeo.org
>>> http://lists.eogeo.org/mailman/listinfo/tiling
>> +-----------------------------------------------------------------+
>> |Paul Spencer                           pspencer at dmsolutions.ca   |
>> +-----------------------------------------------------------------+
>> |Applications & Software Development                              |
>> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
>> +-----------------------------------------------------------------+
>> _______________________________________________
>> tiling mailing list
>> tiling at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/tiling
>> !DSPAM:1003,45008eb3239531365099012!
>
> -- 
> Chris Holmes
> The Open Planning Project
> http://topp.openplans.org
> <cholmes.vcf>

+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+





From steven.ottens at geodan.nl  Fri Sep  8 01:40:04 2006
From: steven.ottens at geodan.nl (Steven M. Ottens)
Date: Fri, 08 Sep 2006 10:40:04 +0200
Subject: [tiling] FOSS4G BOF/sprint?
In-Reply-To: <B23C41BE-83FC-4277-A14C-F086420300E8@dmsolutions.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE2F39@onncrxms3.agr.gc.ca>	<B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>	<45009B83.7090503@openplans.org>
	<B23C41BE-83FC-4277-A14C-F086420300E8@dmsolutions.ca>
Message-ID: <45012C64.5010102@geodan.nl>

DPI is only important if you want to calculate the scale in meters per
meter. For a client a scale of meters per pixel works as well. It's
useful for a calculation to the user, but not important for neither the
client nor the server I believe. Besides a pixel is not a fixed distance
unit, it can differ from screen to screen.

I'd like to throw in a new issue: Different projections. We're now
discussion a google like global tile scheme. But what about the
different national projections. The square grid ones require a different
approach I believe. Or put it this way I wrote a simple tile scheme for
the dutch 'RD' projection but it doesn't work for lat/long ones since it
assumes that each tile has the same size in meters. So I can imagine
that a tile scheme for lat/long doesn't work in projected maps.

Looking forward to the discussion next week :)

Steven


Paul Spencer wrote:
> DPI is only important when it comes to calculating scale, I think,  
> although I could be wrong on that :)
>
> I'm looking forward to having this moved forward!
>
> Cheers
>
> Paul
>
> On 7-Sep-06, at 6:21 PM, Chris Holmes wrote:
>
>   
>> I think the google approach makes good sense, start with one  
>> 256x256 tile of the whole earth and go with factors of 2 from there.
>>
>> Could you explain DPI Paul, and what the relevance is here?
>>
>> I think tile size is still important, since it allows better  
>> caching on the server side.  I suppose if you had a true 'tiling  
>> server' it wouldn't matter as much, since the tile server would  
>> have the full image stored at the zoom levels and it could divide  
>> it up as it likes.  But my big interest this is primarily being  
>> able to have a way to strap tiling and caching on to existing WMS  
>> services.
>>
>> I agree that a 'tiling server' could be a valuable thing, and would  
>> allow better display of labels and more control.  I think perhaps  
>> we might have 2 tiling 'profiles'?  One a best practices of how to  
>> make dynamic WMS requests such that the server can cache and  
>> different clients will get the benefits of the cache, and one a  
>> tiling server that would only respond to the set tiles.  The  
>> advantage of the former is that it doesn't take a spec revision and  
>> someone else other than the main provider could do the cache (I  
>> know the openlayers guys have done some of this, have ka-map  
>> cascade jpl and bluemarble with caching goodness).
>>
>> If we have a single 'best practices' of 256x256 tiles and clients  
>> use that as default then I don't think we would even need something  
>> added to WMS capabilities - ie there'd be no 'preferred tile size',  
>> since all would know it's 256x256.  But I do think in the future  
>> it'd be nice those that did tile at least let others know, and  
>> could also advertise other tile sizes supported.
>>
>> (thanks Peter for kicking off the conversation, I'd been meaning to  
>> and kept letting it slip)
>>
>> best regards,
>>
>> Chris
>>
>> Paul Spencer wrote:
>>     
>>> I had a couple of thoughts on this subject.
>>> First, we could adopt the Google approach, which is to start at a   
>>> tile that fits the entire world.  Google uses a mercator  
>>> projection  (that can be replicated in proj.4) and slightly  
>>> reduced latitudes  (87.something) to fit the world onto a single  
>>> 256x256 tile and zoom  levels at a factor of 2 from that.  This  
>>> turns out to be very  intuitive and convenient for servers and  
>>> clients ...  In an epsg:4326  projection, this would mean either  
>>> two tiles at that scale or one  tile with blank areas in the top/ 
>>> bottom half.
>>> Second, we could choose an arbitrary scale (say 1) and center  
>>> point  (say 0,0) and just go in multiples of two up/down from that.
>>> I definitely think we need to set a DPI (96).  Tile size is  
>>> actually  less important, at least from a client perspective, as  
>>> long as the  servers support the same scales.  A tiling server  
>>> just needs to  advertise what tile size(s) it supports and enough  
>>> other metadata to  allow clients to request and render tiles.
>>> Paul
>>> On 7-Sep-06, at 3:26 PM, Schut, Peter wrote:
>>>       
>>>> I think any such scheme should have "mandatory" and optional
>>>> scales/tilings.
>>>>
>>>> Without a lot of thought let me propose a starting point, so we can
>>>> argue about it.  I favour having a tiling derived from an  
>>>> initial  layer
>>>> of tiles that each cover one "square" degree of latitude and   
>>>> longitude.
>>>> Here is the tile situated immediately NE of the equator and the  
>>>> prime
>>>> meridian:
>>>>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>1 1</upperCorner>
>>>>
>>>> Mandatory additional tile layers would be created by applying a  
>>>> scale
>>>> factor of 2, and at the same time quartering each tile from the  
>>>> level
>>>> above, eg:
>>>>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.5 0.5</upperCorner>
>>>> and
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.25 0.25</upperCorner>
>>>> and
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.125 0.125</upperCorner>
>>>> ...
>>>>
>>>> Tiling at smaller scales would extend this pattern in the other
>>>> direction:
>>>>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>2 2</upperCorner>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>4 4</upperCorner>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>8 8</upperCorner>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>16 16</upperCorner>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>32 32</upperCorner>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>64 64</upperCorner>
>>>>
>>>> Optional tile layers would be created as intermediate layers  
>>>> that  don't
>>>> nest completely, by splitting the difference between two adjacent
>>>> mandatory tilings. E.g.:
>>>>
>>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.75 0.75</upperCorner>
>>>>
>>>> Scale is somewhat meaningless, because the images should be   
>>>> produced in
>>>> a geographic (lat/long) projection.  Tiles should be produced at a
>>>> resolution of 96dpi, with 256 x 256 pixels.
>>>>
>>>> Cheers, Peter.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: tiling-bounces at lists.eogeo.org
>>>> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Raj Singh
>>>> Sent: Thursday, August 17, 2006 12:18 PM
>>>> To: Steven M. Ottens; Chris Holmes
>>>> Cc: tiling at lists.eogeo.org
>>>> Subject: Re: [tiling] FOSS4G BOF/sprint?
>>>>
>>>> Can we get a head start on this prior to FOSS4G? In previous
>>>> conversations
>>>> we've identified the need for a global tiling scheme and map  
>>>> scales as
>>>> primary requirements. Would anyone like to propose such a scheme   
>>>> and/or
>>>> scales?
>>>>
>>>> --Raj
>>>>
>>>>
>>>> _______________________________________________
>>>> tiling mailing list
>>>> tiling at lists.eogeo.org
>>>> http://lists.eogeo.org/mailman/listinfo/tiling
>>>>         
>>> +-----------------------------------------------------------------+
>>> |Paul Spencer                           pspencer at dmsolutions.ca   |
>>> +-----------------------------------------------------------------+
>>> |Applications & Software Development                              |
>>> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
>>> +-----------------------------------------------------------------+
>>> _______________________________________________
>>> tiling mailing list
>>> tiling at lists.eogeo.org
>>> http://lists.eogeo.org/mailman/listinfo/tiling
>>> !DSPAM:1003,45008eb3239531365099012!
>>>       
>> -- 
>> Chris Holmes
>> The Open Planning Project
>> http://topp.openplans.org
>> <cholmes.vcf>
>>     
>
> +-----------------------------------------------------------------+
> |Paul Spencer                           pspencer at dmsolutions.ca   |
> +-----------------------------------------------------------------+
> |Applications & Software Development                              |
> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
> +-----------------------------------------------------------------+
>
>
>
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
>   


-- 
Geodan S&R Amsterdam

-------------------------------------
Geodan S&R
President Kennedylaan 1
1079 MB Amsterdam (NL)
-------------------------------------
Tel: +31 (0)20 - 5711 311
Fax: +31 (0)20 - 5711 333
-------------------------------------
E-mail: steven.ottens at geodan.nl
Website: www.geodan.nl
Disclaimer: www.geodan.nl/disclaimer
-------------------------------------



From nhv at cape.com  Fri Sep  8 05:30:54 2006
From: nhv at cape.com (Norman Vine)
Date: Fri, 8 Sep 2006 08:30:54 -0400
Subject: [tiling] FOSS4G BOF/sprint?
In-Reply-To: <B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>
Message-ID: <200609081230.k88CUxO6019702@smtp11.cape.com>

Raj Singh  writes:
> > Sent: Thursday, August 17, 2006 12:18 PM
> > Subject: Re: [tiling] FOSS4G BOF/sprint?
> >
> > Can we get a head start on this prior to FOSS4G? In previous 
> > conversations we've identified the need for a global tiling 
> scheme and 
> > map scales as primary requirements. Would anyone like to 
> propose such 
> > a scheme and/or scales?

Perhaps there is some applicable 'prior art' here
http://svs.gsfc.nasa.gov/documents/index.html

Norman


From cholmes at openplans.org  Fri Sep  8 10:42:57 2006
From: cholmes at openplans.org (Chris Holmes)
Date: Fri, 08 Sep 2006 13:42:57 -0400
Subject: [tiling] FOSS4G BOF/sprint?
In-Reply-To: <45012C64.5010102@geodan.nl>
References: <783BB96C25B79249A236DF62F559D6A501EE2F39@onncrxms3.agr.gc.ca>	<B7A3E78B-751E-41B2-B6C2-0B0A91F05126@dmsolutions.ca>	<45009B83.7090503@openplans.org>
	<B23C41BE-83FC-4277-A14C-F086420300E8@dmsolutions.ca>
	<45012C64.5010102@geodan.nl>
Message-ID: <4501ABA1.2060108@openplans.org>


> I'd like to throw in a new issue: Different projections. We're now
> discussion a google like global tile scheme. But what about the
> different national projections. The square grid ones require a different
> approach I believe. Or put it this way I wrote a simple tile scheme for
> the dutch 'RD' projection but it doesn't work for lat/long ones since it
> assumes that each tile has the same size in meters. So I can imagine
> that a tile scheme for lat/long doesn't work in projected maps.
Ah yes.  My inclination is to pick one, likely either lat/long or 
mercator, and have that be a global recommendation.  And then in the 
'second' profile, the specific tile server, it can also include other 
projections.

Chris

> 
> Looking forward to the discussion next week :)
> 
> Steven
> 
> 
> Paul Spencer wrote:
>> DPI is only important when it comes to calculating scale, I think,  
>> although I could be wrong on that :)
>>
>> I'm looking forward to having this moved forward!
>>
>> Cheers
>>
>> Paul
>>
>> On 7-Sep-06, at 6:21 PM, Chris Holmes wrote:
>>
>>   
>>> I think the google approach makes good sense, start with one  
>>> 256x256 tile of the whole earth and go with factors of 2 from there.
>>>
>>> Could you explain DPI Paul, and what the relevance is here?
>>>
>>> I think tile size is still important, since it allows better  
>>> caching on the server side.  I suppose if you had a true 'tiling  
>>> server' it wouldn't matter as much, since the tile server would  
>>> have the full image stored at the zoom levels and it could divide  
>>> it up as it likes.  But my big interest this is primarily being  
>>> able to have a way to strap tiling and caching on to existing WMS  
>>> services.
>>>
>>> I agree that a 'tiling server' could be a valuable thing, and would  
>>> allow better display of labels and more control.  I think perhaps  
>>> we might have 2 tiling 'profiles'?  One a best practices of how to  
>>> make dynamic WMS requests such that the server can cache and  
>>> different clients will get the benefits of the cache, and one a  
>>> tiling server that would only respond to the set tiles.  The  
>>> advantage of the former is that it doesn't take a spec revision and  
>>> someone else other than the main provider could do the cache (I  
>>> know the openlayers guys have done some of this, have ka-map  
>>> cascade jpl and bluemarble with caching goodness).
>>>
>>> If we have a single 'best practices' of 256x256 tiles and clients  
>>> use that as default then I don't think we would even need something  
>>> added to WMS capabilities - ie there'd be no 'preferred tile size',  
>>> since all would know it's 256x256.  But I do think in the future  
>>> it'd be nice those that did tile at least let others know, and  
>>> could also advertise other tile sizes supported.
>>>
>>> (thanks Peter for kicking off the conversation, I'd been meaning to  
>>> and kept letting it slip)
>>>
>>> best regards,
>>>
>>> Chris
>>>
>>> Paul Spencer wrote:
>>>     
>>>> I had a couple of thoughts on this subject.
>>>> First, we could adopt the Google approach, which is to start at a   
>>>> tile that fits the entire world.  Google uses a mercator  
>>>> projection  (that can be replicated in proj.4) and slightly  
>>>> reduced latitudes  (87.something) to fit the world onto a single  
>>>> 256x256 tile and zoom  levels at a factor of 2 from that.  This  
>>>> turns out to be very  intuitive and convenient for servers and  
>>>> clients ...  In an epsg:4326  projection, this would mean either  
>>>> two tiles at that scale or one  tile with blank areas in the top/ 
>>>> bottom half.
>>>> Second, we could choose an arbitrary scale (say 1) and center  
>>>> point  (say 0,0) and just go in multiples of two up/down from that.
>>>> I definitely think we need to set a DPI (96).  Tile size is  
>>>> actually  less important, at least from a client perspective, as  
>>>> long as the  servers support the same scales.  A tiling server  
>>>> just needs to  advertise what tile size(s) it supports and enough  
>>>> other metadata to  allow clients to request and render tiles.
>>>> Paul
>>>> On 7-Sep-06, at 3:26 PM, Schut, Peter wrote:
>>>>       
>>>>> I think any such scheme should have "mandatory" and optional
>>>>> scales/tilings.
>>>>>
>>>>> Without a lot of thought let me propose a starting point, so we can
>>>>> argue about it.  I favour having a tiling derived from an  
>>>>> initial  layer
>>>>> of tiles that each cover one "square" degree of latitude and   
>>>>> longitude.
>>>>> Here is the tile situated immediately NE of the equator and the  
>>>>> prime
>>>>> meridian:
>>>>>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>1 1</upperCorner>
>>>>>
>>>>> Mandatory additional tile layers would be created by applying a  
>>>>> scale
>>>>> factor of 2, and at the same time quartering each tile from the  
>>>>> level
>>>>> above, eg:
>>>>>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.5 0.5</upperCorner>
>>>>> and
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.25 0.25</upperCorner>
>>>>> and
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.125 0.125</upperCorner>
>>>>> ...
>>>>>
>>>>> Tiling at smaller scales would extend this pattern in the other
>>>>> direction:
>>>>>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>2 2</upperCorner>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>4 4</upperCorner>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>8 8</upperCorner>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>16 16</upperCorner>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>32 32</upperCorner>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>64 64</upperCorner>
>>>>>
>>>>> Optional tile layers would be created as intermediate layers  
>>>>> that  don't
>>>>> nest completely, by splitting the difference between two adjacent
>>>>> mandatory tilings. E.g.:
>>>>>
>>>>> <lowerCorner>0 0</lowerCorner><upperCorner>0.75 0.75</upperCorner>
>>>>>
>>>>> Scale is somewhat meaningless, because the images should be   
>>>>> produced in
>>>>> a geographic (lat/long) projection.  Tiles should be produced at a
>>>>> resolution of 96dpi, with 256 x 256 pixels.
>>>>>
>>>>> Cheers, Peter.
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: tiling-bounces at lists.eogeo.org
>>>>> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Raj Singh
>>>>> Sent: Thursday, August 17, 2006 12:18 PM
>>>>> To: Steven M. Ottens; Chris Holmes
>>>>> Cc: tiling at lists.eogeo.org
>>>>> Subject: Re: [tiling] FOSS4G BOF/sprint?
>>>>>
>>>>> Can we get a head start on this prior to FOSS4G? In previous
>>>>> conversations
>>>>> we've identified the need for a global tiling scheme and map  
>>>>> scales as
>>>>> primary requirements. Would anyone like to propose such a scheme   
>>>>> and/or
>>>>> scales?
>>>>>
>>>>> --Raj
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tiling mailing list
>>>>> tiling at lists.eogeo.org
>>>>> http://lists.eogeo.org/mailman/listinfo/tiling
>>>>>         
>>>> +-----------------------------------------------------------------+
>>>> |Paul Spencer                           pspencer at dmsolutions.ca   |
>>>> +-----------------------------------------------------------------+
>>>> |Applications & Software Development                              |
>>>> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
>>>> +-----------------------------------------------------------------+
>>>> _______________________________________________
>>>> tiling mailing list
>>>> tiling at lists.eogeo.org
>>>> http://lists.eogeo.org/mailman/listinfo/tiling
>>>>
>>>>       
>>> -- 
>>> Chris Holmes
>>> The Open Planning Project
>>> http://topp.openplans.org
>>> <cholmes.vcf>
>>>     
>> +-----------------------------------------------------------------+
>> |Paul Spencer                           pspencer at dmsolutions.ca   |
>> +-----------------------------------------------------------------+
>> |Applications & Software Development                              |
>> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
>> +-----------------------------------------------------------------+
>>
>>
>>
>>
>> _______________________________________________
>> tiling mailing list
>> tiling at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/tiling
>>   
> 
> 

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20060908/42417b3f/attachment.vcf 

From tisham at apogee.com.au  Sat Sep  9 05:32:12 2006
From: tisham at apogee.com.au (Tishampati Dhar)
Date: Sat, 9 Sep 2006 22:02:12 +0930
Subject: [tiling] Picking projection
Message-ID: <200609092202.12339.tisham@apogee.com.au>

Hi all,

Picking a Global projection and reprojecting national projections to this is 
what has happened in effect.
Worldwind has picked epsg:4326 - the latlong projection
While Google/Yahoo/Microsoft have picked mercator.
As the VE plugin and IGN(French imagery) plugin in Worldwind demonstrate as 
long a projection is global there is still some room to reproject on the fly 
on the client side to view the data in context. The IGN plugin in fact 
reprojects from a local projection.

Regards,
Tisham(aka what_nick)
http://whatnick.blogspot.com


From nhv at cape.com  Sun Sep 10 02:59:05 2006
From: nhv at cape.com (Norman Vine)
Date: Sun, 10 Sep 2006 05:59:05 -0400
Subject: [tiling] FOSS4G BOF/sprint?
In-Reply-To: <200609081230.k88CUxO6019702@smtp11.cape.com>
Message-ID: <200609100959.k8A9x5O6011721@smtp11.cape.com>

Norman Vine wrote:
> 
> Perhaps there is some applicable 'prior art' here
> http://svs.gsfc.nasa.gov/documents/index.html

Another interesting project
http://iipimage.sourceforge.net/index.shtml

IIPImage is an Open Source light-weight client-server system for the remote
viewing of very high-resolution images. It is designed to be bandwidth and
memory efficient and usable even over a slow internet connection. The system
is fast because the client only needs to download the portion of the whole
image that is visible on the screen of the user at their current viewing
resolution. The client requests a view of an image and the server only needs
to send back the image tiles necessary for that particular view.
http://iipimage.sourceforge.net/protocol.shtml

Cheers

Norman


From crschmidt at crschmidt.net  Tue Sep 12 18:23:26 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Tue, 12 Sep 2006 21:23:26 -0400
Subject: [tiling] Tiling BOF at FOSS4G
Message-ID: <20060913012326.GH21651@crschmidt.net>

Earlier this evening (or, in Swiss time, yesterday evening, since it's
now 2:35AM), there was a BOF for discussing WMS tiling, as previously
discussed on the OSGeo wiki, at
http://wiki.osgeo.org/index.php/WMS_Tile_Caching .

Participants represented all walks of the tiling rainbow, and the
discussion was lively and interesting and largely productive.

Schuyler has much more detailed notes that he plans to type up, but
since the affect of jet lag on me is apparently to become unable to
sleep for more than 4 hours a night, I'm going to type up a few notes
now:

Decisions:
 * The discussion began on the principle that the tiling requests should
   be built on top of WMS -- in other words, a compliant tile request
   is a GetMap request, for backwards compatibility reasons.
 * Metadata for WMS-C will be stored as additional WMS metadata,
   availble via getcapabilities requests. 
 * A number of parameters are required to define the caching scheme in
   use by the server serving the tiles. 
    * Geographic origin of tiles
    * A set of resolutions for which tiles are available
      Resolution is defined as the number of map units per pixel.
    * Tile Size
    * Layer name
    * Projection
    * Format
   Some of these are contrary to the earlier definition on the OSGeo
   wiki: specifically, scale is no longer used, and scale no longer must
   be defined as a specific 'top level', and a factor from there. The
   primary complaint against this comes from cartogrpahers, who
   explained that each country has 'default' scales which are in use.
   (Think 1:24K USGS quads in the US.) Preventing the tiling scheme from
   being able to descirbe these tiles would have been a mistake.
 * However, although it is possible to define these in any way,
   depending on the needs of your client, there will be established a
   set of 'default' parameters which create the first WMS-C profile. The
   exact values of these parameters was a topic of discussion -- agreed
   at the meeting was:
    * Tile Size of 256x256
    * Projection of EPSG:4326
    * Resolutions must contain 1.40625 as top, and must contain at least
      one resolution: resolutions below 1.40625 should be divisors of 2
      of this value.
   Not decided when we ran out of time were:
    * Geographic origin of tiles (but I think we were close to
      '-180,-90' as a decision.)

   The idea here is that if you want your tiles to be used alongside
   other map tiles, the easiest way to do it is to support these
   properties. I feel like there was something else we hadn't yet
   finished discussing, but I don't remember what.
 * Layer name for tiled requests must be a *single layer* -- grouping
   should be done by the provider, or the provider can provide multiple
   caches for different layers if they are prepared to suffer the
   caching properties from having clients request them all.

Possible ideas brought up:   
 * Handling errors. Because tiles are specified requests, it should be
   possible to create a static, non-WMS backed tile server
   (pre-generating the tiles and load balancing over lightweight
   servers). This brought up the case of error handling: an idea was
   suggested to use standard HTTP error codes, but also to encourage the
   content of the 404 to be an image with text in it, to mimic the
   inimage exception (supported by Mapserver at least)
 * Support for 3 different modes (stated somewhere in metadata): "No
   tiling" ( default WMS), "Some tiling" (I serve tiles, but will also
   serve other WMS requests) or "only tiling" (I don't support your
   silly non-tiled matching requests), which is useful for static
   servers.
 
Not yet tackled, but needs to be:
 * Rounding. In order to support the same boxes, a standard for how to
   round bbox requests should be established.

Postponed:

 * Implementation of changes in clients in order to better support
   cachability was put aside for the time being. Although setting up a
   tiling specification does *allow* easier cachability, it doesn't
   depend on it. 
 * Implementation of a "GetTile" request, which requests tiles based on
   a grid with a 'zoom level', was postponed.

Future plans: 
 * Several volunteers (Schuyler Erle, Paul Spencer, Paul Ramsey) offered 
   to help write the prose version of the spec -- I'm hoping some of
   what I typed out will help.
 * The plan is to have a draft implementation prepared in time for the
   next OGC meeting, October 2nd.
 * Hopefully, it will be possible to demonstrate an implementation of
   the tiling schema by that time. 

Possibilities once tiling spec is complete:
 * Create generally useful datasets with fully cached fast served
   tiles. (VMap0, TIGER, etc.) These can then be used by most clients,
   saving the need for repition of effort in generating these tiles
 * (Personal, not brought up at meeting) Tiled WMS directory listing. 
   This is a bit similar to the geodata committee catalog idea brought
   up for OSGeo... only simpler, since you need only provide a single
   WMS URL in order to add it to the catalog

Testing tools:
 * There should be a testing tool which allows you to enter a set of
   caching params, and choose a grid ref (0,0, 0,1, etc.) and a zoom
   level, and have the bbox be generated -- clients can then test
   conformance against this URL. 
 * Server implementations are laregely already complete in the form of
   WMS.

General Info: 
 * Attendence at the BOF was high, around 40-50 people in total. 
 * Developers of Ka-Map, MapBuilder and OpenLayers were in attendance
   (and I feel like I'm missing some other tiling mapping client
   somewhere, but I don't know.)
 * Developers of MapServer and GeoServer.
 * Many many other developers, interested parties, contributors, etc.

All in all, it was far more productive and enjoyable than I expected it
ot be. It was good to see everyone in one room and discussing things
rationally :) 

Many thanks to all participants. Looking forward to seeing work continue
in this thread.

Regards,   
-- 
Christopher Schmidt
Web Developer

From SCHUTP at AGR.GC.CA  Wed Sep 13 08:32:11 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Wed, 13 Sep 2006 11:32:11 -0400
Subject: [tiling] Tiling BOF at FOSS4G
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE2F5E@onncrxms3.agr.gc.ca>

Thanks for the summary, Christopher.  It seems you made a lot of
progress.  I'm quite comfortable with the basic parameters of 
    * Tile Size of 256x256
    * Projection of EPSG:4326
    * Resolutions must contain 1.40625 as top, and must contain at least
      one resolution: resolutions below 1.40625 should be divisors of 2
      of this value.
    * Geographic origin of tiles at -180, -90.

One thing that strikes me is that basing the tiling requests on top of
WMS will not allow for optimal performance.  I agree that a WMS approach
is needed, and it will offer up a great deal of flexibility and serious
improvements to performance to conventional WMS.  However, I think that
for truly high-performance mapping it would be most useful to develop a
convention around tile caches that use a standardized set of file and
directory names to provide access to the tiles.  In this fashion, a
client could predict the URL of any tile simply by knowing the base URL
of the cache, and each request to the server for a tile would simply be
for a .png file within that file system, allowing for the fastest
possible server response.  

The file system could look something like this:
  /landsat/1/1.png    <-- highest level
  /landsat/2/1-1.png  <-- next level
  /landsat/2/1-2.png  
  /landsat/2/2-1.png  
  /landsat/2/2-2.png
  /landsat/3/...      <-- third level
In terms of javascripting at the client end, it's easy to predict the
URLs of surrounding tiles or tiles at another level of the hierarchy. 

OK, taking this idea one step further, if you accept a standard file
naming convention, all of a sudden you don't need to touch the WMS spec,
rewrite the WMS code, and upgrade all the WMS servers on the planet; you
can instead develop a utility that generates a known set of tiles from
any existing WMS (or even other services like ArcIMS).  Essentially, all
this utility would do is to string together a whole bunch of GetMap
requests and write the outputs to a file system to generate a static
cache.  Enabling this utility in a real-time way (as redirects or
whatever) would allow for dynamic tile generation from a WMS.

Clean, simple, and far less work than revising the WMS spec.

Cheers, Peter.




-----Original Message-----
From: tiling-bounces at lists.eogeo.org
[mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Christopher Schmidt
Sent: Tuesday, September 12, 2006 9:23 PM
To: tiling at lists.eogeo.org
Subject: [tiling] Tiling BOF at FOSS4G

Earlier this evening (or, in Swiss time, yesterday evening, since it's
now 2:35AM), there was a BOF for discussing WMS tiling, as previously
discussed on the OSGeo wiki, at
http://wiki.osgeo.org/index.php/WMS_Tile_Caching .

Participants represented all walks of the tiling rainbow, and the
discussion was lively and interesting and largely productive.

Schuyler has much more detailed notes that he plans to type up, but
since the affect of jet lag on me is apparently to become unable to
sleep for more than 4 hours a night, I'm going to type up a few notes
now:

Decisions:
 * The discussion began on the principle that the tiling requests should
   be built on top of WMS -- in other words, a compliant tile request
   is a GetMap request, for backwards compatibility reasons.
 * Metadata for WMS-C will be stored as additional WMS metadata,
   availble via getcapabilities requests. 
 * A number of parameters are required to define the caching scheme in
   use by the server serving the tiles. 
    * Geographic origin of tiles
    * A set of resolutions for which tiles are available
      Resolution is defined as the number of map units per pixel.
    * Tile Size
    * Layer name
    * Projection
    * Format
   Some of these are contrary to the earlier definition on the OSGeo
   wiki: specifically, scale is no longer used, and scale no longer must
   be defined as a specific 'top level', and a factor from there. The
   primary complaint against this comes from cartogrpahers, who
   explained that each country has 'default' scales which are in use.
   (Think 1:24K USGS quads in the US.) Preventing the tiling scheme from
   being able to descirbe these tiles would have been a mistake.
 * However, although it is possible to define these in any way,
   depending on the needs of your client, there will be established a
   set of 'default' parameters which create the first WMS-C profile. The
   exact values of these parameters was a topic of discussion -- agreed
   at the meeting was:
    * Tile Size of 256x256
    * Projection of EPSG:4326
    * Resolutions must contain 1.40625 as top, and must contain at least
      one resolution: resolutions below 1.40625 should be divisors of 2
      of this value.
   Not decided when we ran out of time were:
    * Geographic origin of tiles (but I think we were close to
      '-180,-90' as a decision.)

   The idea here is that if you want your tiles to be used alongside
   other map tiles, the easiest way to do it is to support these
   properties. I feel like there was something else we hadn't yet
   finished discussing, but I don't remember what.
 * Layer name for tiled requests must be a *single layer* -- grouping
   should be done by the provider, or the provider can provide multiple
   caches for different layers if they are prepared to suffer the
   caching properties from having clients request them all.

Possible ideas brought up:   
 * Handling errors. Because tiles are specified requests, it should be
   possible to create a static, non-WMS backed tile server
   (pre-generating the tiles and load balancing over lightweight
   servers). This brought up the case of error handling: an idea was
   suggested to use standard HTTP error codes, but also to encourage the
   content of the 404 to be an image with text in it, to mimic the
   inimage exception (supported by Mapserver at least)
 * Support for 3 different modes (stated somewhere in metadata): "No
   tiling" ( default WMS), "Some tiling" (I serve tiles, but will also
   serve other WMS requests) or "only tiling" (I don't support your
   silly non-tiled matching requests), which is useful for static
   servers.
 
Not yet tackled, but needs to be:
 * Rounding. In order to support the same boxes, a standard for how to
   round bbox requests should be established.

Postponed:

 * Implementation of changes in clients in order to better support
   cachability was put aside for the time being. Although setting up a
   tiling specification does *allow* easier cachability, it doesn't
   depend on it. 
 * Implementation of a "GetTile" request, which requests tiles based on
   a grid with a 'zoom level', was postponed.

Future plans: 
 * Several volunteers (Schuyler Erle, Paul Spencer, Paul Ramsey) offered

   to help write the prose version of the spec -- I'm hoping some of
   what I typed out will help.
 * The plan is to have a draft implementation prepared in time for the
   next OGC meeting, October 2nd.
 * Hopefully, it will be possible to demonstrate an implementation of
   the tiling schema by that time. 

Possibilities once tiling spec is complete:
 * Create generally useful datasets with fully cached fast served
   tiles. (VMap0, TIGER, etc.) These can then be used by most clients,
   saving the need for repition of effort in generating these tiles
 * (Personal, not brought up at meeting) Tiled WMS directory listing. 
   This is a bit similar to the geodata committee catalog idea brought
   up for OSGeo... only simpler, since you need only provide a single
   WMS URL in order to add it to the catalog

Testing tools:
 * There should be a testing tool which allows you to enter a set of
   caching params, and choose a grid ref (0,0, 0,1, etc.) and a zoom
   level, and have the bbox be generated -- clients can then test
   conformance against this URL. 
 * Server implementations are laregely already complete in the form of
   WMS.

General Info: 
 * Attendence at the BOF was high, around 40-50 people in total. 
 * Developers of Ka-Map, MapBuilder and OpenLayers were in attendance
   (and I feel like I'm missing some other tiling mapping client
   somewhere, but I don't know.)
 * Developers of MapServer and GeoServer.
 * Many many other developers, interested parties, contributors, etc.

All in all, it was far more productive and enjoyable than I expected it
ot be. It was good to see everyone in one room and discussing things
rationally :) 

Many thanks to all participants. Looking forward to seeing work continue
in this thread.

Regards,   
-- 
Christopher Schmidt
Web Developer
_______________________________________________
tiling mailing list
tiling at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/tiling

From stein at geofusion.com  Wed Sep 13 09:51:04 2006
From: stein at geofusion.com (Chuck Stein)
Date: Wed, 13 Sep 2006 09:51:04 -0700
Subject: [tiling] The GeoMatrix Tiling system
Message-ID: <023a01c6d754$d35b5280$0200a8c0@lapchuck>

Greetings all,

The GeoMatrix(r) Globe tiling system is a very powerful system used in
virtual globe rendering systems.  This is the same tiling system implemented
by our GeoMatrix Toolkit SDK and used by ESRI in ArcGlobe, ViewTec in
TerrainViewGlobe, and other products including our free web-based GeoPlayer
viewer (www.geoplayer.com/gateways).  I have attached a pre-print of a paper
presented by Paul Hansen (GeoFusion President) at the 2nd International
Conference on Discrete Global Grids.

The GeoMatrix system uses a hybrid projection, Geographic between +45 and
-45 latitude, and a "square polar" projection in the polar areas.  The
square polar projection allows us to have a very efficient representation at
the poles while reducing distortion during rendering (texture mapping).
Please read the PDF for the details.  Beyond the projection details our tile
format includes:

+ fast lookup "database" (minimum-quad-tree - mqt) look-up file that
identifies tiles that exist in the dataset and whether they have full or
partial coverage by the data.

+ optional 1-bit in alpha channel indicating valid/invalid (transparent)
pixel data.  Full 8-bit alpha supported for blending of datasets.

+ support for numerous "texture" formats.  Since our renderer is using
texture mapping to display the imagery on the terrain, we support normal
texture formats including DXT texture compression formats.  These provide a
huge gain for the transmission phase and client side (reduced requirements
for texture memory and loading).

+ zlib (lossless) compression of each tile for further reduction in size for
transmission and loading.

+ the scheme supports arbitrarily sparse datasets (islanded).

Until now we have used our own GeoMatrix Tile Server and I am very
interested in getting GeoMatrix support from a WMS server.  GeoMatrix Tiles
can be specified simply with:

        + dataset name
        + globe face
        + resolution level
        + row
        + column

We currently load a reference file (XML metadata) and the MQT database file
first before requesting tiles.   This provides an optimized situation where
the client knows in advance where the tiles are.  An alternative is to
assume global coverage and just request tiles from a WMS.  The biggest
hurdles in implementing this in a WMS is getting support for the
square-polar projection, DXT compression formats, valid/invalid bit, MQT
file.  I am very interested in exploring how a WMS can server GeoMatrix
Tiles, there are many possibilities including having some of the work could
be done on the client side (although this would not be optimal).

I look forward to your comments.

Chuck

     Chuck Stein
   GeoFusion, Inc.
  www.geofusion.com
     831.662.2282
 stein @ geofusion.com 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: GEOMATRIX_GRID.pdf
Type: application/pdf
Size: 225931 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/tiling/attachments/20060913/60ab18d8/attachment-0001.pdf 

From crschmidt at crschmidt.net  Thu Sep 14 01:19:25 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Thu, 14 Sep 2006 04:19:25 -0400
Subject: [tiling] Tiling BOF at FOSS4G
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE2F5E@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE2F5E@onncrxms3.agr.gc.ca>
Message-ID: <20060914081924.GI21651@crschmidt.net>

On Wed, Sep 13, 2006 at 11:32:11AM -0400, Schut, Peter wrote:
> Thanks for the summary, Christopher.  It seems you made a lot of
> progress.  I'm quite comfortable with the basic parameters of 
>     * Tile Size of 256x256
>     * Projection of EPSG:4326
>     * Resolutions must contain 1.40625 as top, and must contain at least
>       one resolution: resolutions below 1.40625 should be divisors of 2
>       of this value.
>     * Geographic origin of tiles at -180, -90.
> 
> One thing that strikes me is that basing the tiling requests on top of
> WMS will not allow for optimal performance.  I agree that a WMS approach
> is needed, and it will offer up a great deal of flexibility and serious
> improvements to performance to conventional WMS.  However, I think that
> for truly high-performance mapping it would be most useful to develop a
> convention around tile caches that use a standardized set of file and
> directory names to provide access to the tiles.  In this fashion, a
> client could predict the URL of any tile simply by knowing the base URL
> of the cache, and each request to the server for a tile would simply be
> for a .png file within that file system, allowing for the fastest
> possible server response.  

There are a number of arguments in the same vein, that center around the
idea of making tile requests easier to get at.

However, the system you've described -- the ability to *only* use a
filesystem based cache -- was discussed at the tiling BOF, and it is
certainly not impossible to do this *without* coming up with a new URL
scheme: For an example, simply see http://crschmidt.net/mapping/tiling/:
 * Fill a directory with images
 * Inform clients of the constrained set of WMS parameters you allow
 * Users can then set up the directory directly so that it reads files

(Note that this doesn't work perfectly in this case, because apache will
find the Query String if you just load up the files... but you can see
the idea.) 

> In terms of javascripting at the client end, it's easy to predict the
> URLs of surrounding tiles or tiles at another level of the hierarchy. 

Yes, but it's all math to get between the two: given an adequately
defined spec, it is possible to write a single Javascript "cache tile
url generator" --  which would accept a grid param, a 'zoom' level, and
then tell you what the URL output should be. I believe I mentioned this
in the 'testing' section of the previous email.

> OK, taking this idea one step further, if you accept a standard file
> naming convention, all of a sudden you don't need to touch the WMS spec,
> rewrite the WMS code, and upgrade all the WMS servers on the planet; you
> can instead develop a utility that generates a known set of tiles from
> any existing WMS (or even other services like ArcIMS).  Essentially, all
> this utility would do is to string together a whole bunch of GetMap
> requests and write the outputs to a file system to generate a static
> cache.  Enabling this utility in a real-time way (as redirects or
> whatever) would allow for dynamic tile generation from a WMS.

Hm. This sounds like what I just described? Am I missing something
there?

-- 
Christopher Schmidt
Web Developer

From tisham at apogee.com.au  Fri Sep 15 19:22:58 2006
From: tisham at apogee.com.au (Tishampati Dhar)
Date: Sat, 16 Sep 2006 11:52:58 +0930
Subject: [tiling] Worldwind server
Message-ID: <200609161152.58558.tisham@apogee.com.au>

Hi all,

Looks like the spec being develped here is VERY close to a standard worldwind 
server. There are already 3 implementations of this.. one is here :
http://issues.worldwind.arc.nasa.gov/confluence/display/SRVR/Home
Others are here:
http://www.worldwindcentral.com/wiki/Making_layers
and f0urtyfive(Matt Mills) and Nowak(Adam Nowacki) host another one.

With rich clients such as WW and OssimPlanet making 3D viewing possible 
DEM/tiling/serving and blending is another area to look at.

As is Progressive sharpening eg using progressive Jpeg or JP2K/ECW.

Just food for thought.

Tisham Dhar(aka what_nick)
Software Developer
Apogee Imaging International
http://www.apogee.com.au

From SCHUTP at AGR.GC.CA  Mon Sep 18 10:02:29 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Mon, 18 Sep 2006 13:02:29 -0400
Subject: [tiling] Worldwind server
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE2F78@onncrxms3.agr.gc.ca>

OK, so I finally got around to reading the whirlwind documentation, and I wish I'd taken a look a long time ago.  Tisham is right.  It's almost exactly what we seem to have been gravitating towards.  There are two problems I see:

1)  There is no standardized level 0 tile size.  I feel we need this because I would like to be able to predict the name of a tile from any other tile store by just knowing the root URL and the image format.  This would simplify client operations like switching between two different vintages of the same dataset, and switching transparent layers on and off.  My vote is for standardizing on 180 degrees for the level zero tile size.  

2)  The naming convention for whirlwind files is suitable for satellite scale imagery, but not appropriate for high resolution imagery such as aerial photography.  Whirlwind tile names currently follow the convention ####_####.abc, which means each tile covers about 5km at the equator.  If we standardize on #######_#######.abc then at the highest resolution that would fit within this naming convention each image would cover at most 5 meters.

Cheers, Peter.


Peter Schut 
Director, Geomatics / Directeur, science g?omatiques
Agriculture and Agri-Food Canada / Agriculture et Agroalimentaire Canada
Telephone/T?l?phone: 613 759-1874
Facsimile/T?l?copieur: 613 759-1937
960 Carling Avenue
Ottawa ON K1A 0C6





-----Original Message-----
From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Tishampati Dhar
Sent: Friday, September 15, 2006 10:23 PM
To: tiling at lists.eogeo.org
Subject: [tiling] Worldwind server

Hi all,

Looks like the spec being develped here is VERY close to a standard worldwind 
server. There are already 3 implementations of this.. one is here :
http://issues.worldwind.arc.nasa.gov/confluence/display/SRVR/Home
Others are here:
http://www.worldwindcentral.com/wiki/Making_layers
and f0urtyfive(Matt Mills) and Nowak(Adam Nowacki) host another one.

With rich clients such as WW and OssimPlanet making 3D viewing possible 
DEM/tiling/serving and blending is another area to look at.

As is Progressive sharpening eg using progressive Jpeg or JP2K/ECW.

Just food for thought.

Tisham Dhar(aka what_nick)
Software Developer
Apogee Imaging International
http://www.apogee.com.au
_______________________________________________
tiling mailing list
tiling at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/tiling

From adoyle at eogeo.org  Mon Sep 18 10:19:18 2006
From: adoyle at eogeo.org (Allan Doyle)
Date: Mon, 18 Sep 2006 13:19:18 -0400
Subject: [tiling] Two approaches (was Re:  Worldwind server)
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE2F78@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE2F78@onncrxms3.agr.gc.ca>
Message-ID: <7D652743-922D-48DF-87C1-B9C2F991DC74@eogeo.org>

I talked to a few people after the meeting, and I think we can/should  
distinguish the cases like this:

WMS-C - Cacheable WMS. This is a set of recommendations primarily to  
WMS clients, that if followed, result in faster access.

   Example clients would be osgPlanet, OpenLayers, MapBuilder, etc.

WMS-T - Tiling WMS. This may not, strictly speaking be WMS, since it  
really will be a new spec. Or it could just layer a "GetTile" on top,  
with a possible extension to GetCapabilities. But it would be a new  
spec, not just a profile of something existing.

   Example clients would be Google Maps, Google Earth, Worldwind

Of course, either kind of client can probably be pretty quickly  
adapted to be the other kind. The reason I think WMS-C is important  
is that it can leverage all of the existing WMS's that are out there  
with very minimal additional work.

I am all in favor of proceeding with both, and am further in favor of  
thinking it through in a way that makes it easier to build an adaptor  
that sits between a WMS-C and a WMS-T. And, of course, the easier it  
is to build the adaptor, the less important it is that there be two.

	Allan

On Sep 18, 2006, at 13:02, Schut, Peter wrote:

> OK, so I finally got around to reading the whirlwind documentation,  
> and I wish I'd taken a look a long time ago.  Tisham is right.   
> It's almost exactly what we seem to have been gravitating towards.   
> There are two problems I see:
>
> 1)  There is no standardized level 0 tile size.  I feel we need  
> this because I would like to be able to predict the name of a tile  
> from any other tile store by just knowing the root URL and the  
> image format.  This would simplify client operations like switching  
> between two different vintages of the same dataset, and switching  
> transparent layers on and off.  My vote is for standardizing on 180  
> degrees for the level zero tile size.
>
> 2)  The naming convention for whirlwind files is suitable for  
> satellite scale imagery, but not appropriate for high resolution  
> imagery such as aerial photography.  Whirlwind tile names currently  
> follow the convention ####_####.abc, which means each tile covers  
> about 5km at the equator.  If we standardize on #######_#######.abc  
> then at the highest resolution that would fit within this naming  
> convention each image would cover at most 5 meters.
>
> Cheers, Peter.
>
>
> Peter Schut
> Director, Geomatics / Directeur, science g?omatiques
> Agriculture and Agri-Food Canada / Agriculture et Agroalimentaire  
> Canada
> Telephone/T?l?phone: 613 759-1874
> Facsimile/T?l?copieur: 613 759-1937
> 960 Carling Avenue
> Ottawa ON K1A 0C6
>
>
>
>
>
> -----Original Message-----
> From: tiling-bounces at lists.eogeo.org [mailto:tiling- 
> bounces at lists.eogeo.org] On Behalf Of Tishampati Dhar
> Sent: Friday, September 15, 2006 10:23 PM
> To: tiling at lists.eogeo.org
> Subject: [tiling] Worldwind server
>
> Hi all,
>
> Looks like the spec being develped here is VERY close to a standard  
> worldwind
> server. There are already 3 implementations of this.. one is here :
> http://issues.worldwind.arc.nasa.gov/confluence/display/SRVR/Home
> Others are here:
> http://www.worldwindcentral.com/wiki/Making_layers
> and f0urtyfive(Matt Mills) and Nowak(Adam Nowacki) host another one.
>
> With rich clients such as WW and OssimPlanet making 3D viewing  
> possible
> DEM/tiling/serving and blending is another area to look at.
>
> As is Progressive sharpening eg using progressive Jpeg or JP2K/ECW.
>
> Just food for thought.
>
> Tisham Dhar(aka what_nick)
> Software Developer
> Apogee Imaging International
> http://www.apogee.com.au
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling

-- 
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org




From steven_morris at ncsu.edu  Thu Sep 21 15:28:52 2006
From: steven_morris at ncsu.edu (Steve Morris)
Date: Thu, 21 Sep 2006 18:28:52 -0400
Subject: [tiling] Two approaches (was Re:  Worldwind server)
In-Reply-To: <7D652743-922D-48DF-87C1-B9C2F991DC74@eogeo.org>
References: <783BB96C25B79249A236DF62F559D6A501EE2F78@onncrxms3.agr.gc.ca>
	<7D652743-922D-48DF-87C1-B9C2F991DC74@eogeo.org>
Message-ID: <45131224.7020005@ncsu.edu>


I'm curious how the temporal component will play out in 
this--particularly in the case of WMS services based on volatile vector 
data.  Presumably there's some temporal component to allow for staleness 
testing on the cache--could that be extended to the point of 
intentionally requesting an older version of the data if an archive were 
to accumulate cached versions?  or is that strictly an internal cache 
function and independent of the tile request?  The reason I am wondering 
is we are involved in a geodata preservation project with the Library of 
Congress and have been kicking around the notion of 'pickling' a WMS 
service.  I've been watching the tiling/caching discussion closely since 
if there were a standard way to request static tiles then we might have 
a market for archived tiles that we might capture--and perhaps some 
guidance on how to grab those tiles with the greatest likelihood of them 
being useful. 

I think maybe someone mentioned there would be a tiling/caching 
discussion at the upcoming OGC TC?  There will also be a Historical Data 
session (agenda not finalized).  I wonder if there's any opportunity to 
cross-fertilize discussions, or perhaps its too early. 

Steve

Allan Doyle wrote:

>I talked to a few people after the meeting, and I think we can/should  
>distinguish the cases like this:
>
>WMS-C - Cacheable WMS. This is a set of recommendations primarily to  
>WMS clients, that if followed, result in faster access.
>
>   Example clients would be osgPlanet, OpenLayers, MapBuilder, etc.
>
>WMS-T - Tiling WMS. This may not, strictly speaking be WMS, since it  
>really will be a new spec. Or it could just layer a "GetTile" on top,  
>with a possible extension to GetCapabilities. But it would be a new  
>spec, not just a profile of something existing.
>
>   Example clients would be Google Maps, Google Earth, Worldwind
>
>Of course, either kind of client can probably be pretty quickly  
>adapted to be the other kind. The reason I think WMS-C is important  
>is that it can leverage all of the existing WMS's that are out there  
>with very minimal additional work.
>
>I am all in favor of proceeding with both, and am further in favor of  
>thinking it through in a way that makes it easier to build an adaptor  
>that sits between a WMS-C and a WMS-T. And, of course, the easier it  
>is to build the adaptor, the less important it is that there be two.
>
>	Allan
>
>On Sep 18, 2006, at 13:02, Schut, Peter wrote:
>
>  
>
>>OK, so I finally got around to reading the whirlwind documentation,  
>>and I wish I'd taken a look a long time ago.  Tisham is right.   
>>It's almost exactly what we seem to have been gravitating towards.   
>>There are two problems I see:
>>
>>1)  There is no standardized level 0 tile size.  I feel we need  
>>this because I would like to be able to predict the name of a tile  
>>from any other tile store by just knowing the root URL and the  
>>image format.  This would simplify client operations like switching  
>>between two different vintages of the same dataset, and switching  
>>transparent layers on and off.  My vote is for standardizing on 180  
>>degrees for the level zero tile size.
>>
>>2)  The naming convention for whirlwind files is suitable for  
>>satellite scale imagery, but not appropriate for high resolution  
>>imagery such as aerial photography.  Whirlwind tile names currently  
>>follow the convention ####_####.abc, which means each tile covers  
>>about 5km at the equator.  If we standardize on #######_#######.abc  
>>then at the highest resolution that would fit within this naming  
>>convention each image would cover at most 5 meters.
>>
>>Cheers, Peter.
>>
>>
>>Peter Schut
>>Director, Geomatics / Directeur, science g?omatiques
>>Agriculture and Agri-Food Canada / Agriculture et Agroalimentaire  
>>Canada
>>Telephone/T?l?phone: 613 759-1874
>>Facsimile/T?l?copieur: 613 759-1937
>>960 Carling Avenue
>>Ottawa ON K1A 0C6
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: tiling-bounces at lists.eogeo.org [mailto:tiling- 
>>bounces at lists.eogeo.org] On Behalf Of Tishampati Dhar
>>Sent: Friday, September 15, 2006 10:23 PM
>>To: tiling at lists.eogeo.org
>>Subject: [tiling] Worldwind server
>>
>>Hi all,
>>
>>Looks like the spec being develped here is VERY close to a standard  
>>worldwind
>>server. There are already 3 implementations of this.. one is here :
>>http://issues.worldwind.arc.nasa.gov/confluence/display/SRVR/Home
>>Others are here:
>>http://www.worldwindcentral.com/wiki/Making_layers
>>and f0urtyfive(Matt Mills) and Nowak(Adam Nowacki) host another one.
>>
>>With rich clients such as WW and OssimPlanet making 3D viewing  
>>possible
>>DEM/tiling/serving and blending is another area to look at.
>>
>>As is Progressive sharpening eg using progressive Jpeg or JP2K/ECW.
>>
>>Just food for thought.
>>
>>Tisham Dhar(aka what_nick)
>>Software Developer
>>Apogee Imaging International
>>http://www.apogee.com.au
>>_______________________________________________
>>tiling mailing list
>>tiling at lists.eogeo.org
>>http://lists.eogeo.org/mailman/listinfo/tiling
>>_______________________________________________
>>tiling mailing list
>>tiling at lists.eogeo.org
>>http://lists.eogeo.org/mailman/listinfo/tiling
>>    
>>
>
>  
>

-- 
Steve Morris
Head of Digital Library Initiatives
North Carolina State University Libraries
Phone: (919) 515-1361  Fax: (919) 515-3031 
Steven_Morris at ncsu.edu