[gdal-dev] OGR_L_SetAttributeFilter

Paul Ramsey pramsey at cleverelephant.ca
Fri Apr 29 12:19:05 PDT 2016


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