Robotic Localization Service Avatar
  1. OMG Specification

Robotic Localization Service — All Issues

  • Acronym: RLS
  • Issues Count: 130
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
RLS11-39 Obligation of AttributeSet::attrs & AttributeSet::def RLS 1.0 RLS 1.1 Resolved closed
RLS-94 Separate XMI definition from RLS specification document. RLS 1.0b1 RLS 1.0 Resolved closed
RLS-96 (Tbl135/Tbl136) The 'connect' methods RLS 1.0b1 RLS 1.0 Resolved closed
RLS-95 7.3.2 Identity Information RLS 1.0b1 RLS 1.0 Resolved closed
RLS-93 Figure 6 - Error Type RLS 1.0b1 RLS 1.0 Resolved closed
RLS11-30 The usage of ParameterValue class is not clear 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-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-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-24 Frequency attribute in StreamAbility RLS 1.0 RLS 1.1 Resolved closed
RLS11-27 C++ PSM arguments RLS 1.0 RLS 1.1 Resolved closed
RLS11-23 Source/destination type of ErrorTypeOperation RLS 1.0 RLS 1.1 Resolved closed
RLS11-31 Specifying data formats RLS 1.0 RLS 1.1 Resolved closed
RLS-25 Relative/Mobile operations are not well defined RLS 1.0b1 RLS 1.0 Resolved closed
RLS-24 Relative/Mobile CRS name is confusing RLS 1.0b1 RLS 1.0 Resolved closed
RLS-23 Typos RLS 1.0b1 RLS 1.0 Resolved closed
RLS-22 Sample C++ Header RLS 1.0b1 RLS 1.0 Resolved closed
RLS-17 Figure 21 - RoLo Ability and RoLo Parameter Set RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-16 7.4.1 Common data format TypeII.Polar coordinate system RLS 1.0b1 RLS 1.0 Resolved closed
RLS-29 Possible inconsistency between RoLo Attribute Set attributes RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-28 RoLo Attribute Set definition typo RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-18 Figure 22 - RoLo Service RLS 1.0b1 RLS 1.0 Resolved closed
RLS-26 SymbolicCS/CRS name is confusing RLS 1.0b1 RLS 1.0 Resolved closed
RLS-27 Possible inconsistency between RoLo Data class attributes RLS 1.0b1 RLS 1.0 Resolved closed
RLS-21 Table 134 - RoLo Stream class RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-20 Table 133 - Stream Ability class RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-19 Table 132 - Stream Parameter Set class RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-75 RLS - typos RLS 1.0b1 RLS 1.0 Resolved closed
RLS-71 Inconsistency between PIM and PSM namings RLS 1.0b1 RLS 1.0 Resolved closed
RLS-70 Typo in Service Ability class description RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-77 (Annex A) Mapping between PIM and C++ PSM is not clear RLS 1.0b1 RLS 1.0 Resolved closed
RLS-76 (7.4.1) Timestamp for common data types RLS 1.0b1 RLS 1.0 Resolved closed
RLS-80 Fig3,Tbl9,Fig22,Tbl134,Tbl140) Mobile Datum class, RoLo Stream class and RoLo Service RLS 1.0b1 RLS 1.0 Resolved closed
RLS-79 7.5) Filter condition requires naming of RoLo data elements. However, the naming rules are not clear. RLS 1.0b1 RLS 1.0 Resolved closed
RLS-81 Fig5,Fig9) RoLo Symbolic Position class and RoLo Position class RLS 1.0b1 RLS 1.0 Resolved closed
RLS-74 Missing references RLS 1.0b1 RLS 1.0 Resolved closed
RLS-73 Typo: argument type for methods in RoLo Service class RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-78 (7.5) In the filter condition section RLS 1.0b1 RLS 1.0 Resolved closed
RLS-82 (Fig7) Matrix class is specified as "DataType" but this is unnecessary RLS 1.0b1 RLS 1.0 Resolved closed
RLS-72 Inconsistency in class names RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-47 Hierarchy of Error can be reduced RLS 1.0b1 RLS 1.0 Resolved closed
RLS-46 Filter Condition should be reduced and move to annex as informative RLS 1.0b1 RLS 1.0 Resolved closed
RLS-56 Conformance shall be specified in detail RLS 1.0b1 RLS 1.0 Resolved closed
RLS-55 Inability of representing range values (Figure21/Table120) RLS 1.0b1 RLS 1.0 Resolved closed
RLS-50 Simplication of Error Type (Figure 6): RLS 1.0b1 RLS 1.0 Resolved closed
RLS-49 Hierarchical relationship for instances of CRS and RoLo Data Spec RLS 1.0b1 RLS 1.0 Resolved closed
RLS-53 The type of 'usesOperation' attribute of RoLo Data Transformation (Table62) RLS 1.0b1 RLS 1.0 Resolved closed
RLS-52 Obligation of 'values' attribute of Matrix (Figure7/Table36) RLS 1.0b1 RLS 1.0 Resolved closed
RLS-45 Figure 8 may accompany an object diagram RLS 1.0b1 RLS 1.0 Resolved closed
RLS-44 Definition mismatch for Service Ability class in Figure 22 and Table 139 RLS 1.0b1 RLS 1.0 Resolved closed
RLS-43 Typo in Position Element Concatenated Operation class definition RLS 1.0b1 RLS 1.0 Resolved closed
RLS-54 Association between RoLo Parameter Set and RoLo Parameter Definition (Figure 21) RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-48 XML mapping of RoLo Data and RoLo Element RLS 1.0b1 RLS 1.0 Resolved closed
RLS-51 Typo in Table 22 (RoLo SymbolRef) RLS 1.0b1 RLS 1.0 Resolved closed
RLS-65 Ambiguity in 'rla' attribute description in RelativeDatum class RLS 1.0b1 RLS 1.0 Resolved closed
RLS-64 Some description on Coordinate System usage shall be added RLS 1.0b1 RLS 1.0 Resolved closed
RLS-62 Typos in 6.3 Background RLS 1.0b1 RLS 1.0 Resolved closed
RLS-61 Names missing in "6.2 Acknowledgements" RLS 1.0b1 RLS 1.0 Resolved closed
RLS-57 Some references are missing RLS 1.0b1 RLS 1.0 Resolved closed
RLS-69 Structural change for RoLo Service class RLS 1.0b1 RLS 1.0 Resolved closed
RLS-60 Some organization missing in "6.1 Supporting Organizations" RLS 1.0b1 RLS 1.0 Resolved closed
RLS-68 Typo in RoLo Attribute Definition class description RLS 1.0b1 RLS 1.0 Resolved closed
RLS-67 'numDists' attribute in Lineare Mixure Model class may be unnecessary RLS 1.0b1 RLS 1.0 Resolved closed
RLS-59 Symbol should be described RLS 1.0b1 RLS 1.0 Resolved closed
RLS-58 Terms and Definition shall be added RLS 1.0b1 RLS 1.0 Resolved closed
RLS-66 'inStream' attribute in MobileDatum class shall be an object RLS 1.0b1 RLS 1.0 Resolved closed
RLS-63 Overview in 6.3 Background needs to be modified RLS 1.0b1 RLS 1.0 Resolved closed
RLS-3 Sequence diagrams should be added RLS 1.0b1 RLS 1.0 Resolved closed
RLS-2 create sub packages RLS 1.0b1 RLS 1.0 Resolved closed
RLS-11 Figure 7 - Error information RLS 1.0b1 RLS 1.0 Resolved closed
RLS-10 Figure 5 - Identity information RLS 1.0b1 RLS 1.0 Resolved closed
RLS-12 Figure 9 - RoLo Architecture RLS 1.0b1 RLS 1.0 Resolved closed
RLS-14 Figure 11 - RoLo Data format RLS 1.0b1 RLS 1.0 Resolved closed
RLS-13 Figure 10 - RoLo Data Operation RLS 1.0b1 RLS 1.0 Resolved closed
RLS-9 Figure 4 - Mobile CRS operations RLS 1.0b1 RLS 1.0 Resolved closed
RLS-8 Table 5 RelativeDatum class RLS 1.0b1 RLS 1.0 Resolved closed
RLS-6 The association end name should be added as follows RLS 1.0b1 RLS 1.0 Resolved closed
RLS-5 The navigability notation(arrow head) should be added as follows RLS 1.0b1 RLS 1.0 Resolved closed
RLS-7 add an explanatory note RLS 1.0b1 RLS 1.0 Resolved closed
RLS-4 Figure 3 - Relative and Mobile c oordinate reference system RLS 1.0b1 RLS 1.0 Resolved closed
RLS-15 7.4.1 Common data format TypeI.Cartesian coordinate system RLS 1.0b1 RLS 1.0 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-19 Multiplicity of Architecture::WeightedModel.weight RLS 1.0 RLS 1.1 Resolved closed
RLS11-20 Usage of Architecture::StaticRelativeCRS RLS 1.0 RLS 1.1 Resolved closed
RLS-90 (C++-PSM) Methods shall better send return codes as exceptions RLS 1.0b1 RLS 1.0 Resolved closed
RLS-89 Tbl130,Tbl136) The 'setData' method in InStream class RLS 1.0b1 RLS 1.0 Resolved closed
RLS-91 Subset specifications (Fig22) RLS 1.0b1 RLS 1.0 Resolved closed
RLS-87 Tbl134) The behavior of setParameter method in RoLo Stream class is unclear RLS 1.0b1 RLS 1.0 Resolved closed
RLS-86 (Tbl135/Tbl136) RLS 1.0b1 RLS 1.0 Resolved closed
RLS-92 Parent class wrong for RelativeCRS RLS 1.0b1 RLS 1.0 Resolved closed
RLS-84 Tbl124) Specifying RoLo Attribute Singlevalue class as an enumeration RLS 1.0b1 RLS 1.0 Resolved closed
RLS-83 Tbl119-Tbl129) RLS 1.0b1 RLS 1.0 Resolved closed
RLS-88 Tbl130) Two types of data passing mode specified in StreamType enumeration is not clear RLS 1.0b1 RLS 1.0 Resolved closed
RLS-85 7.6) RoLo service is described to have only one output stream, but this is sometimes too difficult to use RLS 1.0b1 RLS 1.0 Resolved closed
RLS-41 posSpecRef in Error Element (Figure 9/Table 49) RLS 1.0b1 RLS 1.0 Resolved closed
RLS-40 Filter package for the Issue #12916 RLS 1.0b1 RLS 1.0 Closed; No Change closed
RLS-35 Angle unit representation RLS 1.0b1 RLS 1.0 Resolved closed
RLS-34 Change the class name of RoLo Architecture RLS 1.0b1 RLS 1.0 Resolved closed
RLS-38 Name of Orientation RLS 1.0b1 RLS 1.0 Resolved closed
RLS-37 Name of Type II coordinate system RLS 1.0b1 RLS 1.0 Resolved closed
RLS-33 The union of a documents RLS 1.0b1 RLS 1.0 Resolved closed
RLS-32 RoLo Attribute Definition Set definition typo RLS 1.0b1 RLS 1.0 Resolved closed
RLS-30 Typo in 6.3.4 Robotic Localization Architecture RLS 1.0b1 RLS 1.0 Resolved closed
RLS-42 Missing 'public:' declaration in PSM RelativeDatum definition RLS 1.0b1 RLS 1.0 Resolved closed
RLS-31 Typo in Position Element Operation class description RLS 1.0b1 RLS 1.0 Resolved closed
RLS-36 Posistion description in Type II RLS 1.0b1 RLS 1.0 Resolved closed
RLS-39 Definition of orientation in Type I, II, III RLS 1.0b1 RLS 1.0 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-38 Architecture::Ability usage 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-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-8 Parent class of Architecture::MobileOperation RLS 1.0 RLS 1.1 Resolved closed
RLS11-15 CRS definition for pose information RLS 1.0 RLS 1.1 Resolved closed
RLS11-11 Multiplicity of Architecture::WeightedModel 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-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-16 Definition of don't-cares RLS 1.0 RLS 1.1 Resolved closed
RLS11-17 Obtaining configuration of Interface::Stream instances RLS 1.0 RLS 1.1 Resolved closed

