Re: [gdal-dev] windows install - best practices? install from source, or from precompiled binaries?

[timbo1711]

Anyone have a chance to read this and give me a few tips please?



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Question on how to open a raster in HDFS using GDAL

[James McClain]

You are very welcome, thank you for the report!

On Tue, Nov 27, 2018 at 5:44 PM ZAZHIL-HA HERENA 
wrote:

> Hi there,
>
> Thanks everybody for your valuable help, with your suggestions I finally
> got it working in my cluster with Cloudera 6 distribution(Hadoop 3) with
> Java, I would like to list here a few things I had to do to make it work
> since I used Cloudera to compile:
>
>
>- In Cloudera, Hadoop libraries are under $CLOUDERA_PATH/lib/hadoop so
>this is the path I use for ./configure in --with-hdfs
>- Then* ./configure* is looking for  a file *include/hdfs.h* , this
>directory in Cloudera exists in different path (outside Hadoop)
>$CLOUDERA_PATH/include, so I had to copy it under Hadoop path.
>- Same for libhdfs.so , *make* expects to find it in
>*lib/native/libhdfs.so*, for Cloudera it is in $CLOUDERA_PATH/lib64 ,
>so I just copied it to the expected location.
>
>
> I tested using command line and also my Java application and /vsihdfs/
> works as expected.
>
> Thanks!!!
> Zazhil-ha
> --
> *From:* gdal-dev  on behalf of James
> McClain 
> *Sent:* Friday, November 23, 2018 3:18 PM
> *To:* gdal-dev@lists.osgeo.org
> *Subject:* Re: [gdal-dev] Question on how to open a raster in HDFS using
> GDAL
>
> Hello,
>
> It may not be finding the native HDFS libraries.  Please see the pull
> request https://github.com/OSGeo/gdal/pull/714 for build instructions (in
> particular, you may need to augment the LD_LIBRARY_PATH environment
> variable).
>
> If trouble persists, I would suggest building against Apache Hadoop 2.7.6
> or 2.7.7 (both of those are know to work) as an experiment.
>
> Sincerely,
> James McClian
>
> On Fri, Nov 23, 2018 at 2:15 PM ZAZHIL-HA HERENA 
> wrote:
>
> Thank you so much!, now I am working on 2.4 source code but I am getting
> an error when trying to configure using:
>
> *./configure
> --prefix=/scratch/zherena/gdal/build/gdal-master/gdal/outputb/
> --with-complete=yes
> --with-java=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64/
> --with-swig-java=yes
> --with-hdfs=/scratch/zherena/gdal/CDH-6.0.1-1.cdh6.0.1.p0.590678/
> --with-curl=/usr/bin/curl-config*
>
> The error I get is:
>
>
> *  checking for HDFS in
> /scratch/zherena/gdal/CDH-6.0.1-1.cdh6.0.1.p0.590678/... checking for
> hdfsConnect in -lhdfs... no *
>
> *  checking for
> /scratch/zherena/gdal/CDH-6.0.1-1.cdh6.0.1.p0.590678//include/hdfs.h... yes
> *
> *  configure: error: HDFS support not enabled.*
>
>
> Is there any configuration in my environment that I should consider? or
> maybe another distribution of Hadoop?
>
>
> --
> *From:* Even Rouault 
> *Sent:* Friday, November 23, 2018 11:52 AM
> *To:* gdal-dev@lists.osgeo.org
> *Cc:* ZAZHIL-HA HERENA; James McClain; n...@nikosalexandris.net
> *Subject:* Re: [gdal-dev] Question on how to open a raster in HDFS using
> GDAL
>
> > Version says 2.3.2 but libraries say: libgdal.so.20.4.2 .
>
> Libtool number (.so.20.4.2) has nothing to do with user-friendly version
> number (2.3.2)
>
> > I am not sure if I
> > got the latest code, this is the first time I compile it myself, I used
> > this link to download source code:
> > http://download.osgeo.org/gdal/CURRENT/gdal-2.3.2.tar.gz
>
> This is the latest release, but /vsihdfs/ is in the development version,
> not
> yet released, so download
>
> https://github.com/OSGeo/gdal/archive/master.zip
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
>
>
> --
> "I prayed for freedom for twenty years, but received no answer until I
> prayed with my legs."
>  -- Frederick Douglass
>
>

-- 
"I prayed for freedom for twenty years, but received no answer until I
prayed with my legs."
 -- Frederick Douglass
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Question on how to open a raster in HDFS using GDAL

