TACSIT Controller Interface Avatar
  1. OMG Specification

TACSIT Controller Interface — Open Issues

  • Acronym: TCI
  • Issues Count: 48
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
TCI_-48 The machine readable files include redundant and/or useless files TCI 1.0b1 open
TCI_-47 There is a Model file for the Java PSM but not the C++ PSM as claimed in the Manifest. TCI 1.0b1 open
TCI_-46 Compliance Section issue TCI 1.0b1 open
TCI_-45 The Normative References section should be in part 2 TCI 1.0b1 open
TCI_-44 normative PIM is expressed as a MagicDraw file TCI 1.0b1 open
TCI_-43 Section 7.1.1.1.3 "isPointEntity": the table is written twice in the text TCI 1.0b2 open
TCI_-42 The GeodeticPosition is an interface, it would be appropriate if wildcards were used. TCI 1.0b2 open
TCI_-41 Add clarification / comment to ViewportManager.getViewports method TCI 1.0b2 open
TCI_-40 Add comments to ViewEye TCI 1.0b2 open
TCI_-39 Revise comments in code/model for clarity in TacsitController TCI 1.0b2 open
TCI_-38 Revise comments in code/model for clarity in TacsitController.getEntityTypes TCI 1.0b2 open
TCI_-37 Add comments to QueryManager TCI 1.0b2 open
TCI_-36 Fix Comment in IntersectionQuery TCI 1.0b2 open
TCI_-35 Remove “plural” designation of method call in EntityTypeQuery TCI 1.0b2 open
TCI_-34 Modify the comments in ContainQuery TCI 1.0b2 open
TCI_-33 Add method to Entity interface to “getReferencePoint” TCI 1.0b2 open
TCI_-32 Add a Distance Class to the Standard TCI 1.0b2 open
TCI_-31 SelectionManager selection methods take a single Entity parameter TCI 1.0b2 open
TCI_-30 SelectionEvent takes a single Entity parameter TCI 1.0b2 open
TCI_-29 SelectionMethodology not implemented TCI 1.0b2 open
TCI_-28 Add clarification / comment to ViewportManager.getViewports method TCI 1.0b2 open
TCI_-27 Add comments to ViewEye TCI 1.0b2 open
TCI_-26 Revise comments in code/model for clarity in TacsitController TCI 1.0b2 open
TCI_-25 Revise comments in code/model for clarity in TacsitController.getEntityTypes TCI 1.0b2 open
TCI_-24 Add comments to QueryManager TCI 1.0b2 open
TCI_-23 Fix Comment in IntersectionQuery TCI 1.0b2 open
TCI_-22 Remove “plural” designation of method call in EntityTypeQuery TCI 1.0b2 open
TCI_-21 Add method to Entity interface to “getReferencePoint TCI 1.0b2 open
TCI_-20 Modify the comments in ContainQuery TCI 1.0b2 open
TCI_-19 Add an EntityRepository Concept / Class to the Standard TCI 1.0b2 open
TCI_-18 Add a Distance Class to the Standard TCI 1.0b2 open
TCI_-17 Add an Angle Class to the Standard TCI 1.0b2 open
TCI_-16 Viewport scaleToPoints takes a single GeodeticPosition parameter TCI 1.0b2 open
TCI_-15 SelectionManager selection methods take a single Entity parameter TCI 1.0b2 open
TCI_-14 Issue: SelectionEvent takes a single Entity parameter TCI 1.0b2 open
TCI_-13 SelectionMethodology not implemented TCI 1.0b2 open
TCI_-12 Sample C++ header files TCI 1.0b1 open
TCI_-11 Consistent centring with a moving entity TCI 1.0b1 open
TCI_-10 getEntityTypes TCI 1.0b1 open
TCI_-9 Setting the categories of selectable items TCI 1.0b1 open
TCI_-8 Selection by track number TCI 1.0b1 open
TCI_-7 SelectionType TCI 1.0b1 open
TCI_-6 addSelectionListener TCI 1.0b1 open
TCI_-5 Stanard - editorial TCI 1.0b1 open
TCI_-4 Ref. to 6.3.2 TCI 1.0b1 open
TCI_-3 Conformance Criteria TCI 1.0b1 open
TCI_-2 Dealing with error at PIM level TCI 1.0b1 open
TCI_-1 GeoPosition vs. GeodeticPosition TCI 1.0b1 open