Issues Descriptions

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

Separate XMI definition from RLS specification document.

  • Key: RLS-94
  • Legacy Issue Number: 12918
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    The division of documents
    The RLS Specification FTF Beta1(dtc/2008-07-01) includes XMI definition(Annex B).
    I think that the XMI definition had better separate from RLS specification document.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Separate XMI from the main RLS specification document

  • Updated: Sat, 7 Mar 2015 19:52 GMT

(Tbl135/Tbl136) The 'connect' methods

  • Key: RLS-96
  • Legacy Issue Number: 14010
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    (Tbl135/Tbl136) The 'connect' methods lacks the facility to let the targetting module to know about which module is making the connection. This knowledge is required for some methods such as 'getConnectedStream' method in RoLo Stream class. Some means shall be provided to make this specification independent to underlying middleware

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13439 for disposition

  • Updated: Sat, 7 Mar 2015 19:52 GMT

7.3.2 Identity Information

  • Key: RLS-95
  • Legacy Issue Number: 12926
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    I think that explanation may be added about attributes(direct,indirect)
    in RoLo Symbol Position class.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add the following sentence in "Description" of Table 23:
    This class is used as a data holder for accessing symbolic information transparently,
    whether it is directly held or indirectly referenced.

  • Updated: Sat, 7 Mar 2015 19:52 GMT

Figure 6 - Error Type

  • Key: RLS-93
  • Legacy Issue Number: 12927
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In RoLo Error Type Operation class, derived attributes(+source,+target) should added

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 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

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

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

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

Frequency attribute in StreamAbility

  • Key: RLS11-24
  • Legacy Issue Number: 16194
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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

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

Source/destination type of ErrorTypeOperation

  • Key: RLS11-23
  • Legacy Issue Number: 16193
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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

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

Relative/Mobile operations are not well defined

  • Key: RLS-25
  • Legacy Issue Number: 13107
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Static2Mobile/Mobile2Static operations defined in Figure 4 are defined
    to have SC_CRS as source/target domain. However, as SC_CRS is a base
    class for both RelativeCRS and MobileCRS, these operations may take
    MobileCRS for both source and target. This is confusing and shall be
    well defined.

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add some additional description to relevant tables for showing limitation that
    ‘static’ CRS shall not be an instance of DynamicRelativeCRS or inherited classes

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

Relative/Mobile CRS name is confusing

  • Key: RLS-24
  • Legacy Issue Number: 13106
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Although the relative/mobile CRS are defined as 'relative' and
    'mobile' in Figure 3, operations are defined as 'static' and 'mobile'
    in Figure 4. The names are confusing, and shall reflect the
    static/dynamic nature of the coordinate systems.

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Introduce new classes (RelativeCRS, RelativeDatum, DynamicRelativeCRS and
    DynamicRelativeDatum) to reflect the static/dynamic nature of the relative
    coordinate systems separately. RelativeCRS is renamed as StaticRelativeCRS,
    and names of related classes are changed in a similar manner. Make MobileCRS
    to be derived from DynamicRelativeCRS.
    Based on this change, Mobile CRS is a special case of Relative CRS. Therefore,
    change the title of section 7.3.1 Relative and Mobile Coordinate Reference
    Systems to be 'Relative Coordinate Reference Systems' to avoid confusion.

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

Typos

  • Key: RLS-23
  • Legacy Issue Number: 12940
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In Table12, "Fixed2Mobile Operation class" should rename "Static2Mobile Operation class".
    -In Table18, Derived From section, "CD_Datum [ISO19111]" should replace "CS_SingleCRS [ISO19111]".
    -In Table 21, occurrence section of "coordinate", "1" should replace "N ord".
    -In Table 36, occurrence section of "values", "1" should replace "N ord".
    -In Table 54, occurrence section of "elemSpec", "N" should replace "N ord".
    -In Table 55, occurrence section of "elem", "N" should replace "N ord".
    -In Table 60, Derived From section, "RoLo Architecture Operation"
    should replace "RoLo Data Operation".
    -In Table 60, attribute type section of "childOperation", "RoLo Architecture Operation"
    should replace "RoLo Data Operation".
    -In Table 60, description of "childOperation", "Ordered list of RoLo Architecture Operation
    to be appied." should replace "Ordered list of RoLo Data Operation to be applied."
    -In Table 61, Derived From section, "RoLo Architecture Operation"
    should replace "RoLo Data Operation".
    -In Table 62, Derived From section, "RoLo Architecture Single Operation"
    should replace "RoLo Data Single Operation".
    -In Table 63, Derived From section, "RoLo Architecture Single Operation"
    should replace "RoLo Data Single Operation".
    -In Table 65, Derived From section, "IO_IdentifiedObject" should replace "RoLo Data Format".
    -In Table 125, "ord" of value, "M ord, N" should replace "M , N ord".
    -In Table 134, parameter type section of the argument "parameter" in getParameter(),
    "RoLo Parameter" should replace "Stream Parameter Set".
    -In Table 134, parameter type section of the argument "parameter" in setParameter(),
    "RoLo Parameter" should replace "Stream Parameter Set".
    -In Table 135, parameter type section of the argument "value" in getResult(),
    "RoLo Data Set" should replace "RoLo Data".
    -In Table 136, parameter type section of the argument "value" in setResult(),
    "RoLo Data Set" should replace "RoLo Data".

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Correct the typos according to the suggestions in summary of this issue.
    However, the typos in Table 125 and 134 does not exist any more due to
    changes by issue 13322. Therefore, we simply discard these two items.

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

Sample C++ Header

  • Key: RLS-22
  • Legacy Issue Number: 12939
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In header definition(P.58), "#include <vector>" should added.
    -RoLoAttributeValueSet class(P.58)
    -The class name "RoLoAttributeValueSet" should replace "RoLoAttributeValueList".
    -The type of value "std::set<RoLoAttributeSingleValue>"
    should replace "std::vector<RoLoAttributeSingleValue>".
    -RoLoAttributeType(P.59)
    -ISO19111::IO_IdentifiedObject should added as super class.
    -UniformGaussian(P.62)
    -The super class "RoLoErrorType" should replace "ErrorDistribution".
    -DirectSymbol(P.65)
    -The attribute "dimension:Integer" should be added.
    -ErrorElementSpecification(P.69)
    -The attribute "errType:RoLo Error Type" should be added.
    -StreamParameterSet(P.72)
    -In super class "RLS::RoLoAbility", "RLS::" should be deleted.
    -StreamAbility(P.72)
    -In super class "RLS::RoLoAbility", "RLS::" should be deleted.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    All suggestions except the one for ErrorElementSpecification is now unnecessary
    due to changes made in other issues.

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

Figure 21 - RoLo Ability and RoLo Parameter Set

  • Key: RLS-17
  • Legacy Issue Number: 12934
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In RoLo Attribute class, attributes(def,value) should replace to derived attribute.
    -In RoLo Attribute ValueList class, attributes(value) should replace to derived attribute.
    -In RoLo Attribute Definition Set class, the multiplicity of attribute(attribute)
    should replace to [1..*].

    -The navigability notation(arrow head) should be added as follows:
    -one side of self association at RoLo Attribute Set class.
    -one side of self association at RoLo Attribute Definition Set class.
    -RoLo Attribute class side of association between RoLo Attribute Set and RoLo Attribute.
    -RoLo Attribute Definition Set class side of association between RoLo Attribute Set
    and RoLo Attribute Definition Set.
    -RoLo Attribute Definition class side of association between RoLo Attribute Definition Set
    and RoLo Attribute Definition.
    -RoLo Parameter Set class side of association between RoLo Ability and RoLo Parameter Set.
    -RoLo Attribute Definition class side of association between RoLo Attribute
    and RoLo Attribute Definition.
    -RoLo Attribute Value class side of association between RoLo Attribute and RoLo Attribute Value.
    -RoLo Attribute SingleValue class side of association between RoLo Attribute ValueList
    and RoLo Attribute SingleValue.
    -RoLo Attribute Type class side of association between RoLo Attribute Definition
    and RoLo Attribute Type.

    -There are associations as follows but there is no attribute in C++ PSM.
    -between Stream Parameter Set and Stream Parameter Definition
    -between Stream Ability and Stream Parameter Definition
    -between Stream Ability and Service Ability
    -between Stream Ability and Service Parameter Definition
    -between Service Parameter Set and Service Parameter Definition

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