[ZAZHIL-HA HERENA]

Hi there,

Thanks everybody for your valuable help, with your suggestions I finally got it 
working in my cluster with Cloudera 6 distribution(Hadoop 3) with Java, I would 
like to list here a few things I had to do to make it work since I used 
Cloudera to compile:


  *   In Cloudera, Hadoop libraries are under $CLOUDERA_PATH/lib/hadoop so this 
is the path I use for ./configure in --with-hdfs
  *   Then ./configure is looking for  a file include/hdfs.h , this directory 
in Cloudera exists in different path (outside Hadoop) $CLOUDERA_PATH/include, 
so I had to copy it under Hadoop path.
  *   Same for libhdfs.so , make expects to find it in lib/native/libhdfs.so, 
for Cloudera it is in $CLOUDERA_PATH/lib64 , so I just copied it to the 
expected location.

I tested using command line and also my Java application and /vsihdfs/ works as 
expected.

Thanks!!!
Zazhil-ha

From: gdal-dev  on behalf of James McClain 

Sent: Friday, November 23, 2018 3:18 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Question on how to open a raster in HDFS using GDAL

Hello,

It may not be finding the native HDFS libraries.  Please see the pull request 
https://github.com/OSGeo/gdal/pull/714 for build instructions (in particular, 
you may need to augment the LD_LIBRARY_PATH environment variable).

If trouble persists, I would suggest building against Apache Hadoop 2.7.6 or 
2.7.7 (both of those are know to work) as an experiment.

Sincerely,
James McClian

On Fri, Nov 23, 2018 at 2:15 PM ZAZHIL-HA HERENA 
mailto:zazhil...@hotmail.com>> wrote:
Thank you so much!, now I am working on 2.4 source code but I am getting an 
error when trying to configure using:

./configure --prefix=/scratch/zherena/gdal/build/gdal-master/gdal/outputb/ 
--with-complete=yes 
--with-java=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64/ 
--with-swig-java=yes 
--with-hdfs=/scratch/zherena/gdal/CDH-6.0.1-1.cdh6.0.1.p0.590678/ 
--with-curl=/usr/bin/curl-config

The error I get is:

  checking for HDFS in 
/scratch/zherena/gdal/CDH-6.0.1-1.cdh6.0.1.p0.590678/... checking for 
hdfsConnect in -lhdfs... no
  checking for 
/scratch/zherena/gdal/CDH-6.0.1-1.cdh6.0.1.p0.590678//include/hdfs.h... yes
  configure: error: HDFS support not enabled.


Is there any configuration in my environment that I should consider? or maybe 
another distribution of Hadoop?



From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Friday, November 23, 2018 11:52 AM
To: gdal-dev@lists.osgeo.org
Cc: ZAZHIL-HA HERENA; James McClain; 
n...@nikosalexandris.net
Subject: Re: [gdal-dev] Question on how to open a raster in HDFS using GDAL

> Version says 2.3.2 but libraries say: libgdal.so.20.4.2 .

Libtool number (.so.20.4.2) has nothing to do with user-friendly version
number (2.3.2)

> I am not sure if I
> got the latest code, this is the first time I compile it myself, I used
> this link to download source code:
> http://download.osgeo.org/gdal/CURRENT/gdal-2.3.2.tar.gz

This is the latest release, but /vsihdfs/ is in the development version, not
yet released, so download

https://github.com/OSGeo/gdal/archive/master.zip

--
Spatialys - Geospatial professional services
http://www.spatialys.com


--
"I prayed for freedom for twenty years, but received no answer until I prayed 
with my legs."
 -- Frederick Douglass

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

Re: [gdal-dev] Early GDAL 2.4.0 release ?

[Sean Gillies]

Hi Even,

Many of the tasks in
https://github.com/OSGeo/gdal/edit/master/gdal/HOWTO-RELEASE are beyond me
(looks like it needs root on the osgeo server and Maven knowledge) but I
signed myself up for writing the NEWS file in
https://github.com/OSGeo/gdal/issues/1119.


On Tue, Nov 27, 2018 at 10:00 AM Even Rouault 
wrote:

