[gdal-dev] Handling Ordnance Survey Change Only Updates

Frank Warmerdam warmerdam at pobox.com
Tue Aug 17 09:07:19 EDT 2010


Jez Walters wrote:
> Peter,
> 
> 
> I can't see how to use ogr2ogr with Change Only Updates (COU) either, but I
> was hoping for a more definitive response (no offense intended)!  :-)

Jez,

I think Peter's statements were all accurate.

> I'm receiving full and COU data in 'chunks' for the whole of Great Britain,
> and features can move from chunk to chunk between updates.  For example, a
> bridge feature might be first described in the full data file
> '123456-000012-10.gz' but amendments to this feature might be issued three
> months later in the COU data file '123456-000011-10.gz'.

Ouch.

> Because of the data volumes involved, I can't process each full data
> shapefile in turn to check its features against ALL of the changed features
> for the WHOLE of Great Britain.  I need an algorithm that processes COU data
> files one at a time.
> 
> I see the first step as establishing which full data shapefile contains a
> given feature that has changed.  Should I maintain my own feature index for
> this, or can the OGR library work this out for me?
> 
> Once I know which shapefile to edit, is it possible (however risky) to add,
> update and delete features from it - and if so, how?

You can add, update and delete features in a shapefile using the OGR API.
See CreateFeature(), SetFeature(),  and DeleteFeature() in the OGRLayer class
for details.

OGR is going to refer to features by "FID" (feature id) which is a 32bit
numeric value unique only within one layer (gml file, shapefile, etc), while
presumably you are working with alphanumeric gml id's unique across all
of the datasets.

My *suggestion* would be to load all your original data into postgis, and
then run a python/perl/etc script to read the COU files, and apply the
updates to the database.  If you do it in a database it should be much
easier to find the features without having to maintain a separate feature
id index mapping to particular files.

Note that OGR is not likely to provide any help maintaining a gml:id index.

Hmm, I just tried opening a mastermap file I have sitting around with OGR
and it also appears that OGR is not preserving the fid attribute on the
features as an attribute.  If there isn't a work around for this you may
have a very hard time processing updates - assuming they operate against
this fid.  Perhaps this is something that has already been discussed?

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent



More information about the gdal-dev mailing list