Issues for Mailing list of the Robotic Localization Service (RLS) Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 16173: Parent class of Architecture::DirectSymbol and Architecture::SymbolRef
Issue 16174: Inconsistency in structure of Symbolic and Numeric Value for Position class
Issue 16175: Relation between Architecture::MobileDatum and Architecture::InStream
Issue 16176: Parent class of Architecture::MobileOperation
Issue 16177: Description on symbolic extension
Issue 16178: Representation of identity coordinate axis
Issue 16179: Multiplicity of Architecture::WeightedModel
Issue 16180: Architecture::Matrix
Issue 16182: Operations for Architecture::ErrorElement
Issue 16183: Operation for Architecture::SymbolicIdentityCRS
Issue 16184: CRS definition for pose information
Issue 16185: Definition of don't-cares
Issue 16186: Obtaining configuration of Interface::Stream instances
Issue 16187: Axis definition for polar coordinate system
Issue 16189: Multiplicity of Architecture::WeightedModel.weight
Issue 16190: Usage of Architecture::StaticRelativeCRS
Issue 16191: Description of UniformGaussian class
Issue 16192: Typo in Parameter class definition
Issue 16193: Source/destination type of ErrorTypeOperation
Issue 16194: Frequency attribute in StreamAbility
Issue 16195: Relation between DataMappingOperation and ElementSpecification
Issue 16196: InStream & OutStream
Issue 16197: C++ PSM arguments
Issue 16198: Service::connect() confusion
Issue 16199: Ambiguity in InterfaceBase parameters
Issue 16200: The usage of ParameterValue class is not clear
Issue 16201: Specifying data formats
Issue 16202: Ambiguity in CRS usage
Issue 16203: Auto configuration between RoLo Service modules
Issue 16204: Confusion in StreamAbility::dataFormat and StreamAbility::dataSpec
Issue 16205: Parent of Service class
Issue 16206: Obligation of AttributeSet::attrs & AttributeSet::def
Issue 16207: Type of InterfaceBase::get/setParameterValues() argument in C++ PSM
Issue 16208: Formal definition of XML
Issue 16209: Architecture::Ability usage

Issue 16173: Parent class of Architecture::DirectSymbol and Architecture::SymbolRef (rls-rtf)

In Figure7.3-Identity Information, classes Architecture::DirectSymbol and Architecture::SymbolRef for representing symbolic values are defined as subclasses of ISO19111::IO_IdentifiedObjectBase. However, ISO19107::DirectPosition, ISO19107::GM_PointRef, which are the counterparts for numeric values are defined as 'DataType' and are not subclass of ISO19111::IO_IdentifiedObjectBase, thus leading to inconsistent definitions.
Also, Architecture::Position class (Figure7.8-RoLo Architecture) is defined to be able to hold either a symbolic value (Architecture::SymbolicPosition) or a numeric value (ISO19107::GM_Position). However, while Architecture::SymbolicPosition inherits ISO19111::IO_IdentifiedObjectBase, ISO19107::GM_Position does not, thus showing inconsistency. 

In Figure 7.10 - RoLo Architecture, Position class is defined to hold both symbolic and numeric values. While Symbolic Position class for holding symbolic values is derived from IO_IdentifiedObjectBase [ISO19111], numeric values are held by GM_Position [ISO19111] class which is not derived from IO_IdentifiedObject. Thus there is an asymmetry in the two definitions.

In Figure 7.1 - Relative and Mobile coordinate reference system, Architecture::InStream and Architecture::MobileDatum are related as composition. However, as Architecture::InStreamcan exist by itself, the relation shall be weaker. Possibly modify Architecture::MobileDatum to use InStream (directed assotiation).

Here, MobileDatum.inStream is owned by MobileDatum, not referred, As this
InStream belongs to the datum. Therefore, using composition is suitable.
Disposition: Closed, no change

