This PR proposes to enhance the import operation to avoid duplicate top-level city objects in the database.
The CityGML/CityJSON input file(s) are first searched for top-level city objects to be imported based on the specified import filters. The identifiers (gml:id) of those top-level city objects are then queried in the database to check whether city objects with identical identifiers already exist in the database. If no such duplicate/conflicting city object is detected in the database, the top-level city object from the input file is imported just as before. In addition, the user can now define how to handle duplicate/conflicting top-level city objects using the new input fields Import mode and Options (see screenshot above).
Insert and Import all: All city objects from the input file(s) are imported independent of whether a duplicate already exists in the database. This is the default behaviour of the current Importer/Exporter and also the default setting of this PR.
Insert and Skip existing: Top-level city objects from the input file(s) are skipped and not imported if a duplicate already exists in the database. This should maybe be the new default behaviour in the future.
Overwrite and Delete existing: The duplicate city objects in the database are overwritten with the city objects from the input file(s). For this purpose, they are first physically deleted from the database. Afterwards, all city objects from the input file(s) are imported.
Overwrite and Terminate existing: Same as 3) except that the duplicates are only terminated in the database.
For the CLI, a new option --duplicate-mode has been added to the import command. Allowed modes are import_all, skip, delete, and terminate, which correspond to the options above.
Limitations:
The duplicate check is only based on the identifier (gml:id). No spatial checks (e.g. overlap), no attribute checks, no feature type checks.
Only the top-level features from the input file(s) are tested but not their nested child objects.
For option 2), the entire top-level feature from the input file including all its nested child objects is skipped.
For option 3) and 4), the duplicate city object in the database including all its nested child objects is deleted/terminated.
This PR proposes to enhance the import operation to avoid duplicate top-level city objects in the database.
The CityGML/CityJSON input file(s) are first searched for top-level city objects to be imported based on the specified import filters. The identifiers (
gml:id) of those top-level city objects are then queried in the database to check whether city objects with identical identifiers already exist in the database. If no such duplicate/conflicting city object is detected in the database, the top-level city object from the input file is imported just as before. In addition, the user can now define how to handle duplicate/conflicting top-level city objects using the new input fieldsImport modeandOptions(see screenshot above).InsertandImport all: All city objects from the input file(s) are imported independent of whether a duplicate already exists in the database. This is the default behaviour of the current Importer/Exporter and also the default setting of this PR.InsertandSkip existing: Top-level city objects from the input file(s) are skipped and not imported if a duplicate already exists in the database. This should maybe be the new default behaviour in the future.OverwriteandDelete existing: The duplicate city objects in the database are overwritten with the city objects from the input file(s). For this purpose, they are first physically deleted from the database. Afterwards, all city objects from the input file(s) are imported.OverwriteandTerminate existing: Same as 3) except that the duplicates are only terminated in the database.For the CLI, a new option
--duplicate-modehas been added to theimportcommand. Allowed modes areimport_all,skip,delete, andterminate, which correspond to the options above.Limitations:
gml:id). No spatial checks (e.g. overlap), no attribute checks, no feature type checks.