> Hi,
>
> I've been considering an early GDAL 2.4.0 release for the end of this year
> instead of the traditionnal mid-April / May target.
>
> The rationale is that the work related to the GDAL/PROJ SRS revamp effort
> (aka
> "GDAL barn": https://gdalbarn.com/) will probably require non-null
> integration
> work from GDAL users, which will unnecessarily delay the "time-to-market"
> of
> features currently in GDAL master.
>
> I've just began integrating the PROJ changes in a GDAL branch of mine and
> the
> current and future changes can be classified in the following categories:
> - for sure: behaviour changes. exportToWKT() / exportToProj4() will for
> example return different strings. Most of the time equivalent, but
> nonetheless
> different, which can break other software unit tests
> - probable: some OGRSpatialReference methods / OSR functions might be
> removed,
> or become no-operation
> - uncertain at this point: impact of being axis order and unit compliant
> with
> the CRS definition from the authority.
>
> I'd like the GDAL 2.5.0 release that will integrate the GDAL barn work to
> still be scheduled for mid-April / May date, and with my branch being
> hopefully ready for being merged into master in January.
>
> A temptative schedule for 2.4.0 might be:
>
> - December 14th: GDAL 2.4.0RC1 (I believe master is mature enough to go to
> RC
> stage directly, with no/very few changes affecting backward compatibility,
> but
> this is just from memory. The updated NEWS would help to confirm, but
> creating
> it is the bulk of the release work), likely coupled with a GDAL 2.3.3RC1
> that
> would be the final point release for the GDAL 2.3 series
>
> - December 21th: GDAL 2.4.0final
>
> Thoughts ? Ah, and the release manager role is still open for volunteers
> (or
> any help, particularly updating NEWS, would be appreciated)
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] Early GDAL 2.4.0 release ?

[Martin Landa]

Hi,

út 27. 11. 2018 v 18:12 odesílatel Daniel Morissette
 napsal:
> +1 for me. I like your plan.

make sense to me

+1

Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Early GDAL 2.4.0 release ?

[Daniel Morissette]

+1 for me. I like your plan.

Daniel


On 2018-11-27 11:59 a.m., Even Rouault wrote:

Hi,

I've been considering an early GDAL 2.4.0 release for the end of this year
instead of the traditionnal mid-April / May target.

