[mapserver-users] MapCache and the GoogleCRS84Quad TileMatrixSet
Andre Vautour
andre.vautour at caris.com
Fri Jul 19 11:53:20 PDT 2013
Hi Thomas,
I was looking at GoogleCRS84Quad and fell on this thread. I'd like to share my interpretation of the standard as I don't believe that well-known scale-set is broken.
I think we can all agree that level 0 is unambiguous and should be
/<TileMatrix>
// //<Identifier>0</Identifier>
// //<ScaleDenominator>559082264.0287178</ScaleDenominator>
/ /<TopLeftCorner>180.000000 -180.000000</TopLeftCorner>
/ /<TileWidth>256</TileWidth>
/ /<//TileHeight>256</TileHeight>
// //<MatrixWidth>1</MatrixWidth>
// //<MatrixHeight>1</MatrixHeight>
//</TileMatrix>/
I could be wrong, but it seems to you have interpreted the statement
"/The next level represents the whole world in 2x2 tiles of 256x256 pixels and so on in powers of 2./"
as meaning the exact world, that is -90,-180 to 90,180. I believe that level 1 is still supposed to be -180,-180 to 180,180
I'll elaborate. The first sentence is "This well-known scale set has been defined to allow quadtree pyramids in CRS84". That would imply to me that
each lower level would be the upper level exactly divided by 4. That is, I am pretty sure that all the levels in that scale set are supposed to be aligned.
I interpreted the/"whole world in 2x2/" in the context of the quad tree. I believe the intent of the author(s) was simply to communicate that each level is a power of 2 of the previous level.
So, I would expect level 1 to be:
/<TileMatrix>
// //<Identifier>1</Identifier>
// //<ScaleDenominator>279541132.0143589</ScaleDenominator>
/ /<TopLeftCorner>180.000000 -180.000000</TopLeftCorner>
/ /<TileWidth>256</TileWidth>
/ /<//TileHeight>256</TileHeight>
// //<MatrixWidth>2</MatrixWidth>
// //<MatrixHeight>2</MatrixHeight>
//</TileMatrix>/
That is, I believe all levels should shared the same top-left corner.
The TileMatrixSetLimits can and probably should be used to avoid clients trying to read tiles outside of the world.
André
Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company.
No binding contract will result from this email until such time as a written document is signed on behalf of the company.
On 10 April 2013 08:50, thomas bonfort <thomas.bonfort at gmail.com <mailto:mapserver-users%40lists.osgeo.org?Subject=Re%3A%20%5Bmapserver-users%5D%20MapCache%20and%20the%20GoogleCRS84Quad%20TileMatrixSet&In-Reply-To=%3CCAOM3y2gf3pXMBzwU1PDZ5vudbOgFRq6jVXbuKZChsbez0Ui%2Bcg%40mail.gmail.com%3E> <http://lists.osgeo.org/mailman/listinfo/mapserver-users>> wrote:
> Armin,
> I don't have much to add to what you have already found out. I personally
> consider the GoogleCRS84Quad grid as defined by the spec to be broken, and
> have not implemented its support as it would require some specific hacks in
> the code (as the extent for level 0 needs to be hardcoded for this specific
> grid, instead of it being derived from grid properties as is the case with
> all other grid definitions).
>
> I suppose that support for this could be added if you really need it badly.
> The impact is not negligible as all places where an extent is derived from
> a tile coordinate and vice-versa would need to be updated to support this
> illogical quirk.
>
> FWIW, I believe I had brought this up as a change request to the wmts
> working group, but this was ignored as I am not a member.
>
> best regards,
>
> thomas
>
> On 9 April 2013 20:57, Armin Burger <armin.burger at gmx.net <http://lists.osgeo.org/mailman/listinfo/mapserver-users>> wrote:
>>/ Dear all
/>>/
/>>/ I have a question regarding the GoogleCRS84Quad TileMatrixSet defined in
/>>/ MapCache. MapCache specifies this in the docs with the first level [0] as
/>>/ pixel resolution 0.70312500 deg, and an extent of
/>>/ <extent>-180 -90 180 90</extent>/.
>>/
/>>/ and returns the GoogleCRS84Quad TileMatrixSet in the Capabilities response
/>>/ like
/>>/
/>>/ <TileMatrixSet>
/>>/ <Identifier>WGS84</Identifier>
/>>/ <Title>GoogleCRS84Quad</Title>
/>>/ <SupportedCRS>urn:ogc:def:crs:**EPSG:6.3:4326</SupportedCRS>
/>>/ <BoundingBox crs="urn:ogc:def:crs:EPSG:6.3:**4326">
/>>/ <LowerCorner>-180.000000 -90.000000</LowerCorner>
/>>/ <UpperCorner>180.000000 90.000000</UpperCorner>
/>>/ </BoundingBox>
/>>/
/>>/ <WellKnownScaleSet>urn:ogc:**def:wkss:OGC:1.0:**GoogleCRS84Quad</**
/>>/ WellKnownScaleSet>
/>>/ <TileMatrix>
/>>/ <Identifier>0</Identifier>
/>>/ <ScaleDenominator>279541132.**01435887813568115234</**
/>>/ ScaleDenominator>
/>>/ <TopLeftCorner>90.000000 -180.000000</TopLeftCorner>
/>>/ <TileWidth>256</TileWidth>
/>>/ <TileHeight>256</TileHeight>
/>>/ <MatrixWidth>2</MatrixWidth>
/>>/ <MatrixHeight>1</MatrixHeight>
/>>/ </TileMatrix>
/>>/ .....
/>>/ </TileMatrixSet>
/>>/
/>>/ This looks clear and logical, but the OGC specs at
/>>/ http://portal.opengeospatial.**org/files/?artifact_id=35326<http://portal.opengeospatial.org/files/?artifact_id=35326 <http://portal.opengeospatial.**org/files/?artifact_id=35326%3Chttp://portal.opengeospatial.org/files/?artifact_id=35326>>
/>>/ define this TileMatrixSet differently as
/>>/
/>>/ "E.3 GoogleCRS84Quad (urn:ogc:def:wkss:OGC:1.0:**GoogleCRS84Quad)
/>>/ This well-known scale set has been defined to allow quadtree pyramids in
/>>/ CRS84. Level 0 allows representing the whole world in a single 256x256
/>>/ pixels (where the first 64 and last 64 lines of the tile are left blank).
/>>/ The next level represents the whole world in 2x2
/>>/ tiles of 256x256 pixels and so on in powers of 2. Scale denominator is
/>>/ only accurate near the equator."
/>>/
/>>/ The level 0 in the OGC specs uses a resolution of 1.40625000.
/>>/
/>>/ The tile 0/0/0 in MapCache is not a single tile as in the OGC specs but
/>>/ the first out of 2 tiles for this level, correctly defined with MatrixWidth
/>>/ 2 and MatrixHeight 1 (level 1 has 4x2 tiles). For me the OGC specs are not
/>>/ logical, because the TopLeft corner would correspond to 180 -180 degrees
/>>/ which makes no sense for me, but somehow they are regarded as the default
/>>/ specs...
/>>/
/>>/ So the XML definition of the OGC specs should probably result in something
/>>/ like
/>>/
/>>/ <TileMatrix>
/>>/ <Identifier>0</Identifier>
/>>/ <ScaleDenominator>559082264.**0287178</ScaleDenominator>
/>>/ <TopLeftCorner>180.000000 -180.000000</TopLeftCorner>
/>>/ <TileWidth>256</TileWidth>
/>>/ <TileHeight>256</TileHeight>
/>>/ <MatrixWidth>1</MatrixWidth>
/>>/ <MatrixHeight>1</MatrixHeight>
/>>/ </TileMatrix>
/>>/
/>>/ Unfortunately the OGC doc does not provide this matrix set's full
/>>/ definition in XML to check this.
/>>/
/>>/
/>>/ So I'm wondering which is the correct definition? And any idea how to deal
/>>/ with this discrepancy?
/>>/
/>>/ Thanks
/>>/ Armin
/>>/
/>>/
/>>/
/>>/
/>>/
/>>/
/>>/ ______________________________**_________________
/>>/ mapserver-users mailing list
/>>/ mapserver-users at lists.osgeo. <http://lists.osgeo.org/mailman/listinfo/mapserver-users>**org <mapserver-users at lists.osgeo.org <http://lists.osgeo.org/mailman/listinfo/mapserver-users>>
/>>/ http://lists.osgeo.org/**mailman/listinfo/mapserver-**users<http://lists.osgeo.org/mailman/listinfo/mapserver-users <http://lists.osgeo.org/**mailman/listinfo/mapserver-**users%3Chttp://lists.osgeo.org/mailman/listinfo/mapserver-users>>
/>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20130719/528f8378/attachment.html>
More information about the mapserver-users
mailing list