POSREP IEPD Land Scenario Data

OGC 13-080r3 Copyright © 2013 Open Geospatial Consortium Page 21 8 Components

8.1 Data Source and Data Storage

This section discusses the source of the data used in MOGIE and how it was ultimately stored in the database tables. In both scenarios, the data used to support the MOGIE experiment was stored in a PostGIS enabled PostgreSQL database, which acted as the backend data source to the WFS, as shown in Figure 10 and Figure 12.

8.1.1 Land Scenario Data

Section 7.1 describes the land scenario which simulates a military use case where an enemy is spotted, targeted and destroyed. The observations and resulting attack information is collected, organized and distributed using NIEM and GML conformant XML exchanges processed through MOGIE services. The three NIEM IEPDs used in this scenario were: Position Report Message POSREP, Observation Report Message OBSREP and Call For Fire CFF. The NIEM XML instances generated from these IEPDs were parsed with Java code and inserted in the PostGIS database using simple SQL statements. The IEPDs used in the land scenario were derived from existing IEPDs previously used in multiple venues during the development of C2 Core. For MOGIE, the IEPDs were modified in that all CUI material was removed and they were made to fully conform to NIEM v3.0 Alpha 2 release.

8.1.1.1 POSREP IEPD

The POSREP IEPD conveys the location of a reporting unit at a certain point in time. It also includes additional unit status information such as unit strength, unit identifier, unit name, etc. Additional attributes included in the database but not in the IEPD were message_time_text, time_stale, and time_stale_text. These were added to support the client development and configuration. The time_stale attribute indicates the time when this message is no longer valid because the unit issued an updated location message. Because simulating an actual real-time data feed was outside the scope of this experiment, it was decided to playback the position reports from a pre-populated set of reports. The client developer only had to query the WFS service for the entire set and then replay them. Because the KML timespan feature was being leveraged, a start and end time was needed for each message report. For more information see Section 8.2.2. The message_time_text and time_stale_text attributes are string type versions of the Timestamp attributes. This was necessary to facilitate the temporal field features in ArcMap. GeoServer currently has no feature that allows a timestamp format string to be passed with a WFS query. This means the WFS clients were forced to work with the default time string format. ie: “2001-12-17T09:31:16Z” Since this was not one of the immediatley supported formats in ArcMap, a text version of the timestamp attributes was added with the timestamps pre- formated as a string that ArcMap understood. ie: “2001-12-17 09:31:16” This modification was made to all timestamp types found in both scenarios, not just Position Report Message. They are all suffixed with “_text”. Figure 13 shows the data fields and definitions in the PostGIS database. The field “From IEPD” indicates whether that field originated from the NIEM source. The “Client Support” field indicates whether that field was added to support client development. OGC 13-080r3 Copyright © 2013 Open Geospatial Consortium Page 22 Figure 13: Position Report Database Attributes

8.1.1.2 OBSREP IEPD