Conversation
…mary and mission frame features to support SNAARE.
|
I'm reading this as many of the changes are reading a TASS specific format and my inclination is to leave a "stanag4676" format that sticks to the spec (I know its evolving, but within reason) and have a format with a different name exposed "stanag4676-tass" or something like that which extends from the original format and adds a few features. A lot of the changes seems to be related to the original spec, but it seems some of these things are out of spec? |
|
Hey Rich, thanks for reviewing my changes. BAE has submitted a change request to the spec to include the mission summary information. Not sure how the process works or how long it takes to change the spec, but, at a minimum, the committee is aware of the change. My understanding is that track object classification is already part of the spec, but BAE would like to add two new classification types MOTORCYCLE and TRUCK - BOX. The plugin has been tested against STANAG XML files with and without track object classification data. The ObjectClass attributes are null when the no track object classification data is available. Let me know if this information changes your mind or not. Thanks again!! |
|
Thanks Mike! That info does change my mind. It wasn't clear that this was all either part of the spec or upcoming to the spec. Because I know the spec is evolving I am happy with that answer. I was just trying to avoid the situation where someone else tries to use this for stanag4676 data and find that it is specific to a tool. when you say BAE would like to add two new classification types MOTORCYCLE and TRUCK - BOX, you mean to the spec? Let us know when you wrap it up and we can go through it in a little more detail and pull it in. But in short it looks like its coming along well. |
|
Ok, the code is ready for review. Let me know if you have any questions or concerns. Rich, I'm assuming BAE will request to add MOTORCYCLE and TRUCK - BOX to the spec, but I don't know for sure. |
There was a problem hiding this comment.
Consider being more specific, using Polygon.class
|
It looks really good. The only minor critique I had was based on issues we've encountered with Geometry.class (in the latest version of geotools for example line styling would throw exceptions for GetFeatureInfo when using Geometry.class but not when the specific geometry type is used). I think geotools/geoserver works best when you are specific on the geometry type for the feature type definition. I know we are guilty of having the generic Geometry.class in places, which from geotools is only intended when you vary geometry types within the same feature type. In these cases, it seems to be a constant geometry type. Line ~27 of Stanag4676Utils defines Geometry.class when it would best be Point.class. Anyways, I realize you just used the same pattern we've used in the past, we just recently discovered we need to move away from that pattern to use the specific geometry types when possible. Otherwise, we're ready to merge this into master. |
|
Thanks Rich. As requested, I changed the geometry types to: |
This pull request includes modifications to the GeoWave STANAG 4676 plugin to support BAE SNAARE processing. The changes can be grouped into three separate categories: Mission Summary, Track Point Modality and Track Object Classification.
Mission Summary Changes:
This pull request adds two new feature types (mission_summary and mission_frame) that capture the contents of the MissionSummary.xml file.
The mission_summary feature type captures mission metadata in the following attributes:
geometry (Geometry) - Polygon of coverage area
Mission (String) - Unique ID
StartTime (Date) - Mission start time
EndTime (Date) - Mission end time
Name (String) - Mission name
Security (String) - Classification level
ActiveObjectClass (String) - Comma separated list of the track object classifications that were active during the processing of the mission (see below).
The mission_frame feature type captures mission frame metadata in the following attributes:
geometry (Geometry) - Polygon of coverage area
Mission (String) - Unique ID
TimeStamp (Date) - Frame timestamp
FrameNumber (Integer) - Frame number
Track Point Modality Changes:
This pull request adds a TrackPointSource (String) attribute to the track_point feature which captures the source modality of the track point.
Track Object Classification Changes:
The BAE TASS software is capable of classifying tracks as objects (CAR, MOTORCYCLE, TRUCK-BOX, etc.). TASS can be configured to run multiple track object classifications simultaneously (active). Each track is classified for each of the active object classifications. An object classification consists of a confidence (0-10) and source reliability (0-10) value.
My first approach stored the track object classifications in a separate feature type. However, for query efficiency purposes, the BAE team requested that we store the object classification data as attributes in the track feature. The object classification data is stored as comma separated string attributes:
ObjectClass: CAR,MOTORCYCLE,TRUCK - BOX
ObjectClassConf: 0,5,10
ObjectClassRel: 0,0,0
ObjectClassTime: 2013-08-04T14:54:11.500Z,2013-08-04T14:54:12.000Z,2013-08-04T14:54:12.500Z
This pull request was opened to get feedback on the changes. It's not 100% ready to be pulled it. At a minimum, I need to add mission summary support to the NATO4676Encoder.