Advanced Import Settings - Configuration - P54592-P101-A1 - P54592-P118-A1

Since the import wizard is used for all interfaces, select a coordinate system is always necessary. The specified coordinate system is always saved as information during the import process and impacts the positional calculation during the further course of the configuration. You can choose between:

• Data with positional information: The selection of the coordinate system is crucial for this type of data. Floor layouts and calibration points contain positional information for example.
• Data without positional information: Select the same coordinate system for all import processes.
• Reimport: Always use the same coordinate system used with the first import. Otherwise this can lead to calculation errors.

Always select the correct coordinate system. If necessary, ask the provider of the information that made the data available for you.

General Information on the Coordinate System

The following types of coordinate systems are available:

Geodetic Coordinate System

The geodetic coordinate system is used for level illustration of the earth globe. Site plans with buildings and topographical environment data are usually stored in a geodetic coordinate system. Based on the type of projection, the following distinction is made:

• GK projection (Gauß-Krüger): This is an older illustration by which the earth globe is divided into 120 meridian strips. Two GK projection types exist for Germany owed to the split between the Eastern and the Western blocks. The territory of Germany is located in zones 2 to 5 for both GK projection types. Selection of the GK zone can be omitted in Siveillance Control if necessary. For the territory of West Germany as well as Saxony and Thuringia select DHDN (Deutsches Hauptdreiecksnetz/German Main Triangle Net). For the Eastern German states select Pulkovo.
• UTM projection: This is a newer illustration by which the earth globe is divided into 60 zones. The German territory is located in zones 32 and 33. The transition from zone 32 to zone 33 is roughly at the former inner-German border. For the territory of West Germany select WGS 84/UTM zone 32N (default), for the territory of East Germany select WGS 84/UTM zone 33N. Alternatively, the UTM zone can be ignored if necessary, for the territory of Germany. In this case, select WGS 84.

Local Coordinate System

A local coordinate system is offset from the global origin and used for specific purposes only. Building layouts are generally saved in a local coordinate system.

The source ID is generated automatically and saved for each imported object. The source ID is required for reimports. If a file or object is modified and reimported, the source ID ensures the traceability of affiliation with the former file or object. If files are renamed, for example, during the configuration, this can result in the source ID being changed. In this case, the data saved in Siveillance Control cannot be merged with the data being imported. New data with a different source ID is saved. However, you can change the source ID manually and thus enforce the object merging in case of a reimport.

You have the following options:

• Import with identical source: Depending on further settings, the information is imported and added to the already existing object.
• Import with different source: The file is imported several times with a different source. In case of multiple data pools, you cannot see which data pool is up to date.

The import of a source ID differs for objects with identical and different source as well as for the first and second import. The effects of the selected settings are described based on an example.

All data in Siveillance Control is saved as objects. The status of an object consists of its properties and the connections to other objects. The objects are saved in the database and are merged with the objects from the import file during the import process. You can determine how the saved objects are merged with the objects to be imported in the Objects grouping.

In order for Siveillance Control to be able to determine internally whether the object is a new or existing object or an object that no longer exists, two lists are generated. The first list contains all objects in the import file. The second list contains the objects saved in Siveillance Control with the source ID of the import file.

You have the following options:

• New > Add: Objects from the import not yet saved in Siveillance Control are added.
• New > Skip: Objects from the import not yet saved in Siveillance Control are not added.
• Existing > Merge: Objects from the import are merged with identical objects in Siveillance Control. Select this setting if attribute values of objects have changed in the import file.
• Existing > Skip: No merging takes place. The objects in Siveillance Control remain unchanged.
• Orphan > Keep: All objects saved in Siveillance Control continue to be available after the import.
• Orphan > Delete: Objects in Siveillance Control coming from exactly the same source as the objects in the import file, but are no longer contained in the import file, will be deleted.
• Marked to be deleted > Delete: Objects marked for deletion in the import file are deleted in Siveillance Control. This is only possible if the format of the import file supports this functionality.
• Object type changed > Keep: All objects keep the existing object type. If any object type change was made, the existing objects keep the type which is currently active in Siveillance Control.
• Object type changed > Update: When reimporting an already existing object in Siveillance Control, the object type is taken over from the import file.

The effects of the selected settings are described based on an example.

• A KML file has been imported.

1. Edit the KML file by completing the following steps:

• New: Building 30 N was newly added.

• Existing: A coordinate for Building 30 NO was changed.

• Orphan: Building 30 NW was deleted.

• Save the KML file.

2. Reimport the KML file with the following settings:

• New: Building 30 N is not imported.

• Existing: Building 30 NO is not updated.

