date:20220127

Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly

2022-01-27 Thread dthorne


The S57 file we used to test with each language and it is read correctly in C# 
& python, our c++ project is the problem. The S57 is the one generated in 
"\gdal-3.4.1\autotest\ogr\data\s57" when we built gdal. But [ here is a link ]( 
https://drive.google.com/file/d/1AGCHEQMWHvs6IJgDW45KJvK6gm-r_cpH/view?usp=sharing
 ) to that s57 folder.

The specific s57 file we used was "1B5X02NE.000" which in reference to the 
first image I linked should have 13 layers. 
Thanks in advance for the help! 

Daniel



-Original Message-
From: "kusala nine" 
Sent: Friday, January 28, 2022 7:04am
To: "Momtchil Momtchev" 
Cc: dtho...@pivotmaritime.com, gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly


I’m an S57 expert. Send me the data - I’ll take a look, there’s a lot of leeway 
with S57 and sometimes it trips up GDAL. I had issues with AML data before 
which is similar…
Jonathan. 


Sent from my iPhone

On 27 Jan 2022, at 10:44, Momtchil Momtchev  wrote:



 
Your code looks OK, can you send me the file too?
 
On 27/01/2022 03:34, [ dtho...@pivotmaritime.com ]( 
mailto:dtho...@pivotmaritime.com ) wrote:
Here is the C++ code we have written to read the test s57 file. 
[ https://pastebin.com/seXrkgmB ]( https://pastebin.com/seXrkgmB )
  
 We feel that it is some setup stuff we have missed but can't find any clear 
information. For example we hadn't seen GDAL_DATA environment variables 
mentioned in any of the documentation we've tried following until Even 
mentioned it. Are there any other setup stuff we need to do? [ 
 ]( https://pastebin.com/seXrkgmB )


-Original Message-
 From: "Momtchil Momtchev" [  ]( 
mailto:momtc...@momtchev.com )
 Sent: Wednesday, January 26, 2022 9:21pm
 To: [ dtho...@pivotmaritime.com ]( mailto:dtho...@pivotmaritime.com ), [ 
gdal-dev@lists.osgeo.org ]( mailto:gdal-dev@lists.osgeo.org )
 Subject: Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly



 
Can you post your C++ code? Generally, you have more chances of getting an 
answer for this type of question on [ https://gis.stackexchange.com/ ]( 
https://gis.stackexchange.com/ )
 
On 24/01/2022 06:36, [ dtho...@pivotmaritime.com ]( 
mailto:dtho...@pivotmaritime.com ) wrote:
Hi, So I am trying to get a test C++ project built to read S57 files using the 
gdal/ogr C++ library. I have previously used the C# library that is on there 
NuGet manager which states v2.4.4 and that seems to read the s57 without 
issues. Also tried python and that seems to read it with no issues. However, I 
am having a problem with the C++ test project. Having built the C++ library 
into the .lib and .dll files I have included them into a blank project and 
implemented the functions to read the s57 file, however it is only reporting 5 
layers.These 5 layers are the same no matter the s57 file. And 4 out of those 5 
layers are not actually layers.Using the autotest generated s57 file as a unit 
test to cross check, there is supposed to be 13 layers. 
 Note: I had feedback from Even indicating the setup environment is probably 
wrong. And to set up the GDAL_DATA environment variable, so we've made an 
environment variable referencing the gdal/data folder and that hasn't fixed the 
problem, but I think it's on the right track as Even said they could reproduce 
the problem if not setup correctly.
Has anyone had success reading s57 files with a C++ 3.4.1. project that could 
possibly help get this going?

 Link to reference Image: [ https://imgur.com/a/KwmqZSe ]( 
https://imgur.com/a/KwmqZSe )
Regards,Daniel

___ gdal-dev mailing list [ 
gdal-dev@lists.osgeo.org ]( mailto:gdal-dev@lists.osgeo.org ) [ 
https://lists.osgeo.org/mailman/listinfo/gdal-dev ]( 
https://lists.osgeo.org/mailman/listinfo/gdal-dev )
-- Momtchil Momtchev [  ]( mailto:momtc...@momtchev.com )
-- Momtchil Momtchev [  ]( mailto:momtc...@momtchev.com 
)___
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] GDAL/OGR 3.4.1 not reading S57 correctly

2022-01-27 Thread kusala nine via gdal-dev

I’m an S57 expert. Send me the data - I’ll take a look, there’s a lot of leeway 
with S57 and sometimes it trips up GDAL. I had issues with AML data before 
which is similar…

Jonathan. 

Sent from my iPhone

> On 27 Jan 2022, at 10:44, Momtchil Momtchev  wrote:
> 
> 
> 
> 
> Your code looks OK, can you send me the file too?
> 
> 
> 
> On 27/01/2022 03:34, dtho...@pivotmaritime.com wrote:
>> Here is the C++ code we have written to read the test s57 file. 
>> https://pastebin.com/seXrkgmB
>>  
>> We feel that it is some setup stuff we have missed but can't find any clear 
>> information. For example we hadn't seen GDAL_DATA environment variables 
>> mentioned in any of the documentation we've tried following until Even 
>> mentioned it. Are there any other setup stuff we need to do? 
>> 
>> 
>> -Original Message-
>> From: "Momtchil Momtchev" 
>> Sent: Wednesday, January 26, 2022 9:21pm
>> To: dtho...@pivotmaritime.com, gdal-dev@lists.osgeo.org
>> Subject: Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly
>> 
>>  
>> Can you post your C++ code? Generally, you have more chances of getting an 
>> answer for this type of question on https://gis.stackexchange.com/
>>  
>> On 24/01/2022 06:36, dtho...@pivotmaritime.com wrote:
>> Hi, 
>> So I am trying to get a test C++ project built to read S57 files using the 
>> gdal/ogr C++ library. 
>> I have previously used the C# library that is on there NuGet manager which 
>> states v2.4.4 and that seems to read the s57 without issues. Also tried 
>> python and that seems to read it with no issues. 
>> 
>> However, I am having a problem with the C++ test project. Having built the 
>> C++ library into the .lib and .dll files I have included them into a blank 
>> project and implemented the functions to read the s57 file, however it is 
>> only reporting 5 layers.
>> These 5 layers are the same no matter the s57 file. And 4 out of those 5 
>> layers are not actually layers.
>> Using the autotest generated s57 file as a unit test to cross check, there 
>> is supposed to be 13 layers. 
>> 
>> Note: I had feedback from Even indicating the setup environment is probably 
>> wrong. And to set up the GDAL_DATA environment variable, so we've made an 
>> environment variable referencing the gdal/data folder and that hasn't fixed 
>> the problem, but I think it's on the right track as Even said they could 
>> reproduce the problem if not setup correctly.
>> 
>> Has anyone had success reading s57 files with a C++ 3.4.1. project that 
>> could possibly help get this going?
>> 
>> Link to reference Image: https://imgur.com/a/KwmqZSe
>> 
>> Regards,
>> Daniel
>> 
>> 
>> ___ gdal-dev mailing list 
>> gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
>> -- Momtchil Momtchev 
> -- 
> Momtchil Momtchev 
> ___
> 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] [Question] PROJ4String to WKT2 Transformations

2022-01-27 Thread Felipe Matas via gdal-dev

 Hi, Thx!, now is a lot more clear!, I have a shape with this CRS:
Coordinate Reference System:
  User input: WGS 84 / UTM zone 19S 
  wkt:
PROJCRS["WGS 84 / UTM zone 19S",
    BASEGEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
    ELLIPSOID["WGS 84",6378137,298.257223563,
    LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
    ANGLEUNIT["degree",0.0174532925199433]],
    ID["EPSG",4326]],
    CONVERSION["UTM zone 19S",
    METHOD["Transverse Mercator",
    ID["EPSG",9807]],
    PARAMETER["Latitude of natural origin",0,
    ANGLEUNIT["Degree",0.0174532925199433],
    ID["EPSG",8801]],
    PARAMETER["Longitude of natural origin",-69,
    ANGLEUNIT["Degree",0.0174532925199433],
    ID["EPSG",8802]],
    PARAMETER["Scale factor at natural origin",0.9996,
    SCALEUNIT["unity",1],
    ID["EPSG",8805]],
    PARAMETER["False easting",50,
    LENGTHUNIT["metre",1],
    ID["EPSG",8806]],
    PARAMETER["False northing",1000,
    LENGTHUNIT["metre",1],
    ID["EPSG",8807]]],
    CS[Cartesian,2],
    AXIS["(E)",east,
    ORDER[1],
    LENGTHUNIT["metre",1]],
    AXIS["(N)",north,
    ORDER[2],
    LENGTHUNIT["metre",1]],
    ID["EPSG",32719]]
This CRS is a tranformation from WGS84 to   UTM zone 19S?, If is a 
transfomation, I don't know, if the data of the file is already transformed, 
or, the data will be transformed to  UTM zone 19S.
Because, in case it is already transform, to recover the original, I should 
rollback the transformation and set the WGS84 as the CRS to can use WKT2 in the 
right way. (skipping the WGS84 pivot)

Thx.
El martes, 11 de enero de 2022 12:15:14 a. m. GMT-3, Rahkonen Jukka (MML) 
 escribió:  
 
 
Hi,
 
  
 
The more or less same question seems to be asked some time ago in 
gis.stackexchange 
https://gis.stackexchange.com/questions/420378/can-we-construct-wkt2-from-proj4string-correctly.
 
  
 
-Jukka Rahkonen-
 
  
 
  
 
Lähettäjä: gdal-dev Puolesta Felipe Matas via 
gdal-dev
Lähetetty: maanantai 10. tammikuuta 2022 22.07
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] [Question] PROJ4String to WKT2 Transformations
 
  
 
Hi hi, I was looking for someplace to ask about this, and I was in doubt is was 
here or in PROJ, but lets do a try.
 
  
 
Actually, probably I'm not the only one, I have some questions about how WKT2 
and PROJ4Strings are transformed.
 
  
 
>From what I read, a PROJ4String don't have enough info to construct a precise 
>WKT2, so, actually how PROJ4String is deprecated my main question is how to 
>construct the right WKT2, there is a lot o data stored in the old format, 
>there is usually no more information, and even the software/hardware that get 
>the data in some way save all of it with all the errors.
 
  
 
Actually, we can transform a old CRS to a WKT2:
 
  
 > st_crs("+type=crs +proj=utm +zone=19 +south +datum=WGS84 +units=m +no_defs 
 > +ellps=WGS84 +towgs84=0,0,0" + ) Coordinate Reference System:   User input: 
 > +type=crs +proj=utm +zone=19 +south +datum=WGS84 +units=m +no_defs 
 > +ellps=WGS84 +towgs84=0,0,0    wkt: BOUNDCRS[     SOURCECRS[     
 > PROJCRS["unknown",     BASEGEOGCRS["unknown",     
 > DATUM["World Geodetic System 1984",     ELLIPSOID["WGS 
 > 84",6378137,298.257223563,     LENGTHUNIT["metre",1]],   
 >   ID["EPSG",6326]],     PRIMEM["Greenwich",0,    
 >  ANGLEUNIT["degree",0.0174532925199433],     
 > ID["EPSG",8901]]],     CONVERSION["UTM zone 19S",     
 > METHOD["Transverse Mercator",     ID["EPSG",9807]],  
 >    PARAMETER["Latitude of natural origin",0,     
 > ANGLEUNIT["degree",0.0174532925199433],     
 > ID["EPSG",8801]],     PARAMETER["Longitude of natural 
 > origin",-69,     ANGLEUNIT["degree",0.0174532925199433], 
 >     ID["EPSG",8802]],     PARAMETER["Scale factor at 
 > natural origin",0.9996,     SCALEUNIT["unity",1],    
 >      ID["EPSG",8805]],     PARAMETER["False easting",50, 
 >     LENGTHUNIT["metre",1],     
 > ID["EPSG",8806]],     PARAMETER["False northing",1000,   
 >   LENGTHUNIT["metre",1],     ID["EPSG",8807]],   
 >   ID["EPSG",17019]],     CS[Cartesian,2],    
 >  AXIS["(E)",east,     ORDER[1],     
 > LENGTHUNIT["metre",1,     ID["EPSG",9001]]],     
 > AXIS["(N)",north,     ORDER[2],     
 > LENGTHUNIT["metre",1,     ID["EPSG",9001],     
 > TARGETCRS[

[gdal-dev] What to do with DODS drivers ?

2022-01-27 Thread Even Rouault


Hi,

The GDAL and OGR DODS drivers were announced to be planned for removal 
for 3.5. Someone jumped yesterday in 
https://github.com/OSGeo/gdal/issues/5173 to ask to keep them (or maybe 
just one of the raster of vector one, but they didn't specify which one 
they use).


To what extent is that still useful and working ? It looks like 
protocols doing things similar to WCS or WFS ?


As I indicated in the ticket, our unit tests for those drivers are all 
disabled currently. If someone has still interest in keeping those 
drivers, they should quickly come with a pull request to resurrect the 
tests.


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

Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly

2022-01-27 Thread Momtchil Momtchev



    Your code looks OK, can you send me the file too?


On 27/01/2022 03:34, dtho...@pivotmaritime.com wrote:


Here is the C++ code we have written to read the test s57 file.
https://pastebin.com/seXrkgmB

We feel that it is some setup stuff we have missed but can't find any 
clear information. For example we hadn't seen GDAL_DATA environment 
variables mentioned in any of the documentation we've tried following 
until Even mentioned it. Are there any other setup stuff we need to do?



-Original Message-
From: "Momtchil Momtchev" 
Sent: Wednesday, January 26, 2022 9:21pm
To: dtho...@pivotmaritime.com, gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly

Can you post your C++ code? Generally, you have more chances of 
getting an answer for this type of question on 
https://gis.stackexchange.com/


On 24/01/2022 06:36, dtho...@pivotmaritime.com wrote:

Hi,
So I am trying to get a test C++ project built to read S57 files
using the gdal/ogr C++ library.
I have previously used the C# library that is on there NuGet
manager which states v2.4.4 and that seems to read the s57 without
issues. Also tried python and that seems to read it with no issues.

However, I am having a problem with the C++ test project. Having
built the C++ library into the .lib and .dll files I have included
them into a blank project and implemented the functions to read
the s57 file, however it is only reporting 5 layers.
These 5 layers are the same no matter the s57 file. And 4 out of
those 5 layers are not actually layers.
Using the autotest generated s57 file as a unit test to cross
check, there is supposed to be 13 layers.

Note: I had feedback from Even indicating the setup environment is
probably wrong. And to set up the GDAL_DATA environment variable,
so we've made an environment variable referencing the gdal/data
folder and that hasn't fixed the problem, but I think it's on the
right track as Even said they could reproduce the problem if not
setup correctly.

*Has anyone had success reading s57 files with a C++ 3.4.1.
project that could possibly help get this going?*

Link to reference Image: https://imgur.com/a/KwmqZSe


Regards,
Daniel


___ gdal-dev mailing
list gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- Momtchil Momtchev 


--
Momtchil Momtchev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly

Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly

Re: [gdal-dev] [Question] PROJ4String to WKT2 Transformations

[gdal-dev] What to do with DODS drivers ?

Re: [gdal-dev] GDAL/OGR 3.4.1 not reading S57 correctly

5 matches

Site Navigation

Mail list logo

Footer information