In Figure 7.2 - Mobile CRS operations, Architecture::MobileOperation is defined as a subclass of ISO19111::CC_Transformation. However, it may be better to define as a subclass of much general ISO19111::CC_SingleOperation. (Note: ISO19111::CC_CoordinateOperation is not appropriate as a parent class as if we did so, Architecture::MobileOperation  cannot be elements of ISO19111::CC_ConcatenatedOperation instances). 

First, ISO19111::CC_ConcatenatedOperation is defined to hold a sequence of
ISO19111::CC_CoordinateOperation, thus the candidate to change
Architecture::MobileOperation’s parent class can be
ISO19111::CC_CoordinateOperation, not just CC_SingleOperation.
However, ISO19111::CC_Transformation which is the parent class of
Architecture::MobileOperation in RLS 1.0 is defined as ‘A coordinate operation
through which the input and output coordinates are referenced to different
datums.’ [ISO19111] As Architecture::MobileOperation maps between mobile
CRS and static CRS or between mobile CRS and different mobile CRS, the
current inheritance relationship is appropriate.
Disposition: Closed, no change

The following description on symbolic extension may be insufficient (in P.19, third paragraph):
"The actual coordinate value holding structure in GIS standard [ISO19107] only allows numeric values as coordinate value elements. Thus, similar structures in use with symbolic values are also defined."

The description seems to be sufficient.
Disposition: Closed, no change

When identities are to be limited to finite set of values, such as a set of predefined symbols or discrete numerical values, how can this be represented? 

In Figure 7.6 - RoLo Error, multiplicity of Architecture::WeightedModel for Architecture::LinearMixtureModel is defined as "1..*". However, as there may be cases that no model exists, it is better to define it as "0..*". 

In Figure 7.8 - RoLo Error, Architecture::Matrix is defined as a subclass of IO_IdentifiedObjectBase. However, as it is quite unlikely that instances of this class requires to be identified, it is better to define it as a DataType.

In Figure 7.10- RoLo Data Operation, no operation is defined for Architecture ::ErrorElement , except Architecture ::DataMappingOperation. Some operation for transforming error information, as Architecture ::PositionElementOperation for Architecture ::PositionElement, is necessary. 

ErrorElement relies on PositionElements, thus an operation only over
ErrorElements cannot be defined. Operation over ErrorElements are handled by
DataOperation as a whole.
Disposition: Closed, no change

CRS for symbolic systems are defined in Figure 7.3 - Identity Information as extension to ISO19111. Operations specific to these CS/CRS are missing.

In the definition of ISO19111::CC_CoordinateOperation, source
(+coordOperationFrom) and target (+coordOperationTo) domains for conversion
are defined to be ISO19111::SC_CRS, which does not limit its axis to be defined
over numerical values. Thus, ISO19111::CC_CoordinateOperation can be used
for Architecture::SymbolicIdentityCRS and its derivatives. Note that, although
ISO19107::DirectPosition defines its attribute +coordinate as
Sequence<Number> and refers to ISO19111::SC_CRS, ISO19111::SC_CRS or
ISO19111::CC_CoordinateOperation does not depend on
ISO19107::DirectPosition
Disposition: Closed, no change

Explicit CRS definition for pose information is necessary. Especially, the relation between pose CRS and position CRS and its semantics shall be defined

Classes and objects for using don't' cares are defined in Figure 7.9 - Don't-care classes and objects. However, it may be better to define the subclasses of Architecture::DontCare as DataType, as instances of these classes will be treated as constants

The intention is to use only the don’t-care objects, the constants, and not the
classes. The classes are for clearly indicating the nature of don’t-care objects.
Thus, no changes are necessary.
Disposition: Closed, no change

The Interface::StreamAbility instance obtainable from Interface::Stream denotes the ability of each Interface::Stream instance. However, there is no method for obtaining how each instance is configured. Such a method is necessary.

Interface::InterfaceBase.getParameterValues() can be used to show configurable
parameters. Thus, no changes are necessary.
Disposition: Closed, no change

ISO19111::CS_PolarCS is to be used for representing polar coordinate systems. However, no specific axis is defined for this coordinate system. 

