[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