TACSIT Controller Interface Avatar
  1. OMG Specification

TACSIT Controller Interface — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
TCI11-35 Issue: SelectionEvent takes a single Entity parameter TCI 1.0b2 open
TCI11-34 SelectionManager selection methods take a single Entity parameter TCI 1.0b2 open
TCI11-36 SelectionMethodology not implemented TCI 1.0b2 open
TCI11-26 Add an EntityRepository Concept / Class to the Standard TCI 1.0b2 open
TCI11-32 Add an Angle Class to the Standard TCI 1.0b2 open
TCI11-31 Add a Distance Class to the Standard TCI 1.0b2 open
TCI11-30 Add method to Entity interface to “getReferencePoint TCI 1.0b2 open
TCI11-25 Modify the comments in ContainQuery TCI 1.0b2 open
TCI11-28 Fix Comment in IntersectionQuery TCI 1.0b2 open
TCI11-29 Remove “plural” designation of method call in EntityTypeQuery TCI 1.0b2 open
TCI11-27 Add comments to QueryManager TCI 1.0b2 open
TCI11-33 Viewport scaleToPoints takes a single GeodeticPosition parameter TCI 1.0b2 open
TCI11-16 Add method to Entity interface to “getReferencePoint” TCI 1.0b2 open
TCI11-15 Modify the comments in ContainQuery TCI 1.0b2 open
TCI11-14 Remove “plural” designation of method call in EntityTypeQuery TCI 1.0b2 open
TCI11-17 Add a Distance Class to the Standard TCI 1.0b2 open
TCI11-19 Revise comments in code/model for clarity in TacsitController.getEntityTypes TCI 1.0b2 open
TCI11-20 SelectionEvent takes a single Entity parameter TCI 1.0b2 open
TCI11-18 SelectionManager selection methods take a single Entity parameter TCI 1.0b2 open
TCI11-21 SelectionMethodology not implemented TCI 1.0b2 open
TCI11-23 Add comments to ViewEye TCI 1.0b2 open
TCI11-22 Add clarification / comment to ViewportManager.getViewports method TCI 1.0b2 open
TCI11-24 Revise comments in code/model for clarity in TacsitController TCI 1.0b2 open
TCI11-6 Revise comments in code/model for clarity in TacsitController.getEntityTypes TCI 1.0b2 open
TCI11-8 Add clarification / comment to ViewportManager.getViewports method TCI 1.0b2 open
TCI11-7 Add comments to QueryManager TCI 1.0b2 open
TCI11-13 Fix Comment in IntersectionQuery TCI 1.0b2 open
TCI11-9 Add comments to ViewEye TCI 1.0b2 open
TCI11-10 Revise comments in code/model for clarity in TacsitController TCI 1.0b2 open
TCI11-12 The GeodeticPosition is an interface, it would be appropriate if wildcards were used. TCI 1.0b2 open
TCI11-11 Section 7.1.1.1.3 "isPointEntity": the table is written twice in the text TCI 1.0b2 open

Issues Descriptions

Issue: SelectionEvent takes a single Entity parameter

  • Key: TCI11-35
  • Legacy Issue Number: 17001
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

SelectionManager selection methods take a single Entity parameter

  • Key: TCI11-34
  • Legacy Issue Number: 17002
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

SelectionMethodology not implemented

  • Key: TCI11-36
  • Legacy Issue Number: 17000
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add an EntityRepository Concept / Class to the Standard

  • Key: TCI11-26
  • Legacy Issue Number: 17006
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add an Angle Class to the Standard

  • Key: TCI11-32
  • Legacy Issue Number: 17004
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add a Distance Class to the Standard

  • Key: TCI11-31
  • Legacy Issue Number: 17005
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add method to Entity interface to “getReferencePoint

  • Key: TCI11-30
  • Legacy Issue Number: 17008
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Modify the comments in ContainQuery

  • Key: TCI11-25
  • Legacy Issue Number: 17007
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Fix Comment in IntersectionQuery

  • Key: TCI11-28
  • Legacy Issue Number: 17010
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Remove “plural” designation of method call in EntityTypeQuery

  • Key: TCI11-29
  • Legacy Issue Number: 17009
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add comments to QueryManager

  • Key: TCI11-27
  • Legacy Issue Number: 17011
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Viewport scaleToPoints takes a single GeodeticPosition parameter

  • Key: TCI11-33
  • Legacy Issue Number: 17003
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add method to Entity interface to “getReferencePoint”

  • Key: TCI11-16
  • Legacy Issue Number: 17054
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Modify the comments in ContainQuery

  • Key: TCI11-15
  • Legacy Issue Number: 17055
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Remove “plural” designation of method call in EntityTypeQuery

  • Key: TCI11-14
  • Legacy Issue Number: 17056
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add a Distance Class to the Standard

  • Key: TCI11-17
  • Legacy Issue Number: 17053
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

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

  • Key: TCI11-19
  • Legacy Issue Number: 17012
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

SelectionEvent takes a single Entity parameter

  • Key: TCI11-20
  • Legacy Issue Number: 17051
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

SelectionManager selection methods take a single Entity parameter

  • Key: TCI11-18
  • Legacy Issue Number: 17052
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

SelectionMethodology not implemented

  • Key: TCI11-21
  • Legacy Issue Number: 17050
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add comments to ViewEye

  • Key: TCI11-23
  • Legacy Issue Number: 17014
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add clarification / comment to ViewportManager.getViewports method

  • Key: TCI11-22
  • Legacy Issue Number: 17015
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Revise comments in code/model for clarity in TacsitController

  • Key: TCI11-24
  • Legacy Issue Number: 17013
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

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

  • Key: TCI11-6
  • Legacy Issue Number: 17059
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add clarification / comment to ViewportManager.getViewports method

  • Key: TCI11-8
  • Legacy Issue Number: 17062
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add comments to QueryManager

  • Key: TCI11-7
  • Legacy Issue Number: 17058
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Fix Comment in IntersectionQuery

  • Key: TCI11-13
  • Legacy Issue Number: 17057
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Add comments to ViewEye

  • Key: TCI11-9
  • Legacy Issue Number: 17061
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

Revise comments in code/model for clarity in TacsitController

  • Key: TCI11-10
  • Legacy Issue Number: 17060
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

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

  • Key: TCI11-12
  • Legacy Issue Number: 17240
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT

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

  • Key: TCI11-11
  • Legacy Issue Number: 17454
  • Status: open  
  • Source: SimVentions ( Mr. 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: Wed, 1 Feb 2023 21:57 GMT