ISO19111::CS_CoordinateSystemAxis can be used for ISO19111::CS_PolarCS.
However, the definition of CS_CoordinateSystemAxis is too limited to GIS usage
and not appropriate for robotics usage. The definition shall be modified in future,
not in RLS, but in the ISO19111.
Disposition: Closed, no change

In Figure 7.6 - RoLo Error, multiplicity of Architecture: WeightedModel.weight is fixed to "1". However, in some cases, such as representing result of simple Monte-Carlo sampling, weights may be unnecessary (equal to 1/N), so the multiplicity shall better be specified as optional ("0..1"). 

The use of 'base' and 'dataSpec' attribute in Architecture::StaticRelativeCRS is not clear.

This is actually on attributes in StaticRelativeDatum, not in StaticRelativeCRS. As
in issue 16184, when we see CRSs as realization of transformations and datums
as set of transformation parameters, the description in the StaticRelativeDatum
class table becomes much clearer. Thus, the description here shall be sufficient.

Disposition: Closed, no change

The note in Table 7.35 - UniformGaussian class says "Dimensions of the cov attribute derived from class Gaussian shall all be equal to 1. That is, nRow = nCol = 1." However, as a covariance matrix is diagonal from its definition, the number of rows/columns shall be more than one (starting from two). 

Being a covariance matrix does not limit the number of rows/columns to be larger
than one. Moreover, this definition of UniformGaussian is necessary to make its
definition consistent with much general Gaussian class.
Disposition: Closed, no change

In table 7.80 - Parameter class, the type of 'isConfigurable' attribute is denoted as 'Bool' but this shall be 'Boolean'.

In Figure 7.5 - RoLo Error Type and in Table 7.28 - ErrorTypeOperation class, only 'source' (ErrorType) and 'target' (ErrorType) attributes are defined. However, these attributes are parameters for determining the type of conversion operation, and the actual Element-s to be converted shall as well be specified.

This is OK, as these are classes for representing RoLo error conversion
algorithms and not the actual operations.
Disposition: Closed, no change

In Figure 7.19 - RoLo Service and in Table 7.91 - StreamAbility class, the 'frequency' attribute of StreamAbility is marked as optional. However, it is not clear in what way the module behaves when the frequency attribute is omitted. Also, as for the dataSpec attribute, don't-care shall be defined for dataFormat and frequency attributes to indicate that no specific value is defined.

The frequency attribute is not specified when the actual input/output frequency of
the Stream is not certain. This is different from specifying a don’t-care which
means any frequencies can be specified. This is not the case with realistic
implementations.
Disposition: Closed, no change

In Figure 7.10 - RoLo Data Operation, the relation between DataMappingOperation class and ElementSpecification class is defined as aggregation. However, considering the strength of relation between the two classes, directed association is much suitable.

InStream & OutStream are just conceptually different in usage but physically the same. The separation makes the implementation difficult. Instream may be redundant, and OutStream also requires setData().

Some RLS modules, such as ones embedding sensors, may only own
OutputStreams while some modules such as aggregation modules may own both
InputStreams and OutputStreams. Thus, Interface::Instream and
Interface::OutStream are necessary to clearly indicate whether a certain stream
is for data input or for data output. In this sense, setData() is not necessary for
OutputStream class.
Disposition: Closed, no change

In C++ implementation, the element types should be a pointer or reference to enable homomorphism. It means that we need dynamic memory allocation/deallocation for data passing, making the implementation very difficult, such as for identifying real instance type or for copying data. C++ PSM part of RLS Spec. should be corrected into pointer type not to make the developers confusing.

Actually, parameters will not be problems as they can be casted to parent
classes. The same can be applied for returned values.
Disposition: Closed, no change

As for Service::connect() method, difference of two connect() methods are not clearly described, and developers can be very confused. The notations IN service and OUT service is confusing. Given a relation A->B, which one is IN service? Receiver(IN) / Sender(OUT) would be more clear conceptually. 

