[gdal-dev] RFC 29: OGR Set Desired Fields

[Peter J Halls]

Jez, Martin,

    I am now convinced that the solution is to store these data in separate 
tables, recording the FID of the parent record in each child record for, eg, 
TopographicArea, along with the TopographicArea data.  Ideally, I think the 
parent record could have a TopographicArea_Counnt column, thus recording that 
there are 2 entries in TopograhicArea for record a, 5 for record b, 1 for record 
c, and so on.  To achieve the latter will require changes to the OGR GML driver 
- for the present I am using my own GML parser instead.

Such an approach overcomes the problem of output formats with limits as to row 
width, column counts, etc, and column naming and leaves the user free to 
recombine these data in whatever manner s/he desires.  It also maintains the 
topological neutrality of GDAL/OGR, which has been an issue for some.

This is predicated on being able to create separate, non-spatial tables (driver 
issue).  To this end I submitted an enhancement to the OCI driver to support the 
creation of tables with a feature geometry type of wkbNone, in which no Geometry 
column is inserted.  Some other drivers are already able to do this, explicitly 
with wkbNone or implictly, as with the dbf driver.  I shall shortly be using 
this approach (coding delayed by meetings!) for a project working with large 
amounts of Mastermap ITN data, in which the problem is significant.

Best wishes,

Peter

Martin Dobias wrote:
> On Wed, Jul 21, 2010 at 3:31 PM, Jez Walters <Jez.Walters at ipl.com> wrote:
>> Martin,
>>
>>
>> I may be misunderstanding how the API works (I'm not actually using it myself), but if someone wants to parse a given layer of the OS MasterMap vector data that is divided into chunks they can't use fixed field numbers, because the field order varies between chunks.
>>
>> For example, suppose I want to only extract the 'physicalPresence' field from the 'TopographicArea' layer. Using your current proposed API I would have to sometimes specify to extract field 10 and sometimes to extract field 11, depending on which chunk I'm reading.
> 
> Well, then this should be probably handled better in the underlying
> GML driver...
> 
>> This CAN be accommodated of course (although it's rather fiddly), but the problem disappears if field names are used, as field names don't change between chunks.
> 
> I think it's rather easy to find out what field index is bound with
> each field name. Passing field indexes makes more sense to me as OGR
> internally works with field indexes, not field names.
> 
> Anyway, if you only use command line tools and do not develop
> applications/libraries with OGR API, the proposed RFC doesn't affect
> you at all.
> 
> Regards
> Martin
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
--------------------------------------------------------------------------------
Peter J Halls, GIS Advisor, University of York
Telephone: 01904 433806     Fax: 01904 433740
Snail mail: Computing Service, University of York, Heslington, York YO10 5DD
This message has the status of a private and personal communication
--------------------------------------------------------------------------------