7.4.1 Common data format TypeII.Polar coordinate system

  • Key: RLS-16
  • Legacy Issue Number: 12933
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In Table 70 - Common data format type II, the Unit of Position is only "radian".
    It should replace "meter,radian".
    -The explanation of Position is "The unit of each value is radian.".
    It should replace "The unit of r is meter and that of alpha and beta is radian.".
    -Table 70 - Common data format type II, the Unit of Orientation is "degree",
    but the explanation of Orientation is "The unit of this parameter is radians.".
    Which is correct?

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13120 for disposition

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

Possible inconsistency between RoLo Attribute Set attributes

  • Key: RLS-29
  • Legacy Issue Number: 13111
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    In the RoLo Attribute Set definition (Table 127), there are two
    attributes which leads to the elements of the RoLo Attribute
    Definition Set: def (class RoLo Attribute Definition Set) and
    attribute (class RoLo Attribute). This allows inconsistent
    specification in the two attributes. Description shall be added to
    notice users not to lead any inconsistency.

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

RoLo Attribute Set definition typo

  • Key: RLS-28
  • Legacy Issue Number: 13110
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The 'attribute' attribute in RoLo Attribute Set class definition
    (Table 127) is inconsistent with the UML diagram (Figure 21).
    This shall be defined as 'O' (optional), not 'M' (mandatory).

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    As RoLo Attribute Set and its related classes are restructured in issue #13322,
    these modifications are not necessary any more.
    Disposition: Closed, no change

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

Figure 22 - RoLo Service

  • Key: RLS-18
  • Legacy Issue Number: 12935
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In RoLo Streame class, attributes(ability,parameterSet) should replace to derived attribute.
    -In RoLo Streame class, the type of augument(ability) at getAbility()
    should replace to "Stream Ability".
    -In RoLo Streame class, the type of augument(parameter) at getParameter()
    should replace to "Stream Parameter Set".
    -In RoLo Streame class, the type of augument(parameter) at setParameter()
    should replace to "Stream Parameter Set".
    -In Stream Parameter Set class, the attribute(dataFormat) should rename to "df".
    -In Stream Ability class, the type of attribute(dfList) should replace to "RoLo Data Format".

    -The navigability notation(arrow head) should be added as follows:
    -Stream Parameter Set class side of association between RoLo Stream and Stream Parameter Set.
    -StreamType class side of association between Stream Parameter Set and StreamType.
    -StreamType class side of association between Stream Ability and StreamType.
    -Stream Ability class side of association between RoLo Stream and Stream Ability.
    -Service Ability class side of association between RoLo Service and Service Ability.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    As RoLo service and its related classes are restructured in issue #13439, these
    modifications are not necessary any more. Disposition: Closed, no change

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

SymbolicCS/CRS name is confusing

  • Key: RLS-26
  • Legacy Issue Number: 13108
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    In 6.3.2 Identity Information, symbolic identity CS/CRS are defined as
    'SymolicCS/CRS' where numberic ones are defined as
    'NumericIdentityCS/CRS'. Symbolic ID CS/CRS classes shall also be
    named in the same manner.

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    In order to make the naming consistent, rename SymbolicCS to
    SymbolicIdentityCS and SymbolicCRS to SymbolicIdentityCRS.

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

Possible inconsistency between RoLo Data class attributes

  • Key: RLS-27
  • Legacy Issue Number: 13109
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    In the RoLo Data class definition (Table 55), there are two attributes
    which defines the elements of the target RoLo Architecture: rla (class
    RoLo Architecture) and elem (class RoLo Element). This allows
    inconsistent specification in the two attributes. Description shall be
    added to notice users not to lead any inconsistency

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Place additional sentences to ‘elem’ attribute description for showing that
    consistency is required.

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

Table 134 - RoLo Stream class

  • Key: RLS-21
  • Legacy Issue Number: 12938
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In type section of argument parameter of setParameter(),"Stream Parameter"
    should replace "Stream Parameter Set".
    -In type section of argument parameter of getParameter(),"Stream Parameter"
    should replace "Stream Parameter Set".

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

Table 133 - Stream Ability class

  • Key: RLS-20
  • Legacy Issue Number: 12937
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    In obligation section of attribute dfList, "M" should replace "O".
    -In obligation section of streamTypeList, "M" should replace "O".

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

Table 132 - Stream Parameter Set class

  • Key: RLS-19
  • Legacy Issue Number: 12936
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    In Derived From section, "RoLo Parameter" should replace "RoLo Parameter Set".
    -In obligation section of attribute df, "M" should replace "O".
    -In obligation section of attribute streamType, "M" should replace "O".
    -In Condition section, the explanation is "If the RoLo Architecture can be identified by
    the specified data format, the rlaList attribute may not necessary be specified explicitly.",
    what is "rlaList attribute"?

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

RLS - typos

  • Key: RLS-75
  • Legacy Issue Number: 13998
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:
    • (Fig7/Tbl36) Reference to ISO19103 missing for Matrix::values
    • (Fig7) Matrix.values shall be drawn as an composition to ISO19103::Number
    • (Fig3) RelativeDatum.rla is not described as optional
    • (Fig3) Description of RelativeDatum.base is hard to understand. Please clarify.
    • (Fig5) RoLo Symbol Ref.point and DirectSymbol.coordinateReferenceSystem shall be described as association name. Also these association shall be arrowed.
    • (Fig10) Position Element Concatenated Operation.childOperation, RoLo Data Concatenated Operation.childOperation and RoLo Data Transformation.usesOperation shall be described as derived attributes.
    • (Fig11) association between User Defined Data Format and RoLo Architecture shall be drawn as an arrowed association between Specific Data Format and RoLo Architecture
    • (Tbl33) Description shall say this class is abstract
    • (Tbl35) Description shall say this class is abstract
    • (Tbl35) Delete unnecessary 'Attribute' row from table
    • (Tbl37) Add note indicating that covariance matrix need to be a square matrix
    • (Tbl39) Uniform Gaussian, from its meaning, shall be a child class of Gaussian class. Thus, its 'stddev' attribute is unnecessary and 'covariance' attribute in Gaussian class shall be used. However, restriction shall be noted that this 'covariance' attribute can only be a matrix where row/col dimensions are limited to 1
    • (Tbl43) reference to ISO specification missing in 'Derived From'
    • (Fig7/Tbl43) For Weighted Distribution class, reference to ISO specification missing for type name (Probability) of attribute weight
    • (Fig7) Weighted Distribution class's 'weight' shall be described as composition
    • (Fig7,Tbl45) 'dists' attribute for Mixture of Gaussian class shall be restricted to Gaussian class, from its meaning
    • Section number "6.2" in the sentence starting as "Note that derived attributes" in 7.1.1 is wrong; should be "7.2"
    • (Tbl8) The word "Polar" shall be "polar" in the description line
    • (Tbl46) Reference to ISO specification missing for typename of 'numeric' attribute
    • (Fig9) 'elem' attribute in RoLo Data class shall be described as composition
    • (Tbl55) Typo in description for 'elem' attribute: Ordered list for the... -> Ordered list of the...
    • (Tbl36) Describe that dimensions of matrix shall always be 1 or more than 1; that is, matrix will never be 0-dimensional
    • Information on Submitters and Submitting Organizations shall be added
    • (Fig5,Tbl21) 'dimension' attribute for DirectSymbol class is redundunt; it can be obtained from the list 'coordinate'.
    • (Fig22,Tbl134) The names of setParameter/getParameter methods are strange. It is the parameter values that is to be set/get, not the parameter itself. It shall be renamed as setParameterValue/getParameterValue
    • (Fig22,Tbl135) The name 'getResult' in OutStream class is not consistent with the 'setData' method in InStream class. This shall be changed to 'getData'
    • Attribute names are inconsistent throughout the specification. Some are plural and some are not plural, even if it denote a list of values. Some are abbreviated and some are not. This inconsistency shall be fixed.
  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Fix typos based on the suggestions

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

Inconsistency between PIM and PSM namings

  • Key: RLS-71
  • Legacy Issue Number: 13441
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    As class names with blanks are not allowed in most programming
    languages (or XML defnitions), different class names are used in PIM
    and PSM. This should be fixed. One way is to remove blanks from PIM
    class names.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    In addition to the item pointed out in the summary, some class names have the
    ¡¥RoLo¡¦ prefix and some does not (issue 13442). In order to resolve these
    inconsistencies, the following changes are performed:
    „O Remove blanks from PIM class names
    „O Remove 'RoLo' prefix from PIM and PSM class names
    „O Instead, use global namespace 'RoLo' in place of 'RLS'. As most class
    definitions belong to some packages (from issue 12916), two namespaces
    will be used for class definitions.
    For example, ¡§RoLo Element Specification¡¨ class will be renamed as
    ¡§ElementSpecification¡¨ or ¡§::RoLo::Architecture::ElementSpecification¡¨ in full
    resolution.
    However, this change makes descriptions in natural language harder to read. To
    make sentences simple, we follow the resolution from #13116 such that
    whenever class names are used to indicate its instances, the names are written
    in small letters in divided forms with a ¡¥RoLo¡¦ prefix. For example, ¡§xxx is a list of
    references to PositionElement class instances¡¨ are rewritten as ¡§xxx is a list of
    reference to RoLo position elements.¡¦
    There also exist inconsistencies in attribute names (from issue 13998). To
    reduce this inconsistency, we will modify attribute names based on the following
    rules:
    ¡E Shorten the attribute names whenever it is possible, but keep it long when
    it is not easy to infer the original name. Use the same attribute names across the specification whenever they
    indicates the same meanings.
    • Make attribute name to be plural when multiplicity of the attribute is able to
    be more than 1.
    For clarification, we will enclose the names of attributes and methods with a pair
    of single quotation marks whenever they appear in natural language sentences.

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

Typo in Service Ability class description

  • Key: RLS-70
  • Legacy Issue Number: 13440
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The phrase 'Service Parameter class' in the Service Ability class
    description shall be 'Service Parameter Definition class'. UML diagram
    shall be fixed, and also a subset note shall be added to the relation
    between Service Ability class and Service Parameter Definition class
    in the diagram.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

