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 <[email protected]> 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
[email protected]
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
--------------------------------------------------------------------------------
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
