Fixed
Details
Details
Assignee
Oana Hogoiu
Oana HogoiuReporter
Oana Hogoiu
Oana HogoiuRelevance
Default
Sprint
Add sprint
Affects versions
Components
Priority
Created 2 March 2023 at 13:43
Updated 24 March 2023 at 10:08
Resolved 13 March 2023 at 16:55
Reported in the forum:
https://forum.step.esa.int/t/snap-fails-openning-jp2openjpeg-epsg-4326-images/38717
After investigations, it was noticed that the latest OpenJPEG versions (for this specific EPSG::4326) produce something like this:
<gml:axisName>x</gml:axisName> <gml:axisName>y</gml:axisName> ... <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">-0 8.98315284119521e-05</gml:offsetVector> <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">-8.98315284119521e-05 -0</gml:offsetVector>
while older versions produce something like:
<!--first axis latitude: urn:ogc:def:axis-name:EPSG::4326--> <gml:axisName>Geodetic latitude</gml:axisName> <!--second axis longitude: urn:ogc:def:axis-name:EPSG::4326--> <gml:axisName>Geodetic longitude</gml:axisName> ... <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326"> -0.000004629629630 0</gml:offsetVector> <gml:offsetVector srsName="urn:ogc:def:crs:EPSG::4326">0 0.000004629629630</gml:offsetVector>
Therefore the axis order should not be always interpreted as (y,x) for EPSG::4326 (it should be read as it is in JP2 header, since we don’t know the tool version it was produced with) and also the values within offsetVector should be considered depending on their logic. For example the result produced with the newer versions of OpenJPEG don’t respect the order given in the axis. E.g. the first offsetVector is for stepX (when the first axisName is “x“) and it should have the Y component (the second value) set to 0. [which is not respected if we look at the first example]