(Annex A) Mapping between PIM and C++ PSM is not clear

  • Key: RLS-77
  • Legacy Issue Number: 14000
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    (Annex A) Mapping between PIM and C++ PSM is not clear

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Describe how C++ PSM was mapped from PIM

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

(7.4.1) Timestamp for common data types

  • Key: RLS-76
  • Legacy Issue Number: 13999
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    (7.4.1) Timestamp for common data types are described as 'POSIX time' but it is not clear which type shall be actually used

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13120 for disposition

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

Fig3,Tbl9,Fig22,Tbl134,Tbl140) Mobile Datum class, RoLo Stream class and RoLo Service

  • Key: RLS-80
  • Legacy Issue Number: 14003
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Fig3,Tbl9,Fig22,Tbl134,Tbl140) Mobile Datum class, RoLo Stream class and RoLo Service class holds public attributs and at the same time provide methods for obtaining the value of the same public attributes. This is redundunt and is losing flexibility of dynamically creating the returned values

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Make the attributes as protected

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

7.5) Filter condition requires naming of RoLo data elements. However, the naming rules are not clear.

  • Key: RLS-79
  • Legacy Issue Number: 14002
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    7.5) Filter condition requires naming of RoLo data elements. However, the naming rules are not clear.

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13184 for disposition

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

Fig5,Fig9) RoLo Symbolic Position class and RoLo Position class

  • Key: RLS-81
  • Legacy Issue Number: 14004
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Fig5,Fig9) RoLo Symbolic Position class and RoLo Position class are specified to be 'union' but it is better to leave them unspecified. 'Union' is hard to implement for some programming language

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Stop using ‘union’ as suggested in the summary, For the C++ PSM, as we found
    that some compilers are unable to treat ‘union’ with elements that owns
    constructors, we will also stop using union and make the elements as pointers.
    Implementers need to be aware that only one of the elements shall be effective.

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

Missing references

  • Key: RLS-74
  • Legacy Issue Number: 13451
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    The RLS specification refers to some other specifications.
    These references should be added. For example,
    *[UML] Unified Modeling Language, Superstructure Specification version 2.1.2
    http://www.omg.org/technology/documents/formal/uml.htm
    *[XML] .....

  • Reported: RLS 1.0b1 — Tue, 27 Jan 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13427 for disposition

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

Typo: argument type for methods in RoLo Service class

  • Key: RLS-73
  • Legacy Issue Number: 13443
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The argument types for 'setParameter' and 'getParameter' methods in
    RoLo Service class shall be 'Service Parameter Set' class, not
    'Service Parameter' class.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

(7.5) In the filter condition section

  • Key: RLS-78
  • Legacy Issue Number: 14001
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    (7.5) In the filter condition section, an extention to RoLo Service class is described which enables RoLo Services to specify filter conditions. However, this is not a good way to implement, and will lead in lack of interoperabiility. Instead, it is much better to make it so that conditions can be specified through some parameters

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13184 for disposition

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

(Fig7) Matrix class is specified as "DataType" but this is unnecessary

  • Key: RLS-82
  • Legacy Issue Number: 14005
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    (Fig7) Matrix class is specified as "DataType" but this is unnecessary

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Remove the stereotype as suggested

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

Inconsistency in class names

  • Key: RLS-72
  • Legacy Issue Number: 13442
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Some classes have 'RoLo' prefix in their names, and others do
    not. These namings shall be modified to follow some rule.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

Hierarchy of Error can be reduced

  • Key: RLS-47
  • Legacy Issue Number: 13185
  • Status: closed  
  • Source: AIST ( Dr. Itsuki Noda)
  • Summary:

    Particle Set in Error can be defined as a subclass of Linear
    Mixture Model. In this case each particle is denoted as an
    impulse distribution

  • Reported: RLS 1.0b1 — Sat, 20 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Delete Particle class and reorganize classes in Figure 7 to reduce the hierarchy
    of Error classes. Also add some description for improving understandability.

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

Filter Condition should be reduced and move to annex as informative

  • Key: RLS-46
  • Legacy Issue Number: 13184
  • Status: closed  
  • Source: AIST ( Dr. Itsuki Noda)
  • Summary:

    There is an activity in ISO TC211 to develop UML diagram of
    filter condition encoding. So, we should refer it directly
    instead to define our own UML diagram.

    • Filter Condition will be useful specification for various
      application of RLS. But it domain is slightly different from
      RLS's main target. In addition, ISO TC211's definition is not
      finalized yet. So, the specification should be included in the
      annex as an informative.
  • Reported: RLS 1.0b1 — Sat, 20 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    As described in issue 13122, Filter Condition cannot be moved to be an
    informative part for now, and thus will remain in its original position as mandatory.
    However, as an identical ISO standard which can be used for RoLo service is
    under process, descriptions will be modified to use the ongoing ISO draft. Here,
    we modify the interface for treating filter conditions in Robotic Localization
    Service. In the beta1 specification, section for filter condition (7.5) defined an
    additional method for RoLo service class to treat filter condition data. As pointed
    out by issue 14001, this is not a good way from the viewpoint of interoperability.
    Thus, we define a much simple method that treats filter condition as a parameter
    defined in ability description for RoLo streams. This allows users to check
    whether filter condition functionality is supported or not and provides an easy
    mean to specify conditions.
    In addition, as the new filtering functionality based on ISO standard requires XML
    notation of RoLo data (also from issue 13186) and naming rules (from issue
    14002), we define two informative annexes, XML-PSM and naming rules. With
    this addition, some description about what is given as annex is also added in
    Section 1 “Scope”.

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

Conformance shall be specified in detail

  • Key: RLS-56
  • Legacy Issue Number: 13426
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Conformance criteria described in chapter 2 is too simple and too
    strict. Shall be described in more detail.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add further description showing the conformance conditions.

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

Inability of representing range values (Figure21/Table120)

  • Key: RLS-55
  • Legacy Issue Number: 13322
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    The 'choice' attribute of RoLo Attribute Definition class (Table 120) can only represent a list of discrete values. In case of ranged attributes that have minimum and maximum value, it cannot be well expressed.

    One possible resolution is to introduce a new class, RoLo Attribute RangeValue, which is derived from RoLo Attribute Value and has 'minValue' and 'maxValue' attributes of type of RoLo Attribute SingleValue.

  • Reported: RLS 1.0b1 — Thu, 22 Jan 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    solution suggested in the summary is sufficient for this issue. But similar
    issues may rise if we kept on using the current definition of RoLo Attribute
    SingleValue class defined as an enumeration of types which is not extendable by
    users. Thus, in order to make the RoLo Attribute structures more extendable and
    flexible, we restructure these classes to use type templates. In addition, some
    more sentences are added to clarify how RoLo attribute and related structures
    are to be used.
    Also from issue 14006, there are too many classes of similar functionality.
    Especially, usage of RoLo Attribute Definition Set was unclear and distinction
    between RoLo Attribute and RoLo Parameter (Set) was not clear. Thus, the
    following reorganization of class structure is proposed:

    • Remove the RoLo Attribute SingleValue, RoLo Attribute Value, RoLo
      Attribute ValueList, RoLo Attribute Type classes that were used to represent
      variations of type/value pair. InStread, Make RoLo Attribute class to be a
      template class. By this change, RoLo Attribute can be used for any time that
      is required for attributes.
    • Separate ‘attribute’ and ‘parameter’ explicitly, and describe their differences.
      Here, attributes are ‘constant’ parameters that users cannot change.
      Parameters are user-changeable attributes. As requested by summary, we
      will prepare several template types for the datatype of parameter. This is for
      convenience, and users can always extend this to any types on demand. Simplify the attribute set/attribute definition set class structures for clarity.
      Some attributes (such as min/maxOccurence in RoLo Attribute Definition) are
      not necessary any more due to the introduction of templates (users can
      always define types with these occurrence limits).
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Simplication of Error Type (Figure 6):

  • Key: RLS-50
  • Legacy Issue Number: 13317
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    Error Type classes are defined for each Error Information class in Figure 6. However it seems to be unnatural and too complex to define such classes just for discriminating error types. Implementation also is hard.

    More natural way would be defining one class that is an enumeration of various error types like the case of RoLo Attribute SingleValue in Figure 21.

  • Reported: RLS 1.0b1 — Thu, 22 Jan 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Instead of the way suggested in the summary, we decided to use only a single
    class for describing RoLo error types and use hierarchy of RoLo error type
    instances to represent the relationships instead of the class hierarchy in the
    original specification. By this change, we can decrease the complexity of defining
    classes that is never instantiated while preserving the original functionality and
    extendibility.

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

Hierarchical relationship for instances of CRS and RoLo Data Spec

  • Key: RLS-49
  • Legacy Issue Number: 13187
  • Status: closed  
  • Source: AIST ( Dr. Itsuki Noda)
  • Summary:
    • Some applications need to handle unlimited number of CRSs and
      their corresponding structures of RoLo Data Specification.

    For example, suppose that a human counting application that can
    connect camera systems that are mounted various rooms. Because
    the origin of CRS used in each camera system is different from
    each other, corresponding RoLo Data Specification is different.
    It means that the application need to recognize unbounded number
    of RoLo Architectures.

    In order to avoid such situations, we can utilize hierarchical
    relations among CRSs. In the case of above example, we define a
    generic CRS, by which a CRS used in each camera system is
    defined a kind of a derived CRS of the generic CRS. In the same
    time, the human counting application is designed to accept the
    generic CRS and corresponding RoLo architecture. Then, the
    application can handle each derived CRS and its corresponding
    RoLo architecture.

    • In order to realize such functionality, we should introduce the
      following mechanisms to define relations among CRSs and among
      RoLo architectures.
    • To define a hierarchical relation between two CRSs, we introduce
      a CRS Hierarchical Relation class. In the class, baseCRS and
      subCRS are specified. The baseCRS is a generic CRS and the
      subSRC is a derived CRS.

    Whole relations of CRSs shall form a lattice structure.

    • To define a hierarchical relations between two RoLo Data
      Specifications, we introduce a class for RoLo Data
      Specifications, in which baseSpec and subSpec is specified. The
      baseSpec is a generic RoLo Data Specification and subSpec is a
      derived RoLo Data Specification.

    Whole relations of RoLo Data Specifications shall form a lattice
    structure.

    • To define a hierarchical relations between two RoLo Element
      Specifications, we introduce a class for RoLo Element
      Specifications, in which baseSpec and subSpec is specified. The
      baseSpec is a generic RoLo Element Specification and subSpec is
      a derived RoLo Element Specification.

    Whole relations of RoLo Element Specifications shall form a lattice
    structure.

  • Reported: RLS 1.0b1 — Sat, 20 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Instead of introducing a new class to represent hierarchical relationship among
    instances, use the don’t-care functionality in the original specification. However,
    as there were not enough description in the original specification and also as
    there were some errors, do some reorganization to clarify this.

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