Issues Descriptions

The machine readable files include redundant and/or useless files

  • Key: TCI_-48
  • Legacy Issue Number: 15607
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The machine readable files include redundant and/or useless files – the .mdr and mdr.bak files are useless and the mdzip is not needed as well as the .xml file since one is a compressed version of the other.

  • Reported: TCI 1.0b1 — Mon, 20 Sep 2010 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:21 GMT

There is a Model file for the Java PSM but not the C++ PSM as claimed in the Manifest.

  • Key: TCI_-47
  • Legacy Issue Number: 15606
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    There is a Model file for the Java PSM but not the C++ PSM as claimed in the Manifest.

  • Reported: TCI 1.0b1 — Mon, 20 Sep 2010 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:21 GMT

Compliance Section issue

  • Key: TCI_-46
  • Legacy Issue Number: 15605
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The Compliance section should state how software complies e.g. it might say that for the Java PSM that software will implement all the normative APIs and exhibit the behavior for each as defined in the specification.

  • Reported: TCI 1.0b1 — Mon, 20 Sep 2010 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:21 GMT

The Normative References section should be in part 2

  • Key: TCI_-45
  • Legacy Issue Number: 15604
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The Normative References section should be in part 2. However the current reference is not Normative and so the section should be blank

  • Reported: TCI 1.0b1 — Mon, 20 Sep 2010 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:21 GMT

normative PIM is expressed as a MagicDraw file

  • Key: TCI_-44
  • Legacy Issue Number: 15603
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    In the AB today, when the TACSIT submission was presented, I noted that the normative PIM is expressed as a MagicDraw file, not a pure OMG-compliant XMI file. The normative PIM should be an OMG-compliant file and the MagicDraw file should be a convenience artifact.

  • Reported: TCI 1.0b1 — Mon, 20 Sep 2010 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:21 GMT

Section 7.1.1.1.3 "isPointEntity": the table is written twice in the text

  • Key: TCI_-43
  • Legacy Issue Number: 17454
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    Section 7.1.1.1.3 "isPointEntity": the table is written twice in the text

  • Reported: TCI 1.0b2 — Thu, 21 Jun 2012 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

