Ticket #11 (closed defect: fixed)

Opened 9 years ago

Last modified 9 years ago

problems with delete of objects

Reported by: astrid.emde Owned by: warmerdam
Priority: major Milestone: 0.6 release
Component: ogr Version: 0.6
Keywords: Cc: warmerdam@…,frank.jaeger,frank.haertel@…

Description

After the first import of the whole NAS data we just import update files (NBA-Verfahren) which contain the changes.

We noticed that objects are not deleted. A NAS-file is attached to this ticket with the DELETE statements

<wfs:Delete typeName="AX_Flurstueck">
	<ogc:Filter>
		<ogc:FeatureId fid="DENW44AL00000fVl20100730T092847Z" />
	</ogc:Filter>
</wfs:Delete>

Attachments

NBA_RIO_testdel.xml (95.9 KB) - added by astrid.emde 9 years ago.
sample NBA file with delete requests
NBA_RIO_20110430T000000_0von0_0_0.xml (1.5 MB) - added by astrid.emde 9 years ago.
sample NBA file with delete insert and replace comnmands

Change History

Changed 9 years ago by astrid.emde

sample NBA file with delete requests

comment:1 Changed 9 years ago by astrid.emde

  • Owner Info deleted
  • Component changed from Info to ogr

comment:2 Changed 9 years ago by astrid.emde

mail Frank Warmedam: suggestion for a solution:

The wfs:Delete support required for ticket #11 is a bit tricky. We are not really processing the NAS wfs operations as operations. We just treat the Insert operations as features. So there is no direct way to represent the wfs:Delete operations as features that will trigger feature deletions as they are applied to postgres.

My suggestion is that I treat the wfs:Delete operations as a special "feature_deletions" layer with attribute "typeName" and "fid". We could then first load this into a table in PostgreSQL and then run an SQL statement (or set of statements) that would delete those features and empty the "feature_deletions" table before we rerun ogr2ogr to transfer the rest of the features.

Of course this is somewhat messy compared to a simple ogr2ogr operation. I'm increasingly wondering if we ought to have a custom PostNAS loader script or executable rather than using the generic ogr2ogr executable.

comment:3 Changed 9 years ago by warmerdam

  • Owner set to warmerdam

As a first pass at this I have modified the NAS driver to treat wfs:Delete as a special feature with a typeName and FeatureId? properties (r 22086).

Changed 9 years ago by astrid.emde

sample NBA file with delete insert and replace comnmands

comment:4 Changed 9 years ago by astrid.emde

Function to handle the objects that should be deleted could look like the following:

DROP FUNCTION deletefeature(text, text);
CREATE FUNCTION deleteFeature(typename text, featureid text) RETURNS text 
AS $$ 
 DECLARE 
  query text;
  res text; 
 BEGIN 
     query := 'DELETE FROM ' || $1 || ' WHERE gml_id = substring(''' || $2 || ''' from 1 for 16)';
     EXECUTE query;

     IF FOUND THEN 
	RAISE NOTICE 'query successfull % ', query; 
	res := 1;
     ELSE 
        RAISE NOTICE 'query no object found % ', query; 
        res := 0;
     END IF; 
  RETURN res; 
 END; 
$$ LANGUAGE plpgsql; 

Example

-- sample entry
INSERT INTO AA_Antragsgebiet (gml_id) VALUES ('DENW44AL0000okRc');

-- sample enmtry in delete table
INSERT INTO delete (typename, featureid) VALUES ('AA_Antragsgebiet','DENW44AL0000okRc20110428T135110Z');

-- deletes the features from the refered tables with the given gml_id
Select deleteFeature(typename,featureid) from delete;

the Funktion deleteFeature could empty the entries in the delete table too

comment:5 Changed 9 years ago by warmerdam

  • Status changed from new to assigned

I will address the wfsext:Replace operations by treating them like wfs:Insert *and* also putting the table/featureid into the feature_deletions. This means that for a given NAS file being loaded it will be necessary to load the feature_deletions table, run the SQL delete script, and *then* load the rest of the layers. Presumably in the context of PostNAS this will be two ogr2ogr commands, the first only transferring the feature_deletions layer.

comment:6 Changed 9 years ago by warmerdam

  • Status changed from assigned to closed
  • Resolution set to fixed

I have implemented this in gdal trunk (http://trac.osgeo.org/gdal/changeset/22438).

Note that wfsext:Replace operations actually give a new feature id for the replacement feature so there is no pressing need to do the delete operations before the new features are inserted.

Note that deletions options are actually in a layer named "Delete" contrary to what was said above.

So from the PostNAS side of things running the deletion script after a load will take care of both wfs:Delete and wfsext:Replace operations.

comment:7 Changed 9 years ago by astrid.emde

I checked the GeoInfoDoc? 6.0.1 concerning the wfs:Replace process (the documents says on page 105ff)

  • the replace should only contain the featureID. Complex filters are not allowed
  • a parameter with date/time of the object (like CCYYMMDDThhmmssZ) is passed in the filter too, to check the actuality of the operation
  • a replace-operation always contains all parameters (not only the ones that changed)
Note: See TracTickets for help on using tickets.