The type of 'usesOperation' attribute of RoLo Data Transformation (Table62)

  • Key: RLS-53
  • Legacy Issue Number: 13320
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    In Table 62, the type of 'usesOperation' attribute of RoLo Data Transformation should be "Position Element Operation".

  • Reported: RLS 1.0b1 — Thu, 22 Jan 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Modify Table 62 as described in the summary. Also modify the description for this
    attribute to fit this change.

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

Obligation of 'values' attribute of Matrix (Figure7/Table36)

  • Key: RLS-52
  • Legacy Issue Number: 13319
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    In Table 36 (Matrix) the obligation of 'values' attribute is mandatory but it is represented as optional in Figure 7. Which one is correct?

  • Reported: RLS 1.0b1 — Thu, 22 Jan 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    The obligation of 'values' attribute is mandatory. Therefore, fix Figure 7 to make
    'values' attribute to be mandatory

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

Figure 8 may accompany an object diagram

  • Key: RLS-45
  • Legacy Issue Number: 13145
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    This is actually not an issue, but Figure 8 "Representation of error
    information related to multiple localization data" shall better be
    accompanied with an UML object diagram.

  • Reported: RLS 1.0b1 — Fri, 5 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    For better understanding of the specification, add an non-mandatory UML object
    diagram into Figure 8 so that the original figure is accompanied with the UML
    object diagram.

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

Definition mismatch for Service Ability class in Figure 22 and Table 139

  • Key: RLS-44
  • Legacy Issue Number: 13144
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The inStreamAbility and outStreamAbility attributes of Service Ability
    class are listed in Table 139 but not in Figure 22.

  • Reported: RLS 1.0b1 — Fri, 5 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13322 for disposition

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

Typo in Position Element Concatenated Operation class definition

  • Key: RLS-43
  • Legacy Issue Number: 13143
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    In The Position Element Concatenated Operation class diagram (Figure
    10), the childOperation attribute is described to be a reference to a
    list of RoLo Element Operation. This does not match its definition in
    Table 57, and should be replace to be a reference to a list of
    Position Element Operation.

  • Reported: RLS 1.0b1 — Fri, 5 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Correct the typo as suggested in the summary

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

Association between RoLo Parameter Set and RoLo Parameter Definition (Figure 21)

  • Key: RLS-54
  • Legacy Issue Number: 13321
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    In Figure 21 (RoLo Ability and RoLo Parameter Set), the aggregation association between RoLo Parameter Set and RoLo Parameter Definition is not fully specified. If it is for derived 'def' attribute, we should add association end name in Figure 21 and an explanatory note to limit the value of derived attribute in Table 128 (RoLo Parameter Set).

  • Reported: RLS 1.0b1 — Thu, 22 Jan 2009 05:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

XML mapping of RoLo Data and RoLo Element

  • Key: RLS-48
  • Legacy Issue Number: 13186
  • Status: closed  
  • Source: AIST ( Dr. Itsuki Noda)
  • Summary:
    • We should have a rule to denote RoLo Data in XML format. In
      order to do it, we need to have an template of XML schemas for
      the RoLo Data XML format and the mapping rule from RoLo Data
      Specifications.
    • This rule will be a part of annex as informative
  • Reported: RLS 1.0b1 — Sat, 20 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13184 for disposition

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

Typo in Table 22 (RoLo SymbolRef)

  • Key: RLS-51
  • Legacy Issue Number: 13318
  • Status: closed  
  • Source: ETRI ( Jaeyeong Lee)
  • Summary:

    In Table 22, 'Point' attribute of RoLo SymbolRef should be renamed by 'point' for namning consistency.

  • Reported: RLS 1.0b1 — Thu, 22 Jan 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Correct the typo

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

Ambiguity in 'rla' attribute description in RelativeDatum class

  • Key: RLS-65
  • Legacy Issue Number: 13435
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The description for 'rla' attribute in RelativeDatum class (Table 6)
    is somewhat ambiguious. The second sentence 'If the base attribute
    contains structural information, ' shall be modified as following: 'If
    the base attribute contains structural information, or if the
    coordinate reference system in target holds no relation with other
    coordinate reference systems,'.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Modify the description for 'rla' attribute according to the suggestion in the
    summary.

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

Some description on Coordinate System usage shall be added

  • Key: RLS-64
  • Legacy Issue Number: 13434
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    In this specification, the CS_CoordinateSystem class from ISO19111 is
    used in a rather special manner than its original intention, such as
    the assumption for using it in n-dimensional spaces (where n >
    3) or using axis definitions in a more flexible manner. Although this
    does not violate the original ISO specification, it is better to have
    some notes.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add some description which clarifies the difference between the usage in this
    specification and the implicit assumption made in the ISO 19111 specification.

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

Typos in 6.3 Background

  • Key: RLS-62
  • Legacy Issue Number: 13432
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    There are some simple typos in "6.3 Background." For example, the
    phrase 'wit this specification' at the end of page 6 shall be 'with
    this specification.'
    Also, for the purpose of this specification, it is better to describe
    explicitly that this specification can be applied to fields other than
    robotics, such as GIS or LBS.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Correct the typo and add some description in section 6.3.

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

Names missing in "6.2 Acknowledgements"

  • Key: RLS-61
  • Legacy Issue Number: 13431
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Some more people shall be added here.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add names to be acknowledged.

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

Some references are missing

  • Key: RLS-57
  • Legacy Issue Number: 13427
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Reference described in chapter 3 is not enough, and shall be
    added. Non-normative references may also be helpful.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add necessary references. Also, split chapter 3 to include both normative and
    non-normative references.

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

Structural change for RoLo Service class

  • Key: RLS-69
  • Legacy Issue Number: 13439
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The RoLo Service class may be modified not to inherit OutStream
    class, as to clarify its functionality. In order for this change, the
    following modification are required: 1. Change description at the
    beginning of 7.5 Service Interface, 2. UML diagram fix, and 3. add
    some attributes that were inherited from OutStream class. (Originally
    proposed by Mr. Han, ETRI)

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    In the beta1 specification, the RoLo service class which denotes the service
    interface for Robotic Localization Service was described to be inherited from
    OutStream class which denotes data output stream. This issue points out that
    although from the point of functionality this is sufficient, from the meaning of the
    classes this is somewhat misleading. Thus, we decided to change the structure
    of RoLo service class so that it will not be inherited from OutStream, but instead
    will contain OutStream instances as well as InStream instances.
    Based on the proposed solution, we made a reconstruction of RoLo Service
    class and related classes. Based on this change, some additional description is
    also added for clarity.

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

Some organization missing in "6.1 Supporting Organizations"

  • Key: RLS-60
  • Legacy Issue Number: 13430
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Not sure whether this section is necessary, but if so, some more
    organizations shall be added here.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add another section describing the organizations which submitted the original
    specification. Also, from issue 13998, add submitter information

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

Typo in RoLo Attribute Definition class description

  • Key: RLS-68
  • Legacy Issue Number: 13438
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    'Of minOccurence...' shall be modified to be 'If minOccurence...'.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    No Data Available

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

'numDists' attribute in Lineare Mixure Model class may be unnecessary

  • Key: RLS-67
  • Legacy Issue Number: 13437
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    'numDists' attribute in Lineare Mixure Model class may be unnecessary

    The 'numDists' may not be necessary, as this value can be obtained
    from the 'dists' attribute (which is a list).

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Delete 'numDists' attribute from Lineare Mixure Model class.

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

Symbol should be described

  • Key: RLS-59
  • Legacy Issue Number: 13429
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Chapter 5 "Symbol" shall be described, especially for the data format
    section.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add necessary symbol descriptions

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

Terms and Definition shall be added

  • Key: RLS-58
  • Legacy Issue Number: 13428
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    There are certainly some terms and definitions required for this
    specification.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add necessary definitions on terms used in this specification

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

'inStream' attribute in MobileDatum class shall be an object

  • Key: RLS-66
  • Legacy Issue Number: 13436
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    'inStream' attribute in MobileDatum class shall be an object, not n
    reference to an object.

    There seems to be no reason to make the 'inStream' attribute to be a
    reference.

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Although the ‘Description’ part of MobileDatum explicitly says that ‘inStream’
    attribute is an instance, it is described as a reference in the description of the
    attribute. Fix this inconsistency and modify ‘inStream’ attribute in MobileDatum as
    non-reference.

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

Overview in 6.3 Background needs to be modified

  • Key: RLS-63
  • Legacy Issue Number: 13433
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The paragraph beginning with 'In order to fulfill the requirements...'
    in 6.3 needs to be updated

  • Reported: RLS 1.0b1 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 12916 for disposition

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

Sequence diagrams should be added

  • Key: RLS-3
  • Legacy Issue Number: 12917
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    In RLS specification, there is no sequence diagram.
    I think it is difficult to understand behavior.
    So I think it would be better if sequence diagrams were added.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Add non-mandatory sequence diagram and accompanying description at the last
    part of section 7.5, in order to show typical RoLo service usage.

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