The rationale is that the work related to the GDAL/PROJ SRS revamp effort (aka
"GDAL barn": https://gdalbarn.com/) will probably require non-null integration
work from GDAL users, which will unnecessarily delay the "time-to-market" of
features currently in GDAL master.

I've just began integrating the PROJ changes in a GDAL branch of mine and the
current and future changes can be classified in the following categories:
- for sure: behaviour changes. exportToWKT() / exportToProj4() will for
example return different strings. Most of the time equivalent, but nonetheless
different, which can break other software unit tests
- probable: some OGRSpatialReference methods / OSR functions might be removed,
or become no-operation
- uncertain at this point: impact of being axis order and unit compliant with
the CRS definition from the authority.

I'd like the GDAL 2.5.0 release that will integrate the GDAL barn work to
still be scheduled for mid-April / May date, and with my branch being
hopefully ready for being merged into master in January.

A temptative schedule for 2.4.0 might be:

- December 14th: GDAL 2.4.0RC1 (I believe master is mature enough to go to RC
stage directly, with no/very few changes affecting backward compatibility, but
this is just from memory. The updated NEWS would help to confirm, but creating
it is the bulk of the release work), likely coupled with a GDAL 2.3.3RC1 that
would be the final point release for the GDAL 2.3 series

- December 21th: GDAL 2.4.0final

Thoughts ? Ah, and the release manager role is still open for volunteers (or
any help, particularly updating NEWS, would be appreciated)

Even




--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Get area of use of a spatial reference system

[Even Rouault]

On mardi 27 novembre 2018 16:53:10 CET Marcel Wendler wrote:
> Hi all,
> 
> 
> I am wondering if GDAL has a method that returns the area of use/the areas
> epsg code of a particular spatial reference system.

Marcel,

No, this is not currently imported from the EPSG dataset in the .csv files 
used by GDAL. As part of my ongoing work on the SRS front in GDAL/PROJ, this 
should be available in the GDAL version that will be out around May next year 
(see my previous message)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Early GDAL 2.4.0 release ?

[Even Rouault]

Hi,

I've been considering an early GDAL 2.4.0 release for the end of this year 
instead of the traditionnal mid-April / May target.

The rationale is that the work related to the GDAL/PROJ SRS revamp effort (aka 
"GDAL barn": https://gdalbarn.com/) will probably require non-null integration 
work from GDAL users, which will unnecessarily delay the "time-to-market" of 
features currently in GDAL master.

I've just began integrating the PROJ changes in a GDAL branch of mine and the 
current and future changes can be classified in the following categories:
- for sure: behaviour changes. exportToWKT() / exportToProj4() will for 
example return different strings. Most of the time equivalent, but nonetheless 
different, which can break other software unit tests
- probable: some OGRSpatialReference methods / OSR functions might be removed, 
or become no-operation
- uncertain at this point: impact of being axis order and unit compliant with 
the CRS definition from the authority.

I'd like the GDAL 2.5.0 release that will integrate the GDAL barn work to 
still be scheduled for mid-April / May date, and with my branch being 
hopefully ready for being merged into master in January.

A temptative schedule for 2.4.0 might be:

- December 14th: GDAL 2.4.0RC1 (I believe master is mature enough to go to RC 
stage directly, with no/very few changes affecting backward compatibility, but 
this is just from memory. The updated NEWS would help to confirm, but creating 
it is the bulk of the release work), likely coupled with a GDAL 2.3.3RC1 that 
would be the final point release for the GDAL 2.3 series

- December 21th: GDAL 2.4.0final

Thoughts ? Ah, and the release manager role is still open for volunteers (or 
any help, particularly updating NEWS, would be appreciated)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Get area of use of a spatial reference system

[Marcel Wendler]

Hi all,


I am wondering if GDAL has a method that returns the area of use/the areas epsg 
code of a particular spatial reference system.

>From what I could find (e.g. in the OGRSpatialReference class doc and in the 
>data provided in GDALs share folder) I think it's not possible. It seems a 
>little bit strange as other information (like Inverse Flattening, Semi Major 
>Axis etc.) from the EPSG dataset is present and can be accessed via methods in 
>OGRSpatialReference.


I'd be happy if anyone can clarify this for me and, at best, prove me wrong ;)



Thanks,


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

Re: [gdal-dev] GML element/attribute discovery inconsistency

[Even Rouault]

On mardi 27 novembre 2018 14:16:19 CET Björn Harrtell wrote:
> Thanks for the clarifications Even,
> 
> I've tried GMLAS but been unsuccessful in getting it to produce useful
> output.

I assume you had a schema to point to.
The GMLAS driver has been tested on a number of fairly complicated models 
(Inspire, CityGML, etc.) as well as Simple Feature ones, but I cannot exclude 
it might fail on some schemas. Or perhaps the structure it generates was too 
complicated (which just reflects the complexity of the original schemas) ?

> 
> I'm actually quite happy with the standard GML driver, except that it
> ignores other attributes when element has xsi:nil. Would it be a welcome
> change to remove that behavior, treating other attributes as normal, and if
> so does that change need to be opt in?

If GML_ATTRIBUTES_TO_OGR_FIELDS is set, we could probably avoid treating 
xsi:nil as a particular case.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GML element/attribute discovery inconsistency

[Björn Harrtell]

Thanks for the clarifications Even,

I've tried GMLAS but been unsuccessful in getting it to produce useful
output.

I'm actually quite happy with the standard GML driver, except that it
ignores other attributes when element has xsi:nil. Would it be a welcome
change to remove that behavior, treating other attributes as normal, and if
so does that change need to be opt in?

Björn

Den tis 27 nov. 2018 kl 12:46 skrev Even Rouault :

> > Are my observations correct?
>
> Björn,
>
> It would be difficult to deny the results of tests :-)
>
> The GML driver has a lot of particular handling tailored for particular
> datasets, which makes understanding its behaviour non-obvious
>
> From the code (which confirms your observations),
> - if an element has a xsi:nil attribute, then its other attributes are
> ignored
> and the content of the element is set to NULL (what you observe with a1)
> - there is a particular case for the uom attribute, which is always
> reported
> even if GML_ATTRIBUTES_TO_OGR_FIELDS is not set (the _uom case was added
> before the generalization of GML_ATTRIBUTES_TO_OGR_FIELDS)
> - empty elements (if empty for all features) are not reported as OGR fields
>
> You may want to try the GMLAS driver for something that involves less
> guessing. The GML driver can work without any schema, and if the schema is
> present only supports simple constructs in it. Contrary to the GMLAS
> driver,
> which is (almost) completely schema driven to create the OGR layer and
> attribute structure:
> https://www.gdal.org/drv_gmlas.html
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GML element/attribute discovery inconsistency

[jratike80]

Hi,

I would mention also an open option EMPTY_AS_NULL=NO that seems to adds some
fields into ogrinfo result:

gml_id: String (0.0) NOT NULL
a1: StringList (0.0)
a2: String (0.0)
a2_uom: String (1.0)
a3_title: String (5.0)
a3: String (0.0)
a3_href: String (22.0)
a4: String (0.0)
a4_href: String (40.0)
a5: String (0.0)
OGRFeature(MyFeaturetype1):785667386
  gml_id (String) = id.8685d1b8-a851-4034-b8ed-a4c785667386
  a1 (StringList) = (null)
  a2 (String) =
  a2_uom (String) = m
  a3_title (String) = title
  a3 (String) =
  a3_href (String) = https://test.com/value
  a4 (String) =
  a4_href (String) = #id.8685d1b8-a851-4034-b8ed-a4c785667386
  a5 (String) =

-Jukka Rahkonen-



 
Even Rouault-2 wrote
>> Are my observations correct?
> 
> Björn,
> 
> It would be difficult to deny the results of tests :-)
> 
> The GML driver has a lot of particular handling tailored for particular 
> datasets, which makes understanding its behaviour non-obvious
> 
> From the code (which confirms your observations),
> - if an element has a xsi:nil attribute, then its other attributes are
> ignored 
> and the content of the element is set to NULL (what you observe with a1)
> - there is a particular case for the uom attribute, which is always
> reported 
> even if GML_ATTRIBUTES_TO_OGR_FIELDS is not set (the _uom case was added 
> before the generalization of GML_ATTRIBUTES_TO_OGR_FIELDS)
> - empty elements (if empty for all features) are not reported as OGR
> fields
> 
> You may want to try the GMLAS driver for something that involves less 
> guessing. The GML driver can work without any schema, and if the schema is 
> present only supports simple constructs in it. Contrary to the GMLAS
> driver, 
> which is (almost) completely schema driven to create the OGR layer and 
> attribute structure:
> https://www.gdal.org/drv_gmlas.html
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GML element/attribute discovery inconsistency

