Open ekulno opened 3 years ago
Hmm, that is odd since we support GML in our list of bundled drivers: https://github.com/contra/node-gdal-next/blob/master/deps/libgdal/gyp-formats/ogr_gml.gyp
I can look into it - I just read through the driver docs and saw this:
The reading part of the driver only works if OGR is built with Xerces linked in. When Xerces is unavailable, read support also works if OGR is built with Expat linked in. XML validation is disabled by default. GML writing is always supported, even without Xerces or Expat.
Issue may be that we aren't linking it with libexpat correctly.
@Ysgorg, I just tried to load your geometry with the latest version of node-gdal-next
and it works fine for me - I get the feature geometry. I just had to modify the code to load a JSON (the gdal.open
call), but since you report a geometry error and not a dataset opening error, I guess it was correct on your side. Can you try again and report your findings?
When I submitted this ticket I was using version 2.1.0
of the gdal-next
package. I now upgraded to 2.4.0
and reran the example code given in the ticket description. I got the same result.
@mmomtchev , I'm not sure what you mean by modifying the code to load JSON. In my use-case I have a large amount of input data and manually rewriting it to JSON is not an option.
@Ysgorg, I am sorry, in fact I tried loading the JSON.
This is a duplicate of #8, add support for curve geometries.
ogr2ogr
silently eliminates the curve geometry, that's why it creates the impression that it works.
I have a GML file which I want to convert to another format. I am able to do this with the
ogr2ogr
tool, but withgdal-next
I get an error when I try to do the same thing.With
ogr2ogr
:With
gdal-next
:I get the following error for the
getGeometry
call:test.gml
has the following content.