[gdal-dev] Reading from PNG file in Java from using GDAL
I've used gdalwarp.exe to project a tif-file from EPSG:4326 to EPSG:32635 and
storing it in the PNG-format:
gdalwarp.exe -dstalpha -t_srs EPSG:32635 -s_srs EPSG:4326 -if GTiff -of PNG
-et 0.125 -r cubicspline -co COMPRESS=LZW -co WORLDFILE=YES H:\somlos_8.tif
H:\trans32635.png
Then I try to read that PNG_file in JAVA with GDAL:
import org.geotools.coverage.grid.GridCoverage2D;
import org.geotools.coverage.grid.io.AbstractGridFormat;
import org.geotools.coverage.grid.io.GridCoverage2DReader;
import org.geotools.coverage.grid.io.GridFormatFinder;
import org.geotools.factory.Hints;
import org.geotools.gce.geotiff.GeoTiffFormat;
public class Test {
public Test() {
AbstractGridFormat format =
GridFormatFinder.findFormat("H:\\trans32635.png");
Hints hints=null;;
GridCoverage2DReader reader = null;
if (!format.getName().equals("Unknown Format"))
hints = new Hints();
if (format instanceof GeoTiffFormat) {
hints = new Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER,
Boolean.TRUE);
}
try {
reader = format.getReader("H:\\trans32635.png", hints);
GridCoverage2D cov = null;
cov = reader.read(null); // here it breaks
...
...
} catch (Exception e1) {
e1.printStackTrace();
}
}
}
The problem is reading "GridCoverage2D" from the reader "cov =
reader.read(null);", where it breaks. It works with the original TIF-file.
The program breaks here:
java.awt.geom.affineTransform.class (public AffineTransform(AffineTransform Tx)
{ this.m00 = Tx.m00; )
I have the gt-image module and matching .wld, .prj and .png.aux.xml files.
I'm running the JAVA-program on Windows 10 and using GDAL 3.21 and org.geotools
0.0.1-SNAPSHOT.
Any ideas?
Kind regards,
Paul
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
As a result of our fundraising activity and development of NumFOCUS as a financial conduit, it is my pleasure to put forward a motion to approve Even Rouault as a contracted GDAL maintainer for the year 2021-2022 beginning on August 1st, 2021 and ending July 31st, 2022. Excellent news! It’s so encouraging to see a strong measure of stability and future proofing established. Matt Geomatics Developer and Administrator | Environment | T 867-667-8133 | Yukon.ca Hours: 08:30-16:30, Mon-Wed: Office, Thu: Remote, Fri: Away. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
+1 KurtS On Tue, Aug 17, 2021 at 8:35 AM Howard Butler wrote: > Dear PSC, > > As a result of our fundraising activity and development of NumFOCUS as a > financial conduit, it is my pleasure to put forward a motion to approve > Even Rouault as a contracted GDAL maintainer for the year 2021-2022 > beginning on August 1st, 2021 and ending July 31st, 2022. > > Details of the maintenance tasking and duties can be found at the > previously approved RFC 83 > https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html > > The terms of the contract are for 833 hours at $120/hr USD. > > Howard > > PS I will coordinating the contracting activity in my role as the GDAL > NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. > Please contact us directly with any comments or concerns. > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
+1 Tamas > 2021. aug. 17. dátummal, 17:35 időpontban Howard Butler írta: > > Dear PSC, > > As a result of our fundraising activity and development of NumFOCUS as a > financial conduit, it is my pleasure to put forward a motion to approve Even > Rouault as a contracted GDAL maintainer for the year 2021-2022 beginning on > August 1st, 2021 and ending July 31st, 2022. > > Details of the maintenance tasking and duties can be found at the previously > approved RFC 83 > https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html > > The terms of the contract are for 833 hours at $120/hr USD. > > Howard > > PS I will coordinating the contracting activity in my role as the GDAL > NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. > Please contact us directly with any comments or concerns. > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
I’m not a member of the core group, or even a direct gdal user, so I can’t officially vote, but I am really impressed with how the core group has managed this process. And from a far distance, Even seems like a great choice. Keep up the good work! Jerry Gerald C. Nelson Professor Emeritus, UIUC +1 217-390-7888 (cell) +1 970-639-2079 (land line) Skype: jerrynelson http://bit.ly/1arho7d From: gdal-dev on behalf of Sean Gillies Date: Tuesday, August 17, 2021 at 9:58 AM To: gdal dev Subject: Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer +1 from me. What a great milestone for the project! On Tue, Aug 17, 2021 at 9:34 AM Howard Butler mailto:how...@hobu.co>> wrote: Dear PSC, As a result of our fundraising activity and development of NumFOCUS as a financial conduit, it is my pleasure to put forward a motion to approve Even Rouault as a contracted GDAL maintainer for the year 2021-2022 beginning on August 1st, 2021 and ending July 31st, 2022. Details of the maintenance tasking and duties can be found at the previously approved RFC 83 https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html The terms of the contract are for 833 hours at $120/hr USD. Howard PS I will coordinating the contracting activity in my role as the GDAL NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. Please contact us directly with any comments or concerns. -- Sean Gillies ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
+1 from me. What a great milestone for the project! On Tue, Aug 17, 2021 at 9:34 AM Howard Butler wrote: > Dear PSC, > > As a result of our fundraising activity and development of NumFOCUS as a > financial conduit, it is my pleasure to put forward a motion to approve > Even Rouault as a contracted GDAL maintainer for the year 2021-2022 > beginning on August 1st, 2021 and ending July 31st, 2022. > > Details of the maintenance tasking and duties can be found at the > previously approved RFC 83 > https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html > > The terms of the contract are for 833 hours at $120/hr USD. > > Howard > > PS I will coordinating the contracting activity in my role as the GDAL > NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. > Please contact us directly with any comments or concerns. > -- Sean Gillies ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
+1 Norman On Tue, Aug 17, 2021 at 10:53 AM Frank Warmerdam wrote: > +1 FrankW ! > > On Tue, Aug 17, 2021 at 10:33 PM Howard Butler wrote: > >> Dear PSC, >> >> As a result of our fundraising activity and development of NumFOCUS as a >> financial conduit, it is my pleasure to put forward a motion to approve >> Even Rouault as a contracted GDAL maintainer for the year 2021-2022 >> beginning on August 1st, 2021 and ending July 31st, 2022. >> >> Details of the maintenance tasking and duties can be found at the >> previously approved RFC 83 >> https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html >> >> The terms of the contract are for 833 hours at $120/hr USD. >> >> Howard >> >> PS I will coordinating the contracting activity in my role as the GDAL >> NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. >> Please contact us directly with any comments or concerns. >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://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 | +1 650-701-7823 > and watch the world go round - Rush| Geospatial Software Developer > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
+1 FrankW ! On Tue, Aug 17, 2021 at 10:33 PM Howard Butler wrote: > Dear PSC, > > As a result of our fundraising activity and development of NumFOCUS as a > financial conduit, it is my pleasure to put forward a motion to approve > Even Rouault as a contracted GDAL maintainer for the year 2021-2022 > beginning on August 1st, 2021 and ending July 31st, 2022. > > Details of the maintenance tasking and duties can be found at the > previously approved RFC 83 > https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html > > The terms of the contract are for 833 hours at $120/hr USD. > > Howard > > PS I will coordinating the contracting activity in my role as the GDAL > NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. > Please contact us directly with any comments or concerns. > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://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 | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
Dear PSC, As a result of our fundraising activity and development of NumFOCUS as a financial conduit, it is my pleasure to put forward a motion to approve Even Rouault as a contracted GDAL maintainer for the year 2021-2022 beginning on August 1st, 2021 and ending July 31st, 2022. Details of the maintenance tasking and duties can be found at the previously approved RFC 83 https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html The terms of the contract are for 833 hours at $120/hr USD. Howard PS I will coordinating the contracting activity in my role as the GDAL NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. Please contact us directly with any comments or concerns. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] HANA driver proposal
Thanks for your reply, Even. Maxim is on vacation, so let me try to answer on his behalf. Good point about the symbol clashes. We weren’t thinking of that yet. Adding an additional namespace prefix seems to be a good idea. We should introduce that option upstream. Before we implemented our own ODBC wrapper, we checked out existing ones. Indeed, nanodbc seems to be the best maintained wrapper with the most features. However, it does not support batch inserts with data-at-execution parameters (https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/using-arrays-of-parameters?view=sql-server-ver15), which we consider rather important in a spatial context as the length of geometry values can vary greatly. We considered contributing, but batch inserts with data-at-execution parameters are poorly supported by ODBC drivers. Of the drivers we tested, we found that only PostgreSQL and SAP HANA support it the way we understand the specification. Hence, we preferred to write our own wrapper as the data-at-execution parameters support might be considered a buggy feature. Yes, the SAP HANA Client (https://tools.hana.ondemand.com/#hanatools) contains the ODBC driver for SAP HANA (it also contains database connectors for other languages). The driver is not required at compile time, it’s only required at runtime if you want to connect to an SAP HANA database. Can you point us to an example of a GDAL plugin that is offered as download from a GDAL external website? This might be an option, but we would prefer contributing directly to GDAL, of course. Maintaining binary plugin versions externally for all the relevant versions/platforms/compilers will probably be difficult. Would it be sufficient if the OGR SAP HANA driver is reviewed by members of our team? And if that’s not sufficient, what options do we have to find someone who is qualified to do the final review? Thanks, and best regards, Stefan From: gdal-dev On Behalf Of Even Rouault Sent: Friday, August 13, 2021 7:31 PM To: Rylov, Maxim ; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] HANA driver proposal Maxim, > “I assume the driver would depend on the ODBC library, and would require > users to build https://github.com/SAP/odbc-cpp-wrapper as the corresponding > ODBC driver ?” The odbc-cpp-wrapper library is going to be used only during the compilation phase and linked statically, thus end users will get only one dynamic/shared library of the HANA driver. Hence, no additional actions are required from end users. For those who want to compile the GDAL sources with HANA support on their own, the sources of the odbc-cpp-wrapper are needed. However, this step can be omitted if we store a copy of the library in https://github.com/OSGeo/gdal/tree/master/gdal/third_party like we did in QGIS (see https://github.com/qgis/QGIS/tree/master/external/odbccpp). I can anticipate potential issues if both GDAL and QGIS have a odbcpp vendorized copy, and that for some reason they differ in versions. That could cause symbol clashes at runtime. Putting the vendorized copy in a dedicated namespace prefix (GDAL::) could avoid that. Otherwise, isn't the cpl_odbc.h abstraction good enough ? Side note: are you aware of https://github.com/nanodbc/nanodbc that is also a C++ wrapper for ODBC ? (Mateusz one of our PSC members was the main developer of it, although I believe he has retired from it) Note, that any HANA plugin (GDAL/QGIS) also requires the SAP HANA Client (https://tools.hana.ondemand.com/#hanatools) to be able to connect an SAP HANA database. Is that the ODBC driver for SAP HANA ? Unfortunately, we are not able to answer the remaining raised points as they are beyond our expertise. Perhaps they should be addressed in a separate dedicated discussion. Well, if you contribute to GDAL, then that should be in your area of interest and concern :-) I think the main practical issue for this to go forward is for you to find someone who would want to review your contribution. Another option is to propose the OGR SAP HANA driver as a plugin for download from your website. Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