• Orphan: Building 30 NW is deleted.

3. Reimport the KML file for the second time with the following settings:

• New: Building 30 N is not imported.

• Existing: Building 30 NO is changed (GIS Position is changed).

• Orphan: Building 30 NW is deleted.

4. Reimport the KML file for the third time with the following settings:

• New: Building 30 N is added.

• Existing: Building 30 NO was already changed during the second import.

You can save several references for objects. For example, you can alter the existing tree structure in Siveillance Control during the import process depending on the settings. If the data or objects are saved in structured form in the import file, this data or tree structure can be transferred to Siveillance Control.

You have the following options:

• New > Add: The tree relationship in the import file for new objects is added.
• New > Skip: The tree relationships for new objects in the import file are ignored. This can result in newly imported objects not being displayed in Siveillance Control. If the data pool is inconsistent as a result, an error message is displayed in the Tasks view.
• Existing > Keep: The tree structure saved in Siveillance Control is retained and not changed.
• Existing > Add: The behavior differs for tree nodes and objects. Tree nodes are moved as specified inside the import file, since tree nodes are saved uniquely. Objects are added as additional references to another tree node assigned in the import file, since the reference to objects is saved within the tree structure.
• Orphan > Keep: All tree relationships saved in Siveillance Control continue to be available after the import.
• Orphan > Delete: Those tree relationships of an object in Siveillance Control that are not contained in the import file are deleted during the import process.

The effects of the selected settings are described based on an example. The following situation is assumed as a starting point for the example:

• An LDIF file with users and user groups has been imported.

1. Edit the LDIF file by completing the following steps:

• Delete Walker as Administrator.

• Delete Maier as Operator.

• Move the user group Access Control including the user Gray.

• Additionally, reference Walker as Operator.

• Add Fischer as a new Operator.

• Save the LDIF file.

2. Reimport the LDIF file with the following tree parenting settings:

• Walker is removed from user group Administrator.

• Maier is removed from user group Operator.

3. Reimport the LDIF file for the second time with the following tree parenting settings:

• The user group Access Control including the user Gray is moved.

• Walker is added in user group Operator.

4. Reimport the LDIF file for the third time with the following settings:

• Fischer is added in user group Operator.

You can configure the handling of object symbols in graphics, for example for detectors which are placed in graphics.

• New: Specifies how to handle new symbols in graphics during the import, for example when a new detector has been repositioned in one or more graphics in comparison to the last import from the same source.
• Existing: Specifies how to handle symbols in graphics during the import, which are already exist due to the previous import from the same source and may now have changed during the new import.
• Orphan: Specifies how to handle symbols in graphics during the import, which are already exist due to the previous import from the same source and are now no longer included in the new import.

You have the following options:

• New > Add: Symbols in graphics from the import not yet saved in Siveillance Control are added.
• New > Skip: Symbols in graphics from the import not yet saved in Siveillance Control are not added.
• Existing > Update: Existing symbols in graphics from a prior import in Siveillance Control are updated, for example position and properties.
• Existing > Keep: All symbols in graphics and their properties saved in Siveillance Control remain unchanged and keep their position and properties even if the import contains the corresponding modified data.
• Orphan > Keep: Existing symbols in graphics that no longer exist in the current import in Siveillance Control continue to be available after the import.
• Orphan > Delete: Existing symbols in graphics that no longer exist in the current import in Siveillance Control are deleted after the import.

The effects of the selected settings are described based on an example for symbols in an aloXerv exchange format file.

• A MOX file has been imported.

1. Edit the MOX file by completing the following steps:

• New: Detector FD U1 was newly added.

• Existing: The position of Detector FD C1 was changed.

• Orphan: Detector FD B1 was deleted.

• Save the MOX file.

2. Reimport the MOX file with the following settings:

• New: Detector FD U1 is not imported.

• Existing: Detector FD C1 is not updated.

• Orphan: Detector FD B1 is deleted.

3. Reimport the MOX file with the following settings:

• New: Detector FD U1 is not imported.

• Existing: Detector FD C1 is changed.

• Orphan: Detector FD B1 is deleted.

4. Reimport the MOX file with the following settings:

• New: Detector FD U1 is imported.

• Existing: Detector FD C1 is not updated.

• Orphan: Detector FD B1 is deleted.

If the Prohibit orphan MORefs option is disabled, the import of objects that reference an object already existing in the system is possible. Non-existing therefore means that the object does not exist in the current import file.

Example

Import of a detector: The detector with its Discipline attribute references the fire alarm technology (BMT) discipline. This discipline is part of the default server configuration and therefore not listed again in the same source.