From adoyle at eogeo.org Wed Nov 1 06:57:10 2006
From: adoyle at eogeo.org (Allan Doyle)
Date: Wed, 1 Nov 2006 09:57:10 -0500
Subject: [tiling] WMS Tiling Client Recommendation
In-Reply-To: <74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net>
References: <20061101011433.GM30475@vishnu.tridity.org>
<74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net>
Message-ID: <567285C6-09A5-4ACE-98D1-026BBB0A160A@eogeo.org>
On Oct 31, 2006, at 23:48, Paul Ramsey wrote:
> There are some mandatory WMS request parameters that are not in the
> list of parameters, like VERSION. The more I think about this, the
> more it seems like a fools errand to try and constrain WMS requests
> sufficiently to get acceptable shared caching behavior.
I guess it depends on how hard you're willing to work. The ideal
might be to have completely canonical URLs with fixed WIDTH and
HEIGHT and BBOXes that only have very specific values. But if, for
some reason you can't guarantee a specific keyword order or can't
guarantee proper encoding, there's still a chance of a clever URL
rewriter being able to fix that stuff on the way in. You can still
benefit from caching.
That being said, however, once you're being that clever in the
rewriting, there's no reason you can't rewrite the tiling scheme into
a caching scheme, and thus I now completely change my position (it's
been slowly changing anyway) about wanting to do the caching before
we do the tiling.
It may be that once tiling is settled, caching will just happen.
Allan
>
> On 31-Oct-06, at 5:14 PM, Schuyler Erle wrote:
>
>> I've finally published a tiling WMS recommendation, although I
>> seem to
>> have gone a bit overboard from what Paul probably envisioned when he
>> titled the wiki page "WMS Tiling Client Recommendation".[1] I did,
>> at any
>> rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I
>> don't think I missed anything important. Comments? Questions?
>> Complaints? Should the page be renamed? Or should the server
>> extensions be thrown away in favor of TMS?
>>
>> [1] http://wiki.osgeo.org/index.php/
>> WMS_Tiling_Client_Recommendation
>> [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF
>>
>> SDE
>> _______________________________________________
>> 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 schuyler at nocat.net Wed Nov 1 09:20:33 2006
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed, 1 Nov 2006 09:20:33 -0800
Subject: [tiling] WMS Tiling Client Recommendation
In-Reply-To: <567285C6-09A5-4ACE-98D1-026BBB0A160A@eogeo.org>
References: <20061101011433.GM30475@vishnu.tridity.org>
<74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net>
<567285C6-09A5-4ACE-98D1-026BBB0A160A@eogeo.org>
Message-ID: <20061101172033.GN30475@vishnu.tridity.org>
* On 1-Nov-2006 at 6:57AM PST, Allan Doyle said:
>
> > There are some mandatory WMS request parameters that are not in the
> > list of parameters, like VERSION. The more I think about this, the
> > more it seems like a fools errand to try and constrain WMS requests
> > sufficiently to get acceptable shared caching behavior.
>
> I guess it depends on how hard you're willing to work. The ideal
> might be to have completely canonical URLs with fixed WIDTH and
> HEIGHT and BBOXes that only have very specific values. But if, for
> some reason you can't guarantee a specific keyword order or can't
> guarantee proper encoding, there's still a chance of a clever URL
> rewriter being able to fix that stuff on the way in. You can still
> benefit from caching.
I wouldn't mind implementing what we've got and seeing how well it
performs in practice. I've updated the text to address some of the
concerns stated so far:
http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation
Someone changed the GetCaps example to use LatLonBoundingBox rather
than BoundingBox. Does that make a lot of sense? It made more sense to
me to have the bounding boxes in the same SRS as the layer. In the
same vein, I changed the Mercator profile BBOX back to square. Totally
ready to hear feedback on this.
SDE
From adoyle at eogeo.org Wed Nov 1 09:24:59 2006
From: adoyle at eogeo.org (Allan Doyle)
Date: Wed, 1 Nov 2006 12:24:59 -0500
Subject: [tiling] WMS Tiling Client Recommendation
In-Reply-To: <20061101172033.GN30475@vishnu.tridity.org>
References: <20061101011433.GM30475@vishnu.tridity.org>
<74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net>
<567285C6-09A5-4ACE-98D1-026BBB0A160A@eogeo.org>
<20061101172033.GN30475@vishnu.tridity.org>
Message-ID: <02955931-4EEB-4FB3-A5D6-EEF7337C37F9@eogeo.org>
On Nov 1, 2006, at 12:20, Schuyler Erle wrote:
> * On 1-Nov-2006 at 6:57AM PST, Allan Doyle said:
>>
>>> There are some mandatory WMS request parameters that are not in the
>>> list of parameters, like VERSION. The more I think about this, the
>>> more it seems like a fools errand to try and constrain WMS requests
>>> sufficiently to get acceptable shared caching behavior.
>>
>> I guess it depends on how hard you're willing to work. The ideal
>> might be to have completely canonical URLs with fixed WIDTH and
>> HEIGHT and BBOXes that only have very specific values. But if, for
>> some reason you can't guarantee a specific keyword order or can't
>> guarantee proper encoding, there's still a chance of a clever URL
>> rewriter being able to fix that stuff on the way in. You can still
>> benefit from caching.
>
> I wouldn't mind implementing what we've got and seeing how well it
> performs in practice. I've updated the text to address some of the
> concerns stated so far:
>
> http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation
>
> Someone changed the GetCaps example to use LatLonBoundingBox rather
> than BoundingBox. Does that make a lot of sense? It made more sense to
> me to have the bounding boxes in the same SRS as the layer. In the
> same vein, I changed the Mercator profile BBOX back to square. Totally
> ready to hear feedback on this.
The reason LatLonBoundingBox is in WMS is to make everything at least
be in the same CRS when you're searching for services. Each layer in
WMS is free to advertise its BoundingBox in its own CRS as well.
--
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org
From schuyler at nocat.net Wed Nov 1 09:45:02 2006
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed, 1 Nov 2006 09:45:02 -0800
Subject: [tiling] WMS Tiling Client Recommendation
In-Reply-To: <02955931-4EEB-4FB3-A5D6-EEF7337C37F9@eogeo.org>
References: <20061101011433.GM30475@vishnu.tridity.org>
<74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net>
<567285C6-09A5-4ACE-98D1-026BBB0A160A@eogeo.org>
<20061101172033.GN30475@vishnu.tridity.org>
<02955931-4EEB-4FB3-A5D6-EEF7337C37F9@eogeo.org>
Message-ID: <20061101174502.GO30475@vishnu.tridity.org>
* On 1-Nov-2006 at 9:25AM PST, Allan Doyle said:
> >
> > Someone changed the GetCaps example to use LatLonBoundingBox rather
> > than BoundingBox. Does that make a lot of sense? It made more sense to
> > me to have the bounding boxes in the same SRS as the layer. In the
> > same vein, I changed the Mercator profile BBOX back to square. Totally
> > ready to hear feedback on this.
>
> The reason LatLonBoundingBox is in WMS is to make everything at least
> be in the same CRS when you're searching for services. Each layer in
> WMS is free to advertise its BoundingBox in its own CRS as well.
Anyone want to make a call on this? The key thing is that the grid
origin and size are explicitly stated.
SDE
From SCHUTP at AGR.GC.CA Wed Nov 1 09:56:08 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Wed, 1 Nov 2006 12:56:08 -0500
Subject: [tiling] Global profile
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE3170@onncrxms3.agr.gc.ca>
I really like this spec - it offers a good balance between flexibility
and standardization, and I love the RESTful approach.
In order to make it really simple to code clients for the global
profile, I think it would help if the global profile also standardized
the tileset directory names. This would free the global client from
having to parse the contents of the TileMap document, because the base
URL is all that it would need to know in order to display any compliant
layer inside the current view. It also makes it easy for the client to
calculate what tiles are needed when zooming in or out, without having
to resort to a lookup table containing the TileSet information.
The directory names could be the same as the factor "n" used in the
units-per-pixel calculation. I.e.:
Cheers, Peter.
From noreply at geocartic.com Wed Nov 1 10:09:37 2006
From: noreply at geocartic.com (Tim Schaub)
Date: Wed, 1 Nov 2006 11:09:37 -0700
Subject: [tiling] WMS Tiling Client Recommendation
In-Reply-To: <20061101174502.GO30475@vishnu.tridity.org>
Message-ID: <007001c6fde0$e4e5b9c0$15fea8c0@meridian>
> >
> > The reason LatLonBoundingBox is in WMS is to make
> everything at least
> > be in the same CRS when you're searching for services. Each
> layer in
> > WMS is free to advertise its BoundingBox in its own CRS as well.
>
> Anyone want to make a call on this? The key thing is that the
> grid origin and size are explicitly stated.
>
I think that two major drawbacks of the WMS spec are that BoundingBox and
ScaleHint are optional for layers. This means that there is no way a client
can say for sure whether or not a given request is going to return a valid
map. (A layer doesn't have to be available in EPSG:4326, but is only
required to advertise a LatLonBoundingBox. Even if the client can transform
coordinates, there's no guarantee that your request will be within the
optionally advertised range of scales.)
All this is to say that I think more requirements should be placed on
servers so we can write dumb clients and get good results. So, my vote
would be for no requirements on parameter order/encoding (let servers be
smart), required BoundingBox for each CRS, and required LatLonBoundingBox
for effective searches.
Thanks for pushing this forward.
Tim
> SDE
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
>
>
From pramsey at refractions.net Wed Nov 1 10:28:03 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Wed, 1 Nov 2006 10:28:03 -0800
Subject: [tiling] Global profile
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE3170@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE3170@onncrxms3.agr.gc.ca>
Message-ID: <5DE07868-99CE-4B36-9387-12FC96555D75@refractions.net>
Hm. I guess I'm OK with this, despite the added watering down of the
RESTfulness :) Anyone have any objections?
P
On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
> I really like this spec - it offers a good balance between flexibility
> and standardization, and I love the RESTful approach.
>
> In order to make it really simple to code clients for the global
> profile, I think it would help if the global profile also standardized
> the tileset directory names. This would free the global client from
> having to parse the contents of the TileMap document, because the base
> URL is all that it would need to know in order to display any
> compliant
> layer inside the current view. It also makes it easy for the
> client to
> calculate what tiles are needed when zooming in or out, without having
> to resort to a lookup table containing the TileSet information.
>
> The directory names could be the same as the factor "n" used in the
> units-per-pixel calculation. I.e.:
>
> order="0" />
> order="1" />
> order="2" />
From pramsey at refractions.net Wed Nov 1 10:29:53 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Wed, 1 Nov 2006 10:29:53 -0800
Subject: [tiling] WMS Tiling Client Recommendation
In-Reply-To: <20061101174502.GO30475@vishnu.tridity.org>
References: <20061101011433.GM30475@vishnu.tridity.org>
<74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net>
<567285C6-09A5-4ACE-98D1-026BBB0A160A@eogeo.org>
<20061101172033.GN30475@vishnu.tridity.org>
<02955931-4EEB-4FB3-A5D6-EEF7337C37F9@eogeo.org>
<20061101174502.GO30475@vishnu.tridity.org>
Message-ID: <76AE950E-7DE5-4049-8C57-965DA6048660@refractions.net>
I was the one who changed BoundingBox to LatLonBoundingBox, but I
only did it so that the coordinates in the example you wrote Schuyler
would harmonize with the SRS. I think any search server is going to
be smart enough to handle re-projection, almost by definition, so
requiring LatLonBoundingBox is redundant, IMO.
P
On 1-Nov-06, at 9:45 AM, Schuyler Erle wrote:
> * On 1-Nov-2006 at 9:25AM PST, Allan Doyle said:
>>>
>>> Someone changed the GetCaps example to use LatLonBoundingBox rather
>>> than BoundingBox. Does that make a lot of sense? It made more
>>> sense to
>>> me to have the bounding boxes in the same SRS as the layer. In the
>>> same vein, I changed the Mercator profile BBOX back to square.
>>> Totally
>>> ready to hear feedback on this.
>>
>> The reason LatLonBoundingBox is in WMS is to make everything at least
>> be in the same CRS when you're searching for services. Each layer in
>> WMS is free to advertise its BoundingBox in its own CRS as well.
>
> Anyone want to make a call on this? The key thing is that the grid
> origin and size are explicitly stated.
>
> SDE
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From sgillies at frii.com Wed Nov 1 10:58:39 2006
From: sgillies at frii.com (Sean Gillies)
Date: Wed, 01 Nov 2006 11:58:39 -0700
Subject: [tiling] Global profile
In-Reply-To: <5DE07868-99CE-4B36-9387-12FC96555D75@refractions.net>
References: <783BB96C25B79249A236DF62F559D6A501EE3170@onncrxms3.agr.gc.ca>
<5DE07868-99CE-4B36-9387-12FC96555D75@refractions.net>
Message-ID: <4548EE5F.50901@frii.com>
It's pragmatic. I like it.
Sean
Paul Ramsey wrote:
> Hm. I guess I'm OK with this, despite the added watering down of the
> RESTfulness :) Anyone have any objections?
>
> P
>
> On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
>
>> I really like this spec - it offers a good balance between flexibility
>> and standardization, and I love the RESTful approach.
>>
>> In order to make it really simple to code clients for the global
>> profile, I think it would help if the global profile also standardized
>> the tileset directory names. This would free the global client from
>> having to parse the contents of the TileMap document, because the base
>> URL is all that it would need to know in order to display any
>> compliant
>> layer inside the current view. It also makes it easy for the
>> client to
>> calculate what tiles are needed when zooming in or out, without having
>> to resort to a lookup table containing the TileSet information.
>>
>> The directory names could be the same as the factor "n" used in the
>> units-per-pixel calculation. I.e.:
>>
>> > order="0" />
>> > order="1" />
>> > order="2" />
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
>
From cholmes at openplans.org Wed Nov 1 11:09:47 2006
From: cholmes at openplans.org (Chris Holmes)
Date: Wed, 01 Nov 2006 14:09:47 -0500
Subject: [tiling] Global profile
In-Reply-To: <4548EE5F.50901@frii.com>
References: <783BB96C25B79249A236DF62F559D6A501EE3170@onncrxms3.agr.gc.ca> <5DE07868-99CE-4B36-9387-12FC96555D75@refractions.net>
<4548EE5F.50901@frii.com>
Message-ID: <4548F0FB.1050808@openplans.org>
I like it too, good to make things as easy as possible for clients to
implement. And I can't think of implementation issues on the server
side that would make this difficult.
Sean Gillies wrote:
> It's pragmatic. I like it.
>
> Sean
>
> Paul Ramsey wrote:
>> Hm. I guess I'm OK with this, despite the added watering down of the
>> RESTfulness :) Anyone have any objections?
>>
>> P
>>
>> On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
>>
>>> I really like this spec - it offers a good balance between flexibility
>>> and standardization, and I love the RESTful approach.
>>>
>>> In order to make it really simple to code clients for the global
>>> profile, I think it would help if the global profile also standardized
>>> the tileset directory names. This would free the global client from
>>> having to parse the contents of the TileMap document, because the base
>>> URL is all that it would need to know in order to display any
>>> compliant
>>> layer inside the current view. It also makes it easy for the
>>> client to
>>> calculate what tiles are needed when zooming in or out, without having
>>> to resort to a lookup table containing the TileSet information.
>>>
>>> The directory names could be the same as the factor "n" used in the
>>> units-per-pixel calculation. I.e.:
>>>
>>> >> order="0" />
>>> >> order="1" />
>>> >> order="2" />
>> _______________________________________________
>> 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
>
> !DSPAM:1003,4548ee53210807785049143!
>
--
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/20061101/1783da0f/attachment.vcf
From pramsey at refractions.net Wed Nov 1 11:25:56 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Wed, 1 Nov 2006 11:25:56 -0800
Subject: [tiling] Global profile
In-Reply-To: <4548F0FB.1050808@openplans.org>
References: <783BB96C25B79249A236DF62F559D6A501EE3170@onncrxms3.agr.gc.ca> <5DE07868-99CE-4B36-9387-12FC96555D75@refractions.net>
<4548EE5F.50901@frii.com> <4548F0FB.1050808@openplans.org>
Message-ID:
I take it back, it is not a super duper simplification, it only
*appears* to be based on some of the examples in the specification.
The idea that it is simple flows from the idea that you reference
your at a base directory-like URL, and that the
is itself a directory-like URL, and that the s are
directories under that.
That is not guaranteed, not even at the highest level.
If the references a then the fact that it is global-
profile 1 is not useful to the client, even if the
directory endings are standardized. The client will still have to
parse the tilemap.xml file
* to figure out where those standardized tileset directories reside and
* to figure out which of the standard resolutions exist.
In some respects the whole global-profile flag is redundant, all that
is needed is the implementation advice, since the client will have to
parse enough information just to operate that it can figure out
whether the service is a global profile or not ("hm, its 4326, the
resolutions are standard, yep, it's a global profile").
Paul
On 1-Nov-06, at 11:09 AM, Chris Holmes wrote:
> I like it too, good to make things as easy as possible for clients
> to implement. And I can't think of implementation issues on the
> server side that would make this difficult.
>
> Sean Gillies wrote:
>> It's pragmatic. I like it.
>> Sean
>> Paul Ramsey wrote:
>>> Hm. I guess I'm OK with this, despite the added watering down of
>>> the RESTfulness :) Anyone have any objections?
>>>
>>> P
>>>
>>> On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
>>>
>>>> I really like this spec - it offers a good balance between
>>>> flexibility
>>>> and standardization, and I love the RESTful approach.
>>>>
>>>> In order to make it really simple to code clients for the global
>>>> profile, I think it would help if the global profile also
>>>> standardized
>>>> the tileset directory names. This would free the global client
>>>> from
>>>> having to parse the contents of the TileMap document, because
>>>> the base
>>>> URL is all that it would need to know in order to display any
>>>> compliant
>>>> layer inside the current view. It also makes it easy for the
>>>> client to
>>>> calculate what tiles are needed when zooming in or out, without
>>>> having
>>>> to resort to a lookup table containing the TileSet information.
>>>>
>>>> The directory names could be the same as the factor "n" used in the
>>>> units-per-pixel calculation. I.e.:
>>>>
>>>> >>> order="0" />
>>>> >>> order="1" />
>>>> >>> order="2" />
>>> _______________________________________________
>>> 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
>> !DSPAM:1003,4548ee53210807785049143!
>
> --
> Chris Holmes
> The Open Planning Project
> http://topp.openplans.org
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From adoyle at eogeo.org Wed Nov 1 12:10:16 2006
From: adoyle at eogeo.org (Allan Doyle)
Date: Wed, 1 Nov 2006 15:10:16 -0500
Subject: [tiling] WMS Tiling Client Recommendation
In-Reply-To: <76AE950E-7DE5-4049-8C57-965DA6048660@refractions.net>
References: <20061101011433.GM30475@vishnu.tridity.org>
<74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net>
<567285C6-09A5-4ACE-98D1-026BBB0A160A@eogeo.org>
<20061101172033.GN30475@vishnu.tridity.org>
<02955931-4EEB-4FB3-A5D6-EEF7337C37F9@eogeo.org>
<20061101174502.GO30475@vishnu.tridity.org>
<76AE950E-7DE5-4049-8C57-965DA6048660@refractions.net>
Message-ID:
On Nov 1, 2006, at 13:29, Paul Ramsey wrote:
> I was the one who changed BoundingBox to LatLonBoundingBox, but I
> only did it so that the coordinates in the example you wrote
> Schuyler would harmonize with the SRS. I think any search server
> is going to be smart enough to handle re-projection, almost by
> definition, so requiring LatLonBoundingBox is redundant, IMO.
I'm not sure I buy that. The LatLonBoundingBox requirement is far
older than WMS. It may have started in the Geo profile of Z39.50.
Finding out whether a point lies in an llbb is much easier than
finding of the same point lies in a projected bb. True, most search
servers are specifically programmed to know about projections, but it
seems to me that tossing the llbb when it's easy to provide should be
done with some caution.
Allan (who still harbors the naive hope that Google will someday
provide lat/lon based spatial search).
>
> P
>
> On 1-Nov-06, at 9:45 AM, Schuyler Erle wrote:
>
>> * On 1-Nov-2006 at 9:25AM PST, Allan Doyle said:
>>>>
>>>> Someone changed the GetCaps example to use LatLonBoundingBox rather
>>>> than BoundingBox. Does that make a lot of sense? It made more
>>>> sense to
>>>> me to have the bounding boxes in the same SRS as the layer. In the
>>>> same vein, I changed the Mercator profile BBOX back to square.
>>>> Totally
>>>> ready to hear feedback on this.
>>>
>>> The reason LatLonBoundingBox is in WMS is to make everything at
>>> least
>>> be in the same CRS when you're searching for services. Each layer in
>>> WMS is free to advertise its BoundingBox in its own CRS as well.
>>
>> Anyone want to make a call on this? The key thing is that the grid
>> origin and size are explicitly stated.
>>
>> SDE
>> _______________________________________________
>> 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 SCHUTP at AGR.GC.CA Wed Nov 1 12:08:00 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Wed, 1 Nov 2006 15:08:00 -0500
Subject: [tiling] Global profile
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE3173@onncrxms3.agr.gc.ca>
Paul, it may not be guaranteed currently, but I'm suggesting it should
be as part of the global profile. The value of the global profile
should be to restrict implementation options as much as reasonable, so
it becomes as easy as possible to understand and implement. What is the
real value of allowing flexibility at the directory level, or for the
base URL? Performance optimization is the only reason that really makes
sense, and performance optimization is more of a problem within a
TileSet than between TileSets. Take a look at the GM client - no two
adjacent tiles are stored on the same server - so if performance is an
issue we should be allowing freedom for the whole naming convention,
which the current spec doesn't support.
OK, here's an alternative that offers more flexibility and at the same
time permits optimal standardization. Instead of specifying the global
profile in the spec, we could just include a reference to a URN. The
URN identifies the profile which contains the directory and file naming
convention. The current spec has examples that deal with directory and
file naming conventions, and these can be used to create the first
profiles. A profile is a generalized version of what we currently
identify as the TileMap document. Other profiles get put forward as
needed to optimize performance in different ways - through different
naming conventions, tile sizes, hosting strategies or whatever.
Or, door number three, have third parties create and publish their own
profiles that implement the spec in some rigid way.
I favour the first option.
Cheers, Peter.
-----Original Message-----
From: tiling-bounces at lists.eogeo.org
[mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
Sent: Wednesday, November 01, 2006 2:26 PM
To: Chris Holmes
Cc: tiling at lists.eogeo.org
Subject: Re: [tiling] Global profile
I take it back, it is not a super duper simplification, it only
*appears* to be based on some of the examples in the specification.
The idea that it is simple flows from the idea that you reference
your at a base directory-like URL, and that the
is itself a directory-like URL, and that the s are
directories under that.
That is not guaranteed, not even at the highest level.
If the references a then the fact that it is global-
profile 1 is not useful to the client, even if the
directory endings are standardized. The client will still have to
parse the tilemap.xml file
* to figure out where those standardized tileset directories reside and
* to figure out which of the standard resolutions exist.
In some respects the whole global-profile flag is redundant, all that
is needed is the implementation advice, since the client will have to
parse enough information just to operate that it can figure out
whether the service is a global profile or not ("hm, its 4326, the
resolutions are standard, yep, it's a global profile").
Paul
On 1-Nov-06, at 11:09 AM, Chris Holmes wrote:
> I like it too, good to make things as easy as possible for clients
> to implement. And I can't think of implementation issues on the
> server side that would make this difficult.
>
> Sean Gillies wrote:
>> It's pragmatic. I like it.
>> Sean
>> Paul Ramsey wrote:
>>> Hm. I guess I'm OK with this, despite the added watering down of
>>> the RESTfulness :) Anyone have any objections?
>>>
>>> P
>>>
>>> On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
>>>
>>>> I really like this spec - it offers a good balance between
>>>> flexibility
>>>> and standardization, and I love the RESTful approach.
>>>>
>>>> In order to make it really simple to code clients for the global
>>>> profile, I think it would help if the global profile also
>>>> standardized
>>>> the tileset directory names. This would free the global client
>>>> from
>>>> having to parse the contents of the TileMap document, because
>>>> the base
>>>> URL is all that it would need to know in order to display any
>>>> compliant
>>>> layer inside the current view. It also makes it easy for the
>>>> client to
>>>> calculate what tiles are needed when zooming in or out, without
>>>> having
>>>> to resort to a lookup table containing the TileSet information.
>>>>
>>>> The directory names could be the same as the factor "n" used in the
>>>> units-per-pixel calculation. I.e.:
>>>>
>>>> >>> order="0" />
>>>> >>> order="1" />
>>>> >>> order="2" />
>>> _______________________________________________
>>> 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
>> !DSPAM:1003,4548ee53210807785049143!
>
> --
> Chris Holmes
> The Open Planning Project
> http://topp.openplans.org
>
> _______________________________________________
> 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
From pramsey at refractions.net Wed Nov 1 13:15:00 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Wed, 1 Nov 2006 13:15:00 -0800
Subject: [tiling] Global profile
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE3173@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE3173@onncrxms3.agr.gc.ca>
Message-ID: <27004CCA-D6B2-4110-822E-B1792A351979@refractions.net>
It is about more than tile location placing, there is also the issue
of the existence of any particular tile set. Even if one was so bold
as to say "all global profiles must be global" and mandate that they
have tilesets from the earth view on down, one would have to be very
bold indeed to mandate exactly how far down they do go. And if you
don't mandate it, the client will have to figure it out by parsing
the and once they are doing that anyways, there is no harm
in having arbitrary directory names.
On the subject of providing even *more* configurability wrt the
contents of s, please, don't tempt me, I dislike the current
arbitrariness of saying "and from here on, do it just this way", it
is not in keeping with the restfullness of the remaining parts of the
spec.
P
On 1-Nov-06, at 12:08 PM, Schut, Peter wrote:
> Paul, it may not be guaranteed currently, but I'm suggesting it should
> be as part of the global profile. The value of the global profile
> should be to restrict implementation options as much as reasonable, so
> it becomes as easy as possible to understand and implement. What
> is the
> real value of allowing flexibility at the directory level, or for the
> base URL? Performance optimization is the only reason that really
> makes
> sense, and performance optimization is more of a problem within a
> TileSet than between TileSets. Take a look at the GM client - no two
> adjacent tiles are stored on the same server - so if performance is an
> issue we should be allowing freedom for the whole naming convention,
> which the current spec doesn't support.
>
> OK, here's an alternative that offers more flexibility and at the same
> time permits optimal standardization. Instead of specifying the
> global
> profile in the spec, we could just include a reference to a URN. The
> URN identifies the profile which contains the directory and file
> naming
> convention. The current spec has examples that deal with directory
> and
> file naming conventions, and these can be used to create the first
> profiles. A profile is a generalized version of what we currently
> identify as the TileMap document. Other profiles get put forward as
> needed to optimize performance in different ways - through different
> naming conventions, tile sizes, hosting strategies or whatever.
>
> Or, door number three, have third parties create and publish their own
> profiles that implement the spec in some rigid way.
>
> I favour the first option.
>
> Cheers, Peter.
>
>
> -----Original Message-----
> From: tiling-bounces at lists.eogeo.org
> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
> Sent: Wednesday, November 01, 2006 2:26 PM
> To: Chris Holmes
> Cc: tiling at lists.eogeo.org
> Subject: Re: [tiling] Global profile
>
> I take it back, it is not a super duper simplification, it only
> *appears* to be based on some of the examples in the specification.
>
> The idea that it is simple flows from the idea that you reference
> your at a base directory-like URL, and that the
> is itself a directory-like URL, and that the s are
> directories under that.
>
> That is not guaranteed, not even at the highest level.
>
> If the references a then the fact that it is global-
> profile 1 is not useful to the client, even if the
> directory endings are standardized. The client will still have to
> parse the tilemap.xml file
>
> * to figure out where those standardized tileset directories reside
> and
> * to figure out which of the standard resolutions exist.
>
> In some respects the whole global-profile flag is redundant, all that
> is needed is the implementation advice, since the client will have to
> parse enough information just to operate that it can figure out
> whether the service is a global profile or not ("hm, its 4326, the
> resolutions are standard, yep, it's a global profile").
>
> Paul
>
> On 1-Nov-06, at 11:09 AM, Chris Holmes wrote:
>
>> I like it too, good to make things as easy as possible for clients
>> to implement. And I can't think of implementation issues on the
>> server side that would make this difficult.
>>
>> Sean Gillies wrote:
>>> It's pragmatic. I like it.
>>> Sean
>>> Paul Ramsey wrote:
>>>> Hm. I guess I'm OK with this, despite the added watering down of
>>>> the RESTfulness :) Anyone have any objections?
>>>>
>>>> P
>>>>
>>>> On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
>>>>
>>>>> I really like this spec - it offers a good balance between
>>>>> flexibility
>>>>> and standardization, and I love the RESTful approach.
>>>>>
>>>>> In order to make it really simple to code clients for the global
>>>>> profile, I think it would help if the global profile also
>>>>> standardized
>>>>> the tileset directory names. This would free the global client
>>>>> from
>>>>> having to parse the contents of the TileMap document, because
>>>>> the base
>>>>> URL is all that it would need to know in order to display any
>>>>> compliant
>>>>> layer inside the current view. It also makes it easy for the
>>>>> client to
>>>>> calculate what tiles are needed when zooming in or out, without
>>>>> having
>>>>> to resort to a lookup table containing the TileSet information.
>>>>>
>>>>> The directory names could be the same as the factor "n" used in
>>>>> the
>>>>> units-per-pixel calculation. I.e.:
>>>>>
>>>>> >>>> order="0" />
>>>>> >>>> order="1" />
>>>>> >>>> order="2" />
>>>> _______________________________________________
>>>> 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
>>> !DSPAM:1003,4548ee53210807785049143!
>>
>> --
>> Chris Holmes
>> The Open Planning Project
>> http://topp.openplans.org
>>
>> _______________________________________________
>> 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
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From SCHUTP at AGR.GC.CA Thu Nov 2 06:18:19 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Thu, 2 Nov 2006 09:18:19 -0500
Subject: [tiling] Global profile
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
I agree that it would make no sense to insist that all tile sets
complying to the global profile must have complete global content. It
would also be foolish to insist that images must be available to a
certain resolution, because that probably wouldn't leave any compliant
datasets. However, just because we mandate the naming convention to any
level, it doesn't follow that every tile must be present. Instead, we
should exploit the fact that servers will return a 404 Not Found if an
image is not available for an expected tile set, and configure the
client to display a standard image for every missing image. That way we
can have a completely standard hierarchy and naming convention, but
nobody has to populate it completely - not even within any particular
tile set.
In order to support zooming from the earth view, we should insist that
for every tile image that exists, all equivalent smaller scale images in
the profile must also exist (with transparency for missing pieces).
OK, OK, WRT increasing the restfulness, I won't tempt you... but it
would be possible!
Cheers, Peter.
-----Original Message-----
From: tiling-bounces at lists.eogeo.org
[mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
Sent: Wednesday, November 01, 2006 4:15 PM
To: Schut, Peter
Cc: tiling at lists.eogeo.org
Subject: Re: [tiling] Global profile
It is about more than tile location placing, there is also the issue
of the existence of any particular tile set. Even if one was so bold
as to say "all global profiles must be global" and mandate that they
have tilesets from the earth view on down, one would have to be very
bold indeed to mandate exactly how far down they do go. And if you
don't mandate it, the client will have to figure it out by parsing
the and once they are doing that anyways, there is no harm
in having arbitrary directory names.
On the subject of providing even *more* configurability wrt the
contents of s, please, don't tempt me, I dislike the current
arbitrariness of saying "and from here on, do it just this way", it
is not in keeping with the restfullness of the remaining parts of the
spec.
P
On 1-Nov-06, at 12:08 PM, Schut, Peter wrote:
> Paul, it may not be guaranteed currently, but I'm suggesting it should
> be as part of the global profile. The value of the global profile
> should be to restrict implementation options as much as reasonable, so
> it becomes as easy as possible to understand and implement. What
> is the
> real value of allowing flexibility at the directory level, or for the
> base URL? Performance optimization is the only reason that really
> makes
> sense, and performance optimization is more of a problem within a
> TileSet than between TileSets. Take a look at the GM client - no two
> adjacent tiles are stored on the same server - so if performance is an
> issue we should be allowing freedom for the whole naming convention,
> which the current spec doesn't support.
>
> OK, here's an alternative that offers more flexibility and at the same
> time permits optimal standardization. Instead of specifying the
> global
> profile in the spec, we could just include a reference to a URN. The
> URN identifies the profile which contains the directory and file
> naming
> convention. The current spec has examples that deal with directory
> and
> file naming conventions, and these can be used to create the first
> profiles. A profile is a generalized version of what we currently
> identify as the TileMap document. Other profiles get put forward as
> needed to optimize performance in different ways - through different
> naming conventions, tile sizes, hosting strategies or whatever.
>
> Or, door number three, have third parties create and publish their own
> profiles that implement the spec in some rigid way.
>
> I favour the first option.
>
> Cheers, Peter.
>
>
> -----Original Message-----
> From: tiling-bounces at lists.eogeo.org
> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
> Sent: Wednesday, November 01, 2006 2:26 PM
> To: Chris Holmes
> Cc: tiling at lists.eogeo.org
> Subject: Re: [tiling] Global profile
>
> I take it back, it is not a super duper simplification, it only
> *appears* to be based on some of the examples in the specification.
>
> The idea that it is simple flows from the idea that you reference
> your at a base directory-like URL, and that the
> is itself a directory-like URL, and that the s are
> directories under that.
>
> That is not guaranteed, not even at the highest level.
>
> If the references a then the fact that it is global-
> profile 1 is not useful to the client, even if the
> directory endings are standardized. The client will still have to
> parse the tilemap.xml file
>
> * to figure out where those standardized tileset directories reside
> and
> * to figure out which of the standard resolutions exist.
>
> In some respects the whole global-profile flag is redundant, all that
> is needed is the implementation advice, since the client will have to
> parse enough information just to operate that it can figure out
> whether the service is a global profile or not ("hm, its 4326, the
> resolutions are standard, yep, it's a global profile").
>
> Paul
>
> On 1-Nov-06, at 11:09 AM, Chris Holmes wrote:
>
>> I like it too, good to make things as easy as possible for clients
>> to implement. And I can't think of implementation issues on the
>> server side that would make this difficult.
>>
>> Sean Gillies wrote:
>>> It's pragmatic. I like it.
>>> Sean
>>> Paul Ramsey wrote:
>>>> Hm. I guess I'm OK with this, despite the added watering down of
>>>> the RESTfulness :) Anyone have any objections?
>>>>
>>>> P
>>>>
>>>> On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
>>>>
>>>>> I really like this spec - it offers a good balance between
>>>>> flexibility
>>>>> and standardization, and I love the RESTful approach.
>>>>>
>>>>> In order to make it really simple to code clients for the global
>>>>> profile, I think it would help if the global profile also
>>>>> standardized
>>>>> the tileset directory names. This would free the global client
>>>>> from
>>>>> having to parse the contents of the TileMap document, because
>>>>> the base
>>>>> URL is all that it would need to know in order to display any
>>>>> compliant
>>>>> layer inside the current view. It also makes it easy for the
>>>>> client to
>>>>> calculate what tiles are needed when zooming in or out, without
>>>>> having
>>>>> to resort to a lookup table containing the TileSet information.
>>>>>
>>>>> The directory names could be the same as the factor "n" used in
>>>>> the
>>>>> units-per-pixel calculation. I.e.:
>>>>>
>>>>> >>>> order="0" />
>>>>> >>>> order="1" />
>>>>> >>>> order="2" />
>>>> _______________________________________________
>>>> 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
>>> !DSPAM:1003,4548ee53210807785049143!
>>
>> --
>> Chris Holmes
>> The Open Planning Project
>> http://topp.openplans.org
>>
>> _______________________________________________
>> 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
> _______________________________________________
> 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
From pramsey at refractions.net Thu Nov 2 08:12:33 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Thu, 2 Nov 2006 08:12:33 -0800
Subject: [tiling] Global profile
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
Message-ID: <2B5462A7-98D3-44C0-AEBC-5D4B78795E62@refractions.net>
OK, I you've talked me down from my ledge Peter. Anyone else up there?
P
On 2-Nov-06, at 6:18 AM, Schut, Peter wrote:
> I agree that it would make no sense to insist that all tile sets
> complying to the global profile must have complete global content. It
> would also be foolish to insist that images must be available to a
> certain resolution, because that probably wouldn't leave any compliant
> datasets. However, just because we mandate the naming convention
> to any
> level, it doesn't follow that every tile must be present. Instead, we
> should exploit the fact that servers will return a 404 Not Found if an
> image is not available for an expected tile set, and configure the
> client to display a standard image for every missing image. That
> way we
> can have a completely standard hierarchy and naming convention, but
> nobody has to populate it completely - not even within any particular
> tile set.
>
> In order to support zooming from the earth view, we should insist that
> for every tile image that exists, all equivalent smaller scale
> images in
> the profile must also exist (with transparency for missing pieces).
>
> OK, OK, WRT increasing the restfulness, I won't tempt you... but it
> would be possible!
>
> Cheers, Peter.
>
>
> -----Original Message-----
> From: tiling-bounces at lists.eogeo.org
> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
> Sent: Wednesday, November 01, 2006 4:15 PM
> To: Schut, Peter
> Cc: tiling at lists.eogeo.org
> Subject: Re: [tiling] Global profile
>
> It is about more than tile location placing, there is also the issue
> of the existence of any particular tile set. Even if one was so bold
> as to say "all global profiles must be global" and mandate that they
> have tilesets from the earth view on down, one would have to be very
> bold indeed to mandate exactly how far down they do go. And if you
> don't mandate it, the client will have to figure it out by parsing
> the and once they are doing that anyways, there is no harm
> in having arbitrary directory names.
>
> On the subject of providing even *more* configurability wrt the
> contents of s, please, don't tempt me, I dislike the current
> arbitrariness of saying "and from here on, do it just this way", it
> is not in keeping with the restfullness of the remaining parts of the
> spec.
>
> P
>
> On 1-Nov-06, at 12:08 PM, Schut, Peter wrote:
>
>> Paul, it may not be guaranteed currently, but I'm suggesting it
>> should
>> be as part of the global profile. The value of the global profile
>> should be to restrict implementation options as much as
>> reasonable, so
>> it becomes as easy as possible to understand and implement. What
>> is the
>> real value of allowing flexibility at the directory level, or for the
>> base URL? Performance optimization is the only reason that really
>> makes
>> sense, and performance optimization is more of a problem within a
>> TileSet than between TileSets. Take a look at the GM client - no two
>> adjacent tiles are stored on the same server - so if performance
>> is an
>> issue we should be allowing freedom for the whole naming convention,
>> which the current spec doesn't support.
>>
>> OK, here's an alternative that offers more flexibility and at the
>> same
>> time permits optimal standardization. Instead of specifying the
>> global
>> profile in the spec, we could just include a reference to a URN. The
>> URN identifies the profile which contains the directory and file
>> naming
>> convention. The current spec has examples that deal with directory
>> and
>> file naming conventions, and these can be used to create the first
>> profiles. A profile is a generalized version of what we currently
>> identify as the TileMap document. Other profiles get put forward as
>> needed to optimize performance in different ways - through different
>> naming conventions, tile sizes, hosting strategies or whatever.
>>
>> Or, door number three, have third parties create and publish their
>> own
>> profiles that implement the spec in some rigid way.
>>
>> I favour the first option.
>>
>> Cheers, Peter.
>>
>>
>> -----Original Message-----
>> From: tiling-bounces at lists.eogeo.org
>> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
>> Sent: Wednesday, November 01, 2006 2:26 PM
>> To: Chris Holmes
>> Cc: tiling at lists.eogeo.org
>> Subject: Re: [tiling] Global profile
>>
>> I take it back, it is not a super duper simplification, it only
>> *appears* to be based on some of the examples in the specification.
>>
>> The idea that it is simple flows from the idea that you reference
>> your at a base directory-like URL, and that the
>> is itself a directory-like URL, and that the s are
>> directories under that.
>>
>> That is not guaranteed, not even at the highest level.
>>
>> If the references a then the fact that it is global-
>> profile 1 is not useful to the client, even if the
>> directory endings are standardized. The client will still have to
>> parse the tilemap.xml file
>>
>> * to figure out where those standardized tileset directories reside
>> and
>> * to figure out which of the standard resolutions exist.
>>
>> In some respects the whole global-profile flag is redundant, all that
>> is needed is the implementation advice, since the client will have to
>> parse enough information just to operate that it can figure out
>> whether the service is a global profile or not ("hm, its 4326, the
>> resolutions are standard, yep, it's a global profile").
>>
>> Paul
>>
>> On 1-Nov-06, at 11:09 AM, Chris Holmes wrote:
>>
>>> I like it too, good to make things as easy as possible for clients
>>> to implement. And I can't think of implementation issues on the
>>> server side that would make this difficult.
>>>
>>> Sean Gillies wrote:
>>>> It's pragmatic. I like it.
>>>> Sean
>>>> Paul Ramsey wrote:
>>>>> Hm. I guess I'm OK with this, despite the added watering down of
>>>>> the RESTfulness :) Anyone have any objections?
>>>>>
>>>>> P
>>>>>
>>>>> On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
>>>>>
>>>>>> I really like this spec - it offers a good balance between
>>>>>> flexibility
>>>>>> and standardization, and I love the RESTful approach.
>>>>>>
>>>>>> In order to make it really simple to code clients for the global
>>>>>> profile, I think it would help if the global profile also
>>>>>> standardized
>>>>>> the tileset directory names. This would free the global client
>>>>>> from
>>>>>> having to parse the contents of the TileMap document, because
>>>>>> the base
>>>>>> URL is all that it would need to know in order to display any
>>>>>> compliant
>>>>>> layer inside the current view. It also makes it easy for the
>>>>>> client to
>>>>>> calculate what tiles are needed when zooming in or out, without
>>>>>> having
>>>>>> to resort to a lookup table containing the TileSet information.
>>>>>>
>>>>>> The directory names could be the same as the factor "n" used in
>>>>>> the
>>>>>> units-per-pixel calculation. I.e.:
>>>>>>
>>>>>> >>>>> order="0" />
>>>>>> >>>>> order="1" />
>>>>>> >>>>> order="2" />
>>>>> _______________________________________________
>>>>> 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
>>>> !DSPAM:1003,4548ee53210807785049143!
>>>
>>> --
>>> Chris Holmes
>>> The Open Planning Project
>>> http://topp.openplans.org
>>>
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From adoyle at eogeo.org Thu Nov 2 11:01:24 2006
From: adoyle at eogeo.org (Allan Doyle)
Date: Thu, 2 Nov 2006 14:01:24 -0500
Subject: [tiling] Global profile
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
Message-ID: <1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
On Nov 2, 2006, at 09:18, Schut, Peter wrote:
> I agree that it would make no sense to insist that all tile sets
> complying to the global profile must have complete global content. It
> would also be foolish to insist that images must be available to a
> certain resolution, because that probably wouldn't leave any compliant
> datasets. However, just because we mandate the naming convention
> to any
> level, it doesn't follow that every tile must be present. Instead, we
> should exploit the fact that servers will return a 404 Not Found if an
> image is not available for an expected tile set, and configure the
> client to display a standard image for every missing image. That
> way we
> can have a completely standard hierarchy and naming convention, but
> nobody has to populate it completely - not even within any particular
> tile set.
>
> In order to support zooming from the earth view, we should insist that
> for every tile image that exists, all equivalent smaller scale
> images in
> the profile must also exist (with transparency for missing pieces).
I think getting back a transparent response might give the impression
that the server actually had content. 404 is more descriptive and
might suggest to a client that it go elsewhere for that tile. I think
a deliberately blank tile with a "200 Success" response violates the
Principle of Least Astonishment.
[http://en.wikipedia.org/wiki/Principle_of_least_astonishment]
Allan
>
> OK, OK, WRT increasing the restfulness, I won't tempt you... but it
> would be possible!
>
> Cheers, Peter.
>
>
> -----Original Message-----
> From: tiling-bounces at lists.eogeo.org
> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
> Sent: Wednesday, November 01, 2006 4:15 PM
> To: Schut, Peter
> Cc: tiling at lists.eogeo.org
> Subject: Re: [tiling] Global profile
>
> It is about more than tile location placing, there is also the issue
> of the existence of any particular tile set. Even if one was so bold
> as to say "all global profiles must be global" and mandate that they
> have tilesets from the earth view on down, one would have to be very
> bold indeed to mandate exactly how far down they do go. And if you
> don't mandate it, the client will have to figure it out by parsing
> the and once they are doing that anyways, there is no harm
> in having arbitrary directory names.
>
> On the subject of providing even *more* configurability wrt the
> contents of s, please, don't tempt me, I dislike the current
> arbitrariness of saying "and from here on, do it just this way", it
> is not in keeping with the restfullness of the remaining parts of the
> spec.
>
> P
>
> On 1-Nov-06, at 12:08 PM, Schut, Peter wrote:
>
>> Paul, it may not be guaranteed currently, but I'm suggesting it
>> should
>> be as part of the global profile. The value of the global profile
>> should be to restrict implementation options as much as
>> reasonable, so
>> it becomes as easy as possible to understand and implement. What
>> is the
>> real value of allowing flexibility at the directory level, or for the
>> base URL? Performance optimization is the only reason that really
>> makes
>> sense, and performance optimization is more of a problem within a
>> TileSet than between TileSets. Take a look at the GM client - no two
>> adjacent tiles are stored on the same server - so if performance
>> is an
>> issue we should be allowing freedom for the whole naming convention,
>> which the current spec doesn't support.
>>
>> OK, here's an alternative that offers more flexibility and at the
>> same
>> time permits optimal standardization. Instead of specifying the
>> global
>> profile in the spec, we could just include a reference to a URN. The
>> URN identifies the profile which contains the directory and file
>> naming
>> convention. The current spec has examples that deal with directory
>> and
>> file naming conventions, and these can be used to create the first
>> profiles. A profile is a generalized version of what we currently
>> identify as the TileMap document. Other profiles get put forward as
>> needed to optimize performance in different ways - through different
>> naming conventions, tile sizes, hosting strategies or whatever.
>>
>> Or, door number three, have third parties create and publish their
>> own
>> profiles that implement the spec in some rigid way.
>>
>> I favour the first option.
>>
>> Cheers, Peter.
>>
>>
>> -----Original Message-----
>> From: tiling-bounces at lists.eogeo.org
>> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
>> Sent: Wednesday, November 01, 2006 2:26 PM
>> To: Chris Holmes
>> Cc: tiling at lists.eogeo.org
>> Subject: Re: [tiling] Global profile
>>
>> I take it back, it is not a super duper simplification, it only
>> *appears* to be based on some of the examples in the specification.
>>
>> The idea that it is simple flows from the idea that you reference
>> your at a base directory-like URL, and that the
>> is itself a directory-like URL, and that the s are
>> directories under that.
>>
>> That is not guaranteed, not even at the highest level.
>>
>> If the references a then the fact that it is global-
>> profile 1 is not useful to the client, even if the
>> directory endings are standardized. The client will still have to
>> parse the tilemap.xml file
>>
>> * to figure out where those standardized tileset directories reside
>> and
>> * to figure out which of the standard resolutions exist.
>>
>> In some respects the whole global-profile flag is redundant, all that
>> is needed is the implementation advice, since the client will have to
>> parse enough information just to operate that it can figure out
>> whether the service is a global profile or not ("hm, its 4326, the
>> resolutions are standard, yep, it's a global profile").
>>
>> Paul
>>
>> On 1-Nov-06, at 11:09 AM, Chris Holmes wrote:
>>
>>> I like it too, good to make things as easy as possible for clients
>>> to implement. And I can't think of implementation issues on the
>>> server side that would make this difficult.
>>>
>>> Sean Gillies wrote:
>>>> It's pragmatic. I like it.
>>>> Sean
>>>> Paul Ramsey wrote:
>>>>> Hm. I guess I'm OK with this, despite the added watering down of
>>>>> the RESTfulness :) Anyone have any objections?
>>>>>
>>>>> P
>>>>>
>>>>> On 1-Nov-06, at 9:56 AM, Schut, Peter wrote:
>>>>>
>>>>>> I really like this spec - it offers a good balance between
>>>>>> flexibility
>>>>>> and standardization, and I love the RESTful approach.
>>>>>>
>>>>>> In order to make it really simple to code clients for the global
>>>>>> profile, I think it would help if the global profile also
>>>>>> standardized
>>>>>> the tileset directory names. This would free the global client
>>>>>> from
>>>>>> having to parse the contents of the TileMap document, because
>>>>>> the base
>>>>>> URL is all that it would need to know in order to display any
>>>>>> compliant
>>>>>> layer inside the current view. It also makes it easy for the
>>>>>> client to
>>>>>> calculate what tiles are needed when zooming in or out, without
>>>>>> having
>>>>>> to resort to a lookup table containing the TileSet information.
>>>>>>
>>>>>> The directory names could be the same as the factor "n" used in
>>>>>> the
>>>>>> units-per-pixel calculation. I.e.:
>>>>>>
>>>>>> >>>>> order="0" />
>>>>>> >>>>> order="1" />
>>>>>> >>>>> order="2" />
>>>>> _______________________________________________
>>>>> 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
>>>> !DSPAM:1003,4548ee53210807785049143!
>>>
>>> --
>>> Chris Holmes
>>> The Open Planning Project
>>> http://topp.openplans.org
>>>
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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 jb-tiling at jasonbirch.com Thu Nov 2 17:38:26 2006
From: jb-tiling at jasonbirch.com (Jason Birch)
Date: Thu, 02 Nov 2006 17:38:26 -0800
Subject: [tiling] Global profile
In-Reply-To: <1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
<1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
Message-ID: <454A9D92.9020508@jasonbirch.com>
I'm really having mail problems today. First I send direct to Allan,
then I send from an address that's not on the list.
Allan Doyle wrote:
> I think getting back a transparent response might give the impression
> that the server actually had content. 404 is more descriptive and
> might suggest to a client that it go elsewhere for that tile. I think
> a deliberately blank tile with a "200 Success" response violates the
> Principle of Least Astonishment.
I think that this makes sense.
Also, in general I think that a larger portion of standard HTTP should
be encouraged in the implementation section.
For instance, do we only support the GET method/verb? Is there a case
for allowing HEAD requests for indexing (determining existence) and
chained caches (freshness). How about PUT and DELETE (with HTTP auth of
course) to allow for external data maintenance?
And for cacheing should we encourage sending Last-Modified and ETag, and
responding to GET or HEAD requests which include If-Modified-Since and
If-None-Match with "304 Not Modified" where appropriate?
On a different note... I understand that the current concept of a
global profile is targeted more towards global datasets (duh), and that
where possible you would want to make the directory structure
"guessable". However, this makes it difficult for limited area large
scale base maps to participate in the global profile.
For instance, if I want to implement TMS global profile for the City of
Nanaimo's basemap:
- Do I have to include definitions of orders 0..(n-1) where n is the
order of the large-scale base map that I'm providing?
- Can I just return 404 for everything other than the orders that I support?
- Is there some way for me to specify the bounding box for my data
within a global profile so that I don't end up having to serve 404's
99.9999999% of the time? If the "guessable" structure is promoted, then
this won't be effective.
Jason
From pramsey at refractions.net Thu Nov 2 20:40:24 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Thu, 2 Nov 2006 20:40:24 -0800
Subject: [tiling] Global profile
In-Reply-To: <454A9D92.9020508@jasonbirch.com>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
<1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
<454A9D92.9020508@jasonbirch.com>
Message-ID: <69F32FE9-B3CE-4D1A-9D75-4D9138BE1B15@refractions.net>
Thanks Jason, I'm back up on the ledge.
The ostensible reason for this "simplification" is to allow clients
to avoid having to parse the , but since they have to parse
the anyways, I am not clear on how much simplicity I
am adding. Chris Schmidt, weigh in here, the current draft doesn't
require rocket science on the part of client implementors...
I'm getting close to declaring completion unless someone knocks some
of my teeth out here soon.
P
On 2-Nov-06, at 5:38 PM, Jason Birch wrote:
> For instance, if I want to implement TMS global profile for the
> City of
> Nanaimo's basemap:
>
> - Do I have to include definitions of orders 0..(n-1) where n is the
> order of the large-scale base map that I'm providing?
>
> - Can I just return 404 for everything other than the orders that I
> support?
>
> - Is there some way for me to specify the bounding box for my data
> within a global profile so that I don't end up having to serve 404's
> 99.9999999% of the time? If the "guessable" structure is promoted,
> then
> this won't be effective.
From pramsey at refractions.net Thu Nov 2 20:44:14 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Thu, 2 Nov 2006 20:44:14 -0800
Subject: [tiling] Global profile
In-Reply-To: <69F32FE9-B3CE-4D1A-9D75-4D9138BE1B15@refractions.net>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
<1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
<454A9D92.9020508@jasonbirch.com>
<69F32FE9-B3CE-4D1A-9D75-4D9138BE1B15@refractions.net>
Message-ID: <29804D5A-43BD-4AC3-96AD-B5AC27FAB951@refractions.net>
Hey, speaking of Chris Schmidt, I seem to recall someone saying that
he could have a client up and running in ... was it 30 minutes? ...
given a draft and a reference implementation ...
Draft is up, reference implementation is up ... please, don't make me
beg, it's unseemly :)
P
On 2-Nov-06, at 8:40 PM, Paul Ramsey wrote:
> Thanks Jason, I'm back up on the ledge.
> The ostensible reason for this "simplification" is to allow clients
> to avoid having to parse the , but since they have to parse
> the anyways, I am not clear on how much simplicity I
> am adding. Chris Schmidt, weigh in here, the current draft doesn't
> require rocket science on the part of client implementors...
> I'm getting close to declaring completion unless someone knocks some
> of my teeth out here soon.
> P
>
> On 2-Nov-06, at 5:38 PM, Jason Birch wrote:
>
>> For instance, if I want to implement TMS global profile for the
>> City of
>> Nanaimo's basemap:
>>
>> - Do I have to include definitions of orders 0..(n-1) where n is the
>> order of the large-scale base map that I'm providing?
>>
>> - Can I just return 404 for everything other than the orders that I
>> support?
>>
>> - Is there some way for me to specify the bounding box for my data
>> within a global profile so that I don't end up having to serve 404's
>> 99.9999999% of the time? If the "guessable" structure is promoted,
>> then
>> this won't be effective.
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From stein at geofusion.com Thu Nov 2 20:54:31 2006
From: stein at geofusion.com (Chuck Stein)
Date: Thu, 2 Nov 2006 20:54:31 -0800
Subject: [tiling] Global profile
In-Reply-To: <454A9D92.9020508@jasonbirch.com>
Message-ID: <01d801c6ff04$2bdb4420$d1a63e05@lapchuck>
I would also like to know, what is the facility for specifying a non-global
dataset? Is it a bounding box, polygon, or polygon list (islanded dataset)?
This way the client can ask for tiles it knows exist.
Thanks,
Chuck
From pramsey at refractions.net Thu Nov 2 20:59:57 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Thu, 2 Nov 2006 20:59:57 -0800
Subject: [tiling] Global profile
In-Reply-To: <01d801c6ff04$2bdb4420$d1a63e05@lapchuck>
References: <01d801c6ff04$2bdb4420$d1a63e05@lapchuck>
Message-ID: <7658A9E5-5DB0-45B9-8A1B-8E4B934432FC@refractions.net>
As specified now, it's a bounding box. The says where the
tile space lower left is and the describes the data
extent. NVine suggested something more flexible, like a polygon, but
that pushes back some geoprocessing requirements on the client.
If a polygon data extent was added, what would the client use it
for? What clients would use it?
On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
> I would also like to know, what is the facility for specifying a
> non-global
> dataset? Is it a bounding box, polygon, or polygon list (islanded
> dataset)?
> This way the client can ask for tiles it knows exist.
>
> Thanks,
>
> Chuck
>
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From stein at geofusion.com Thu Nov 2 21:09:00 2006
From: stein at geofusion.com (Chuck Stein)
Date: Thu, 2 Nov 2006 21:09:00 -0800
Subject: [tiling] Global profile
In-Reply-To: <7658A9E5-5DB0-45B9-8A1B-8E4B934432FC@refractions.net>
Message-ID: <01e001c6ff06$31f0a920$d1a63e05@lapchuck>
A smart client could request tiles only inside the polygons. Our datasets
have a quadtree type database (very small) that allows the client to know
exactly what tiles exist. This file is downloaded first. With your system,
given a polygon description (or multiple polygons for islanded data) a
client could create the quadtree (or similar) to know what tiles to request.
I am thinking of 3D (2.5) earth visualization, not flat maps. A smart
client wants to manage any number of datasets and not spend time requesting
tiles that don't exist.
Chuck
-----Original Message-----
From: Paul Ramsey [mailto:pramsey at refractions.net]
Sent: Thursday, November 02, 2006 9:00 PM
To: stein at geofusion.com
Cc: tiling at lists.eogeo.org
Subject: Re: [tiling] Global profile
As specified now, it's a bounding box. The says where the
tile space lower left is and the describes the data
extent. NVine suggested something more flexible, like a polygon, but
that pushes back some geoprocessing requirements on the client. If a polygon
data extent was added, what would the client use it
for? What clients would use it?
On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
> I would also like to know, what is the facility for specifying a
> non-global
> dataset? Is it a bounding box, polygon, or polygon list (islanded
> dataset)?
> This way the client can ask for tiles it knows exist.
>
> Thanks,
>
> Chuck
>
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org http://lists.eogeo.org/mailman/listinfo/tiling
From pramsey at refractions.net Thu Nov 2 21:29:08 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Thu, 2 Nov 2006 21:29:08 -0800
Subject: [tiling] Global profile
In-Reply-To: <01e001c6ff06$31f0a920$d1a63e05@lapchuck>
References: <01e001c6ff06$31f0a920$d1a63e05@lapchuck>
Message-ID:
Sounds reasonable. Any other spherical people here who want this? I
am thinking optional parameter, with a WKT
representation inside. Yes, I am that primitive. I have been known
to spend hours just beating rocks together. It's fun.
P
On 2-Nov-06, at 9:09 PM, Chuck Stein wrote:
> A smart client could request tiles only inside the polygons. Our
> datasets
> have a quadtree type database (very small) that allows the client
> to know
> exactly what tiles exist. This file is downloaded first. With
> your system,
> given a polygon description (or multiple polygons for islanded data) a
> client could create the quadtree (or similar) to know what tiles to
> request.
> I am thinking of 3D (2.5) earth visualization, not flat maps. A smart
> client wants to manage any number of datasets and not spend time
> requesting
> tiles that don't exist.
>
> Chuck
>
> -----Original Message-----
> From: Paul Ramsey [mailto:pramsey at refractions.net]
> Sent: Thursday, November 02, 2006 9:00 PM
> To: stein at geofusion.com
> Cc: tiling at lists.eogeo.org
> Subject: Re: [tiling] Global profile
>
>
> As specified now, it's a bounding box. The says where the
> tile space lower left is and the describes the data
> extent. NVine suggested something more flexible, like a polygon, but
> that pushes back some geoprocessing requirements on the client. If
> a polygon
> data extent was added, what would the client use it
> for? What clients would use it?
>
> On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
>
>> I would also like to know, what is the facility for specifying a
>> non-global
>> dataset? Is it a bounding box, polygon, or polygon list (islanded
>> dataset)?
>> This way the client can ask for tiles it knows exist.
>>
>> Thanks,
>>
>> Chuck
>>
>>
>> _______________________________________________
>> 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
From crschmidt at crschmidt.net Fri Nov 3 02:43:25 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Fri, 3 Nov 2006 05:43:25 -0500
Subject: [tiling] Global profile
In-Reply-To: <69F32FE9-B3CE-4D1A-9D75-4D9138BE1B15@refractions.net>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
<1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
<454A9D92.9020508@jasonbirch.com>
<69F32FE9-B3CE-4D1A-9D75-4D9138BE1B15@refractions.net>
Message-ID: <20061103104325.GC30315@crschmidt.net>
On Thu, Nov 02, 2006 at 08:40:24PM -0800, Paul Ramsey wrote:
> Thanks Jason, I'm back up on the ledge.
> The ostensible reason for this "simplification" is to allow clients
> to avoid having to parse the , but since they have to parse
> the anyways, I am not clear on how much simplicity I
> am adding.
As an OpenLayers user, what will happen is that any information which is
specified in the service description has to be copied by hand into the
OpenLayers Javascript. Even if we also implement a loading function, it
doesn't help in many cases where the user doesn't have a server-side
component to set up a proxy.
So, the most common OpenLayers user will look at output of your
specification, then copy each piece of information into some data
structure in OpenLayers. Consider that, and then decide how to proceed.
If adding additional information to the description is not going to make
the copying process more ardurous, I'm typically in favor. If it is, I'm
usually not -- every piece of infrmation which can't be automatically
determined from some other piece is something that a user could typo.
Regards,
--
Christopher Schmidt
Web Developer
From crschmidt at crschmidt.net Fri Nov 3 02:44:07 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Fri, 3 Nov 2006 05:44:07 -0500
Subject: [tiling] Global profile
In-Reply-To: <29804D5A-43BD-4AC3-96AD-B5AC27FAB951@refractions.net>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
<1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
<454A9D92.9020508@jasonbirch.com>
<69F32FE9-B3CE-4D1A-9D75-4D9138BE1B15@refractions.net>
<29804D5A-43BD-4AC3-96AD-B5AC27FAB951@refractions.net>
Message-ID: <20061103104407.GD30315@crschmidt.net>
On Thu, Nov 02, 2006 at 08:44:14PM -0800, Paul Ramsey wrote:
> Hey, speaking of Chris Schmidt, I seem to recall someone saying that
> he could have a client up and running in ... was it 30 minutes? ...
> given a draft and a reference implementation ...
>
> Draft is up, reference implementation is up ... please, don't make me
> beg, it's unseemly :)
I haven't seen a reference implementation URL which is serving actual
data. Can you point to some URLs?
Regards,
--
Christopher Schmidt
Web Developer
From BFLOOD at SPATIALDATALOGIC.COM Fri Nov 3 05:20:11 2006
From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood)
Date: Fri, 3 Nov 2006 08:20:11 -0500
Subject: [tiling] Global profile
In-Reply-To: <7658A9E5-5DB0-45B9-8A1B-8E4B934432FC@refractions.net>
Message-ID: <534364EA05A4824790821002CAD4570A02174D@s25.local.spatialdatalogic.com>
hi all
no questions, just echoing some of the other comments so far
Global profile - I think you should just have to conform to the spec
with no regard to how much of the data levels are filled in. The
BoundingBox (and optional poly) will specify the areas that are complete
404 - I agree with Allen, you should return 404 errors instead of a
transparent tiles. This works better for static storage (like S3) where
you don't have any scripting abilities. Clearly you could front end it
with a web server but it would be nice to just work directly against
static files.
Bounding polygon - as an optional parameter, this sounds like a good
idea, especially for "overlay" tile layers that might contains lots of
transparent areas. then again, this only works efficiently if those
areas are large and relatively simple. I can imagine the huge multipart
polygons describing every little area of transparency, that would be a
nightmare.
Origin - does the origin describe the lowerleft of your data or the
lowerleft of the coordinate space?
getting close to posting some example datasets out of ArcMap
cheers
brian
-----Original Message-----
From: tiling-bounces at lists.eogeo.org
[mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
Sent: Friday, November 03, 2006 12:00 AM
To: stein at geofusion.com
Cc: tiling at lists.eogeo.org
Subject: Re: [tiling] Global profile
As specified now, it's a bounding box. The says where the
tile space lower left is and the describes the data
extent. NVine suggested something more flexible, like a polygon, but
that pushes back some geoprocessing requirements on the client.
If a polygon data extent was added, what would the client use it
for? What clients would use it?
On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
> I would also like to know, what is the facility for specifying a
> non-global
> dataset? Is it a bounding box, polygon, or polygon list (islanded
> dataset)?
> This way the client can ask for tiles it knows exist.
>
> Thanks,
>
> Chuck
>
>
> _______________________________________________
> 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
From pspencer at dmsolutions.ca Fri Nov 3 05:27:31 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri, 3 Nov 2006 08:27:31 -0500
Subject: [tiling] Global profile
In-Reply-To: <534364EA05A4824790821002CAD4570A02174D@s25.local.spatialdatalogic.com>
References: <534364EA05A4824790821002CAD4570A02174D@s25.local.spatialdatalogic.com>
Message-ID: <8788E614-6F32-4E2A-9FAD-2FDE4D1FF2B5@dmsolutions.ca>
If I understand things correctly, you can return a 404 error AND a
transparent image. 404 is just the status code. The error page can
also have content, which it normally does - and the content is HTML.
Paul
On 3-Nov-06, at 8:20 AM, Brian Flood wrote:
> 404 - I agree with Allen, you should return 404 errors instead of a
> transparent tiles. This works better for static storage (like S3)
> where
> you don't have any scripting abilities. Clearly you could front end it
> with a web server but it would be nice to just work directly against
> static files.
+-----------------------------------------------------------------+
|Paul Spencer pspencer at dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From adoyle at eogeo.org Fri Nov 3 05:39:55 2006
From: adoyle at eogeo.org (Allan Doyle)
Date: Fri, 3 Nov 2006 08:39:55 -0500
Subject: [tiling] Global profile
In-Reply-To: <8788E614-6F32-4E2A-9FAD-2FDE4D1FF2B5@dmsolutions.ca>
References: <534364EA05A4824790821002CAD4570A02174D@s25.local.spatialdatalogic.com>
<8788E614-6F32-4E2A-9FAD-2FDE4D1FF2B5@dmsolutions.ca>
Message-ID:
I think Brian is on to something. Ideally you should be able to build
a "server" out of static web pages. That sounds to me like a very
important and useful constraint.
If there are options that can be handled by "active" services (i.e.
CGI or other code), then that's ok, but make them optional.
Allan
On Nov 3, 2006, at 08:27, Paul Spencer wrote:
> If I understand things correctly, you can return a 404 error AND a
> transparent image. 404 is just the status code. The error page can
> also have content, which it normally does - and the content is HTML.
>
> Paul
>
> On 3-Nov-06, at 8:20 AM, Brian Flood wrote:
>
>> 404 - I agree with Allen, you should return 404 errors instead of a
>> transparent tiles. This works better for static storage (like S3)
>> where
>> you don't have any scripting abilities. Clearly you could front
>> end it
>> with a web server but it would be nice to just work directly against
>> static files.
>
> +-----------------------------------------------------------------+
> |Paul Spencer pspencer at dmsolutions.ca |
> +-----------------------------------------------------------------+
> |Chief Technology Officer |
> |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 pedro.goncalves at terradue.com Fri Nov 3 06:02:48 2006
From: pedro.goncalves at terradue.com (Pedro Goncalves)
Date: Fri, 3 Nov 2006 15:02:48 +0100
Subject: [tiling] Global profile
In-Reply-To:
References: <534364EA05A4824790821002CAD4570A02174D@s25.local.spatialdatalogic.com>
<8788E614-6F32-4E2A-9FAD-2FDE4D1FF2B5@dmsolutions.ca>
Message-ID: <36B5BAD4-FB14-4283-A4A8-76F12A54810C@terradue.com>
... and those "static" servers will deal automatically with all the
'if-modified' type queries (304, "HEAD" ...and so on ) ..
So I think Allan is right .. the big litmus test to our candidate is
the ability to be retrieved by static web pages, all other fancy
things should be optional and be handled by CGI-like scripts
pedro
On Nov 3, 2006, at 2:39 PM, Allan Doyle wrote:
> I think Brian is on to something. Ideally you should be able to build
> a "server" out of static web pages. That sounds to me like a very
> important and useful constraint.
>
> If there are options that can be handled by "active" services (i.e.
> CGI or other code), then that's ok, but make them optional.
>
> Allan
>
> On Nov 3, 2006, at 08:27, Paul Spencer wrote:
>
>> If I understand things correctly, you can return a 404 error AND a
>> transparent image. 404 is just the status code. The error page can
>> also have content, which it normally does - and the content is HTML.
>>
>> Paul
>>
>> On 3-Nov-06, at 8:20 AM, Brian Flood wrote:
>>
>>> 404 - I agree with Allen, you should return 404 errors instead of a
>>> transparent tiles. This works better for static storage (like S3)
>>> where
>>> you don't have any scripting abilities. Clearly you could front
>>> end it
>>> with a web server but it would be nice to just work directly against
>>> static files.
>>
>> +-----------------------------------------------------------------+
>> |Paul Spencer pspencer at dmsolutions.ca |
>> +-----------------------------------------------------------------+
>> |Chief Technology Officer |
>> |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
>
>
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061103/35b37f8b/attachment.html
From crschmidt at crschmidt.net Fri Nov 3 06:40:01 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Fri, 3 Nov 2006 09:40:01 -0500
Subject: [tiling] Global profile
In-Reply-To: <20061103104407.GD30315@crschmidt.net>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
<1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
<454A9D92.9020508@jasonbirch.com>
<69F32FE9-B3CE-4D1A-9D75-4D9138BE1B15@refractions.net>
<29804D5A-43BD-4AC3-96AD-B5AC27FAB951@refractions.net>
<20061103104407.GD30315@crschmidt.net>
Message-ID: <20061103144000.GE30315@crschmidt.net>
On Fri, Nov 03, 2006 at 05:44:07AM -0500, Christopher Schmidt wrote:
> On Thu, Nov 02, 2006 at 08:44:14PM -0800, Paul Ramsey wrote:
> > Hey, speaking of Chris Schmidt, I seem to recall someone saying that
> > he could have a client up and running in ... was it 30 minutes? ...
> > given a draft and a reference implementation ...
> >
> > Draft is up, reference implementation is up ... please, don't make me
> > beg, it's unseemly :)
>
> I haven't seen a reference implementation URL which is serving actual
> data. Can you point to some URLs?
Paul pointed me to a URL at 9:07AM -- at 9:23, I had a working
implementation, 9:30, it was checked into SVN and viewable at:
http://dev.openlayers.org/sandbox/crschmidt/refractions/examples/refractions.html
So, 23 minutes. (Go, go, gadget OpenLayers!)
Regards,
--
Christopher Schmidt
Web Developer
From pramsey at refractions.net Fri Nov 3 07:51:01 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 07:51:01 -0800
Subject: [tiling] Global profile
In-Reply-To: <20061103104407.GD30315@crschmidt.net>
References: <783BB96C25B79249A236DF62F559D6A501EE3174@onncrxms3.agr.gc.ca>
<1D7AAE58-DC7E-4B07-BF5E-89BEF5BDCDF9@eogeo.org>
<454A9D92.9020508@jasonbirch.com>
<69F32FE9-B3CE-4D1A-9D75-4D9138BE1B15@refractions.net>
<29804D5A-43BD-4AC3-96AD-B5AC27FAB951@refractions.net>
<20061103104407.GD30315@crschmidt.net>
Message-ID: <2B683616-58F8-4EB2-8FC5-43E201D4E384@refractions.net>
http://mapserver.refractions.net/cgi-bin/tms
That has actual data. It's not *my* data, it's NASA's, but it's still
data.
On 3-Nov-06, at 2:44 AM, Christopher Schmidt wrote:
> On Thu, Nov 02, 2006 at 08:44:14PM -0800, Paul Ramsey wrote:
>> Hey, speaking of Chris Schmidt, I seem to recall someone saying that
>> he could have a client up and running in ... was it 30 minutes? ...
>> given a draft and a reference implementation ...
>>
>> Draft is up, reference implementation is up ... please, don't make me
>> beg, it's unseemly :)
>
> I haven't seen a reference implementation URL which is serving actual
> data. Can you point to some URLs?
>
> Regards,
> --
> Christopher Schmidt
> Web Developer
From pramsey at refractions.net Fri Nov 3 08:00:50 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 08:00:50 -0800
Subject: [tiling] Global profile
In-Reply-To: <36B5BAD4-FB14-4283-A4A8-76F12A54810C@terradue.com>
References: <534364EA05A4824790821002CAD4570A02174D@s25.local.spatialdatalogic.com>
<8788E614-6F32-4E2A-9FAD-2FDE4D1FF2B5@dmsolutions.ca>
<36B5BAD4-FB14-4283-A4A8-76F12A54810C@terradue.com>
Message-ID:
That is my design goal, and has almost from the start. If you see
anything in the spec that you think *cannot* be handled by static
files on a standard web server, let me know.
On 3-Nov-06, at 6:02 AM, Pedro Goncalves wrote:
> ... and those "static" servers will deal automatically with all the
> 'if-modified' type queries (304, "HEAD" ...and so on ) ..
>
> So I think Allan is right .. the big litmus test to our candidate
> is the ability to be retrieved by static web pages, all other fancy
> things should be optional and be handled by CGI-like scripts
>
> pedro
>
> On Nov 3, 2006, at 2:39 PM, Allan Doyle wrote:
>
>> I think Brian is on to something. Ideally you should be able to build
>> a "server" out of static web pages. That sounds to me like a very
>> important and useful constraint.
>>
>> If there are options that can be handled by "active" services (i.e.
>> CGI or other code), then that's ok, but make them optional.
>>
>> Allan
>>
>> On Nov 3, 2006, at 08:27, Paul Spencer wrote:
>>
>>> If I understand things correctly, you can return a 404 error AND a
>>> transparent image. 404 is just the status code. The error page can
>>> also have content, which it normally does - and the content is HTML.
>>>
>>> Paul
>>>
>>> On 3-Nov-06, at 8:20 AM, Brian Flood wrote:
>>>
>>>> 404 - I agree with Allen, you should return 404 errors instead of a
>>>> transparent tiles. This works better for static storage (like S3)
>>>> where
>>>> you don't have any scripting abilities. Clearly you could front
>>>> end it
>>>> with a web server but it would be nice to just work directly
>>>> against
>>>> static files.
>>>
>>> +-----------------------------------------------------------------+
>>> |Paul Spencer pspencer at dmsolutions.ca |
>>> +-----------------------------------------------------------------+
>>> |Chief Technology Officer |
>>> |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
>>
>>
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061103/73a55f8a/attachment.html
From sgillies at frii.com Fri Nov 3 08:04:31 2006
From: sgillies at frii.com (Sean Gillies)
Date: Fri, 03 Nov 2006 09:04:31 -0700
Subject: [tiling] Global profile
In-Reply-To:
References: <01e001c6ff06$31f0a920$d1a63e05@lapchuck>
Message-ID: <454B688F.1050407@frii.com>
How about "envelope" for its well known semantics? And georss:polygon.
Paul Ramsey wrote:
> Sounds reasonable. Any other spherical people here who want this? I
> am thinking optional parameter, with a WKT
> representation inside. Yes, I am that primitive. I have been known
> to spend hours just beating rocks together. It's fun.
>
> P
>
> On 2-Nov-06, at 9:09 PM, Chuck Stein wrote:
>
>> A smart client could request tiles only inside the polygons. Our
>> datasets
>> have a quadtree type database (very small) that allows the client
>> to know
>> exactly what tiles exist. This file is downloaded first. With
>> your system,
>> given a polygon description (or multiple polygons for islanded data) a
>> client could create the quadtree (or similar) to know what tiles to
>> request.
>> I am thinking of 3D (2.5) earth visualization, not flat maps. A smart
>> client wants to manage any number of datasets and not spend time
>> requesting
>> tiles that don't exist.
>>
>> Chuck
>>
>> -----Original Message-----
>> From: Paul Ramsey [mailto:pramsey at refractions.net]
>> Sent: Thursday, November 02, 2006 9:00 PM
>> To: stein at geofusion.com
>> Cc: tiling at lists.eogeo.org
>> Subject: Re: [tiling] Global profile
>>
>>
>> As specified now, it's a bounding box. The says where the
>> tile space lower left is and the describes the data
>> extent. NVine suggested something more flexible, like a polygon, but
>> that pushes back some geoprocessing requirements on the client. If
>> a polygon
>> data extent was added, what would the client use it
>> for? What clients would use it?
>>
>> On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
>>
>>> I would also like to know, what is the facility for specifying a
>>> non-global
>>> dataset? Is it a bounding box, polygon, or polygon list (islanded
>>> dataset)?
>>> This way the client can ask for tiles it knows exist.
>>>
>>> Thanks,
>>>
>>> Chuck
>>>
>>>
--
Sean Gillies
http://zcologia.com/news
From adoyle at eogeo.org Fri Nov 3 08:07:56 2006
From: adoyle at eogeo.org (Allan Doyle)
Date: Fri, 3 Nov 2006 11:07:56 -0500
Subject: [tiling] Global profile
In-Reply-To: <454B688F.1050407@frii.com>
References: <01e001c6ff06$31f0a920$d1a63e05@lapchuck>
<454B688F.1050407@frii.com>
Message-ID: <96F3FBB2-6DEC-43EC-8BA2-E3CAE7F50DA3@eogeo.org>
My role for the day: riff on other people's good ideas...
If the servers could describe their coverages in georss, then
aggregators could be used to figure out where to go for tiles.
Allan
On Nov 3, 2006, at 11:04, Sean Gillies wrote:
> How about "envelope" for its well known semantics? And georss:polygon.
>
> Paul Ramsey wrote:
>> Sounds reasonable. Any other spherical people here who want this? I
>> am thinking optional parameter, with a WKT
>> representation inside. Yes, I am that primitive. I have been known
>> to spend hours just beating rocks together. It's fun.
>>
>> P
>>
>> On 2-Nov-06, at 9:09 PM, Chuck Stein wrote:
>>
>>> A smart client could request tiles only inside the polygons. Our
>>> datasets
>>> have a quadtree type database (very small) that allows the client
>>> to know
>>> exactly what tiles exist. This file is downloaded first. With
>>> your system,
>>> given a polygon description (or multiple polygons for islanded
>>> data) a
>>> client could create the quadtree (or similar) to know what tiles to
>>> request.
>>> I am thinking of 3D (2.5) earth visualization, not flat maps. A
>>> smart
>>> client wants to manage any number of datasets and not spend time
>>> requesting
>>> tiles that don't exist.
>>>
>>> Chuck
>>>
>>> -----Original Message-----
>>> From: Paul Ramsey [mailto:pramsey at refractions.net]
>>> Sent: Thursday, November 02, 2006 9:00 PM
>>> To: stein at geofusion.com
>>> Cc: tiling at lists.eogeo.org
>>> Subject: Re: [tiling] Global profile
>>>
>>>
>>> As specified now, it's a bounding box. The says where the
>>> tile space lower left is and the describes the data
>>> extent. NVine suggested something more flexible, like a polygon, but
>>> that pushes back some geoprocessing requirements on the client. If
>>> a polygon
>>> data extent was added, what would the client use it
>>> for? What clients would use it?
>>>
>>> On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
>>>
>>>> I would also like to know, what is the facility for specifying a
>>>> non-global
>>>> dataset? Is it a bounding box, polygon, or polygon list (islanded
>>>> dataset)?
>>>> This way the client can ask for tiles it knows exist.
>>>>
>>>> Thanks,
>>>>
>>>> Chuck
>>>>
>>>>
>
> --
> Sean Gillies
> http://zcologia.com/news
>
> _______________________________________________
> 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 sgillies at frii.com Fri Nov 3 08:17:12 2006
From: sgillies at frii.com (Sean Gillies)
Date: Fri, 03 Nov 2006 09:17:12 -0700
Subject: [tiling] Global profile
In-Reply-To:
References: <534364EA05A4824790821002CAD4570A02174D@s25.local.spatialdatalogic.com> <8788E614-6F32-4E2A-9FAD-2FDE4D1FF2B5@dmsolutions.ca>
Message-ID: <454B6B88.4000200@frii.com>
I'm with Allan. You should be able to deploy a tile service using
nothing more than flat files and an HTTP server.
Apache -- and others, I'm sure -- will let you specify error documents
by status code, and you could configure it to use a transparent error
image. Still, I think that clients should not expect anything more than
a 404 code.
Allan Doyle wrote:
> I think Brian is on to something. Ideally you should be able to build
> a "server" out of static web pages. That sounds to me like a very
> important and useful constraint.
>
> If there are options that can be handled by "active" services (i.e.
> CGI or other code), then that's ok, but make them optional.
>
> Allan
>
> On Nov 3, 2006, at 08:27, Paul Spencer wrote:
>
>> If I understand things correctly, you can return a 404 error AND a
>> transparent image. 404 is just the status code. The error page can
>> also have content, which it normally does - and the content is HTML.
>>
>> Paul
>>
>> On 3-Nov-06, at 8:20 AM, Brian Flood wrote:
>>
>>> 404 - I agree with Allen, you should return 404 errors instead of a
>>> transparent tiles. This works better for static storage (like S3)
>>> where
>>> you don't have any scripting abilities. Clearly you could front
>>> end it
>>> with a web server but it would be nice to just work directly against
>>> static files.
>> +-----------------------------------------------------------------+
>> |Paul Spencer pspencer at dmsolutions.ca |
>> +-----------------------------------------------------------------+
>> |Chief Technology Officer |
>> |DM Solutions Group Inc http://www.dmsolutions.ca/ |
>> +-----------------------------------------------------------------+
--
Sean Gillies
http://zcologia.com/news
From pramsey at refractions.net Fri Nov 3 08:16:18 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 08:16:18 -0800
Subject: [tiling] Global profile
In-Reply-To: <20061103161309.28261.qmail@web30812.mail.mud.yahoo.com>
References: <20061103161309.28261.qmail@web30812.mail.mud.yahoo.com>
Message-ID: <60166AAA-39A3-40EB-9917-84EFA0F2DA13@refractions.net>
Thanks Guys! Very cool, and I like the stopwatch part :)
Could you add your pages to the "reference implementations" section
please? (maybe break it out into clients and server) Hopefully
PaulSpencer will have his ka-map server implementation soon, so we
have 2 clients and servers in place.
P
On 3-Nov-06, at 8:13 AM, Mikel Maron wrote:
> A second client implementation.
>
> http://worldkit.org/tilemap/
>
> Didn't time myself ;)
> Guess this shows that the Global Profile is pretty sensible from
> the client side, and easy to implement .. great stuff
>
>
> -Mikel
>
>
> ----- Original Message ----
> From: Christopher Schmidt
> To: Paul Ramsey
> Cc: tiling at lists.eogeo.org
> Sent: Friday, November 3, 2006 2:40:01 PM
> Subject: Re: [tiling] Global profile
>
> On Fri, Nov 03, 2006 at 05:44:07AM -0500, Christopher Schmidt wrote:
>> On Thu, Nov 02, 2006 at 08:44:14PM -0800, Paul Ramsey wrote:
>>> Hey, speaking of Chris Schmidt, I seem to recall someone saying that
>>> he could have a client up and running in ... was it 30 minutes? ...
>>> given a draft and a reference implementation ...
>>>
>>> Draft is up, reference implementation is up ... please, don't
>>> make me
>>> beg, it's unseemly :)
>>
>> I haven't seen a reference implementation URL which is serving actual
>> data. Can you point to some URLs?
>
> Paul pointed me to a URL at 9:07AM -- at 9:23, I had a working
> implementation, 9:30, it was checked into SVN and viewable at:
>
> http://dev.openlayers.org/sandbox/crschmidt/refractions/examples/
> refractions.html
>
> So, 23 minutes. (Go, go, gadget OpenLayers!)
>
> Regards,
> --
> Christopher Schmidt
> Web Developer
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
>
>
>
From mikel_maron at yahoo.com Fri Nov 3 08:13:08 2006
From: mikel_maron at yahoo.com (Mikel Maron)
Date: Fri, 3 Nov 2006 08:13:08 -0800 (PST)
Subject: [tiling] Global profile
Message-ID: <20061103161309.28261.qmail@web30812.mail.mud.yahoo.com>
A second client implementation.
http://worldkit.org/tilemap/
Didn't time myself ;)
Guess this shows that the Global Profile is pretty sensible from the client side, and easy to implement .. great stuff
-Mikel
----- Original Message ----
From: Christopher Schmidt
To: Paul Ramsey
Cc: tiling at lists.eogeo.org
Sent: Friday, November 3, 2006 2:40:01 PM
Subject: Re: [tiling] Global profile
On Fri, Nov 03, 2006 at 05:44:07AM -0500, Christopher Schmidt wrote:
> On Thu, Nov 02, 2006 at 08:44:14PM -0800, Paul Ramsey wrote:
> > Hey, speaking of Chris Schmidt, I seem to recall someone saying that
> > he could have a client up and running in ... was it 30 minutes? ...
> > given a draft and a reference implementation ...
> >
> > Draft is up, reference implementation is up ... please, don't make me
> > beg, it's unseemly :)
>
> I haven't seen a reference implementation URL which is serving actual
> data. Can you point to some URLs?
Paul pointed me to a URL at 9:07AM -- at 9:23, I had a working
implementation, 9:30, it was checked into SVN and viewable at:
http://dev.openlayers.org/sandbox/crschmidt/refractions/examples/refractions.html
So, 23 minutes. (Go, go, gadget OpenLayers!)
Regards,
--
Christopher Schmidt
Web Developer
_______________________________________________
tiling mailing list
tiling at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/tiling
From sgillies at frii.com Fri Nov 3 08:56:36 2006
From: sgillies at frii.com (Sean Gillies)
Date: Fri, 03 Nov 2006 09:56:36 -0700
Subject: [tiling] Modifications to service metadata
Message-ID: <454B74C4.5030907@frii.com>
I'm hacking away at a client and finally have some ideas.
Let's make the service metadata (for example:
http://mapserver.refractions.net/cgi-bin/tms/1.0.0) explicitly feed-ish.
It would be cool to consume these in other mapping applications
(Allan's idea). This would require name, title, and georss:polygon
elements to be added to TileMap elements. This change also clears up the
vagueness about what is in the text node of a TileMap element.
I'm uncomfortable with using the same TileMapService tag in different
contexts. We should consider something else in documents like
http://mapserver.refractions.net/cgi-bin/tms.
Sean
From stein at geofusion.com Fri Nov 3 08:55:32 2006
From: stein at geofusion.com (Chuck Stein)
Date: Fri, 3 Nov 2006 08:55:32 -0800
Subject: [tiling] Global profile
In-Reply-To: <534364EA05A4824790821002CAD4570A02174D@s25.local.spatialdatalogic.com>
Message-ID: <00b801c6ff68$e5886240$d1a63e05@lapchuck>
Brian Flood wrote:
> Origin - does the origin describe the lowerleft of your data or the
lowerleft of the coordinate space?
Yes I wonder the same thing. If the actual data does not begin on a tile
boundary, which does lower left describe, data or tile specs? Must be the
latter.
Chuck
From pramsey at refractions.net Fri Nov 3 09:21:23 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 09:21:23 -0800
Subject: [tiling] Global profile
In-Reply-To: <00b801c6ff68$e5886240$d1a63e05@lapchuck>
References: <00b801c6ff68$e5886240$d1a63e05@lapchuck>
Message-ID: <0C0AABAE-0321-413A-BD8F-380F1708FE62@refractions.net>
Lower left of the tile coordinate space. Which is usually, but not
always the lower left of the data range space. Hence the separate
BoundingBox, in case they differ.
P
On 3-Nov-06, at 8:55 AM, Chuck Stein wrote:
> Brian Flood wrote:
>
>> Origin - does the origin describe the lowerleft of your data or the
> lowerleft of the coordinate space?
>
> Yes I wonder the same thing. If the actual data does not begin on
> a tile
> boundary, which does lower left describe, data or tile specs? Must
> be the
> latter.
>
> Chuck
>
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From pramsey at refractions.net Fri Nov 3 09:42:15 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 09:42:15 -0800
Subject: [tiling] A Local Profile
Message-ID: <631D6450-706A-4613-B4E9-B101A0670306@refractions.net>
I was walking to work today, thinking about interoperability,
muttering to myself in a way that passersby may have found mildly
disconcerting, and I had a thought:
The global-profile is all well and good for ensuring that different
servers publish data that clients can easily integrate for a couple
popular worldwide projections, but what about the regional case?
If every agency in a region picks a different set of scales for their
data, it won't much matter that they are using the same projection.
There should be a way they can provide standard scales so that
everyone can independently end up with the same scaling, without
talking to each other, simply by having the best of intentions.
And so I came to the local profile.
Unlike the global profile, the local profile would not constrain the
coordinate reference system. It will constrain the scales and the
origin, thusly:
* Scales must adhere to this formula where n >= 0: 2^n
So the idea is that we build scales up from the one-pixel-per-unit
level, instead of downwards from the "whole world" view, as we do
with the global profiles.
* And the origin must always be 0,0 in the chosen coordinate
reference system.
Implementing this, I think I will change global-profile to just
"profile" and change the allowed values of the attribute to "world-
geodetic", "world-mercator", and "local-planar".
Thoughts?
P
From pramsey at refractions.net Fri Nov 3 09:50:34 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 09:50:34 -0800
Subject: [tiling] Modifications to service metadata
In-Reply-To: <454B74C4.5030907@frii.com>
References: <454B74C4.5030907@frii.com>
Message-ID:
On 3-Nov-06, at 8:56 AM, Sean Gillies wrote:
> I'm hacking away at a client and finally have some ideas.
>
> Let's make the service metadata (for example:
> http://mapserver.refractions.net/cgi-bin/tms/1.0.0) explicitly feed-
> ish.
Could I see an example of that idea? Remember that we only want to
do it if it aids practical interoperability, not theoretical
interoperability.
> It would be cool to consume these in other mapping applications
> (Allan's idea). This would require name, title, and georss:polygon
> elements to be added to TileMap elements. This change also clears
> up the
> vagueness about what is in the text node of a TileMap element.
Yeah, I don't think I totally like just stuffing the name text in
there right now, fair 'nuff.
> I'm uncomfortable with using the same TileMapService tag in different
> contexts. We should consider something else in documents like
> http://mapserver.refractions.net/cgi-bin/tms.
I don't share your discomfort and rather like the way things read
right now. If we were around a board-room table right now I'd look
for body language to indicate whether I was in the majority or the
minority. If we have a large collection of changes to the draft
maybe we could have a little IRC get together to figure out what is
desirable and what is not.
P
From pramsey at refractions.net Fri Nov 3 09:51:57 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 09:51:57 -0800
Subject: [tiling] Global profile
In-Reply-To: <96F3FBB2-6DEC-43EC-8BA2-E3CAE7F50DA3@eogeo.org>
References: <01e001c6ff06$31f0a920$d1a63e05@lapchuck>
<454B688F.1050407@frii.com>
<96F3FBB2-6DEC-43EC-8BA2-E3CAE7F50DA3@eogeo.org>
Message-ID:
Perhaps this is a case where multiple formats for the same data could
be a handy REST concept to re-use:
On 3-Nov-06, at 8:07 AM, Allan Doyle wrote:
> My role for the day: riff on other people's good ideas...
>
> If the servers could describe their coverages in georss, then
> aggregators could be used to figure out where to go for tiles.
>
> Allan
>
> On Nov 3, 2006, at 11:04, Sean Gillies wrote:
>
>> How about "envelope" for its well known semantics? And
>> georss:polygon.
>>
>> Paul Ramsey wrote:
>>> Sounds reasonable. Any other spherical people here who want this? I
>>> am thinking optional parameter, with a WKT
>>> representation inside. Yes, I am that primitive. I have been known
>>> to spend hours just beating rocks together. It's fun.
>>>
>>> P
>>>
>>> On 2-Nov-06, at 9:09 PM, Chuck Stein wrote:
>>>
>>>> A smart client could request tiles only inside the polygons. Our
>>>> datasets
>>>> have a quadtree type database (very small) that allows the client
>>>> to know
>>>> exactly what tiles exist. This file is downloaded first. With
>>>> your system,
>>>> given a polygon description (or multiple polygons for islanded
>>>> data) a
>>>> client could create the quadtree (or similar) to know what tiles to
>>>> request.
>>>> I am thinking of 3D (2.5) earth visualization, not flat maps. A
>>>> smart
>>>> client wants to manage any number of datasets and not spend time
>>>> requesting
>>>> tiles that don't exist.
>>>>
>>>> Chuck
>>>>
>>>> -----Original Message-----
>>>> From: Paul Ramsey [mailto:pramsey at refractions.net]
>>>> Sent: Thursday, November 02, 2006 9:00 PM
>>>> To: stein at geofusion.com
>>>> Cc: tiling at lists.eogeo.org
>>>> Subject: Re: [tiling] Global profile
>>>>
>>>>
>>>> As specified now, it's a bounding box. The says where the
>>>> tile space lower left is and the describes the data
>>>> extent. NVine suggested something more flexible, like a polygon,
>>>> but
>>>> that pushes back some geoprocessing requirements on the client. If
>>>> a polygon
>>>> data extent was added, what would the client use it
>>>> for? What clients would use it?
>>>>
>>>> On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
>>>>
>>>>> I would also like to know, what is the facility for specifying a
>>>>> non-global
>>>>> dataset? Is it a bounding box, polygon, or polygon list (islanded
>>>>> dataset)?
>>>>> This way the client can ask for tiles it knows exist.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Chuck
>>>>>
>>>>>
>>
>> --
>> Sean Gillies
>> http://zcologia.com/news
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From pramsey at refractions.net Fri Nov 3 09:55:12 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 09:55:12 -0800
Subject: [tiling] Global profile
In-Reply-To: <454B688F.1050407@frii.com>
References: <01e001c6ff06$31f0a920$d1a63e05@lapchuck>
<454B688F.1050407@frii.com>
Message-ID: <48B609A9-9134-4A63-9B8C-950288D771B8@refractions.net>
Where are envelope's well known semantics described?
I can see how using a stronger format than WKT could save people on
the overhead of WKT parser writing, much though I love WKT (*bang*
*thump* *bang*).
P
On 3-Nov-06, at 8:04 AM, Sean Gillies wrote:
> How about "envelope" for its well known semantics? And georss:polygon.
>
> Paul Ramsey wrote:
>> Sounds reasonable. Any other spherical people here who want this? I
>> am thinking optional parameter, with a WKT
>> representation inside. Yes, I am that primitive. I have been known
>> to spend hours just beating rocks together. It's fun.
>>
>> P
>>
>> On 2-Nov-06, at 9:09 PM, Chuck Stein wrote:
>>
>>> A smart client could request tiles only inside the polygons. Our
>>> datasets
>>> have a quadtree type database (very small) that allows the client
>>> to know
>>> exactly what tiles exist. This file is downloaded first. With
>>> your system,
>>> given a polygon description (or multiple polygons for islanded
>>> data) a
>>> client could create the quadtree (or similar) to know what tiles to
>>> request.
>>> I am thinking of 3D (2.5) earth visualization, not flat maps. A
>>> smart
>>> client wants to manage any number of datasets and not spend time
>>> requesting
>>> tiles that don't exist.
>>>
>>> Chuck
>>>
>>> -----Original Message-----
>>> From: Paul Ramsey [mailto:pramsey at refractions.net]
>>> Sent: Thursday, November 02, 2006 9:00 PM
>>> To: stein at geofusion.com
>>> Cc: tiling at lists.eogeo.org
>>> Subject: Re: [tiling] Global profile
>>>
>>>
>>> As specified now, it's a bounding box. The says where the
>>> tile space lower left is and the describes the data
>>> extent. NVine suggested something more flexible, like a polygon, but
>>> that pushes back some geoprocessing requirements on the client. If
>>> a polygon
>>> data extent was added, what would the client use it
>>> for? What clients would use it?
>>>
>>> On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
>>>
>>>> I would also like to know, what is the facility for specifying a
>>>> non-global
>>>> dataset? Is it a bounding box, polygon, or polygon list (islanded
>>>> dataset)?
>>>> This way the client can ask for tiles it knows exist.
>>>>
>>>> Thanks,
>>>>
>>>> Chuck
>>>>
>>>>
>
> --
> Sean Gillies
> http://zcologia.com/news
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From SCHUTP at AGR.GC.CA Fri Nov 3 10:14:20 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Fri, 3 Nov 2006 13:14:20 -0500
Subject: [tiling] A Local Profile
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE317D@onncrxms3.agr.gc.ca>
You beat me to it. Not quite the solution I had in mind, but perhaps
close enough - and I definitely agree that we need to differentiate
between global and local profiles. However it would make sense to keep
them largely compatible.
I had thought of specifying a local profile as being a special
implementation of a global profile, but with some of the upper level
tile sets missing. Essentially the directory/tile naming convention is
unchanged, but if you zoom out too far you'd get some 404's. Otherwise
the spec is unchanged.
Cheers, Peter.
-----Original Message-----
From: tiling-bounces at lists.eogeo.org
[mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
Sent: Friday, November 03, 2006 12:42 PM
To: tiling at lists.eogeo.org
Subject: [tiling] A Local Profile
I was walking to work today, thinking about interoperability,
muttering to myself in a way that passersby may have found mildly
disconcerting, and I had a thought:
The global-profile is all well and good for ensuring that different
servers publish data that clients can easily integrate for a couple
popular worldwide projections, but what about the regional case?
If every agency in a region picks a different set of scales for their
data, it won't much matter that they are using the same projection.
There should be a way they can provide standard scales so that
everyone can independently end up with the same scaling, without
talking to each other, simply by having the best of intentions.
And so I came to the local profile.
Unlike the global profile, the local profile would not constrain the
coordinate reference system. It will constrain the scales and the
origin, thusly:
* Scales must adhere to this formula where n >= 0: 2^n
So the idea is that we build scales up from the one-pixel-per-unit
level, instead of downwards from the "whole world" view, as we do
with the global profiles.
* And the origin must always be 0,0 in the chosen coordinate
reference system.
Implementing this, I think I will change global-profile to just
"profile" and change the allowed values of the attribute to "world-
geodetic", "world-mercator", and "local-planar".
Thoughts?
P
_______________________________________________
tiling mailing list
tiling at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/tiling
From noreply at geocartic.com Fri Nov 3 10:21:29 2006
From: noreply at geocartic.com (Tim Schaub)
Date: Fri, 3 Nov 2006 11:21:29 -0700
Subject: [tiling] Modifications to service metadata
In-Reply-To: <454B74C4.5030907@frii.com>
Message-ID: <00be01c6ff74$e2577730$15fea8c0@meridian>
How about getting really useful and serving up JSON?
Then we could build "loaders" for clients that didn't have access to a
server (and didn't like copy/pasting).
Tim
> -----Original Message-----
> From: tiling-bounces at lists.eogeo.org
> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Sean Gillies
> Sent: Friday, November 03, 2006 9:57 AM
> To: tiling at lists.eogeo.org
> Subject: [tiling] Modifications to service metadata
>
> I'm hacking away at a client and finally have some ideas.
>
> Let's make the service metadata (for example:
> http://mapserver.refractions.net/cgi-bin/tms/1.0.0)
> explicitly feed-ish.
> It would be cool to consume these in other mapping
> applications (Allan's idea). This would require name, title,
> and georss:polygon elements to be added to TileMap elements.
> This change also clears up the vagueness about what is in the
> text node of a TileMap element.
>
> I'm uncomfortable with using the same TileMapService tag in
> different contexts. We should consider something else in
> documents like http://mapserver.refractions.net/cgi-bin/tms.
>
> Sean
>
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
>
>
From pramsey at refractions.net Fri Nov 3 10:24:01 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 10:24:01 -0800
Subject: [tiling] A Local Profile
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE317D@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE317D@onncrxms3.agr.gc.ca>
Message-ID: <3458681B-18A6-4348-9724-95207F0B814D@refractions.net>
On 3-Nov-06, at 10:14 AM, Schut, Peter wrote:
> I had thought of specifying a local profile as being a special
> implementation of a global profile, but with some of the upper level
> tile sets missing. Essentially the directory/tile naming
> convention is
> unchanged, but if you zoom out too far you'd get some 404's.
> Otherwise
> the spec is unchanged.
You can do this now, just define the scale ranges you want from the
global profile. If your scales happen to only be local in nature,
c'est la vie, no problem, the client reads your list of
and only asks for tiles from you when viewing the scales you provide.
My intent with the local profile is to allow interoperability in
arbitrary projected coordinate systems... the NrCan (or BC
government) use case, if you will. :)
P
From SCHUTP at AGR.GC.CA Fri Nov 3 10:32:14 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Fri, 3 Nov 2006 13:32:14 -0500
Subject: [tiling] A Local Profile
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE3180@onncrxms3.agr.gc.ca>
Right - except it would be useful to know right away if a tile map
service is really global in coverage or not. I'm assuming that the
registry would be happier to just harvest the TileMapService document,
rather than have to parse all the way through the TileMap document as
well.
Cheers, Peter.
----Original Message-----
From: tiling-bounces at lists.eogeo.org
[mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
Sent: Friday, November 03, 2006 1:24 PM
To: tiling at lists.eogeo.org
Subject: Re: [tiling] A Local Profile
On 3-Nov-06, at 10:14 AM, Schut, Peter wrote:
> I had thought of specifying a local profile as being a special
> implementation of a global profile, but with some of the upper level
> tile sets missing. Essentially the directory/tile naming
> convention is
> unchanged, but if you zoom out too far you'd get some 404's.
> Otherwise
> the spec is unchanged.
You can do this now, just define the scale ranges you want from the
global profile. If your scales happen to only be local in nature,
c'est la vie, no problem, the client reads your list of
and only asks for tiles from you when viewing the scales you provide.
My intent with the local profile is to allow interoperability in
arbitrary projected coordinate systems... the NrCan (or BC
government) use case, if you will. :)
P
_______________________________________________
tiling mailing list
tiling at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/tiling
From sgillies at frii.com Fri Nov 3 10:35:37 2006
From: sgillies at frii.com (Sean Gillies)
Date: Fri, 03 Nov 2006 11:35:37 -0700
Subject: [tiling] Modifications to service metadata
In-Reply-To:
References: <454B74C4.5030907@frii.com>
Message-ID: <454B8BF9.5070103@frii.com>
Paul Ramsey wrote:
>
> On 3-Nov-06, at 8:56 AM, Sean Gillies wrote:
>
>> I'm hacking away at a client and finally have some ideas.
>>
>> Let's make the service metadata (for example:
>> http://mapserver.refractions.net/cgi-bin/tms/1.0.0) explicitly feed-ish.
>
> Could I see an example of that idea? Remember that we only want to do
> it if it aids practical interoperability, not theoretical interoperability.
Sure, it would be simple enough to provide a parallel feed, but the fact
is that feeds are the way that discovery is done now. If something
widely adopted like Atom would work, we should seriously think twice
before creating a new and unproven XML language.
>
>> It would be cool to consume these in other mapping applications
>> (Allan's idea). This would require name, title, and georss:polygon
>> elements to be added to TileMap elements. This change also clears up the
>> vagueness about what is in the text node of a TileMap element.
>
> Yeah, I don't think I totally like just stuffing the name text in there
> right now, fair 'nuff.
>
>> I'm uncomfortable with using the same TileMapService tag in different
>> contexts. We should consider something else in documents like
>> http://mapserver.refractions.net/cgi-bin/tms.
>
> I don't share your discomfort and rather like the way things read right
> now. If we were around a board-room table right now I'd look for body
> language to indicate whether I was in the majority or the minority. If
> we have a large collection of changes to the draft maybe we could have a
> little IRC get together to figure out what is desirable and what is not.
>
> P
>
I'm holding my nose. How's that for body language? TileMapService and
TileMap are the only instances that I can quibble about and don't seem
like they will necessarily conflict in practice. I guess I'm just more
picky about elements: I'd like their meaning to not depend on the context.
Overall, I like it.
--
Sean Gillies
http://zcologia.com/news
From SCHUTP at AGR.GC.CA Fri Nov 3 10:44:06 2006
From: SCHUTP at AGR.GC.CA (Schut, Peter)
Date: Fri, 3 Nov 2006 13:44:06 -0500
Subject: [tiling] TileMapService and TileMap
Message-ID: <783BB96C25B79249A236DF62F559D6A501EE3181@onncrxms3.agr.gc.ca>
What is the reasoning behind separating the contents of the TileMap
resource from the TileMapService resource?
Cheers, Peter
From jb-tiling at jasonbirch.com Fri Nov 3 10:44:31 2006
From: jb-tiling at jasonbirch.com (Jason Birch)
Date: Fri, 03 Nov 2006 10:44:31 -0800
Subject: [tiling] A Local Profile
In-Reply-To: <3458681B-18A6-4348-9724-95207F0B814D@refractions.net>
References: <783BB96C25B79249A236DF62F559D6A501EE317D@onncrxms3.agr.gc.ca>
<3458681B-18A6-4348-9724-95207F0B814D@refractions.net>
Message-ID: <454B8E0F.8060205@jasonbirch.com>
Paul Ramsey wrote:
> My intent with the local profile is to allow interoperability in
> arbitrary projected coordinate systems... the NrCan (or BC
> government) use case, if you will. :)
Damned if I'm going to serve up my nice UTM data in BC Albers. Putting
it out in whacky global SRS are bad enough, but at least that gives
global accessibility :)
Seriously, I think there should be two concepts: global profiles, and
non-standard (or implementation-specific) systems. We should not be
encouraging the balkanised "standards" that SDI bodies seem to love.
Jason
From sgillies at frii.com Fri Nov 3 10:49:52 2006
From: sgillies at frii.com (Sean Gillies)
Date: Fri, 03 Nov 2006 11:49:52 -0700
Subject: [tiling] Global profile
In-Reply-To: <48B609A9-9134-4A63-9B8C-950288D771B8@refractions.net>
References: <01e001c6ff06$31f0a920$d1a63e05@lapchuck>
<454B688F.1050407@frii.com>
<48B609A9-9134-4A63-9B8C-950288D771B8@refractions.net>
Message-ID: <454B8F50.8070601@frii.com>
I was thinking envelope polygons as in simple features for sql, but
you're right: envelope means a box in other specs. Bounding shape or
polygon seems to be the right fit.
Paul Ramsey wrote:
> Where are envelope's well known semantics described?
> I can see how using a stronger format than WKT could save people on the
> overhead of WKT parser writing, much though I love WKT (*bang* *thump*
> *bang*).
>
> P
>
> On 3-Nov-06, at 8:04 AM, Sean Gillies wrote:
>
>> How about "envelope" for its well known semantics? And georss:polygon.
>>
>> Paul Ramsey wrote:
>>> Sounds reasonable. Any other spherical people here who want this? I
>>> am thinking optional parameter, with a WKT
>>> representation inside. Yes, I am that primitive. I have been known
>>> to spend hours just beating rocks together. It's fun.
>>>
>>> P
>>>
>>> On 2-Nov-06, at 9:09 PM, Chuck Stein wrote:
>>>
>>>> A smart client could request tiles only inside the polygons. Our
>>>> datasets
>>>> have a quadtree type database (very small) that allows the client
>>>> to know
>>>> exactly what tiles exist. This file is downloaded first. With
>>>> your system,
>>>> given a polygon description (or multiple polygons for islanded data) a
>>>> client could create the quadtree (or similar) to know what tiles to
>>>> request.
>>>> I am thinking of 3D (2.5) earth visualization, not flat maps. A smart
>>>> client wants to manage any number of datasets and not spend time
>>>> requesting
>>>> tiles that don't exist.
>>>>
>>>> Chuck
>>>>
>>>> -----Original Message-----
>>>> From: Paul Ramsey [mailto:pramsey at refractions.net]
>>>> Sent: Thursday, November 02, 2006 9:00 PM
>>>> To: stein at geofusion.com
>>>> Cc: tiling at lists.eogeo.org
>>>> Subject: Re: [tiling] Global profile
>>>>
>>>>
>>>> As specified now, it's a bounding box. The says where the
>>>> tile space lower left is and the describes the data
>>>> extent. NVine suggested something more flexible, like a polygon, but
>>>> that pushes back some geoprocessing requirements on the client. If
>>>> a polygon
>>>> data extent was added, what would the client use it
>>>> for? What clients would use it?
>>>>
>>>> On 2-Nov-06, at 8:54 PM, Chuck Stein wrote:
>>>>
>>>>> I would also like to know, what is the facility for specifying a
>>>>> non-global
>>>>> dataset? Is it a bounding box, polygon, or polygon list (islanded
>>>>> dataset)?
>>>>> This way the client can ask for tiles it knows exist.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Chuck
>>>>>
>>>>>
>>
>> --Sean Gillies
>> http://zcologia.com/news
>>
>> _______________________________________________
>> tiling mailing list
>> tiling at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/tiling
>
>
--
Sean Gillies
http://zcologia.com/news
From pramsey at refractions.net Fri Nov 3 10:49:22 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 10:49:22 -0800
Subject: [tiling] TileMapService and TileMap
In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE3181@onncrxms3.agr.gc.ca>
References: <783BB96C25B79249A236DF62F559D6A501EE3181@onncrxms3.agr.gc.ca>
Message-ID: <7F7D2BE6-D37B-466C-87B0-3C5E944DA88B@refractions.net>
I guess I was thinking that the client could retrieve a lightweight
document up front, and see if any tilemaps interested them before
loading the full tilemap document (if my client only does the
mercator global profile, I could quickly see if anything was of
interest).
But I guess fundamentally I was driven by the idea of splitting the
whole thing into logical "resources" in the service of the RESTy
paradigm. I may have overdone it, it is true.
P
On 3-Nov-06, at 10:44 AM, Schut, Peter wrote:
> What is the reasoning behind separating the contents of the TileMap
> resource from the TileMapService resource?
>
> Cheers, Peter
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
From crschmidt at crschmidt.net Fri Nov 3 14:33:54 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Fri, 3 Nov 2006 17:33:54 -0500
Subject: [tiling] TMS Server implementation
Message-ID: <20061103223354.GB30924@crschmidt.net>
http://dev.openlayers.org/sandbox/crschmidt/refractions/examples/refractions.html
now powered by some code Schuyler and I wrote over the past couple days.
http://labs.metacarta.com/wms-c/tms.cgi/1.0.0/basic/5/32/23.png
It's designed to support pluggable cache backends, and pluggable backend
sources: this one uses MapServer and a disk cache, but it can also use a
MemoryCache, and it can do cascading WMS as well.
Thanks to MetaCarta for letting us work on it.
Regards,
--
Christopher Schmidt
Web Developer
From pramsey at refractions.net Fri Nov 3 17:01:08 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri, 3 Nov 2006 17:01:08 -0800
Subject: [tiling] TMS Server implementation
In-Reply-To: <20061103223354.GB30924@crschmidt.net>
References: <20061103223354.GB30924@crschmidt.net>
Message-ID: <74DAC06F-BE49-4762-B29D-FCBDC5701D6A@refractions.net>
Does this server not do any of the metadata? I can't get any of the
resource responses, just the image tiles.
On 3-Nov-06, at 2:33 PM, Christopher Schmidt wrote:
> http://labs.metacarta.com/wms-c/tms.cgi/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061103/be5d07be/attachment.htm
From crschmidt at crschmidt.net Fri Nov 3 17:12:46 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Fri, 3 Nov 2006 20:12:46 -0500
Subject: [tiling] TMS Server implementation
In-Reply-To: <74DAC06F-BE49-4762-B29D-FCBDC5701D6A@refractions.net>
References: <20061103223354.GB30924@crschmidt.net>
<74DAC06F-BE49-4762-B29D-FCBDC5701D6A@refractions.net>
Message-ID: <20061104011246.GC30924@crschmidt.net>
On Fri, Nov 03, 2006 at 05:01:08PM -0800, Paul Ramsey wrote:
> Does this server not do any of the metadata? I can't get any of the
> resource responses, just the image tiles.
Correct. As a web client developer, the metadata means nothing to me, so
I haven't read the spec, and I haven't figured out how the metadata is
supposed to work yet.
Regards,
--
Christopher Schmidt
Web Developer
From pramsey at refractions.net Sat Nov 4 13:01:47 2006
From: pramsey at refractions.net (Paul Ramsey)
Date: Sat, 04 Nov 2006 13:01:47 -0800
Subject: [tiling] Content Negotiation / Major Revision
Message-ID:
Folks,
Even though Chris Schmidt thinks the TMS is a terrible idea (there,
now you have to tell us why Chris :), he was kind enough to point out
a hole large enough to drive a truck through:
* For web-only clients, the ability to add a 3rd party TMS (which I
consider a pretty important feature of a interoperability spec,
adding previously unknown 3rd party data sources) is constrained by
the fact that web-only clients are bound by the same origin policy
.
** There is a way around this, using JSON as a content type.
Peter Schut has also pointed out that the break between the
TileMapService resource and the TileMap resource does not provide
very much functional benefit. I'm not sure I disagree.
So I am contemplating:
* compressing TileMap into TileMapService
* allowing content negotiation , so that clients can get the service metadata in either
XML or JSON
Thoughts?
P
From crschmidt at crschmidt.net Sat Nov 4 14:18:19 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Sat, 4 Nov 2006 17:18:19 -0500
Subject: [tiling] Content Negotiation / Major Revision
In-Reply-To:
References:
Message-ID: <20061104221819.GD30924@crschmidt.net>
On Sat, Nov 04, 2006 at 01:01:47PM -0800, Paul Ramsey wrote:
> So I am contemplating:
>
> * compressing TileMap into TileMapService
> * allowing content negotiation conneg.html>, so that clients can get the service metadata in either
> XML or JSON
A content type of JSON alone doesn't entirely solve the problem: in
order to actually load the data, it has to be delivered essentially as
executable code. So, rather than:
{'TMS':['a','b','c']}
you would need to deliver:
TMSLoad({'TMS':['a','b','c']});
This allows inclusion in the format:
to run a function called TMSLoad() in the page, which can handle the
content.
Regards,
--
Christopher Schmidt
Web Developer
From robert.coup at onetrackmind.co.nz Sat Nov 4 14:47:26 2006
From: robert.coup at onetrackmind.co.nz (Robert Coup)
Date: Sun, 05 Nov 2006 11:47:26 +1300
Subject: [tiling] Content Negotiation / Major Revision
In-Reply-To: <20061104221819.GD30924@crschmidt.net>
References:
<20061104221819.GD30924@crschmidt.net>
Message-ID: <454D187E.7070808@onetrackmind.co.nz>
Christopher Schmidt wrote:
> A content type of JSON alone doesn't entirely solve the problem: in
> order to actually load the data, it has to be delivered essentially as
> executable code. So, rather than:
>
> {'TMS':['a','b','c']}
>
> you would need to deliver:
>
> TMSLoad({'TMS':['a','b','c']});
>
> This allows inclusion in the format:
>
>
>
> to run a function called TMSLoad() in the page, which can handle the
> content.
>
The more flexible way is to have JSONP/callback support where the
function to call back (in the above example its TMSLoad) can be
specified by the client. This allows client-side toolkits like dojo and
others to use their builtin mechanisms, and clients can avoid hassles
when they request multiple data sources, etc.
eg. request:
example.com/page?jsonp=myTMSload.function7&otherarg=1234
response:
myTMSload.function7({'TMS':['a','b','c']});
The server-side script basically creates the JSON data, then does:
response = GET["jsonp"] + "(" + tmsResponseData + ");"
(converting to your server-side language of choice)
http://ajaxian.com/archives/jsonp-json-with-padding
http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/
http://developer.yahoo.com/common/json.html#callbackparam
Bear in mind that pages requesting JSON data using one of the above
methods are opening themselves up to malicious 3rd party servers being
able to inject code... but if they're requesting it in the first place
then its at their own risk I guess.
Rob :)
--
One Track Mind Ltd.
PO Box 1604, Shortland St, Auckland, New Zealand
Phone +64-9-966 0433 Mobile +64-21-572 632
Web http://www.onetrackmind.co.nz
From noreply at geocartic.com Sat Nov 4 15:40:00 2006
From: noreply at geocartic.com (Tim Schaub)
Date: Sat, 4 Nov 2006 16:40:00 -0700
Subject: [tiling] Content Negotiation / Major Revision
In-Reply-To:
Message-ID: <008b01c7006a$8c780e00$15fea8c0@meridian>
One issue with JSON (which I'm glad to see actually getting traction), is
that a client typically sends a callback function or namespace as part of
the request. (Since executing straight JSON gets you nowhere, you have to
provide the object as an argument to a function or set it as the property of
another object.)
This requires one of two things:
1) that your spec defines one namespace or function to be used by all (ack!)
or
2) that the TMS metadata cannot be served up as a static file
Maybe 2 is not that big a deal, but it does put more of a burden on the
server.
Tim
> -----Original Message-----
> From: tiling-bounces at lists.eogeo.org
> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey
> Sent: Saturday, November 04, 2006 2:02 PM
> To: tiling at lists.eogeo.org
> Subject: [tiling] Content Negotiation / Major Revision
>
> Folks,
>
> Even though Chris Schmidt thinks the TMS is a terrible idea
> (there, now you have to tell us why Chris :), he was kind
> enough to point out a hole large enough to drive a truck through:
>
> * For web-only clients, the ability to add a 3rd party TMS
> (which I consider a pretty important feature of a
> interoperability spec, adding previously unknown 3rd party
> data sources) is constrained by the fact that web-only
> clients are bound by the same origin policy
> .
> ** There is a way around this, using JSON as a content type.
>
> Peter Schut has also pointed out that the break between the
> TileMapService resource and the TileMap resource does not
> provide very much functional benefit. I'm not sure I disagree.
>
> So I am contemplating:
>
> * compressing TileMap into TileMapService
> * allowing content negotiation
> , so that
> clients can get the service metadata in either XML or JSON
>
> Thoughts?
>
> P
> _______________________________________________
> tiling mailing list
> tiling at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/tiling
>
>
From crschmidt at crschmidt.net Sat Nov 4 15:42:21 2006
From: crschmidt at crschmidt.net (Christopher Schmidt)
Date: Sat, 4 Nov 2006 18:42:21 -0500
Subject: [tiling] Content Negotiation / Major Revision
In-Reply-To: <454D187E.7070808@onetrackmind.co.nz>
References:
<20061104221819.GD30924@crschmidt.net>
<454D187E.7070808@onetrackmind.co.nz>
Message-ID: <20061104234221.GE30924@crschmidt.net>
On Sun, Nov 05, 2006 at 11:47:26AM +1300, Robert Coup wrote:
> Christopher Schmidt wrote:
> > A content type of JSON alone doesn't entirely solve the problem: in
> > order to actually load the data, it has to be delivered essentially as
> > executable code. So, rather than:
> >
> > {'TMS':['a','b','c']}
> >
> > you would need to deliver:
> >
> > TMSLoad({'TMS':['a','b','c']});
> >
> > This allows inclusion in the format:
> >
> >
> >
> > to run a function called TMSLoad() in the page, which can handle the
> > content.
> >
> The more flexible way is to have JSONP/callback support where the
> function to call back (in the above example its TMSLoad) can be
> specified by the client. This allows client-side toolkits like dojo and
> others to use their builtin mechanisms, and clients can avoid hassles
> when they request multiple data sources, etc.
Yes, but given that the specification is specifically designed towards
the case where information is created statically one time and then
served forever, introducing a dependency like this into the spec at this
point doesn't make sense.
If you want to move towards a more dynamic specification, then you're
absolutely right, specifying the callback makes sense. If you want to
maintain the ability to create static-file based TMS caches, then there
doesn't seem (to me) to be any way to generate a conforming
JSON+callback doc where the callback can be specified.
Regards,
--
Christopher Schmidt
Web Developer
From robert.coup at onetrackmind.co.nz Sat Nov 4 15:44:50 2006
From: robert.coup at onetrackmind.co.nz (Robert Coup)
Date: Sun, 05 Nov 2006 12:44:50 +1300
Subject: [tiling] Content Negotiation / Major Revision
In-Reply-To: <008b01c7006a$8c780e00$15fea8c0@meridian>
References: <008b01c7006a$8c780e00$15fea8c0@meridian>
Message-ID: <454D25F2.90709@onetrackmind.co.nz>
Tim Schaub wrote:
> One issue with JSON (which I'm glad to see actually getting traction), is
> that a client typically sends a callback function or namespace as part of
> the request. (Since executing straight JSON gets you nowhere, you have to
> provide the object as an argument to a function or set it as the property of
> another object.)
>
> This requires one of two things:
>
> 1) that your spec defines one namespace or function to be used by all (ack!)
>
> or
>
> 2) that the TMS metadata cannot be served up as a static file
>
Note that what Tim, Chris, and I said is only true if you want to do
JSON via
>
> to run a function called TMSLoad() in the page, which can handle the
> content.
>
> Regards,
Chris,
Do you imagine anyone will want to use service metadata directly in a
> >
> > to run a function called TMSLoad() in the page, which can handle the
> > content.
> >
> > Regards,
>
> Chris,
>
> Do you imagine anyone will want to use service metadata directly in a
>
>>>
>>> to run a function called TMSLoad() in the page, which can handle the
>>> content.
>>>
>>> Regards,
>> Chris,
>>
>> Do you imagine anyone will want to use service metadata directly in a
>>
>>>
>>> to run a function called TMSLoad() in the page, which can handle the
>>> content.
>>>
>>> Regards,
>> Chris,
>>
>> Do you imagine anyone will want to use service metadata directly in a
>>