The GeodeticPosition is an interface, it would be appropriate if wildcards were used.

  • Key: TCI_-42
  • Legacy Issue Number: 17240
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The GeodeticPosition is an interface, it would be appropriate if wildcards were used. The suggested fix is as follows:
    void scaleToPoints(List<? Extends GeodeticPosition> points, double margin);

  • Reported: TCI 1.0b2 — Tue, 13 Mar 2012 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add clarification / comment to ViewportManager.getViewports method

  • Key: TCI_-41
  • Legacy Issue Number: 17062
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The method getViewports() returns a Collection of Viewports. A user of this class may think modifying the contents of the Collection would modify the state of the ViewportManager.

    Resolution / Discussion:
    Explicitly state (and enforce) that the returned Collection is unmodifiable.

    Revised Text:
    Add sentence to section 7.1.1.13.4 stating:
    The collection returned by this method is unmodifiable

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add comments to ViewEye

  • Key: TCI_-40
  • Legacy Issue Number: 17061
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The comments of the member variables are very descriptive. However, these comments should appear in the Javadoc for the get and set methods for each property. This provides much better integration with IDEs – most especially important for remembering whether the values are in degrees or radians.

    Resolution / Discussion:
    Copy the comments for member variables ViewEyeProperties to their respective get/set methods.

    Revised Text:
    Update the PIM model and Java PSM to reflect comments in section 7.1.1.9.
    There is no change needed to the specification document.

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Revise comments in code/model for clarity in TacsitController

  • Key: TCI_-39
  • Legacy Issue Number: 17060
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    It is not clear from the comments that the collections returned by getProjections() and getEntityTypes() cannot be changed.

    Resolution / Discussion:
    The comments should say the collections returned by getProjections and getEntityTypes() are unmodifiable.

    Revised Text:
    Add text to paragraphs 7.1.1.8.1 and 7.1.1.8.8.
    Attempted changes to the collection returned by this method will have no effect on the behavior and functionality of the TacsitController.

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Revise comments in code/model for clarity in TacsitController.getEntityTypes

  • Key: TCI_-38
  • Legacy Issue Number: 17059
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The comment for this method reads:
    /**

    • Return the Entity Types which are supported by the TACSIT. This will
    • return a list of all Entity Types currently available for Selection and
    • Query by this TACSITController
    • @return
      */

    The first sentence gives the impression that it will return anything that can possibly be in the TacsitController. The second sentence implies only entities that currently exist in the TacsitController.

    Resolution:
    It seems likely that the first sentence is correct; the wording of the second sentence should be changed to “This will return a list of all Entity Types available for Selection and Query by this TACSITController”.

    Revised Text:
    Change the comments in paragraph 7.1.1.8.2 and the model to read:
    Returns the Entity Types that are supported by the TAC SIT. This will return a list of all Entity Types available for Selection and Query by this TACSITController.

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add comments to QueryManager

  • Key: TCI_-37
  • Legacy Issue Number: 17058
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    It is unclear whether or not a null query is permissible.

    Resolution / Discussion:
    Explicitly state in the interface documentation that a null query should return all Entities in the QueryManager.

    Revised Text:
    Add sentence to 7.2.1.6 “In the case where a null query is passed to the QueryManager, the QueryManager is to return all Entities in the QueryManager.”

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Fix Comment in IntersectionQuery

  • Key: TCI_-36
  • Legacy Issue Number: 17057
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    Summary:

    The intersection query has a comment that states:

    Intersection is determined by using the Entity's Geometry as an argument to the intersects() method on the Geometry specified by this Query, i.e., this.satisfies( entity ) = this.getGeometry().intersects( entity.getGeometry() )

    This is not possible, however. The entity class has no “Geometry” in its interface. If it were present, the Geometry interface does not provide enough information to evaluate such a query.

    Resolution / Discussion:
    Change the comment to a more general description of the problem space. For example: Intersection is determined by checking whether or not one entity partially overlaps another entity.

    Revised Text:
    Changed text in 7.2.1.5 to read:
    The IntersectionQuery is used to determine if an Entity intersects geometrically with a Geometry. Intersection is determined by checking whether or not one entity partially overlaps another entity

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Remove “plural” designation of method call in EntityTypeQuery

  • Key: TCI_-35
  • Legacy Issue Number: 17056
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    Summary:
    Interface specification is pluralized and the figure on 7.2.1.3 shows a return of multiple EntityType objects. This implies that multiple EntityTypes are returned, however, the return value specified in the table and the Java PSM is singular.

    EntityType getEntityTypes( );

    Resolution / Discussion:
    Change the return type in the table to match the model and update the Java PSM.

    The Java PSM will return a Collection<EntityType> instead of a single EntityType object.

    Revised Text:

    In Paragraph 7.2.1.3.1, modify the table to:
    7.2.1.3.1 getEntityTypes
    Returns the list of EntityType objects to compare with.
    Type EntityType [1..n]
    Visibility public
    IsAbstract false
    Parameter

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Modify the comments in ContainQuery

  • Key: TCI_-34
  • Legacy Issue Number: 17055
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    Severity: Support Text

    Summary: The comments of this class reference state this:

    Containment is determined by using the Entity's Geometry as an argument to the contains() method on the Geometry specified by this Query, i.e., this.satisfies( entity ) = this.getGeometry().contains( entity.getGeometry() )

    This is not possible, however. The entity class has no “Geometry” in its interface. If it were present, the Geometry interface does not provide enough information to evaluate such a query.

    Resolution:
    The Geometry class “contains” method accepts a GeodeticPosition, not a Geometry. By adding the “getReferencePoint” method to entity (as proposed by issue XXXX) and modifying the comment on this method

    Change the comment to a more accurate description of how to use it. For example: Containment is determined by checking whether or not an entity’s reference point (GeodeticPosition) is contained within a specific Geometry, i.e. this.satisfies(entity) = this.getGeometry().contains(entity.getReferencePoint()).

    Revised Text:
    Section 7.2.1.1 changed the description / comment for the method to
    “Containment is determined by checking whether or not an entity’s reference point (GeodeticPosition) is contained within a specific Geometry, i.e. this.satisfies(entity) = this.getGeometry().contains(entity.getReferencePoint()).”

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add method to Entity interface to “getReferencePoint”

  • Key: TCI_-33
  • Legacy Issue Number: 17054
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    There is no way to get even a general understanding about where an Entity exists at a general interface level.

    Resolution:
    Define a new method in the entity interface:

    GeodeticPosition getReferencePoint();

    This is logically consistent across any entity type. An entity could still consist of multiple points (e.g., isPointEntity() would return false), and still return a center point. This keeps the conceptual integrity of the entity interface, but expands its utility.

    One such concrete example of the utility: Creating a user interface component for scaling a Viewport to a set of points. The most common use case is for those points to be entity positions. The QueryManager can be used to retrieve a list of entities, but from that point on you have to dive into implementation specific details to convert the Entities to a position to choose from.

    Revised Text:
    Part of this resolution is the editorial fix to clean up the “extra” tables in 7.1.1.1.3.

    Update the model to reflect the new method in the Entity interface to add getReferencePoint() with a return type of GeodeticPosition.

    Add a new section to the specification and update the graphic in paragraph 7.1.1.1 on figure 7.11to reflect the new method.

    7.1.1.1.5 getReferencePoint
    Returns the GeodeticPosition to be used as the main point of reference for this entity.
    Type GeodeticPosition
    Visibility public
    Is Abstract false
    Parameter

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add a Distance Class to the Standard

  • Key: TCI_-32
  • Legacy Issue Number: 17053
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    Using this as an object rather than a plain double value is a cheap way to avoid costly errors. NASA lost a $125 million Mars orbiter because one team was using imperial units instead of metric. Representing distance as an object makes it glaringly obvious in the code which calculations are using which units.

    Consider the following method of Rectangle:
    double getHeight();

    Embedded in the comments of the interface contract is that “getHeight()” returns a double in meters. But that’s not at all obvious in client code that uses getHeight(), especially if it’s 2 or 3 levels removed from the place it is called.
    Instead, if it were changed to:
    Distance getHeight();

    Distance could have methods “double getMeters()”, and “double getFeet()”, that make it immediately obvious what the returned value represents.

    If adopted, the following changes should be made:
    • GeodeticPosition
    o Change altitude property from double to Distance
    • Rectangle
    o Change getHeight() to return Distance
    o Change getWidth() to return Distance
    • Circle
    o Change getRadius() to return Distance
    • ViewEyeProperties
    o Change get/setRangeScale to use Distance
    • Viewport
    o Change scaleToPoints(points, margin) margin parameter to Distance
    Resolution:

    A Distance class has been added to the specification and referenced in the places suggested.

    Revised Text:

    STILL NEED TO IMPLEMENT THIS IN THE SPEC.

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

