Re: [gdal-dev] Extracting (arbitrary?) overviews from ECW file
Markus, I believe the GDAL ECW driver will pass RasterIO() requests through to the ECW SDK to evaluate meaning that there is no constraint based on the advertized power-of-two overviews exposed from GDAL and no loss of quality. Best regards, Frank On Wed, Sep 4, 2013 at 6:52 AM, Markus Schneider wrote: > Dear list, > > I am new to programming with GDAL (and to the ECW format). Let me say > thank you first, because my first experiences have been rather pleasant, > even if my setup is relatively involved (thanks everybody for providing > good documentation): > > - Ubuntu 12.04 (AMD64) > - GDAL 1.10.1 (build from source) > - ECW SDK 5.0 > - GDAL Java bindings > > I successfully created a toy Java class for extracting regions from an > ECW file. Speed is impressive. > > My observations/questions: > > - If I understand correctly, ECW files internally do not have such a > thing as fixed overviews. However, ECW supports extraction of regions > with specified resolution on-the-fly. Is this correct? > - GDAL API reports overviews for ECW datasets. Having a first look at > the code, it seems to generate overview dimensions by subsequently > dividing height and width by two (until a minium side length of 128 has > been reached). > > Final question: Is it possible to efficiently retrieve (regions of) > overviews at self-defined scales using the GDAL API? Or do I have to use > the ECW SDK for that? > > Keep up the good work. Thanks for any pointers. > > Best regards, > Markus > > -- > Markus Schneider > CEO > > Occam Labs UG (haftungsbeschränkt) > Godesberger Allee 139 > 53175 Bonn, Germany > > +49 228 93798874 > > http://www.occamlabs.de > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] A strange thing with a png geospatial file and gdalwarp. Is it a bug?
aborruso wrote > I have changed only the file format, and I obtain different results. > > Is this normal? It is "normal", because more than the format has been changed. Compare the CRS definitions in png vs. tif and you'll find and additional extension definition in the tif: EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs"] The above "auto-correction" includes the +nadgrids=@null parameter, which in return avoids the "change of ellipsoid" step in the transformation. Hermann -- View this message in context: http://osgeo-org.1560.x6.nabble.com/A-strange-thing-with-a-png-geospatial-file-and-gdalwarp-Is-it-a-bug-tp5075948p5076013.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Extracting (arbitrary?) overviews from ECW file
Dear list, I am new to programming with GDAL (and to the ECW format). Let me say thank you first, because my first experiences have been rather pleasant, even if my setup is relatively involved (thanks everybody for providing good documentation): - Ubuntu 12.04 (AMD64) - GDAL 1.10.1 (build from source) - ECW SDK 5.0 - GDAL Java bindings I successfully created a toy Java class for extracting regions from an ECW file. Speed is impressive. My observations/questions: - If I understand correctly, ECW files internally do not have such a thing as fixed overviews. However, ECW supports extraction of regions with specified resolution on-the-fly. Is this correct? - GDAL API reports overviews for ECW datasets. Having a first look at the code, it seems to generate overview dimensions by subsequently dividing height and width by two (until a minium side length of 128 has been reached). Final question: Is it possible to efficiently retrieve (regions of) overviews at self-defined scales using the GDAL API? Or do I have to use the ECW SDK for that? Keep up the good work. Thanks for any pointers. Best regards, Markus -- Markus Schneider CEO Occam Labs UG (haftungsbeschränkt) Godesberger Allee 139 53175 Bonn, Germany +49 228 93798874 http://www.occamlabs.de signature.asc Description: OpenPGP digital signature ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR with SDE support
Hello, Is there a prebuilt version of OGR with ArcSDE-support? /Johan Johan Hallgren Sweco Position AB Telefon direkt +46 (0)23 46492 Mobil +46 (0)73 8006492 johan.hallg...@sweco.se ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] A strange thing with a png geospatial file and gdalwarp. Is it a bug?
Hi Hermann, thank you very much. peifer wrote > At least it isn't a bug. Without -s_srs, the CRS info from the png file is > used which specifies TOWGS84[0,0,0,0,0,0,0]. When specifying the EPSG code > via -s_srs, the parameter +nadgrids=@null is used (in both cases EPSG:3857 > and EPSG:3785). But there is another strange thing. Try to convert the original png file in GTiff p with gdal_translate. Then apply the same gdalwarp commands. In both, with -s_srs and without -s_srs parameter, you obtain the same bounding box. I have changed only the file format, and I obtain different results. Is this normal? Best regards, Andrea -- View this message in context: http://osgeo-org.1560.x6.nabble.com/A-strange-thing-with-a-png-geospatial-file-and-gdalwarp-Is-it-a-bug-tp5075948p5076002.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] A strange thing with a png geospatial file and gdalwarp. Is it a bug?
aborruso wrote > Dear all, > I have a geospatial png file - http://ge.tt/7tmMR7r/v/0?c -and gdalinfo > give me this projection info: > > PROJCS["Popular Visualisation CRS / Mercator", > GEOGCS["Popular Visualisation CRS", > DATUM["Popular_Visualisation_Datum", > SPHEROID["Popular Visualisation Sphere",6378137,0, > AUTHORITY["EPSG","7059"]], > TOWGS84[0,0,0,0,0,0,0], > AUTHORITY["EPSG","6055"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.01745329251994328, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4055"]], > UNIT["metre",1, > AUTHORITY["EPSG","9001"]], > PROJECTION["Mercator_1SP"], > PARAMETER["central_meridian",0], > PARAMETER["scale_factor",1], > PARAMETER["false_easting",0], > PARAMETER["false_northing",0], > AUTHORITY["EPSG","3785"], > AXIS["X",EAST], > AXIS["Y",NORTH]] > > It's EPSG:3785. > > If I run this command: > > gdalwarp -s_srs EPSG:3785 -t_srs EPSG:4326 -of GTiff "input.png" > "output.tif" > > The output file has this extent: > > Upper Left ( -0.6064394, 44.7016078) ( 0d36'23.18"W, 44d42' 5.79"N) > Lower Left ( -0.6064394, 44.6980730) ( 0d36'23.18"W, 44d41'53.06"N) > Upper Right ( -0.5975973, 44.7016078) ( 0d35'51.35"W, 44d42' 5.79"N) > Lower Right ( -0.5975973, 44.6980730) ( 0d35'51.35"W, 44d41'53.06"N) > Center ( -0.6020184, 44.6998404) ( 0d36' 7.27"W, 44d41'59.43"N) > > If I run this command, without -s_srs parameter: > > gdalwarp -t_srs EPSG:4326 -of GTiff "Avenue de Mont-de-Marsan.png" > "male.tif" > > This output has an extent that is different from the previous (look at > latitude): > > Upper Left ( -0.6064394, 44.8937072) ( 0d36'23.18"W, 44d53'37.35"N) > Lower Left ( -0.6064394, 44.8901724) ( 0d36'23.18"W, 44d53'24.62"N) > Upper Right ( -0.5975973, 44.8937072) ( 0d35'51.35"W, 44d53'37.35"N) > Lower Right ( -0.5975973, 44.8901724) ( 0d35'51.35"W, 44d53'24.62"N) > Center ( -0.6020183, 44.8919398) ( 0d36' 7.27"W, 44d53'30.98"N) > > Is it normal? At least it isn't a bug. Without -s_srs, the CRS info from the png file is used which specifies TOWGS84[0,0,0,0,0,0,0]. When specifying the EPSG code via -s_srs, the parameter +nadgrids=@null is used (in both cases EPSG:3857 and EPSG:3785). In the former case, a "change of ellipsoid" is performed during coordinate transformation (from the sphere to WGS84), in the latter case, this isn't done. The difference is a latitude-only offset of around 20 km. What you usually want is the latter transformation, i.e. no change of ellipsoid. Hermann -- View this message in context: http://osgeo-org.1560.x6.nabble.com/A-strange-thing-with-a-png-geospatial-file-and-gdalwarp-Is-it-a-bug-tp5075948p5075998.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] A strange thing with a png geospatial file and gdalwarp. Is it a bug?
Hello, I confirm the problem. I don't know how to fix the bug, nor if it really a bug in GDAL, but I can provide a workaround : use EPSG:3857 instead of EPSG:3785, which is obsolete. gdalwarp -s_srs epsg:3857 -t_srs EPSG:4326 -of GTiff "Avenue de Mont-de-Marsan.png" test.tif Upper Left ( -0.6064394, 44.7016078) ( 0d36'23.18"W, 44d42' 5.79"N) Lower Left ( -0.6064394, 44.6980730) ( 0d36'23.18"W, 44d41'53.06"N) Upper Right ( -0.5975973, 44.7016078) ( 0d35'51.35"W, 44d42' 5.79"N) Lower Right ( -0.5975973, 44.6980730) ( 0d35'51.35"W, 44d41'53.06"N) Center ( -0.6020184, 44.6998404) ( 0d36' 7.27"W, 44d41'59.43"N) Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] A strange thing with a png geospatial file and gdalwarp. Is it a bug?
Here is the correct URL of the test file, sorry: https://dl.dropboxusercontent.com/u/103202/trash/file_test.zip -- View this message in context: http://osgeo-org.1560.x6.nabble.com/A-strange-thing-with-a-png-geospatial-file-and-gdalwarp-Is-it-a-bug-tp5075948p5075966.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] A strange thing with a png geospatial file and gdalwarp. Is it a bug?
Dear all, I have a geospatial png file - http://ge.tt/7tmMR7r/v/0?c -and gdalinfo give me this projection info: PROJCS["Popular Visualisation CRS / Mercator", GEOGCS["Popular Visualisation CRS", DATUM["Popular_Visualisation_Datum", SPHEROID["Popular Visualisation Sphere",6378137,0, AUTHORITY["EPSG","7059"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6055"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4055"]], UNIT["metre",1, AUTHORITY["EPSG","9001"]], PROJECTION["Mercator_1SP"], PARAMETER["central_meridian",0], PARAMETER["scale_factor",1], PARAMETER["false_easting",0], PARAMETER["false_northing",0], AUTHORITY["EPSG","3785"], AXIS["X",EAST], AXIS["Y",NORTH]] It's EPSG:3785. If I run this command: gdalwarp -s_srs EPSG:3785 -t_srs EPSG:4326 -of GTiff "input.png" "output.tif" The output file has this extent: Upper Left ( -0.6064394, 44.7016078) ( 0d36'23.18"W, 44d42' 5.79"N) Lower Left ( -0.6064394, 44.6980730) ( 0d36'23.18"W, 44d41'53.06"N) Upper Right ( -0.5975973, 44.7016078) ( 0d35'51.35"W, 44d42' 5.79"N) Lower Right ( -0.5975973, 44.6980730) ( 0d35'51.35"W, 44d41'53.06"N) Center ( -0.6020184, 44.6998404) ( 0d36' 7.27"W, 44d41'59.43"N) If I run this command, without -s_srs parameter: gdalwarp -t_srs EPSG:4326 -of GTiff "Avenue de Mont-de-Marsan.png" "male.tif" This output has an extent that is different from the previous (look at latitude): Upper Left ( -0.6064394, 44.8937072) ( 0d36'23.18"W, 44d53'37.35"N) Lower Left ( -0.6064394, 44.8901724) ( 0d36'23.18"W, 44d53'24.62"N) Upper Right ( -0.5975973, 44.8937072) ( 0d35'51.35"W, 44d53'37.35"N) Lower Right ( -0.5975973, 44.8901724) ( 0d35'51.35"W, 44d53'24.62"N) Center ( -0.6020183, 44.8919398) ( 0d36' 7.27"W, 44d53'30.98"N) Is it normal? I'm using GDAL 1.10.1, released 2013/08/26, downloaded from here http://vbkto.dyndns.org/sdk/. Thank you, Andrea -- View this message in context: http://osgeo-org.1560.x6.nabble.com/A-strange-thing-with-a-png-geospatial-file-and-gdalwarp-Is-it-a-bug-tp5075948.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 1.10 build fails on FreeBSD
Am 2013-09-03 14:55, schrieb Frank Broniewski: Hi all, I tried updating Gdal to the latest version on my FreeBSD system, but the build fails: c postgisrasterdataset.cpp -fPIC -DPIC -o ../o/.libs/postgisrasterdataset.o postgisrasterdataset.cpp: In function 'void GDALRegister_PostGISRaster()': postgisrasterdataset.cpp:2096: error: 'GDAL_DMD_SUBDATASETS' was not declared in this scope gmake[2]: *** [../o/postgisrasterdataset.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts/postgisraster' gmake[1]: *** [postgisraster-install-obj] Error 2 gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.10.1/frmts' gmake: *** [frmts-target] Error 2 *** [do-build] Error code 1 PostGIS is POSTGIS="1.5.3" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.7.8" USE_STATS (procs from 1.5 r5385 need upgrade) so apparently no raster support ... Is this a GDAL issue or shall I report this to the FreeBSD crew? Or is my PostGIS too old ??? Frank Got it working, it was a FreeBSD issue: http://freebsd.1045724.n5.nabble.com/GDAL-1-10-build-fails-on-FreeBSD-td5841243.html Thanks to everybody for responding ... Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