[Even Rouault]

> Are my observations correct?

Björn,

It would be difficult to deny the results of tests :-)

The GML driver has a lot of particular handling tailored for particular 
datasets, which makes understanding its behaviour non-obvious

From the code (which confirms your observations),
- if an element has a xsi:nil attribute, then its other attributes are ignored 
and the content of the element is set to NULL (what you observe with a1)
- there is a particular case for the uom attribute, which is always reported 
even if GML_ATTRIBUTES_TO_OGR_FIELDS is not set (the _uom case was added 
before the generalization of GML_ATTRIBUTES_TO_OGR_FIELDS)
- empty elements (if empty for all features) are not reported as OGR fields

You may want to try the GMLAS driver for something that involves less 
guessing. The GML driver can work without any schema, and if the schema is 
present only supports simple constructs in it. Contrary to the GMLAS driver, 
which is (almost) completely schema driven to create the OGR layer and 
attribute structure:
https://www.gdal.org/drv_gmlas.html

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GML element/attribute discovery inconsistency

[Björn Harrtell]

I think I've found some inconsistencies in GML parsing.

Given the following example GML:


http://www.opengis.net/gml/3.2;
  xmlns:ex="http://example.com;
  xmlns:xlink="http://www.w3.org/1999/xlink;
  xmlns:xml="http://www.w3.org/XML/1998/namespace;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  gml:id="id.05e55fe5-b525-4cf2-9977-fedfc0532fd6">
  

  
  
  https://test.com/value; xlink:title="title" />
  
  

  


ogrinfo -al will list the following columns:

gml_id: String (0.0) NOT NULL
a1: String (0.0)
a2_uom: String (1.0)

AFAIK it should not define the field a2_uom as GML_ATTRIBUTES_TO_OGR_FIELDS
is NO as default. If I rerun it with GML_ATTRIBUTES_TO_OGR_FIELDS set to
YES the result is:

gml_id: String (0.0) NOT NULL
a1: String (0.0)
a2_uom: String (1.0)
a3_title: String (5.0)
a3_href: String (22.0)
a4_href: String (40.0)

In this case we get more attributes but I think a1_nilReason is missing.

Also, in both cases it seems fields for empty elements are missing (a2, a3,
a4 and a5).

Are my observations correct?

Regards,

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