SelectionManager selection methods take a single Entity parameter

  • Key: TCI_-31
  • Legacy Issue Number: 17052
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    A translation error occurred from the java PSM to the specification source files. This should be a Collection or List of Entity objects, rather than a single entity. The affected methods are:
    • setSelection
    • addToSelection
    • removeFromSelection

    Resolution:
    Update the Java PSM class methods to take a Collection<Entity>.

    Revised Text:

    There is no modification necessary to the text of the specification. Java PSM files only.

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

SelectionEvent takes a single Entity parameter

  • Key: TCI_-30
  • Legacy Issue Number: 17051
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    A translation error occurred from the java PSM to the specification source files. This should be a Collection or List of Entity objects, rather than a single Entity. The affected methods are:
    • Constructor
    • getEntities
    To ensure the integrity of the event object, the internally stored Collection or List should be unmodifiable. This can be easily achieved by copying the List and invoking Collections.unmodifiableList(source).

    Resolution:
    Update the Java PSM class methods to take/return a Collection<Entity> respectively.

    Revised Text:

    There is no modification necessary to the text of the specification. Java PSM files only.

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

SelectionMethodology not implemented

  • Key: TCI_-29
  • Legacy Issue Number: 17050
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    This may be a translation error from the platform specific model, but this must be implemented. It would best be implemented as an enumeration.

    Resolution:
    Nothing to resolve. Already addressed in specification.

    Discussion:
    This is already addressed in paragraph 7.1.1.16 with the Enumeration Class called SelectionMethodology. Its two valid values are “ViewportDependent” and “ViewportIndependent”

  • Reported: TCI 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add clarification / comment to ViewportManager.getViewports method

  • Key: TCI_-28
  • Legacy Issue Number: 17015
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The method getViewports() returns a Collection of Viewports. A user of this class may think modifying the contents of the Collection would modify the state of the ViewportManager.
    Suggested Resolution:
    Explicitly state (and enforce) that the returned Collection is unmodifiable.

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add comments to ViewEye

  • Key: TCI_-27
  • Legacy Issue Number: 17014
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The comments of the member variables are very descriptive. However, these comments should appear in the Javadoc for the get and set methods for each property. This provides much better integration with IDEs – most especially important for remembering whether the values are in degrees or radians.
    Suggested Resolution:
    Copy the comments for member variables ViewEyeProperties to their respective get/set methods.

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Revise comments in code/model for clarity in TacsitController

  • Key: TCI_-26
  • Legacy Issue Number: 17013
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    It is not clear from the comments that the collections returned by getProjections() and getEntityTypes() cannot be changed.

    Suggested resolution:

    The comments should say the collections returned by getProjections and getEntityTYpes() are unmodifiable.

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Revise comments in code/model for clarity in TacsitController.getEntityTypes

  • Key: TCI_-25
  • Legacy Issue Number: 17012
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The comment for this method reads:
    /**

    • Return the Entity Types which are supported by the TACSIT. This will
    • return a list of all Entity Types currently available for Selection and
    • Query by this TACSITController
    • @return
      */

    The first sentence gives the impression that it will return anything that can possibly be in the TacsitController. The second sentence implies only entities that currently exist in the TacsitController.

    Suggested resolution:

    It seems likely that the first sentence is correct; the wording of the second sentence should be changed to “This will return a list of all Entity Types available for Selection and Query by this TACSITController”.

    AGREED

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add comments to QueryManager

  • Key: TCI_-24
  • Legacy Issue Number: 17011
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    It is unclear whether or not a null query is permissible.

    Suggested Resolution:

    Explicitly state in the interface documentation that a null query should return all Entities in the QueryManager.

    AGREED

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Fix Comment in IntersectionQuery

  • Key: TCI_-23
  • Legacy Issue Number: 17010
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The intersection query has a comment that states:

    Intersection is determined by using the Entity's Geometry as an argument to the intersects() method on the Geometry specified by this Query, i.e., this.satisfies( entity ) = this.getGeometry().intersects( entity.getGeometry() )

    This is not possible, however. The entity class has no “Geometry” in its interface. If it were present, the Geometry interface does not provide enough information to evaluate such a query.

    Suggested Resolution:
    Change the comment to a more general description of the problem space. For example: Intersection is determined by checking whether or not one entity partially overlaps another entity.

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Remove “plural” designation of method call in EntityTypeQuery

  • Key: TCI_-22
  • Legacy Issue Number: 17009
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    Interface specification is pluralized. This implies that multiple EntityTypes are returned, however, the return value is singular.
    EntityType getEntityTypes( );

    Suggested Resolution:
    Singularize getEntityTypes() to getEntityType().
    AGREED

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add method to Entity interface to “getReferencePoint

  • Key: TCI_-21
  • Legacy Issue Number: 17008
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    There is no way to get even a general understanding about where an Entity exists at a general interface level.

    Suggested Resolution:
    Define a new method in the entity interface:

    GeodeticPosition getReferencePoint();

    This is logically consistent across any entity type. An entity could still consist of multiple points (e.g., isPointEntity() would return false), and still return a center point. This keeps the conceptual integrity of the entity interface, but expands its utility.

    One such concrete example of the utility: Creating a user interface component for scaling a Viewport to a set of points. The most common use case is for those points to be entity positions. The QueryManager can be used to retrieve a list of entities, but from that point on you have to dive into implementation specific details to convert the Entities to a position to choose from.

    AGREED

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Modify the comments in ContainQuery

  • Key: TCI_-20
  • Legacy Issue Number: 17007
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The comments of this class reference state this:

    Containment is determined by using the Entity's Geometry as an argument to the contains() method on the Geometry specified by this Query, i.e., this.satisfies( entity ) = this.getGeometry().contains( entity.getGeometry() )

    This is not possible, however. The entity class has no “Geometry” in its interface. If it were present, the Geometry interface does not provide enough information to evaluate such a query.

    Suggested Resolution:
    Change the comment to a more general description of the problem space. For example: Containment is determined by checking whether or not one entity is wholly contained within another entity.

    AGREED

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add an EntityRepository Concept / Class to the Standard

  • Key: TCI_-19
  • Legacy Issue Number: 17006
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    The definition of how Entity objects are related to and move around through a TacsitController, ViewportManager, and Viewport seems to be vague by design. Presumably, vendors have different implementations that make creating a cohesive abstraction difficult. It is a worthy goal, however – if it can be achieved. Separating the subsystems into more clearly defined subcomponents (Track providing, and track viewing) promotes encapsulation and division of responsibility. It also allows simplified compliance to the Tacsit specification for implementations which really provide only a single subsystem.

    Consider NASA’s Worldwind. It is a general geographic map package. It provides little facility for getting track information from remote sources. The entire entity store concept is foreign to Worldwind; the reference implementation is purely incidental. Worldwind could work with any entity store, provided it had a well defined interface.

    The reference implementation contains a sample of what an EntityRepository would look like. The definition is given here (sans comments):

    public interface EntityRepository<E extends Entity> extends QueryManager

    { public Iterator<E> getEntities(); public void addRepositoryListener(RepositoryListener listener); public void removeRepositoryListener(RepositoryListener listener); }

    Repository Listener would be defined as follows:

    public interface RepositoryListener

    { public void entitiesAdded(RepositoryChangeEvent event); public void entitiesRemoved(RepositoryChangeEvent event); public void entitiesUpdated(RepositoryChangeEvent event); public void entitiesCleared(RepositoryChangeEvent event); }

    This interface description should be general enough to allow for abstraction of existing implementations.

    An area of common concern for this type of implementation is update speed. If data is being imported at a very fast speed, the user interface may not be able to handle the volume of updates. For instance, consider the common scenario that each update received is an array of structs containing track data that contains all the values for the track in the system. If a repository were to fire an “entitiesUpdated” event every time a property was copied into the entity, that would potentially be many new objects created:

    O = (number of objects created to fire the event) *(number of properties set) * (number of tracks)

    Each track will probably have 10 properties, 2 objects will be needed, and there may be roughly 2000 tracks in the system. That’s 40,000 objects every time a new track block comes in – excluding anything that happens once it gets to the UI.

    However, this problem can be alleviated by deviating slightly from the standard Listener implementation. Instead of broadcasting to a RepositoryListener any time a track is changed, the EntityRepository can poll its Entity objects for changes based on an update rate. It would then fire a summary of those changes to its associated listeners, effectively coalescing all the redundant events into a single one. This drastically cuts down on the number of objects created to:

    O = (number of objects created to fire the event)

    Each entity will need to be “polled” every update, but the polling consists simply of checking a time value against a known value. In the example above, 2000 lastModified values would have to be compared.

    This allows the update interval to be easily scaled to the fastest possible rate that still gives the desired responsiveness in the user interface. The key attribute is this: from the perspective of the client of the entity repository interface, it behaves exactly as per a “normal” Listening pattern. The complexity is masked by the interface and doesn’t creep into client code.

    An example of how such an implementation would work is included in the reference implementation, PolledEntityRepository.

    FUTURE

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add a Distance Class to the Standard

  • Key: TCI_-18
  • Legacy Issue Number: 17005
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    Using this as an object rather than a plain double value is a cheap way to avoid costly errors. NASA lost a $125 million Mars orbiter because one team was using imperial units instead of metric. Representing distance as an object makes it glaringly obvious in the code which calculations are using which units.

    Consider the following method of Rectangle:
    double getHeight();

    Embedded in the comments of the interface contract is that “getHeight()” returns a double in meters. But that’s not at all obvious in client code that uses getHeight(), especially if it’s 2 or 3 levels removed from the place it is called.
    Instead, if it were changed to:
    Distance getHeight();

    Distance could have methods “double getMeters()”, and “double getFeet()”, that make it immediately obvious what the returned value represents.

    If adopted, the following changes should be made:
    • GeodeticPosition
    o Change altitude property from double to Distance
    • Rectangle
    o Change getHeight() to return Distance
    o Change getWidth() to return Distance
    • Circle
    o Change getRadius() to return Distance
    • ViewEyeProperties
    o Change get/setRangeScale to use Distance
    • Viewport
    o Change scaleToPoints(points, margin) margin parameter to Distance
    AGREED

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Add an Angle Class to the Standard

  • Key: TCI_-17
  • Legacy Issue Number: 17004
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    Having an Angle class would be very useful. This would free you from potential errors about worrying whether a double represents degrees or radians. This worry is particularly troublesome, since interface components present angles as degrees, whereas processing is most frequently done in radians. When dealing with unstructured primitive values, it’s an easy mistake to make. An Angle class would allow both to operate in whatever unit was most convenient by providing getters for each unit type.

    In addition to unit safety checking, it also makes property editors (for example, for tables and forms) far simpler to construct. The simplest way to specify an editor or renderer is to set the default cell editor or renderer. This facilitates minimal coupling between UI implementations and the data being presented. If the data is stored and presented as doubles, this approach is not possible because an editor that works for a unit of distance is probably not appropriate to also work for a unit of angle. Since GeodeticPosition contains both, this problem is likely to come up very frequently. The problem can be worked around by explicitly setting a particular column’s editor or renderer, but this strongly couples the display capability to the ordering of the displayed TableModel.

    A sample implementation of Angle is provided in the reference implementation. If Angle is added, the following properties should be changed to an Angle:
    • Rectangle
    o Orientation property
    • Geodetic Position
    o Latitude property
    o Longitude property
    • ViewEyeProperties
    o Orientation property
    AGREED

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Viewport scaleToPoints takes a single GeodeticPosition parameter

  • Key: TCI_-16
  • Legacy Issue Number: 17003
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    A translation error occurred from the java PSM to the specification source files. scaleToPoints takes only a single GeodeticPosition, whereas it should take a List of GeodeticPositions. In addition, since GeodeticPosition is an interface, it would be appropriate if wildcards were used. The suggested fix is as follows:
    void scaleToPoints(List<? Extends GeodeticPosition> points, double margin);

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

