I ran into a weird problem with KML with 3D line, v.import failed when
reprojecting it:
WARNING: pj_transform() failed: latitude or longitude exceeded limits
This happened with GRASS 7.4.0 64bit (GDAL 2.2.3) on Windows 10, on my
Ubuntu with latest GRASS it works (GDAL 2.2.1). Weird thing is that I
installed the same version of GRASS on Windows 10 virtual machine and
there it worked without problems.
this is the output of ogrinfo - apparently it is confused with the
geometry and misinterprets the coordinates:
C:\Users\akratoc\Downloads>ogrinfo -al -so Vincent_Sarah_Flight1.kml
INFO: Open of `Vincent_Sarah_Flight1.kml'
using driver `LIBKML' successful.
I ran into a weird problem with KML with 3D line, v.import failed when
reprojecting it:
WARNING: pj_transform() failed: latitude or longitude exceeded limits
This happened with GRASS 7.4.0 64bit (GDAL 2.2.3) on Windows 10, on my
Ubuntu with latest GRASS it works (GDAL 2.2.1). Weird thing is that I
installed the same version of GRASS on Windows 10 virtual machine and
there it worked without problems.
this is the output of ogrinfo - apparently it is confused with the
geometry and misinterprets the coordinates:
C:\Users\akratoc\Downloads>ogrinfo -al -so Vincent_Sarah_Flight1.kml
INFO: Open of `Vincent_Sarah_Flight1.kml'
using driver `LIBKML' successful.
The KML itself looks good to me, I attached a smaller version of it.
Anyone has experience with 3D KML? Maybe some GDAL trick is needed?
trying
ogr2ogr -f KML ogr2ogr_flight.kml attachment-0001.kml
Warning 1: Layer name 'Flight 1' adjusted to 'Flight_1' for XML validity.
Warning 1: The output driver does not natively support DateTime type for
field timestamp. Misconversion can happen. -mapFieldType can be used to
control field type conversion.
Warning 1: The output driver does not natively support DateTime type for
field begin. Misconversion can happen. -mapFieldType can be used to control
field type conversion.
Warning 1: The output driver does not natively support DateTime type for
field end. Misconversion can happen. -mapFieldType can be used to control
field type conversion.
ERROR 1: Latitude 121.723811 is invalid. Valid range is [-90,90]. This
warning will not be issued any more
Warning 1: Longitude 191.180111 has been modified to fit into range
[-180,180]. This warning will not be issued any more
it seems to be an ogr2ogr/gdal issue as altitude 121.7238106567 is handled
as Longitude .
ogr2ogr -f KML ogr2ogr_flight.kml attachment-0001.kml
Warning 1: Layer name 'Flight 1' adjusted to 'Flight_1' for XML validity.
Warning 1: The output driver does not natively support DateTime type for
field timestamp. Misconversion can happen. -mapFieldType can be used to
control field type conversion.
Warning 1: The output driver does not natively support DateTime type for
field begin. Misconversion can happen. -mapFieldType can be used to
control
field type conversion.
Warning 1: The output driver does not natively support DateTime type for
field end. Misconversion can happen. -mapFieldType can be used to control
field type conversion.
ERROR 1: Latitude 121.723811 is invalid. Valid range is [-90,90]. This
warning will not be issued any more
Warning 1: Longitude 191.180111 has been modified to fit into range
[-180,180]. This warning will not be issued any more
it seems to be an ogr2ogr/gdal issue as altitude 121.7238106567 is handled
as Longitude .
On lundi 5 février 2018 10:04:25 CET Anna Petrášová wrote:
Hi,
I ran into a weird problem with KML with 3D line, v.import failed when
reprojecting it:
WARNING: pj_transform() failed: latitude or longitude exceeded limits
This happened with GRASS 7.4.0 64bit (GDAL 2.2.3) on Windows 10, on my
Ubuntu with latest GRASS it works (GDAL 2.2.1). Weird thing is that I
installed the same version of GRASS on Windows 10 virtual machine and
there it worked without problems.
I can indeed replicate with the LIBKML driver on Windows (probably by libkml itself), and this is specific to this combination. From testing, it appears that the presence of newline+tabulations without spaces between coordinate triplets is the cause of the issue, where libkml doesn’t detect properly the start of the x coordinate of the new triplet and mangles it with the z of the previous one.
As a workaround, you might define OGR_SKIP=LIBKML as configuration option to exclude the LIBKML driver and use the “old” KML one that has not that issue.
Or edit the file to replace tabulations by spaces.
On Mon, Feb 5, 2018 at 2:30 PM, Even Rouault <even.rouault@spatialys.com> wrote:
On lundi 5 février 2018 10:04:25 CET Anna Petrášová wrote:
Hi,
I ran into a weird problem with KML with 3D line, v.import failed when
reprojecting it:
WARNING: pj_transform() failed: latitude or longitude exceeded limits
This happened with GRASS 7.4.0 64bit (GDAL 2.2.3) on Windows 10, on my
Ubuntu with latest GRASS it works (GDAL 2.2.1). Weird thing is that I
installed the same version of GRASS on Windows 10 virtual machine and
there it worked without problems.
I can indeed replicate with the LIBKML driver on Windows (probably by libkml
itself), and this is specific to this combination. From testing, it appears
that the presence of newline+tabulations without spaces between coordinate
triplets is the cause of the issue, where libkml doesn't detect properly the
start of the x coordinate of the new triplet and mangles it with the z of
the previous one.
As a workaround, you might define OGR_SKIP=LIBKML as configuration option to
exclude the LIBKML driver and use the "old" KML one that has not that issue.
Or edit the file to replace tabulations by spaces.