We can access parameter values in two ways: InterfaceBase::getAbility and InterfaceBase::getParameterValues. InterfaceBase::ability can be StreamAbility or ServiceAbility and they have inherited attribute (attrs) from AttributeSet. They also have their own class-specific parameters (frequency, expectedLatency, ... ). However, there only is InterfaceBase::getAbility. We need InterfaceBase::setAbility to initialize Service or Stream. It is not clear what the configurable parameters of InterfaceBase::get/setParameterValues are. Implementation of InterfaceBase::get/setParameterValues is very complex and confusing. Class-specific parameters also are attribute, but handled separately from 'attrs' of AttributeSet. 

Ability class describes what kind of parameters the module provides. These
parameters can be specified through InterfaceBase::getParameterValues().
Disposition: Closed, no change

First, it is hard to access the target Parameter from ParameterValueBase. Second, it is not clear whether we should provide a pointer to a real Parameter instance for ParameterValue::param attribute or use a clone. If clone, we should deallocate the memory (who do?) If not clone, we should not deallocate the memory. There is a possibility that the values of ParameterValue::val and ParameterValue::param.val are inconsistent. How about ParamterValue class to refer to the ID of Parameter instance not the instance itself?  

We defined common data format but not specified how to identify them. 

This is mostly a PSM or implementation issue. For example, if all the data
instances/classes related to RoLo can be realized as objects, object references
can be used for identifying common data formats or CRSs. However, in many
cases, it is better to have some rules for mapping identifiers, especially in the
case of using XML PSM. Thus, we may define an example identifier mapping
mechanism based on “Definition identifier URNs in OGC namespace” (Open
Geospatial Consortium document no. 07-092r3) which is commonly used in GIS
related systems as an informative annex.
However, this addition is beyond the scope of RTF. Thus, this may be discussed
in the future through another RFP process.
Disposition: Closed, Out of Scope

CRS is very important in RLS, but the usage is not clearly described in the Spec. Just referred ISO. Especially, AxisDirection is confusing. Inconsistent implementation may be possible among developers 

For the notion of CRS, please refer to the ISO 19111 specification and to issue
16184. As for CS_AxisDirection, it is described on page 12-13 of RLS 1.0, as
follows:
… One issue is how to treat the attribute bounded to specific features in the real space
such as axisDirection (type CS_AxisDirection) in CS_CoordinateSystemAxis that is a
mandatory attribute, and where the type is defined as a finite enumeration of direction
names such as ‘north’ or ‘south.’ It is clear that these values are not suitable for some
robotics usage such as for relative or mobile coordinate reference systems. We thus
recommend that implementers and users of this specification simply ignore this
attribute and set this value as the first element in the enumeration, ‘north,’ if necessary.
This is a safe solution as we cannot expect GIS systems to treat data based on this
specification correctly; we only expect data from GIS systems to be treated on
systems based on this robotic specification.??
Disposition: Closed, no change

Auto configuration between RoLo Service modules across the network is not supported currently. Return value of getAbility: variable data length, data type, ...How to interpret the result without sharing of memory address? We need to define how to serialize data. 

Auto configuration (or negotiation) between RoLo modules over network, as well
as serialization of data is not in the scope of this specification. It shall be handled
by the underlying (or overlaying) middleware systems, such as SOAP, Java JNI
or the Network Robot platform.
Disposition: Closed, no change

StreamAbility::dataFormat has its own DataSpecification. Difference of these two DataSpecifications is not clear. is it just a redundant duplication? 

In C++ PSM, Service class should be derived from InterfaceBase class, not from OutStream. 

Obligation of AttributeSet::attrs & AttributeSet::def seems not correct (attrs: M, def: O ?) 

Argument type of InterfaceBase::get/setParameterValues is 'set' in PIM but 'list' in PSM. It may cause the developers confusing.

Although examples of XML description is provided in Annex A, an formal
specification such as XML schema is also necessary for constructing a
parser.

Description on Architecture::Abilty and inherited classes are
confusing and difficult to use.