create sub packages

  • Key: RLS-2
  • Legacy Issue Number: 12916
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    The package division
    In RLS specification, there is only one package named RLS.
    I think that it should be divided into some sub packages.
    Ex.Coordinate system package, Data Format package, Filter package, Service package, etc.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Modify Figure 2 as follows:
    ¡V Divide the RoLo package into four sub packages of Architecture
    package, DataFormat package, FilterCondition package and Interface
    package.
    ¡V Delete original dependency relationships between RLS and GIS
    standards and add the following dependency relationships in the
    diagram:
    ƒÞ from Architecture package to ISO 19107
    ƒÞ from Architecture package to ISO 19103
    ƒÞ from Interface package to ISO 19103
    ƒÞ from Interface package to ISO 19115
    ƒÞ from DataFormat package to Architecture package
    ƒÞ from Interface package to Architecture package
    ƒÞ from Architecture package to Interface package
    ƒÞ from RoLo package to ISO 19111
    ƒÞ from FilterCondition package to Interface package FilterCondition package to ISO 19142
    ƒÞ from FilterCondition package to ISO 19143
    Add the following sentences(package descriptions) at the beginning of section
    7 (Platform Independent Model):
    The PIM consists of four parts:
    1. Architecture package
    The architecture package defines a new framework for representing location informatio
    n required in the field of robotics. See section 7.3.
    2. DataFormat package
    The data format package defines how the defined data is represented for exchange amo
    ngst RoLo modules. See section 7.4.
    3. FilterCondition package
    The filter condition package defines methods for filtering localization results. See secti
    on 7.5.
    4. Interface package
    The interface package defines an API for data passing and configuration of RoLo modu
    les. See section 7.6.
    Change the following section titles as package names:
    ¡V Change the title of section 7.3 Representing Robotic Localization
    Results into 'Architecture Package'.
    ¡V Change the title of section 7.4 Data Formats into 'DataFormat Package'.
    ¡V Change the title of section 7.5 Filter Condition into ¡¥FilterCondition
    Package¡¦.
    ¡V Change the title of section 7.6 Service Interface into 'Interface Package'.
    Add package name to following items:

    • MobileDatum class (Table 9 and Figure 3): change type name of
      ¡¥inStream¡¦ attribute and ¡¥inStream¡¦ argument of ¡¥getInStream¡¦ method to
      RoLo::Interface::InStream
    • SpecificDataFormat class (Table66): change type name of ¡¥rla¡¦ attribute
      to RoLo::Architecture::DataSpecification.
    • StreamAbility class (Table 124 and Figure 22): change type names of
      ¡¥rlaList¡¦ and ¡¥dfList¡¦ attributes to RoLo::Architecture::Data and
      RoLo::DataFormat::DataFormat respectively. OutStream class (Table 135 and Figure 22): change type name of
      ‘getResult’ method’s argument ‘value’ as RoLo::Architecture::Data.
    • InStream class (Table 136 and Figure 22): change type name of
      ‘setData’ method’s argument ‘value’ as RoLo::Architecture::Data.
    • RoLo Service class (Table 140 and Figure 22): change type name of
      ‘adjust’ argument ‘data’ as RoLo::Architecture::Data.
      Modify C++ PSM as following:
    • Add header files, Architecture.hpp and Interface.hpp, that represent
      Architecture package and Interface package respectively as following:
      // $Id: Architecture.hpp,v 1.3 2009/06/20 06:18:42 nishio Exp $
      #pragma once
      #include <RLS/RelativeCRS.hpp>
      #include <RLS/MobileCRS.hpp>
      #include <RLS/MobileOperation.hpp>
      #include <RLS/Identity.hpp>
      #include <RLS/ErrorType.hpp>
      #include <RLS/Error.hpp>
      #include <RLS/RoLoArchitecture.hpp>
      #include <RLS/RoLoDataOperation.hpp>
      // $Id: Interface.hpp,v 1.2 2009/06/20 06:18:43 nishio Exp $
      #pragma once
      #include <RLS/Ability.hpp>
      #include <RLS/Service.hpp>
    • Reorder header files in C++ PSM so that files are ordered based on the
      packages they belong to. The files will be in the following order:
      Returncode_t.hpp, Architecture.hpp, RelativeCRS.hpp, MobileCRS.hpp,
      MobileOperation.hpp, Identity.hpp, ErrorType.hpp, Error.hpp,
      RoLoArchitecture.hpp, RoLoDataOperation.hpp, DataFormat.hpp,
      Interface.hpp, Ability.hpp, Service.hpp
    • Move definitions in Error.hpp, ErrorBase.hpp, ErrorType.hpp,
      Identity.hpp, MobileCRS.hpp, MobileOperation.hpp, RelativeCRS.hpp,
      RoLoArchitecture.hpp and RoLoDataOperation.hpp into a namespace
      “::RoLo::Architecture”.
      Note: ErrorBase.hpp is added in issue 13185
    • Move definitions in DataFormat.hpp into a namespace
      “::RoLo::DataFormat”.
    • Move definitions in Ability.hpp and Service.hpp into a namespace
      “::RoLo::Interface”.
    • Modify type of rla in SpecificDataFormat class (DataFormat.hpp)
      as ::RoLo::Architecture::DataSpecification.
    • Modify type of ‘inStream’ and argument ‘inStream’ of getInStream()
      method in MobileDatum class (MobileCRS.hpp)
      as ::RoLo::Interface::InStream. Modify type of ‘dfList’ as ::RoLo::DataFormat::DataFormat and type of
      ‘rlaList’ as ::RoLo::Architecture::DataSpecification (Service.hpp).
    • Modify type of ‘value’ argument of setData() method in InStream
      class (Service.hpp) as ::RoLo::Architecture::Data.
    • Modify type of ‘value’ argument of getResult() method in OutStream
      class (Service.hpp) as ::RoLo::Architecture::Data.
    • Modify type of ‘data’ argument of adjust() method in RoLo Service class
      (Service.hpp) as ::RoLo::Architecture::Data
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7 - Error information

  • Key: RLS-11
  • Legacy Issue Number: 12928
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    The constraint

    {ordered}

    should be added to attribute(particles) in Particle Set class.
    -The multiplicity [0..1] should be added to attribute(errprType) in RoLo Error class.

    -The navigability notation(arrow head) should be added as follows:
    -Particle class side of association between Particle Set and Particle.
    -Probability class side of association between Particle and Probability.
    -Weighted Distribution class side of association between Linear Mixture Model
    and Weighted Distribution.
    -Covariance Matrix class side of association between Gaussian and Covariance Matrix.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Fix Figure 7 according to the suggestions. However, as Particle class and
    ‘particles’ attribute in Particle Set class is removed in issue 13185, items in
    summary related to these will not be revised. Also, for the relations Weighted
    Distribution – Linear Mixture Model and Covariance Matrix – Gaussian are better
    to be shown as compositions

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

Figure 5 - Identity information

  • Key: RLS-10
  • Legacy Issue Number: 12925
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In RoLo Symbolic Position class, attributes(direct,indirect) should replace to derived attributes.

    -The navigability notation(arrow head) should be added as follows:
    -SymbolicCRS class side of association between DirectSymbol and SymbolicCRS.
    -DirectSymbol class side of association between DirectSymbol and RoLo Symbolic Position.
    -RoLo Symbol Ref class side of association between DirectSymbol and RoLo Symbolic Ref.
    -DirectSymbol class side of association between DirectSymbol and RoLo Symbolic Ref.
    -DirectSymbol class side of association between DirectSymbol and RoLo Symbolic Position.
    -RoLo Symbol Ref class side of association between RoLo Symbol Ref and RoLo Symbolic Position.

    -The association end name should be added as follows:
    -direct : DirectSymbol class side of association between DirectSymbol and RoLo Symbolic Position.
    -indirect : RoLo Symbol Ref class side of association between RoLo Symbol Ref and
    RoLo Symbolic Position.

    -Because the following association is meanings to limit relations defined in superior,
    we should add an explanatory note.
    NumericIdentityCS - NumericIdentityCRS
    SymbolicCS - SymbolicCRS
    IdentityCRS - IdentityDatum

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Fix Figure 5 according to the suggestions. However, the associations RoLo
    Symbolic Position – DirectSymbol and RoLo Symbolic Position – RoLo Symbol
    Ref shall be compositions both on RoLo Symbolic Position side. For the
    associations SymbolicCRS – DirectSymbol and DirectSymbol – RoLo Symbolic
    Ref, it is better to make them aggregations that indicate relevant attributes.

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

Figure 9 - RoLo Architecture

  • Key: RLS-12
  • Legacy Issue Number: 12929
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In RoLo Element class, attributes(spec) should replace to attributes.
    -In RoLo Architecture class, attributes(spec) should rename to elemSpec, and should replace
    to derived attribute.
    -In RoLo Position class, attributes(symbolic,numeric) should replace to derived attributes.
    -In Error Element class, attributes(err) should replace to derived attributes.
    -In RoLo Data class, attributes(elem) should replace to derived attributes.

    -The association end name should be added as follows:
    -symbolic : RoLo Symbolic Position class side of association between RoLo Position and
    RoLo Symbolic Position.
    -numeric : ::ISO_19107::GM_Position class side of association between RoLo Position and
    ::ISO_19107::GM_Position.
    -err : RoLo Error class side of association between Error Element and RoLo Error.
    -elem : RoLo Element class side of association between RoLo Data and RoLo Element.

    -The navigability notation(arrow head) should be added as follows:
    -GM_Position class side of association between RoLo Position and GM_Position.
    -RoLo Symbolic Position class side of association between RoLo Position and
    RoLo Symbolic Position.
    -RoLo Position class side of association between Position Element and RoLo Position.
    -RoLo Error class side of association between Position Element and RoLo Error.
    -RoLo Error class side of association between Error Element and RoLo Error.
    -RoLo Element class side of association between RoLo Data and RoLo Element.
    -CS_CoordinateSystem class side of association between RoLo Element Specification
    and CS_CoordinateSystem.
    -SC_CRS class side of association between RoLo Element Specification and SC_CRS.
    -RoLo Error Type class side of association between RoLo Element Specification and RoLo Error Type.
    -RoLo Error Type class side of association between Error Element Specification
    and RoLo Error Type.
    -RoLo Element Specification class side of association between RoLo Architecture
    and RoLo Element Specification.
    -RoLo Architecture class side of association between RoLo Data and RoLo Architecture.

    -Because the following association is meanings to limit relations defined in superior,
    we should add an explanatory note.
    Position Element Specification - Position Element
    Error Element Specification - Error Element

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Apply the necessary modifications to Figure 9 as specified. However, the
    following relations are compositions and do not show derived attributes:
    RoLo Position – ::ISO19107::GM_Position
    RoLo Position – RoLo Symbolic Position
    Position Element – RoLo Position
    Position Element – RoLo Error
    Error Element – RoLo Error
    RoLo Data – RoLo Element
    RoLo Element – RoLo Element Specification
    Thus, for these relations, replace the associations to indicate composition with
    corresponding attribute names.

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

Figure 11 - RoLo Data format

  • Key: RLS-14
  • Legacy Issue Number: 12931
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -Because the following association is meanings to limit relations defined in superior,
    we should add an explanatory note.
    User Defined Data Format - RoLo Architecture

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Actually, this association is required between Specific Data Format and RoLo
    Architecture, and not between User Defined Data Format and RoLo Architecture.
    This association is for the ‘rla’ attribute of Specific Data Format class. Thus,
    instead of adding note for limiting this association, we shall better correct the
    association to be between Specific Data Format and RoLo Architecture that
    shows the derived attribute ‘rla’ of Specific Data Format class. The new
    association is also reported in issue 13998.

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

Figure 10 - RoLo Data Operation

  • Key: RLS-13
  • Legacy Issue Number: 12930
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -In Position Element Operation class, derived attributes(+source,+target) should added.
    -In RoLo Data Operation class, derived attributes(+source,+target) should added.
    -The relationship between Position Element Operation and Position Element Specification
    should replace to association(solod line).
    -In Position Element Single Operation class, attributes(usesOperation,UsesErrorTypeOperation)
    should replace to derived attribute.
    -The navigability notation(arrow head) should be added as follows:
    -CC_SingleOperation class side of association between Position Element Single Operation
    and CC_SingleOperation.
    -RoLo Error Type Operation class side of association between Position Element Single Operation
    and RoLo Error Type Operation.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Correct the errata of UML diagram in Figure 10 (RoLo Data Operation) according
    to the suggestions in the summary except for the first two issues, as they are
    already in the diagram

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

Figure 4 - Mobile CRS operations

  • Key: RLS-9
  • Legacy Issue Number: 12924
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    The relationship between Mobile2Static Operation and ::ISO 19111::SC_CRS should replace
    to association(solod line).
    -The relationship between Mobile2Static Operation and MobileCRS should replace to
    association(solod line).
    -The relationship between Static2Mobile Operation and ::ISO 19111::SC_CRS should replace to
    association(solod line).
    -The relationship between Static2Mobile Operation and MobileCRS should replace to
    association(solod line).
    -In the relationship between Mobile2Static Operation and ::ISO 19111::SC_CRS,
    the association end name "+source" (::ISO 19111::SC_CR side) should replace "+target".
    -In the relationship between Static2Mobile Operation and MobileCRS,
    the association end name "+target" (MobileCRS) should replace "+source".
    -The another directed association should added between MobileCRS and Mobile2Mobile Operation.
    (The direction is from Mobile2Mobile Operation to MobileCRS.)
    And the navigability notation(arrow head) and association end name(+source,+target)
    should be added to MobileCRS class side.
    -In Mobile2Static Operation class, derived attributes(+source,+target) should added.
    -In Static2Mobile Operation class, derived attributes(+source,+target) should added.
    -In Mobile2Mobile Operation class, attributes(+source,+target) should replace to
    derived attributes.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Fix Figure 4 according to the suggestions in the summary

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

Table 5 RelativeDatum class

  • Key: RLS-8
  • Legacy Issue Number: 12923
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -The last of Description is over in "Holds a RoLo Data that".
    Is there no sentence after that?

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Fix the description line by deleting the sentence in Table 5 beginning by "Holds a
    RoLo Data that".

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

The association end name should be added as follows

  • Key: RLS-6
  • Legacy Issue Number: 12921
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -rla : RoLo Architecture class side of association between RelativeDatum and RoLo Architecture.
    -base : RoLo Data class side of association between RelativeDatum and RoLo Data.
    -inStream : InStream class side of association between MobileDatum and inStream.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 12920 for disposition

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

The navigability notation(arrow head) should be added as follows

  • Key: RLS-5
  • Legacy Issue Number: 12920
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    -RoLo Architecture class side of association between RelativeDatum and RoLo Architecture.
    -RoLo Data class side of association between RelativeDatum and RoLo Data.
    -InStream class side of association between MobileDatum and inStream.

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Fix Figure 3 according to the suggestions. However, for the first item, it is better
    to make this an aggregation. For the second and third items on the associations
    RelativeDatum - RoLo Data and MobileDatum – InStream,it is better to make
    these relations as compositions.

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

add an explanatory note

  • Key: RLS-7
  • Legacy Issue Number: 12922
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    Because the following association is meanings to limit relations defined in superior,
    we should add an explanatory note.
    Relativedatum - ReletiveCRS
    RelativeCartesianCRS - SC_CertesianCS
    RelativePolarCRS - SC_PolarCS
    MobileCRS - MobileDatum
    MobileCartesianCRS - SC_CertesianCS
    MobilePolarCRS - SC_PolarCS

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Fix Figure 3 and relevant tables to show that these attributes derived from parent
    classes are restricted in these child classes.

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

Figure 3 - Relative and Mobile c oordinate reference system

  • Key: RLS-4
  • Legacy Issue Number: 12919
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    The association between Relativedatum and ReletiveCRS should be reverse.
    -In RelativeDatum class, attributes(rla,base) should replace to derived attributes.
    -In MobileDatum class, attributes(inStream) should replace to derived attributes

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Fix Figure 3 according to the suggestions. However, for the second and the third
    items, follow the resolution in issue 12920.

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

7.4.1 Common data format TypeI.Cartesian coordinate system

  • Key: RLS-15
  • Legacy Issue Number: 12932
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    In Table 69 - Common data format type I, the Unit of Orientation is "degree",
    but the explanation of Orientation is "The unit of this parameter is radians.".
    Which is correct?

  • Reported: RLS 1.0b1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13120 for disposition

  • 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 ( Mr. 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 ( Mr. 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

Multiplicity of Architecture::WeightedModel.weight

  • Key: RLS11-19
  • Legacy Issue Number: 16189
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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

Usage of Architecture::StaticRelativeCRS

  • Key: RLS11-20
  • Legacy Issue Number: 16190
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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

(C++-PSM) Methods shall better send return codes as exceptions

  • Key: RLS-90
  • Legacy Issue Number: 14014
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    As in most C++ implementations, it is better if methods will return
    the return codes (Returncode_t) as exceptions.

  • Reported: RLS 1.0b1 — Fri, 19 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    All the class methods (functions) in beta1 specification’s C++ PSM were
    returning Returncode_t value. Thus, the attributes marked as ‘out’ were handled
    as by-reference arguments that were normally implemented by pointer passing.
    Besides the C++ style pointed out in the summary, passing pointers are not a
    good manner for effective development. Thus, we will change C++ PSM
    definitions so that methods will use exceptions for passing return codes. The ‘out’
    attributes will be passed as return values whenever possible.

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

Tbl130,Tbl136) The 'setData' method in InStream class

  • Key: RLS-89
  • Legacy Issue Number: 14013
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Tbl130,Tbl136) The 'setData' method in InStream class may be used for 'PUSH' type data passing. However, it is quite common that input side streams can not process all the data received. In such case, some flow control mechanism is required. Such mechanism is required for practical use. This should be defined in the specification, not depending on the middleware's ability of flow control.

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Flow controls for ‘getData’ and ‘setData’ methods in RoLo streams originally
    assumed that flow control will be done by the underlying middleware. However,
    as pointed out in the summary, it will lead to middleware dependency which is
    not what we want. Thus, here we prepare some methods for controlling the flow.
    We add three methods, ‘activate’, ‘deactivate’ and ‘isActivated’ to OutStream
    class.

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

Subset specifications (Fig22)

  • Key: RLS-91
  • Legacy Issue Number: 14015
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The following associations shall be composition and shall have subset
    specification.
    RoLo Stream - Stream Ability
    RoLo Service - Service Ability

  • Reported: RLS 1.0b1 — Fri, 19 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    The RoLo abilities that RoLo streams and service instances hold shall be in an
    aggregation relation, not in a composition relation. This is because several
    instances of RoLo streams or services may share the same RoLo abilities. In
    order to clarify this, we modify the UML diagram to show this explicitly.

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

Tbl134) The behavior of setParameter method in RoLo Stream class is unclear

  • Key: RLS-87
  • Legacy Issue Number: 14011
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Tbl134) The behavior of setParameter method in RoLo Stream class is unclear. When this method is specified an unknown parameter, it shall return some error code. But which type of error code is returned is not described. Please clarify

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Clarify the behavior of ‘setParameter’ method by adding description

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

(Tbl135/Tbl136)

  • Key: RLS-86
  • Legacy Issue Number: 14009
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    (Tbl135/Tbl136) The 'connect' method for initiating service usage is defined for 'stream' classes. However, in most existing systems or languages, connection initiation is performed toward services, and not toward streams. This should be moved as a method for RoLo Service

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13439 for disposition

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

Parent class wrong for RelativeCRS

  • Key: RLS-92
  • Legacy Issue Number: 14016
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The parent class for RelativeCRS is described as SC_CRS but is
    actually SC_EngineeringCRS.

  • Reported: RLS 1.0b1 — Fri, 19 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Correct the error.

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

Tbl124) Specifying RoLo Attribute Singlevalue class as an enumeration

  • Key: RLS-84
  • Legacy Issue Number: 14007
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Tbl124) Specifying RoLo Attribute Singlevalue class as an enumeration is hard to implement for some programming languages. It also lack extendability for new data types. It is better to specify it as template class.

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13322 for disposition

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

Tbl119-Tbl129)

  • Key: RLS-83
  • Legacy Issue Number: 14006
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Tbl119-Tbl129) A set of class related to attribute/parameter/attribute definition is defined, but usage of these classes are not clear. For example, difference between 'parameter' ad 'attribute' is not clear, or how 'attribute definition' classes are related with 'attribute' classes is not clear. Please clarify. Also, there seems to be too many classes of simliar meanings.

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13322 for disposition

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

