problems with delete of objects

[astrid.emde]

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>

[astrid.emde]

sample NBA file with delete requests

[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.

[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).

[astrid.emde]

sample NBA file with delete insert and replace comnmands

[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

[warmerdam]

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.

[warmerdam]

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.

[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)