Puolesta Andrea Aime wrote:
On Fri, Oct 9, 2015 at 1:28 PM, Rahkonen Jukka (MML) <[email protected]<mailto:[email protected]>> 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://www.geo-solutions.it 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. -------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