Tbl130) Two types of data passing mode specified in StreamType enumeration is not clear

  • Key: RLS-88
  • Legacy Issue Number: 14012
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    Tbl130) Two types of data passing mode specified in StreamType enumeration is not clear. It is currently defined to be relative to the stream in concern, but shall be defined by which side of data flow is holding the trigger for data passing.

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    As specified in the summary, PUSH/POP in StreamType enumeration is not clear.
    Here we alter the definition to make them clear.

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

7.6) RoLo service is described to have only one output stream, but this is sometimes too difficult to use

  • Key: RLS-85
  • Legacy Issue Number: 14008
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    7.6) RoLo service is described to have only one output stream, but this is sometimes too difficult to use. It should allow multiple output streams, such as those of server daemons, of the same nature.

  • Reported: RLS 1.0b1 — Thu, 18 Jun 2009 04:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13322 for disposition

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

posSpecRef in Error Element (Figure 9/Table 49)

  • Key: RLS-41
  • Legacy Issue Number: 13129
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:
    • posSpecRef in Error Element (Figure 9/Table 49) shall be a list of
      references to objects

    The attribute posSpecRef in Error Element class is now defined as a
    list of CharacterString, which is used as a reference to objects of
    Position Element class. This shall better be defined as a list of
    references.

  • Reported: RLS 1.0b1 — Mon, 1 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Currently, pointers that indicate which RoLo position element specifications are
    related to a RoLo error element specification are modeled to use ‘specID’
    attribute in RoLo element specifications. Instead, as described in the summary, it
    is much better to directly refer to the RoLo position element specification
    instances. Thus, modify 'posSpecRef' to be an ordered list of references to
    Position Element Specification instances and delete 'specID' attribute from RoLo
    Element Specification class.
    As RoLo Data Mapping Operation class depends on this, also modify
    DataMappingOperation class definition to use the new data structure.
    Additionally, some changes in C++ PSM are also required. Remove ‘specID’ from ElementSpecification class
    (RoLoArchitecture.hpp)
    – Change the definition of ‘posSpecRef’ class variable in
    ErrorElementSpecification class (RoLoArchitecture.hpp) as following:
    ::std::vector<PositionElementSpecification*> posSpecRef;
    – Change the name of ‘sourceIndex’ class variable in
    DataMappingOperation (RoLoDataOperation.hpp) as
    ‘sourceElemSpecs’
    – Change the name of ‘targetIndex’ class variable in
    DataMappingOperation (RoLoDataOperation.hpp) as ‘targetElemSpecs’
    – Change the definition of ‘sourceIndex’ and ‘targetIndex’ class variable in
    DataMappingOperation (RoLoDataOperation.hpp) as following:
    ::std::vector<ElementSpecification*> sourceElemSpecs,
    targetElemSpecs

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

Filter package for the Issue #12916

  • Key: RLS-40
  • Legacy Issue Number: 13122
  • Status: closed  
  • Source: Samsung Electronics ( Yeonho Kim)
  • Summary:

    Before making a decision of including the filter condition as a sub package, we

    have to decide whether the filter condition would be included in the main part or in the Annex part as an option.

    At the last meeting in Ottawa, we concluded that the issue of filter condition should be decided after reviewing more real-world examples. (refer robotics/2008-06-14)

    I suggest to discuss and decide this issue in December meeting.

    Dr. Noda, please show us those examples in December meeting for us to decide this issue.

  • Reported: RLS 1.0b1 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Closed; No Change — RLS 1.0
  • Disposition Summary:

    No Data Available

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

Angle unit representation

  • Key: RLS-35
  • Legacy Issue Number: 13117
  • Status: closed  
  • Source: Samsung Electronics ( Yeonho Kim)
  • Summary:

    In Section 6.4.1, the units of angle in Type I, II and II are not represented consistently .

    I suggest to represent the unit of angle for Type I,II with radian, for Type II with degree.

    All the parts of the document should be changed appropriately.

  • Reported: RLS 1.0b1 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Disposition: See issue 13120 for disposition

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

Change the class name of RoLo Architecture

  • Key: RLS-34
  • Legacy Issue Number: 13116
  • Status: closed  
  • Source: Samsung Electronics ( Yeonho Kim)
  • Summary:

    In the revised proposal, especially in Fig. 8 and 9, the class name of RoLo Architecture is confused with the name of RoLo architecutre that consists of the RoLo data specification and RoLo data.

    I suggest to substitute the class name of RoLo Architecture to RoLo Data Specification.

  • Reported: RLS 1.0b1 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Change the class name of RoLo Architecture to DataSpecification. However,
    when the expression ‘RoLo Architecture’ is used in a sentence to describe an
    object of this class, rewrite as ‘RoLo data specification’ instead of
    ‘DataSpecification’ to improve readability. Also change the names of attributes
    that are typed to this class from ‘rla’ to ‘dataSpec’. However, for the ‘rla’ attribute
    in RoLo Data class, change this to ‘spec’ so that the name will be consistent with
    other elements of RoLo architecture.

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

Name of Orientation

  • Key: RLS-38
  • Legacy Issue Number: 13120
  • Status: closed  
  • Source: Samsung Electronics ( Yeonho Kim)
  • Summary:

    In Table 69, 70, 41, the name of orientation (roll, pitch, yaw) is not relevant to the definition of the orientation that is described below each table.

    It would be better to be removed from the tables.

  • Reported: RLS 1.0b1 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Extend common data formats each have two different interpretations so that they
    can cover both of xyz-Euler's angle representation and roll-pitch-yaw
    representation of orientation (two orientation representations for each Cartesian,
    Polar, and Geodetic coordinate system). We thus have three common data
    formats (syntax) each with two different RoLo data specifications (semantics).
    We also add some figures in the specification to avoid misunderstanding or
    ambiguity regarding the definition of position and orientation for each common
    data format.
    Also, based on issue 13999, change the types for timestamps in the common
    data formats from a real number to two integers, which correspond to standard
    UNIX C structure, time_t. Normally, the first integer indicates the number of
    seconds elapsed from the epoch, and the second one indicates sub-seconds.
    The unit of sub-seconds is normally nano second that is compatible to most
    recent POSIX C time_t struct.

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

Name of Type II coordinate system

  • Key: RLS-37
  • Legacy Issue Number: 13119
  • Status: closed  
  • Source: Samsung Electronics ( Yeonho Kim)
  • Summary:

    The name of Type II, polar coordination is typically defined as a two dimensional coordinate system.

    The coordinate system would be better to be called as spherical coordinated system that is the three dimensioinal extension of the polar coordinate system

  • Reported: RLS 1.0b1 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Disposition: See issue 13120 for disposition

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

The union of a documents

  • Key: RLS-33
  • Legacy Issue Number: 13115
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    The RLS Specification FTF Beta1(dtc/2008-07-01) includes Sample C++ Headers(Annex A).
    I think that the C++ Header is PSM model, so we should include it in the specification
    as 8.1 C++ PSM

  • Reported: RLS 1.0b1 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Include PSM in the specification as section 8.1.

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

RoLo Attribute Definition Set definition typo

  • Key: RLS-32
  • Legacy Issue Number: 13114
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The 'attribute attribute in RoLo Attribute Definitino Set class
    definition (Table 121) is inconsistent with the UML diagram (Figure
    21). This shall be defined as 'O' (optional), not 'M' (mandatory).

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    No Data Available

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

Typo in 6.3.4 Robotic Localization Architecture

  • Key: RLS-30
  • Legacy Issue Number: 13112
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    tino
    The following sentence in the thrid paragraph of 6.3.4 is wrong:
    In such case, the Error Element Specification (derived from RoLo
    Element class) ...

    This shall be as following:
    In such case, the Error Element Specification (derived from RoLo
    Element Specification class) ...

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    This issue is actually about 7.3.4, not 6.3.4.
    Correct the erratum in Section 7.3.4 of RLS Specification Beta1 (robotics/08-07-
    01). Note that the section number #6.3.4 in this issue is based on the previous
    version of RLS Specification (robotics/08-05-02).

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

Missing 'public:' declaration in PSM RelativeDatum definition

  • Key: RLS-42
  • Legacy Issue Number: 13131
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    'public:' is missing in RelativeDatum class definition in
    RelativeCRS.hpp (PSM C++ header).

  • Reported: RLS 1.0b1 — Mon, 1 Dec 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Correct typo as described in the summary.

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

Typo in Position Element Operation class description

  • Key: RLS-31
  • Legacy Issue Number: 13113
  • Status: closed  
  • Source: JARA ( Shuichi Nishio)
  • Summary:

    The description for Position Element Operation class definition (Table
    56), 'RoLo Elements' (twice) shall be replaced to 'Position Elements'.

  • Reported: RLS 1.0b1 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Correct the errata

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

Posistion description in Type II

  • Key: RLS-36
  • Legacy Issue Number: 13118
  • Status: closed  
  • Source: Samsung Electronics ( Yeonho Kim)
  • Summary:

    The desrciption of position in Table 70 is not commonly used.

    Following the ISO 31-11, the description of the position of type II in Table 70 would be better to be [r, ?, f].

  • Reported: RLS 1.0b1 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    Disposition: See issue 13119 for disposition

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

Definition of orientation in Type I, II, III

  • Key: RLS-39
  • Legacy Issue Number: 13121
  • Status: closed  
  • Source: Samsung Electronics ( Yeonho Kim)
  • Summary:

    For the Type I, II, II, he definition of the orientation is ambiguous.

    More precise definition for the orientation is required (with figures if needed)

  • Reported: RLS 1.0b1 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — RLS 1.0
  • Disposition Summary:

    See issue 13120 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

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

Representation of identity coordinate axis

  • Key: RLS11-10
  • Legacy Issue Number: 16178
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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

Relation between Architecture::MobileDatum and Architecture::InStream

  • Key: RLS11-7
  • Legacy Issue Number: 16175
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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 ( Mr. 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 ( Mr. 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

Parent class of Architecture::MobileOperation

  • Key: RLS11-8
  • Legacy Issue Number: 16176
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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

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

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

Axis definition for polar coordinate system

  • Key: RLS11-18
  • Legacy Issue Number: 16187
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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

Operation for Architecture::SymbolicIdentityCRS

  • Key: RLS11-14
  • Legacy Issue Number: 16183
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. 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 ( Mr. 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

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

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