[gdal-dev] OGR FileGDB driver: 'OBJECTID' not recognised as an available field

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] OGR FileGDB driver: 'OBJECTID' not recognised as an available field

Tamas Szekeres
Hi,

It looks like  the sql queries with -dialect "OGRSQL" doesn't seem to work as expected. When I specify the FID in the where clause, it doesn't filter anything. The same query is also described as a solution in the following ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that works at all.

The code causing this problem is fairly generic (ogr_gensql.cpp)

if( psSelectInfo->where_expr && pszDialect != nullptr &&
            EQUAL(pszDialect, "OGRSQL") )
        {
            int nMinIndexForSpecialField = poSrcLayer->GetLayerDefn()->GetFieldCount();
            bForwardWhereToSourceLayer = !OGRGenSQLResultsLayerHasSpecialField
                            (psSelectInfo->where_expr, nMinIndexForSpecialField);
        }
        if (bForwardWhereToSourceLayer)
            pszWHERE = CPLStrdup(pszWHEREIn);
        else
            pszWHERE = nullptr;

In the "where" expression, the FID field is thanslated to OBJECTID and it is now treated as a special field, therefore the "where" expression is not being passed to the driver.

I'm also unsure if that is a correct action to omit passing "where" to the layer instead of providing an error message. 

Is this a bug that should be fixed, or the OGRSQL dialect is considered as unsupported with OpenFileGDB?


Best regards,

Tamas


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGR FileGDB driver: 'OBJECTID' not recognised as an available field

Even Rouault-2
On mercredi 4 septembre 2019 22:13:40 CEST Tamas Szekeres wrote:

> Hi,
>
> It looks like  the sql queries with -dialect "OGRSQL" doesn't seem to work
> as expected. When I specify the FID in the where clause, it doesn't filter
> anything. The same query is also described as a solution in the following
> ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that works at
> all.
>
> The code causing this problem is fairly generic (ogr_gensql.cpp)
>
> if( psSelectInfo->where_expr && pszDialect != nullptr &&
>             EQUAL(pszDialect, "OGRSQL") )
>         {
>             int nMinIndexForSpecialField =
> poSrcLayer->GetLayerDefn()->GetFieldCount();
>             bForwardWhereToSourceLayer =
> !OGRGenSQLResultsLayerHasSpecialField
>                             (psSelectInfo->where_expr,
> nMinIndexForSpecialField);
>         }
>         if (bForwardWhereToSourceLayer)
>             pszWHERE = CPLStrdup(pszWHEREIn);
>         else
>             pszWHERE = nullptr;
>
> In the "where" expression, the FID field is thanslated to OBJECTID and it
> is now treated as a special field, therefore the "where" expression is not
> being passed to the driver.
>
> I'm also unsure if that is a correct action to omit passing "where" to the
> layer instead of providing an error message.

Actually the where isn't completely discarded. It is set on the
OGRGenSQLResultsLayer per

    if( !bForwardWhereToSourceLayer )
        OGRGenSQLResultsLayer::SetAttributeFilter( pszWHEREIn );

around line 492

The issue is that the GenSQL layer has no FID column set, and thus this filter
fails. One could potentially set the FID Column name on it from the source
layer, but that wouldn't be really appropriate in the case of JOIN. That said
I see a poDstFeat->SetFID( poSrcFeat->GetFID() ); at line 1332 of
TranslateFeature(), so...

(there might have been other fixes since #4253 that have made this case
broken)

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGR FileGDB driver: 'OBJECTID' not recognised as an available field

Tamas Szekeres
Hi,

I'm not sure if bForwardWhereToSourceLayer should not be set in this case, since the special field FID in pszWHEREIn has already been replaced.
Or the OpenFileGDB driver should indeed expose OBJECTID as a column according to #4253

Best regards,

Tamas


 Even Rouault <[hidden email]> ezt írta (időpont: 2019. szept. 5., Cs, 13:13):
On mercredi 4 septembre 2019 22:13:40 CEST Tamas Szekeres wrote:
> Hi,
>
> It looks like  the sql queries with -dialect "OGRSQL" doesn't seem to work
> as expected. When I specify the FID in the where clause, it doesn't filter
> anything. The same query is also described as a solution in the following
> ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that works at
> all.
>
> The code causing this problem is fairly generic (ogr_gensql.cpp)
>
> if( psSelectInfo->where_expr && pszDialect != nullptr &&
>             EQUAL(pszDialect, "OGRSQL") )
>         {
>             int nMinIndexForSpecialField =
> poSrcLayer->GetLayerDefn()->GetFieldCount();
>             bForwardWhereToSourceLayer =
> !OGRGenSQLResultsLayerHasSpecialField
>                             (psSelectInfo->where_expr,
> nMinIndexForSpecialField);
>         }
>         if (bForwardWhereToSourceLayer)
>             pszWHERE = CPLStrdup(pszWHEREIn);
>         else
>             pszWHERE = nullptr;
>
> In the "where" expression, the FID field is thanslated to OBJECTID and it
> is now treated as a special field, therefore the "where" expression is not
> being passed to the driver.
>
> I'm also unsure if that is a correct action to omit passing "where" to the
> layer instead of providing an error message.

Actually the where isn't completely discarded. It is set on the
OGRGenSQLResultsLayer per

    if( !bForwardWhereToSourceLayer )
        OGRGenSQLResultsLayer::SetAttributeFilter( pszWHEREIn );

around line 492

The issue is that the GenSQL layer has no FID column set, and thus this filter
fails. One could potentially set the FID Column name on it from the source
layer, but that wouldn't be really appropriate in the case of JOIN. That said
I see a poDstFeat->SetFID( poSrcFeat->GetFID() ); at line 1332 of
TranslateFeature(), so...

(there might have been other fixes since #4253 that have made this case
broken)

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

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev