${taskforce.name} Avatar
  1. OMG Task Force

Robotic Localization Service (RLS) RTF — All Issues

  • Key: RLS11
  • Issues Count: 39
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
RLS11-1 Mismatch in Error Type (Figure 6) and Error Information (Figure 7) definitions RLS 1.0b1 open
RLS11-39 Obligation of AttributeSet::attrs & AttributeSet::def RLS 1.0 RLS 1.1 Resolved closed
RLS11-38 Architecture::Ability usage RLS 1.0 RLS 1.1 Resolved closed
RLS11-37 Formal definition of XML RLS 1.0 RLS 1.1 Resolved closed
RLS11-36 Type of InterfaceBase::get/setParameterValues() argument in C++ PSM RLS 1.0 RLS 1.1 Resolved closed
RLS11-35 Parent of Service class RLS 1.0 RLS 1.1 Resolved closed
RLS11-34 Confusion in StreamAbility::dataFormat and StreamAbility::dataSpec RLS 1.0 RLS 1.1 Resolved closed
RLS11-33 Auto configuration between RoLo Service modules RLS 1.0 RLS 1.1 Resolved closed
RLS11-32 Ambiguity in CRS usage RLS 1.0 RLS 1.1 Resolved closed
RLS11-31 Specifying data formats RLS 1.0 RLS 1.1 Resolved closed
RLS11-30 The usage of ParameterValue class is not clear RLS 1.0 RLS 1.1 Resolved closed
RLS11-29 Ambiguity in InterfaceBase parameters RLS 1.0 RLS 1.1 Resolved closed
RLS11-28 Service::connect() confusion RLS 1.0 RLS 1.1 Resolved closed
RLS11-27 C++ PSM arguments RLS 1.0 RLS 1.1 Resolved closed
RLS11-26 InStream & OutStream RLS 1.0 RLS 1.1 Resolved closed
RLS11-25 Relation between DataMappingOperation and ElementSpecification RLS 1.0 RLS 1.1 Resolved closed
RLS11-24 Frequency attribute in StreamAbility RLS 1.0 RLS 1.1 Resolved closed
RLS11-23 Source/destination type of ErrorTypeOperation RLS 1.0 RLS 1.1 Resolved closed
RLS11-22 Typo in Parameter class definition RLS 1.0 RLS 1.1 Resolved closed
RLS11-21 Description of UniformGaussian class RLS 1.0 RLS 1.1 Resolved closed
RLS11-20 Usage of Architecture::StaticRelativeCRS RLS 1.0 RLS 1.1 Resolved closed
RLS11-19 Multiplicity of Architecture::WeightedModel.weight RLS 1.0 RLS 1.1 Resolved closed
RLS11-18 Axis definition for polar coordinate system RLS 1.0 RLS 1.1 Resolved closed
RLS11-17 Obtaining configuration of Interface::Stream instances RLS 1.0 RLS 1.1 Resolved closed
RLS11-16 Definition of don't-cares RLS 1.0 RLS 1.1 Resolved closed
RLS11-15 CRS definition for pose information RLS 1.0 RLS 1.1 Resolved closed
RLS11-14 Operation for Architecture::SymbolicIdentityCRS RLS 1.0 RLS 1.1 Resolved closed
RLS11-13 Operations for Architecture::ErrorElement RLS 1.0 RLS 1.1 Resolved closed
RLS11-12 Architecture::Matrix RLS 1.0 RLS 1.1 Resolved closed
RLS11-11 Multiplicity of Architecture::WeightedModel RLS 1.0 RLS 1.1 Resolved closed
RLS11-10 Representation of identity coordinate axis RLS 1.0 RLS 1.1 Resolved closed
RLS11-9 Description on symbolic extension RLS 1.0 RLS 1.1 Resolved closed
RLS11-8 Parent class of Architecture::MobileOperation RLS 1.0 RLS 1.1 Resolved closed
RLS11-7 Relation between Architecture::MobileDatum and Architecture::InStream RLS 1.0 RLS 1.1 Resolved closed
RLS11-6 Inconsistency in structure of Symbolic and Numeric Value for Position class RLS 1.0 RLS 1.1 Resolved closed
RLS11-5 Parent class of Architecture::DirectSymbol and Architecture::SymbolRef RLS 1.0 RLS 1.1 Resolved closed
RLS11-4 XML target namespace incorrect RLS 1.1 open
RLS11-3 Specifying a set of CRS instances RLS 1.0 open
RLS11-2 Data Format definitions RLS 1.0 open

Issues Descriptions

Mismatch in Error Type (Figure 6) and Error Information (Figure 7) definitions

  • Key: RLS11-1
  • Legacy Issue Number: 13130
  • Status: open  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    There are mismatches in the hierarchical structure of Error Type
    classes and Error Information classes, which shall correspond to each
    other. One solution will be to:

    • add ET_ErrorDistribution, derived from 'RoLo Error Type'
    • make ET_Gaussian, ET_UniformGaussian, ET_ParticleSet and
      ET_MixtureModel to be derived from ET_ErrorDistribution
  • Reported: RLS 1.0b1 — Mon, 1 Dec 2008 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Obligation of AttributeSet::attrs & AttributeSet::def

  • Key: RLS11-39
  • Legacy Issue Number: 16206
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    As pointed out, Interface::AttributeSet.attrs shall be marked as optional in the UML
    diagram. Moreover, AttributeSet.def is not necessary, as AttributeDefinition-s can be
    accessed through each AttributeBase contained in the AtributeSet instance. Thus, we will
    remove the AttributeDefinitionSet class and AttributeSet.def.

  • Updated: Sat, 7 Mar 2015 21:33 GMT

Architecture::Ability usage

  • Key: RLS11-38
  • Legacy Issue Number: 16209
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

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

  • Reported: RLS 1.0 — Mon, 9 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    See issue 16206 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Formal definition of XML

  • Key: RLS11-37
  • Legacy Issue Number: 16208
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

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

  • Reported: RLS 1.0 — Mon, 9 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    Besides XML examples, Annex A provides XML schema definitions. However, the
    definition is not complete. Thus, revise the XML schema definition in Annex A.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type of InterfaceBase::get/setParameterValues() argument in C++ PSM

  • Key: RLS11-36
  • Legacy Issue Number: 16207
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    In C++ PSM, we found several points of similar inconsistency:

    • std::vector is used to denote ordered list in some definitions and std::list is used
      for other definitions
    • ordered and non-ordered list sometimes does not match the definition in PIM
      In order to clearly represent the PIM, the following rule will be applied for PIM =
      C++ PSM mapping:
    • non-ordered list will be mapped to std::set
    • ordered list will be mapped to std::vector
      Based on these rules, the followings points will be modified in C++ PSM:
    • Modify InterfaceBase::getParameterValues() and setParameterValues()
      methods to use std::set
    • Modify SetParameter class to bind to::std::set<T> for template parameter
    • Modify SetParameter.attrs attribute to use std::vector
    • Modify ServiceAbility.inStreamAbilities attribute to use std::set
    • Modify Service.getChild () method to use std::vector
    • Modify Service.inStreams and outStreams attributes to use std::vector
      In addition, we found that there are some inconsistency between the table
      description and UML, and these will be fixed as following:
    • In Service class, based on the text description, the attributes inStreams and
      outStreams will be marked as “N ord” in the table and will be marked as
      “ordered” in the UML diagram
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parent of Service class

  • Key: RLS11-35
  • Legacy Issue Number: 16205
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    Modify Service class definition in Service.hpp to be inherited from InterfaceBase
    class.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Confusion in StreamAbility::dataFormat and StreamAbility::dataSpec

  • Key: RLS11-34
  • Legacy Issue Number: 16204
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    The two attributes, dataFormat (which is a set of DataFormat::DataFormat
    instances) and dataSpec (which is a set of Architecture::DataSpecification) are
    necessary, as these indicate the possible choices that a certain stream can
    handle. Users of this stream will choose the appropriate data format or data
    specification from the set of available choices. As pointed out, this is not clear in
    the current description, so we will add some more description

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Auto configuration between RoLo Service modules

  • Key: RLS11-33
  • Legacy Issue Number: 16203
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity in CRS usage

  • Key: RLS11-32
  • Legacy Issue Number: 16202
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specifying data formats

  • Key: RLS11-31
  • Legacy Issue Number: 16201
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The usage of ParameterValue class is not clear

  • Key: RLS11-30
  • Legacy Issue Number: 16200
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    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?

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    Whether to use a pointer or cloned instance is an implementation issue and will
    not be discussed here. As suggested, one way of implementation is to refer to
    some ID of Parameter instance, such as the one inherited from
    ISO19111::IO_IdentifiedObject. See issue 16201 for discussion on the
    referencing system.
    As for the two ‘val’ attributes, the actual values for each Attribute (or Parameter)
    instance is held by Attribute.val. ParameterValueBase and inherited class
    instances are used for passing the values to be set, typically through
    InterfaceBase::setParameterValues() or to obtain the current values through
    InterfaceBase::getParameterValues(). As this was not clearly stated in the
    specification, we will add some more description.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity in InterfaceBase parameters

  • Key: RLS11-29
  • Legacy Issue Number: 16199
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service::connect() confusion

  • Key: RLS11-28
  • Legacy Issue Number: 16198
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    As described, the difference of the two connect() methods are in which side
    initiates the connection. The notation ‘receiver’ and ‘sender’ is, as suggested,
    much clear. Thus, change ‘IN service’ as ‘RECEIVER service’ and ‘OUT service’
    as ‘SENDER service’.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ PSM arguments

  • Key: RLS11-27
  • Legacy Issue Number: 16197
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InStream & OutStream

  • Key: RLS11-26
  • Legacy Issue Number: 16196
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    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().

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relation between DataMappingOperation and ElementSpecification

  • Key: RLS11-25
  • Legacy Issue Number: 16195
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    Change the relation between ElementSpecification and DataMappingOperation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Frequency attribute in StreamAbility

  • Key: RLS11-24
  • Legacy Issue Number: 16194
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Source/destination type of ErrorTypeOperation

  • Key: RLS11-23
  • Legacy Issue Number: 16193
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in Parameter class definition

  • Key: RLS11-22
  • Legacy Issue Number: 16192
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    Modify the type of isConfigurable attribute in Parameter class definition as
    “Boolean”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Description of UniformGaussian class

  • Key: RLS11-21
  • Legacy Issue Number: 16191
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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).

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Usage of Architecture::StaticRelativeCRS

  • Key: RLS11-20
  • Legacy Issue Number: 16190
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity of Architecture::WeightedModel.weight

  • Key: RLS11-19
  • Legacy Issue Number: 16189
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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").

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    See issue 16179 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Axis definition for polar coordinate system

  • Key: RLS11-18
  • Legacy Issue Number: 16187
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obtaining configuration of Interface::Stream instances

  • Key: RLS11-17
  • Legacy Issue Number: 16186
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of don't-cares

  • Key: RLS11-16
  • Legacy Issue Number: 16185
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CRS definition for pose information

  • Key: RLS11-15
  • Legacy Issue Number: 16184
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    In ISO 19111 which RLS is based on, relation between CRSs is defined by using
    datums and transformations. In this sense, in order to represent pose information,
    we need to define a new datum. However, we found that generally this is not
    appropriate as identifying pose is tightly related to its associated position. In the
    original idea of CSs and CRSs in ISO 19111, CSs implicitly hold transformations
    that can in most cases be identified trivially. However, when extending this to
    pose, the necessary transformation becomes not so trivial and thus a much
    explicit mean for specifying the associated transformation, in combination with
    ‘position’ transformation, becomes necessary. Moreover, it is only a special case
    that position and pose information (or transformations) are mathematically
    independent, i.e., where transformations for position and pose can be defined
    separately. Therefore, position and pose information shall be represented in
    combination inseparable from each other. One way is to represent position/pose
    as a generalized position which is a set of parameters for a transformation that
    defines a mapping from the base CRS to the resulting position/pose. In this
    sense, what is called a CS or CRS shall be represented as a transformation ,and
    coordinate values which we normally call ‘position’ are parameters for the
    transformation. (for detailed discussion, see [Noda2010])
    [Noda2010] Itsuki Noda, Shuichi Nishio, Takashi Tsubouchi, Takeshi
    Sakamoto and Satoshi Tadokoro, "Mathematical Framework for Localization
    Information Coordinate Reference System for Robotics", in Proc. of Int.
    Workshop on Standards and Common Platform for Robotics 2010 (SCPR
    2010), 2010.
    This notion is mathematically much rigid. However, it requires complete
    reconstruction of the ISO 19111 which RLS is based on. As this is not something
    to be discussed here, here we propose a much modest modifications. In the
    future, this shall be discussed in ISO/TC 211.
    Followings are the modified points: - Add non-normative reference

    • Add background description (section 7.3 – Architecture Package)
    • Add two classes (PoseType and PositionPoseCRS) in Architecture Package
    • Define frequently used pose types
    • Modify section 7.4.1 – Common Data Format to use the defined pose types and
      remove figures/descriptions that also appear in previous description
    • Modify C++ PSM accordingly
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation for Architecture::SymbolicIdentityCRS

  • Key: RLS11-14
  • Legacy Issue Number: 16183
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

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

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations for Architecture::ErrorElement

  • Key: RLS11-13
  • Legacy Issue Number: 16182
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Architecture::Matrix

  • Key: RLS11-12
  • Legacy Issue Number: 16180
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    Change Architecture::Matrix to a DataType and remove inheritance from
    IO_IdentifiedObjectBase [ISO19111].

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity of Architecture::WeightedModel

  • Key: RLS11-11
  • Legacy Issue Number: 16179
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    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..".

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    Concerning also issue 16189 where the multiplicity of weight attribute in
    Architecture::WeightedModel is raised, we perform the following modifications:
    1) Define a new Architecture::Model class which is derived from
    Architecture::PositionElement. Although no attributes or methods added here,
    this class is for representing probability distributions or models, with a position
    in the space and error distribution.
    2) Modify Architecture::WeightedModel class to be derived from
    Architecture::Model class and remove the posElem attribute (this is not
    necessary any more due to its parent class-). Thus, only models with weights
    are represented by the WeightedModel class and thus the ‘weight’ attribute is
    left as mandatory.
    3) Modify Architecture::LinearMixtureModel class to aggregate
    Architecture::Model instances instead of Architecture::WeightedModel, so that
    when the weight in the models shall not be specified. the Model class
    instance shall be used. At the same time, modify the multiplicity of the
    ‘models’ attribute as “0..*.” Also, add some description in the definition of
    LinearMixtureModel class to indicate how the aggregation of non-weighted
    models shall be interpreted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Representation of identity coordinate axis

  • Key: RLS11-10
  • Legacy Issue Number: 16178
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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?

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    Define a new class Architecture::SetCoordinateSystemAxis for representing axis
    with finite set of values. In addition, for convenience, add two frequently used
    axes StringSetCoordinateSystemAxis and IntegerSetCoordinateAxis.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Description on symbolic extension

  • Key: RLS11-9
  • Legacy Issue Number: 16177
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    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."

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parent class of Architecture::MobileOperation

  • Key: RLS11-8
  • Legacy Issue Number: 16176
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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).

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relation between Architecture::MobileDatum and Architecture::InStream

  • Key: RLS11-7
  • Legacy Issue Number: 16175
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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).

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in structure of Symbolic and Numeric Value for Position class

  • Key: RLS11-6
  • Legacy Issue Number: 16174
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    See issue 16173 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parent class of Architecture::DirectSymbol and Architecture::SymbolRef

  • Key: RLS11-5
  • Legacy Issue Number: 16173
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Takeshi Sakamoto)
  • Summary:

    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.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — RLS 1.1
  • Disposition Summary:

    As Architecture::Position class is inherited from ISO19111::IO_IdentifiedObject,
    there shall be small requirements for these classes to hold identity information by
    itself. Modify Architecture::DirectSymbol, Architecture::SymbolRef and
    Architecture::SymbolicPosition definitions as not to be subclass of
    IO_IdentifiedObjectBase.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML target namespace incorrect

  • Key: RLS11-4
  • Legacy Issue Number: 17368
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    A.1 paragraph 3 says "Hereafter, the target namespace of the given XML schemas is assumed to be “http://www.omg.org/rls/1.1.” Also, the prefix “rls” indicates the same namespace."

    However, in fact this URL should be "http://www.omg.org/spec/RLS/1.1".

    This needs to be corrected in the text of the specification (3 places, all on page 79), and in the Schema file dtc/2011-05-13, linked from http://www.omg.org/spec/RLS/1.1/. A corrected version of this file is available as dtc/12-05-01.

  • Reported: RLS 1.1 — Tue, 15 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specifying a set of CRS instances

  • Key: RLS11-3
  • Legacy Issue Number: 16188
  • Status: open  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Occasionally, there are situation where a set of CRSs needs to be defined as acceptable for a specific Interface::Stream, such as accepting a set of IDs based on several CRSs for a single stream. This cannot be realized in the current specification

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Data Format definitions

  • Key: RLS11-2
  • Legacy Issue Number: 16181
  • Status: open  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Data formats that each Interface::Stream can handle are defined in Interface::StreamAbility. dataFormat. However, in certain cases, data formats may be automatically handled by middlewares. We shall reconsider to what extent data formats are treated as part of the RLS specification. Also, definition of each data format is currently not described. As other parts, such as coordinate reference system definitions, specification for describing data format definitions shall be defined.

  • Reported: RLS 1.0 — Sun, 8 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT