Re: [gdal-dev] Problem with OAPIF and numeric id in the data

[Rahkonen Jukka (MML)]

Even Rouault   wrote:

>> However, QGIS seems to drop the native fids and generate new ones but that's 
>> another problem to learn to circumvent.
> Hum, I'm afraid it will not be easy. The QGIS WFS / OAPIF provider stores 
> internally the feature id in the 
> internal feature cache but doesn't expose it. The QGIS feature id you get 
> from such layer is a purely 
> synthetical one, and that may change between sessions. Trying to remember 
> about that design choice,
> there are several reasons:
* if the WFS layer is a result of a join operation, there is no unique id
* if we exposed the gml:id (or JSON id) as a regular field, that could cause 
issues for transactional WFS support where you don't want users to modify that 
value

In that case I think we must publish the id two times in the OAPIF service, 
once as the id member and another time as  "landmark_id" or something in the 
feature properties because the id is meaningful for the users. They must be 
able to search by landmark_id and show them on the map.

> That could probably be changed pending some work.

-Jukka-

> 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] Problem with OAPIF and numeric id in the data

[Even Rouault]

A bit strange message at the end of the debug info but I guess that 
for some reason the features are read twice:
It's due to the reporting of feature count and layer extent. If you just 
want the feature listing, add -nocount -noextent


However, QGIS seems to drop the native fids and generate new ones but 
that’s another problem to learn to circumvent.


Hum, I'm afraid it will not be easy. The QGIS WFS / OAPIF provider 
stores internally the feature id in the internal feature cache but 
doesn't expose it. The QGIS feature id you get from such layer is a 
purely synthetical one, and that may change between sessions. Trying to 
remember about that design choice, there are several reasons:


 * if the WFS layer is a result of a join operation, there is no unique id
 * if we exposed the gml:id (or JSON id) as a regular field, that could
   cause issues for transactional WFS support where you don't want
   users to modify that value

That could probably be changed pending some work.

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] Problem with OAPIF and numeric id in the data

[Rahkonen Jukka (MML)]

Thanks,

I can get a copy of the native OAPIF FID into a normal attribute with

ogrinfo 
OAPIF:https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/
 -dialect sqlite -sql "select rowid, * from RajamerkinSijaintitiedot limit 10" 
--debug on

OGRFeature(SELECT):9
  rowid (Integer) = 12425588

A bit strange message at the end of the debug info but I guess that for some 
reason the features are read twice:
SQLite: 20 features read on layer 'SELECT'.
OGR: Unloading VirtualOGR module

I know now well enough how I can get and store the native fids from OAPIF 
service with GDAL command line tools. However, QGIS seems to drop the native 
fids and generate new ones but that's another problem to learn to circumvent.

-Jukka-

Lähettäjä: Even Rouault 
Lähetetty: maanantai 21. kesäkuuta 2021 17.50
Vastaanottaja: Rahkonen Jukka (MML) ; 
'gdal-dev@lists.osgeo.org' 
Aihe: Re: [gdal-dev] Problem with OAPIF and numeric id in the data


Jukka,

https://github.com/OSGeo/gdal/commit/36aa932aba3775f1e6ec825ba39c633442ffa640 
should help

Even
Le 21/06/2021 à 16:01, Rahkonen Jukka (MML) a écrit :
Hi,

With this request

ogrinfo 
OAPIF:https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/
 -dialect sqlite -sql "select * from RajamerkinSijaintitiedot limit 10" --debug 
on

ogrinfo does not use the "id" member as feature id nor does is report it as an 
attribute. Id exists in the data in this format
{"type":"FeatureCollection","features":[{"type":"Feature","id":12425552,"properties":{
as can be checked with 
https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/collections/RajamerkinSijaintitiedot/items?f=json=10

The service that is used as reference in 
https://gdal.org/drivers/vector/oapif.html is having the id as string
"type" : "Feature","id" : "DENW42AL1000NscuFL",

and in this case ogrinfo does not use "id" ad fid either but at least reads it 
as a normal attribute
ogrinfo -al OAPIF:https://www.ldproxy.nrw.de/rest/services/kataster flurstueck 
--debug on
...
OGRFeature(flurstueck):110
  id (String) = DENW42AL1000NtLGFL


I managed to get the "id" used as fid when converting data from the service at 
maanmittauslaitos.fi into geopackage by using -preserve_fid but for some reason 
today even that does not work for me.

-Jukka Rahkonen-




___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

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

--

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] Converting fid from GeoJSON into GeoPackage

[Rahkonen Jukka (MML)]

Thanks,

I believe this resolves my previous problem by the same. The indirect_sqlite 
dialect is not so handy in this case because it wants do download the whole 
collection from OAPIF.

So because OAPIF is sending data as GeoJSON there is no name for the FID column 
and it is obligatory to use ogr2ogr with "-preserve_fid" if the aim is to 
preserve FID.  I will see if there is something to improve with this in the 
documentation. I had some trouble with joining  edited data with the original 
because 15 million feature ids changed into counting numbers.

-Jukka-

Lähettäjä: Even Rouault 
Lähetetty: maanantai 21. kesäkuuta 2021 18.09
Vastaanottaja: Rahkonen Jukka (MML) ; 
'gdal-dev@lists.osgeo.org' 
Aihe: Re: [gdal-dev] Converting fid from GeoJSON into GeoPackage


Jukka,

Automatic FID preservation requires that the source layer reports a non-empty 
column name for the FID column, which isn't the case of the GeoJSON driver. 
Mostly only SQL-based drivers will report a non-empty FID column name.

Even
Le 21/06/2021 à 17:04, Rahkonen Jukka (MML) a écrit :
Hi,

Take this GeoJSON

{
"type": "FeatureCollection",
"features": [{
"type": "Feature",
"id":12425552,
"properties":
{
},
"geometry": {
"type": "Point",
"coordinates": [26.30578223, 60.26170791]
}
}]
}

Ogrinfo knows the fid
OGRFeature(one_feature):12425552

Convert into a new GeoPackage and the native fid is lost
ogr2ogr -f gpkg one_feature.gpkg one_feature.json
OGRFeature(one_feature):1

Running the command with "-preserve_fid" keeps the native fid but according to 
ogr2ogr documentation https://gdal.org/programs/ogr2ogr.html that should not be 
needed:

"Use the FID of the source features instead of letting the output driver 
automatically assign a new one (for formats that require a FID). If not in 
append mode, this behavior is the default if the output driver has a FID layer 
creation option, in which case the name of the source FID column will be used 
and source feature IDs will be attempted to be preserved."

Is the error in the documentation or in the GeoJSON-GeoPackage conversion?

-Jukka Rahkonen-






___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

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

--

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] Converting fid from GeoJSON into GeoPackage

[Even Rouault]

Jukka,

Automatic FID preservation requires that the source layer reports a 
non-empty column name for the FID column, which isn't the case of the 
GeoJSON driver. Mostly only SQL-based drivers will report a non-empty 
FID column name.


Even

Le 21/06/2021 à 17:04, Rahkonen Jukka (MML) a écrit :


Hi,

Take this GeoJSON

{

"type": "FeatureCollection",

"features": [{

"type": "Feature",

"id":12425552,

"properties":

{

},

"geometry": {

"type": "Point",

"coordinates": [26.30578223, 60.26170791]

}

}]

}

Ogrinfo knows the fid

OGRFeature(one_feature):12425552

Convert into a new GeoPackage and the native fid is lost

ogr2ogr -f gpkg one_feature.gpkg one_feature.json

OGRFeature(one_feature):1

Running the command with “-preserve_fid” keeps the native fid but 
according to ogr2ogr documentation 
https://gdal.org/programs/ogr2ogr.html 
 that should not be needed:


“Use the FID of the source features instead of letting the output 
driver automatically assign a new one (for formats that require a 
FID). If not in append mode, this behavior is the default if the 
output driver has a FID layer creation option, in which case the name 
of the source FID column will be used and source feature IDs will be 
attempted to be preserved.”


Is the error in the documentation or in the GeoJSON-GeoPackage conversion?

-Jukka Rahkonen-


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


--
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

[gdal-dev] Converting fid from GeoJSON into GeoPackage

[Rahkonen Jukka (MML)]

Hi,

Take this GeoJSON

{
"type": "FeatureCollection",
"features": [{
"type": "Feature",
"id":12425552,
"properties":
{
},
"geometry": {
"type": "Point",
"coordinates": [26.30578223, 60.26170791]
}
}]
}

Ogrinfo knows the fid
OGRFeature(one_feature):12425552

Convert into a new GeoPackage and the native fid is lost
ogr2ogr -f gpkg one_feature.gpkg one_feature.json
OGRFeature(one_feature):1

Running the command with "-preserve_fid" keeps the native fid but according to 
ogr2ogr documentation https://gdal.org/programs/ogr2ogr.html that should not be 
needed:

"Use the FID of the source features instead of letting the output driver 
automatically assign a new one (for formats that require a FID). If not in 
append mode, this behavior is the default if the output driver has a FID layer 
creation option, in which case the name of the source FID column will be used 
and source feature IDs will be attempted to be preserved."

Is the error in the documentation or in the GeoJSON-GeoPackage conversion?

-Jukka Rahkonen-


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

Re: [gdal-dev] Problem with OAPIF and numeric id in the data

[Even Rouault]

Jukka,

https://github.com/OSGeo/gdal/commit/36aa932aba3775f1e6ec825ba39c633442ffa640 
should help


Even

Le 21/06/2021 à 16:01, Rahkonen Jukka (MML) a écrit :


Hi,

With this request

ogrinfo 
OAPIF:https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/ 
-dialect sqlite -sql "select * from RajamerkinSijaintitiedot limit 10" 
--debug on


ogrinfo does not use the “id” member as feature id nor does is report 
it as an attribute. Id exists in the data in this format


{"type":"FeatureCollection","features":[{"type":"Feature","id":12425552,"properties":{

as can be checked with 
https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/collections/RajamerkinSijaintitiedot/items?f=json=10 



The service that is used as reference in 
https://gdal.org/drivers/vector/oapif.html 
 is having the id as string


"type" : "Feature","id" : "DENW42AL1000NscuFL",

and in this case ogrinfo does not use “id” ad fid either but at least 
reads it as a normal attribute
ogrinfo -al OAPIF:https://www.ldproxy.nrw.de/rest/services/kataster 
flurstueck --debug on


…

OGRFeature(flurstueck):110

  id (String) = DENW42AL1000NtLGFL

I managed to get the “id” used as fid when converting data from the 
service at maanmittauslaitos.fi into geopackage by using -preserve_fid 
but for some reason today even that does not work for me.


-Jukka Rahkonen-


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


--
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

[gdal-dev] Problem with OAPIF and numeric id in the data

[Rahkonen Jukka (MML)]

Hi,

With this request

ogrinfo 
OAPIF:https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/
 -dialect sqlite -sql "select * from RajamerkinSijaintitiedot limit 10" --debug 
on

ogrinfo does not use the "id" member as feature id nor does is report it as an 
attribute. Id exists in the data in this format
{"type":"FeatureCollection","features":[{"type":"Feature","id":12425552,"properties":{
as can be checked with 
https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/collections/RajamerkinSijaintitiedot/items?f=json=10

The service that is used as reference in 
https://gdal.org/drivers/vector/oapif.html is having the id as string
"type" : "Feature","id" : "DENW42AL1000NscuFL",

and in this case ogrinfo does not use "id" ad fid either but at least reads it 
as a normal attribute
ogrinfo -al OAPIF:https://www.ldproxy.nrw.de/rest/services/kataster flurstueck 
--debug on
...
OGRFeature(flurstueck):110
  id (String) = DENW42AL1000NtLGFL


I managed to get the "id" used as fid when converting data from the service at 
maanmittauslaitos.fi into geopackage by using -preserve_fid but for some reason 
today even that does not work for me.

-Jukka Rahkonen-

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

Re: [gdal-dev] FileGDB missing in C#

[Paul Harwood]

Assuming you mean this NuGet package https://www.nuget.org/packages/GDAL/
then I think it is managed by the SharpMap team
 - you probably should try asking
there. As far as I know it comes with a custom build of GDAL 2.4.x (i.e
gdal204.dll) - which is  not near the current latest version (3.3.x)  {but
if I am wrong about that I would love to know}.

if you mean this NuGet package
https://www.nuget.org/packages/MaxRev.Gdal.Core/ then you probably need to
raise a question on the MaxRev site. I know that the standard build is only
a limited set of drivers but I think they have instructions about how to
compile more in.

There is also a conda package for the C# integrations  - see this page
https://gdal.org/api/csharp/csharp_conda.html and this page
https://gdal.org/api/csharp/index.html.

This uses the latest conda GDAL package - so is always up to date but
requires a bit more manual integration into your .NET app than NuGet (see
the page linked above).

I checked and the current GDAL conda package (as used by the conda csharp
package) :

- includes the OpenFileGDB driver

- does not include the 3rd Party library based FileGDB driver


Which one were you looking for?



On Mon, 21 Jun 2021 at 09:08, Jens Søe Christiansen 
wrote:

> Hi
> I really like to use the ESRI FileGDB driver in my .net application but
> can't figure out how to add the driver to the NuGet version.
> Does anybody know how to add support for this driver in .net ?
>
> Best regards
> Jens Christiansen
> ___
> 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

[gdal-dev] Lidar vertical datum conversion to EGM2008

[fiat lux]

Hi all,


I have a question related to vertical datum conversion; e.g. for AHN3 lidar
data. Can you direct me to resources, or give me tips/tool on how to
convert AHN3 lidar vertical datum to EGM2008?


Thanks very much,

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

[gdal-dev] FileGDB missing in C#

[Jens Søe Christiansen]

Hi
I really like to use the ESRI FileGDB driver in my .net application but
can't figure out how to add the driver to the NuGet version.
Does anybody know how to add support for this driver in .net ?

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