[gdal-dev] OGR FileGDB driver: 'OBJECTID' not recognised as an available field
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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR FileGDB driver: 'OBJECTID' not recognised as an available field
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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR FileGDB driver: 'OBJECTID' not recognised as an available field
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 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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR FileGDB driver: 'OBJECTID' not recognised as an available field
Hi,
I've already reported an issue a while back related to the OGRSQL dialect
along with the FDGB driver, when the where clause contains expression for
the FID column. I'm still experiencing the problem in GDAL master, where
the following query doesn't seem to apply the specified filter:
*ogrinfo "mydata.gdb" -dialect OGRSQL -sql "select * from tablename where
FID=..."*
but this one (without dialect) returns the correct result:
* ogrinfo "mydata.gdb" -sql "select * from tablename where FID=..." *
I'm a bit uncertain about whether it should be fixed in the generic SQL
layer or the FGDB layer (which doesn't expose OBJECTID in the layer defn.),
since the FGDB layer reports the name "OBJECTID" in GetFIDColumn, therefore
the gen SQL layer could automatically consider it in the layer definition
when processing the attribute filter. When adding the OBJECTID to the query
it fixes the problem, but that seems to be a bit awkward:
*ogrinfo "mydata.gdb" -dialect OGRSQL -sql "select *, OBJECTID from
tablename where FID=..." *
Any ideas in this topic would be helpful?
Best regards,
Tamas
Tamas Szekeres ezt írta (időpont: 2019. szept. 5.,
Cs, 22:51):
> 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 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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