SelectionManager selection methods take a single Entity parameter

  • Key: TCI_-15
  • Legacy Issue Number: 17002
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    A translation error occurred from the java PSM to the specification source files. This should be a Collection or List of Entity objects, rather than a single entity. The affected methods are:
    • setSelection
    • addToSelection
    • removeFromSelection

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Issue: SelectionEvent takes a single Entity parameter

  • Key: TCI_-14
  • Legacy Issue Number: 17001
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    A translation error occurred from the java PSM to the specification source files. This should be a Collection or List of Entity objects, rather than a single Entity. The affected methods are:
    • Constructor
    • getEntities
    To ensure the integrity of the event object, the internally stored Collection or List should be unmodifiable. This can be easily achieved by copying the List and invoking Collections.unmodifiableList(source).

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

SelectionMethodology not implemented

  • Key: TCI_-13
  • Legacy Issue Number: 17000
  • Status: open  
  • Source: SimVentions ( Matthew Wilson)
  • Summary:

    This may be a translation error from the platform specific model, but this must be implemented. It would best be implemented as an enumeration.

  • Reported: TCI 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Sample C++ header files

  • Key: TCI_-12
  • Legacy Issue Number: 15803
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Chapter/Section: 9
    Title: Sample C++ header files
    Nature: Enhancement
    Severity: Significant

    Please replace the "sample" before "C++ header files" with "normative".

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Consistent centring with a moving entity

  • Key: TCI_-11
  • Legacy Issue Number: 15802
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The proposed way to do the consistent centring with a moving entity seems inefficient and will imply unsmooth multiple movements of the viewport.
    A specific interface allowing such a slaved centring with an entity would be, in my point of view, by far better than this.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

