Hi,
It may be that it is wrong to define EPSG:4326 RectifiedGrid for images without axisOrder function but in this case there are a bunch of OGC standards which are wrong as well.
For example RectifiedGrid is used in “OGC® GML in JPEG 2000 (GMLJP2) Encoding Standard Part 1: Core” http://docs.opengeospatial.org/is/08-085r4/08-085r4.html
The examples about EPSG:4326 are without GridFunction axisOrder and it looks like the authors of the standard believe that axis order can be handled correctly if offset vectors are defined like
0 3.71e-005 [zero – number]
-3.71e-005 0 [number – zero]
Unfortunately in this standard all the examples are in EPSG:4326. However, in another OGC specification also from year 2014 there is an example about non-flipped EPSG:3857 which defines offsetVectors as [number – zero] + [zero – number].
<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/
3857">10 0</gml:offsetVector>
<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/
3857">0 -10</gml:offsetVector>
Larger excerpt about EPSG:4326
<gml:RectifiedGrid gml:id=“rg0001_C0002” dimension=“2”
srsName=“http://www.opengis.net/def/crs/EPSG/0/4326”>
gml:low1 1</gml:low>
gml:high3 10</gml:high>
</gml:GridEnvelope>
</gml:limits>
gml:axisLabelsLat Long</gml:axisLabels>
<gml:Point gml:id=“P0001”
srsName=“http://www.opengis.net/def/crs/EPSG/0/4326”>
gml:pos9.9 9.9</gml:pos>
</gml:Point>
</gml:origin>
<gml:offsetVector
srsName=“http://www.opengis.net/def/crs/EPSG/0/4326”>0 3.71e-005
</gml:offsetVector>
<gml:offsetVector
srsName=“http://www.opengis.net/def/crs/EPSG/0/4326”>-3.71e-005 0
</gml:offsetVector>
</gml:RectifiedGrid>
Larger excerpt about EPSG:3857
<gml:RectifiedGrid dimension=“2” gml:id=“grid_grey”>
gml:low0 0</gml:low>
gml:high39 29</gml:high>
</gml:GridEnvelope>
</gml:limits>
gml:axisLabelsx y</gml:axisLabels>
<gml:Point gml:id=“grid_origin_grey”
srsName=“http://www.opengis.net/def/crs/EPSG/0/3857”>
gml:pos105 345</gml:pos>
</gml:Point>
</gml:origin>
<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/
3857">10 0</gml:offsetVector>
<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/
3857">0 -10</gml:offsetVector>
</gml:RectifiedGrid>
-Jukka-
···
Lähettäjä: Rahkonen Jukka (MML)
Lähetetty: 9. lokakuuta 2015 15:45
Vastaanottaja: GeoServer Mailing List List
Aihe: Re: [Geoserver-users] New image mosaic does not work in WCS 2.0.1
Puolesta Andrea Aime wrote:
On Fri, Oct 9, 2015 at 1:28 PM, Rahkonen Jukka (MML) <jukka.rahkonen@…6847…> wrote:
Hi Andrea,
Great news. I took some measures if you want to compare: GDAL 2.1-dev with OpenJPEG driver is using 1.4 GB of memory and the conversion of one jp2 into tiled tiff takes 16 seconds. You should have no need to accept anything worse.
I have what comes in stock with the distribution, 1.10.1
1.10 is two years old and current GDAL version is 2.0.1 but we know from the Geoserver project that it may be hard for the people to use the cutting edge versions…
Or did you run commands in parallel?
Nope.
The input JPEG2000 images are INSPIRE compliant and OpenJPEG handles them quite well. Perhaps it would be a time to add GDAL OpenJPEG driver to the supported GDAL image formats http://docs.geoserver.org/stable/en/user/data/raster/gdal.html#data-gdal as an open source alternative for JP2ECW and JP2KAK?
It would be a great idea, pending funding. Honestly i have yet to understand why we don’t have
a single generic driver that can work against whatever is available (maybe at reduced functionality
level compared to a specific format one).
Reasonable tiling structure would be nice to have for large output files. I would immediately convert the output tiff which has this wide stripes “Band 1 Block=24000x8 Type=Byte, ColorInterp=Red” into 256x256 tiled GeoTIFF before using it for anything serious. However, I guess that WCS users would like to get an output that is immediately usable without further processing.
Tiling is also defined in the document “OGC® Web Coverage Service 2.0 Interface Standard - GeoTIFF Coverage Encoding Extension” https://portal.opengeospatial.org/files/?artifact_id=51142
Mapserver seems to implement this extension which brings support for these selections:
GEOTIFF:COMPRESSION=compression: The compression method used for the returned image. Valid options are: None, PackBits, Deflate, Huffman, LZW and JPEG.
GEOTIFF:JPEG_QUALITY=1-100: When the compression method JPEG is chosen, this value defines the quality of the algorithm.
GEOTIFF:PREDICTOR=None|Horizontal|FloatingPoint: The predictor value for the LZW and Deflate compression methods.
GEOTIFF:INTERLEAVE=Band|Pixel: Defines wether the image shall be band or pixel interleaved.
GEOTIFF:TILING=true|false: Defines if the output image shall be internally tiled.
GEOTIFF:TILEWIDTH=tilewidth, GEOTIFF:TILEHEIGHT=tileheight: Define the size of the internal tiles. Must be positive integer divisible by 16.
Yes, we do support these parameters, if none is provided, the native structure of the inputs is used.
What is the “native structure” in this case? If you used gdalwarp command with –co tiled yes then the images in the mosaic have internal tiles of size 256x256 pixels, and each granule of the mosaic is 12000x12000 pixels. I which phase the stripes of 24000x8 pixels are formed?
I have been wondering what would be some practical maximum file size that WCS service should be able to deliver. 1-2 GB of high resolution imagery does not cover especially large area so probably the service should be made to survive such requests. However, above that the processing and data transfer might take too long time and lead to timeouts, truncated files and other problems. I wonder also how the servers would handle many concurrent large requests. But coverages like nationwide DEMs can be very large and WCS does not directly support paging yet so I do not know how a user could collect the whole coverage from WCS.
The only option would be to make several request, making sure they line up with the pixel native
structure.
Mapserver and Rasdaman define the RectifiedGrid for EPSG:4326 in the same way than in the examples of the document “OGC® GML Application Schema - Coverages - GeoTIFF Coverage Encoding Profile”
https://portal.opengeospatial.org/files/?artifact_id=54813
I paste the example below. In short, it defines that firs axis is “lat” and the second is “long”. First offset vector is increasing values along the second axis (long) and the second offset vector is decreasing values along the firs axis (lat).
This is a mistake imho, somewhere one should clarify that the pixels are not lined up with the axis, but flipped instead.
I will try and ask what Stephan Meissl and Peter Bauman have to say about this. I tried to read about RectifiedGrids from around page 214/437 of the GML 3.2.1 spec but it did clarify anything for me.
-Jukka-
Cheers
Andrea
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.