[gdal-dev] OGR_L_SetAttributeFilter

Paul Ramsey pramsey at cleverelephant.ca
Fri Apr 29 19:42:20 PDT 2016


A new question not answered: what is the current specification for SQL
filters in SetAttributeFilter? Has it evolved beyond this spec
(referenced from the GDAL docs)
http://ogdi.sourceforge.net/prop/6.2.CapabilitiesMetadata.html

P.

On Fri, Apr 29, 2016 at 12:19 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> In answer to myself, quoting the offending columns (eg "2name") allows
> otherwise illegal column names to find their way to GDAL's filtering
> machinery.
>
> Another question, which I seem to have an answer for: is "fid" a magic
> column name that will address the OGR fid? It seems to be, which is
> pretty amazing. What happens if an OGR table also has a legit field
> named "fid"?
>
> P
>
>
> On Thu, Apr 28, 2016 at 7:21 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>> http://www.gdal.org/ogr__api_8h.html#a4000d426bf26ad7cc7d4012634c93f09
>>
>> So, the reference to valid attribute filters points to
>>
>> http://ogdi.sourceforge.net/prop/6.2.CapabilitiesMetadata.html
>>
>> And there it says that
>>
>> @field_name@ = @string_token@
>>
>> and that
>>
>> "The @string_token@ starts with a character in a-z,A-Z and is followed
>> by any number of characters in the set a-z,A-Z,0-9 and underscore."
>>
>> Now, OGR layer names can be quite a bit more complicated than that,
>> coming as they do from crazy data sources like FGDB, or even shape
>> file! So 'b-rthday' is a perfectly legal shape file attribute name, as
>> is 'Field Survey' from FGDB.
>>
>> How do we address those column names?
>>
>> I'm working in the FDW space, and have a mapping between PgSQL column
>> names (simple, not unlike the rule from the referenced document) to
>> OGR column names (crazy shit potentially). I figured I'd just re-write
>> the SQL to use the OGR names, and then boom, things would work, but it
>> turns out that OGR doesn't want to accept filters using the very
>> column names OGR has inside... so... what should we feed it?
>>
>> P


More information about the gdal-dev mailing list