getEntityTypes

  • Key: TCI_-10
  • Legacy Issue Number: 15801
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    "getEntityTypes" is misnamed because it doesn't get all the entity types, hence a name such as "getSelectableEntityTypes" would be more explicit.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Setting the categories of selectable items

  • Key: TCI_-9
  • Legacy Issue Number: 15800
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TACSIT Controller Interface for CMS Systems
    Version 1.0 - Beta 1
    Date: October 2010
    dtc/10-10-11

    Chapter/Section: 7.1
    Title: Setting the categories of selectable items
    Nature: Enhancement
    Severity: Significant

    I didn't find any interface allowing to set the categories of selectable items.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Selection by track number

  • Key: TCI_-8
  • Legacy Issue Number: 15799
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TACSIT Controller Interface for CMS Systems
    Version 1.0 - Beta 1
    Date: October 2010
    dtc/10-10-11

    Chapter/Section: 7.1
    Title: Selection by track number
    Nature: Enhancement
    Severity: Significant

    The ways to select by track number as well as to select within geographic geometry seem to me inefficient. Indeed, in that way there are 2 accesses to the TACSIT server(s): one to query on one to effectively select when an interface proposing to select from a an interface with a query as parameter would be more efficient since it implied just one access call to the TACSIT server.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

SelectionType

  • Key: TCI_-7
  • Legacy Issue Number: 15798
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TACSIT Controller Interface for CMS Systems
    Version 1.0 - Beta 1
    Date: October 2010
    dtc/10-10-11

    Chapter/Section: 7.1
    Title: SelectionType
    Nature: Clarification
    Severity: Minor

    It is not clear what "OTHER" is for.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

