Robotic Localization Service Avatar
  1. OMG Specification

Robotic Localization Service — Closed Issues

  • Acronym: RLS
  • Issues Count: 95
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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-94 Separate XMI definition from RLS specification document. RLS 1.0b1 RLS 1.0 Resolved closed
RLS-93 Figure 6 - Error Type RLS 1.0b1 RLS 1.0 Resolved closed
RLS-92 Parent class wrong for RelativeCRS RLS 1.0b1 RLS 1.0 Resolved closed
RLS-91 Subset specifications (Fig22) RLS 1.0b1 RLS 1.0 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-88 Tbl130) Two types of data passing mode specified in StreamType enumeration is not clear 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-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-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-82 (Fig7) Matrix class is specified as "DataType" but this is unnecessary 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-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-78 (7.5) In the filter condition section RLS 1.0b1 RLS 1.0 Resolved 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-75 RLS - typos 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-72 Inconsistency in class names RLS 1.0b1 RLS 1.0 Closed; No Change 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-69 Structural change for RoLo Service class 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-66 'inStream' attribute in MobileDatum class shall be an object 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-63 Overview in 6.3 Background needs to be modified 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-60 Some organization missing in "6.1 Supporting Organizations" 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-57 Some references are missing 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-54 Association between RoLo Parameter Set and RoLo Parameter Definition (Figure 21) RLS 1.0b1 RLS 1.0 Closed; No Change 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-51 Typo in Table 22 (RoLo SymbolRef) 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-48 XML mapping of RoLo Data and RoLo Element RLS 1.0b1 RLS 1.0 Resolved 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-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-42 Missing 'public:' declaration in PSM RelativeDatum definition 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-39 Definition of orientation in Type I, II, III 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-36 Posistion description in Type II RLS 1.0b1 RLS 1.0 Resolved 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-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-31 Typo in Position Element Operation class description 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-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-27 Possible inconsistency between RoLo Data class attributes RLS 1.0b1 RLS 1.0 Resolved closed
RLS-26 SymbolicCS/CRS name is confusing RLS 1.0b1 RLS 1.0 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-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-18 Figure 22 - RoLo Service 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-15 7.4.1 Common data format TypeI.Cartesian coordinate system 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-12 Figure 9 - RoLo Architecture 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-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-7 add an explanatory note 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-4 Figure 3 - Relative and Mobile c oordinate reference system 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

Issues Descriptions

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

Separate XMI definition from RLS specification document.

  • Key: RLS-94
  • Legacy Issue Number: 12918
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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

Figure 6 - Error Type

  • Key: RLS-93
  • Legacy Issue Number: 12927
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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

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

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

(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

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

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

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

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

(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

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

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

(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

(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

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

Missing references

  • Key: RLS-74
  • Legacy Issue Number: 13451
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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

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

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

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

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

'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

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

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

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

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

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

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

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

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

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

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

XML mapping of RoLo Data and RoLo Element

  • Key: RLS-48
  • Legacy Issue Number: 13186
  • Status: closed  
  • Source: AIST ( 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

Hierarchy of Error can be reduced

  • Key: RLS-47
  • Legacy Issue Number: 13185
  • Status: closed  
  • Source: AIST ( 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 ( 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

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

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

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

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

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

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

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

The union of a documents

  • Key: RLS-33
  • Legacy Issue Number: 13115
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 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

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

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

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

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

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

Table 134 - RoLo Stream class

  • Key: RLS-21
  • Legacy Issue Number: 12938
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 ( 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 ( 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

Figure 22 - RoLo Service

  • Key: RLS-18
  • Legacy Issue Number: 12935
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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

Figure 21 - RoLo Ability and RoLo Parameter Set

  • Key: RLS-17
  • Legacy Issue Number: 12934
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 ( 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

7.4.1 Common data format TypeI.Cartesian coordinate system

  • Key: RLS-15
  • Legacy Issue Number: 12932
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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

Figure 11 - RoLo Data format

  • Key: RLS-14
  • Legacy Issue Number: 12931
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 ( 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 9 - RoLo Architecture

  • Key: RLS-12
  • Legacy Issue Number: 12929
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 7 - Error information

  • Key: RLS-11
  • Legacy Issue Number: 12928
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 ( 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 4 - Mobile CRS operations

  • Key: RLS-9
  • Legacy Issue Number: 12924
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 ( 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

add an explanatory note

  • Key: RLS-7
  • Legacy Issue Number: 12922
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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

The association end name should be added as follows

  • Key: RLS-6
  • Legacy Issue Number: 12921
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 ( 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

Figure 3 - Relative and Mobile c oordinate reference system

  • Key: RLS-4
  • Legacy Issue Number: 12919
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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

Sequence diagrams should be added

  • Key: RLS-3
  • Legacy Issue Number: 12917
  • Status: closed  
  • Source: Shibaura Institute of Technology ( 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 ( 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