addSelectionListener

  • Key: TCI_-6
  • Legacy Issue Number: 15797
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TACSIT Controller Interface for CMS Systems
    Version 1.0 - Beta 1
    Date: October 2010
    dtc/10-10-11

    -------------------------------
    Chapter/Section: 7.1
    Title: addSelectionListener
    Nature: Enhancement
    Severity: Significant

    This API seems to me very poor. Wouldn't it be possible to add some convenience APIs allowing a listener on the primary selection, the secondary selection, on setting or unsetting on of these selection... This would lower the number of server-client exchanges for nothing but test that this not something of interest.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Stanard - editorial

  • Key: TCI_-5
  • Legacy Issue Number: 15796
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TACSIT Controller Interface for CMS Systems
    Version 1.0 - Beta 1
    Date: October 2010
    dtc/10-10-11

    -------------------------------
    Page: 7
    Title: Stanard
    Nature: Clarification
    Severity: Minor

    "stanard" instead of "standard".

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Ref. to 6.3.2

  • Key: TCI_-4
  • Legacy Issue Number: 15795
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TACSIT Controller Interface for CMS Systems
    Version 1.0 - Beta 1
    Date: October 2010
    dtc/10-10-11

    Page: 7
    Title: Ref. to 6.3.2
    Nature: Clarification
    Severity: Minor

    Broken reference to section 6.3.2.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Conformance Criteria

  • Key: TCI_-3
  • Legacy Issue Number: 15794
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Chapter/Section: 2
    Title: Conformance Criteria
    Nature: Revision
    Severity: Significant

    Please add "completely" between "match" and "one or more of".

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

Dealing with error at PIM level

  • Key: TCI_-2
  • Legacy Issue Number: 15793
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TACSIT Controller Interface for CMS Systems
    Version 1.0 - Beta 1
    Date: October 2010
    dtc/10-10-11

    Chapter/Section: all
    Title: Dealing with error at PIM level
    Nature: Revision
    Severity: Significant

    Error should be dealt with at the PIM level for each method.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT

GeoPosition vs. GeodeticPosition

  • Key: TCI_-1
  • Legacy Issue Number: 15792
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TACSIT Controller Interface for CMS Systems
    Version 1.0 - Beta 1
    Date: October 2010
    dtc/10-10-11

    -------------------------------
    Chapter/Section: all
    Title: GeoPosition vs. GeodeticPosition
    Nature: Revision
    Severity: Significant

    Two classes seems to speak of the same stuff: GeoPosition (see Section 2.3.1.3) and GeodeticPosition. My guess is that GeoPosition should be renamed ad GeodeticPosition. Please fix or explain.

  • Reported: TCI 1.0b1 — Wed, 3 Nov 2010 04:00 GMT
  • Updated: Sat, 7 Mar 2015 08:56 GMT