OpenLR Linear Extension
The association from "OpenlrLineLocationReference" to the "OpenlrOffsets" class has no multiplicity defined. I assume this is intended to be [1]. The definitions of the "openlrPositiveOffset" (POFF) and "openlrNegativeOffset" (NOFF) need to be more explicit to clarify their use.
The reuse of the "OffsetDistance" class implies that the reference points are Alert-C points as specified in the definitions of the class and its attributes. But this referencing method is not limited to Alert-C mapped networks and there are no Alert-C reference points used in this sub-model. Hence this class should not be reused here, even though in practice the reference points may well be Alert-C points.
The composition of "openlrLocationReferencePoints" should be ordered by use of an “indexed” qualifier construct.
OpenLR Point Extension
The note states that the container class "OpenlrPointLocationReference" has to have at least one of the associated classes (a GeoCoordinate, a Poi or a PointAlongLine). But the model allows more than one to be present, potentially each with different coordinate sets. So what would be the location of the point in that case? The note should say that only one point type must be present.
I assume that the "OpenlrPointAlongLine" class is for defining a point along a linear “line” which is a road or route as defined in the Linear sub-model extension. But I don’t see how you know which line it is since all you know are the coordinates and line attributes of the last point on the line and the coordinates, path attributes and line attributes of the point itself. Should it not make a reference to an instance of the "OpenlrLineLocationReference" class. Also why is the "OpenlrPointAlongLine" class not used in the Linear sub-model extension?
The reuse of the "OffsetDistance" class as a composition of the "OpenlrPointAlongLine" class is unclear. Again as this class refers to Alert-C reference points which do not exist in this sub-model its reuse is inappropriate. Also it is not specified whether the offset is referring to the "OpenlrLastlocationreferencePoint" or the "OpenlrLocationReferencePoint", hence is it a POFF or a NOFF? It could be applied to either or both from the way it is modelled.
The "OpenlrPoiWithAccessPoint" seems to be very confusing regarding what are the point coordinates. The definition of the class "OpenlrPoiWithAccessPoint" implies there are two points being defined, one for the POI itself and one for the access point from the road network. It has a direct association to the "PointCoordinates" class which I assume defines the actual location of the POI, but this is not explicitly stated in the role. It also can inherit coordinates via it being a specialisation of the "OpenlrPointAlongLine" class which can add another two pairs of coordinates (assuming multiplicities of [1] on the compositions – need specifying), one pair for the end of the line and another pair for, I assume, the “access point” from the road network. If this is correct it needs to be explicitly defined. However, I think the specialisation from the "OpenlrPointAlongLine" is wrong. It should be an association to define that a POI which maybe off network can have an optional access point which is on the road network defined by the "OpenlrPointAlongLine" class.
The definition of the "OpenlrLocationReferencePoint" class is incomplete. “.....All fields are ??”
enumeration - OpenlrFormOfWay
I know this is what is in the OpenLR specs, so this is more a comment on the specifications than how it has been modelled here.
This list of values seems rather limited. What about tunnel sections, elevated sections, underpasses, service roads, distinction between feeder and exit slips etc. Also why is “motorway” in this enumeration. It is really a definition of the road class and should therefore be in the "OpenlrFunctionalRoadClassEnum", probably defined as equivalent to FRC0.
datatype - AngleInDegreesRestrictedRange
I think the restriction of this data type to angles of between 0 -359 (by use of the facets tag) is what should have been used in the level A model for the "AngleInDegrees" class. That would be in accordance with its definition. Hence there would be no need to define a new data type here. This should be a requested modification to the level A model prior to final standardisation approval.
General comment
All target multiplicities should be explicitly defined as [1]
The naming of the following three classes relating to points is confusing: "OpenlrPointLocationReference", "OpenlrLocationReferencePoint", "OpenlrBaseLocationReferencePoint".
Note that the definition of the "OpenlrBaseLocationReferencePoint" says that it is “A last location reference point …..”. What is it? A last location or a base location?
Text starting with JJ means a replay
OpenLR Linear Extension
The association from "OpenlrLineLocationReference" to the "OpenlrOffsets" class has no multiplicity defined. I assume this is intended to be [1].
It should be 0..1
The definitions of the "openlrPositiveOffset" (POFF) and "openlrNegativeOffset" (NOFF) need to be more explicit to clarify their use.
JJ Updated definitions, but see also the OpenlrOffsets class definition.
The reuse of the "OffsetDistance" class implies that the reference points are Alert-C points as specified in the definitions of the class and its attributes. But this referencing method is not limited to Alert-C mapped networks and there are no Alert-C reference points used in this sub-model. Hence this class should not be reused here, even though in practice the reference points may well be Alert-C points.
JJ Agree, removed OffsetsDistance. Moved those to the OpenLROffsets class.
The composition of "openlrLocationReferencePoints" should be ordered by use of an “indexed” qualifier construct.
JJ It could, but I am not sure that it is needed.
OpenLR Point Extension
The note states that the container class "OpenlrPointLocationReference" has to have at least one of the associated classes (a GeoCoordinate, a Poi or a PointAlongLine). But the model allows more than one to be present, potentially each with different coordinate sets. So what would be the location of the point in that case? The note should say that only one point type must be present.
JJ OK, agree.
I assume that the "OpenlrPointAlongLine" class is for defining a point along a linear “line” which is a road or route as defined in the Linear sub-model extension. But I don’t see how you know which line it is since all you know are the coordinates and line attributes of the last point on the line and the coordinates, path attributes and line attributes of the point itself. Should it not make a reference to an instance of the "OpenlrLineLocationReference" class. Also why is the "OpenlrPointAlongLine" class not used in the Linear sub-model extension?
JJ I assume the whole pint with OpenLR is that you do not exchange ID to locations. From the data supplied you should be able to find the ID e.g. of a link in your own database.
The reuse of the "OffsetDistance" class as a composition of the "OpenlrPointAlongLine" class is unclear. Again as this class refers to Alert-C reference points which do not exist in this sub-model its reuse is inappropriate. Also it is not specified whether the offset is referring to the "OpenlrLastlocationreferencePoint" or the "OpenlrLocationReferencePoint", hence is it a POFF or a NOFF? It could be applied to either or both from the way it is modelled.
JJ Agree, used the OpenLROffsets instead which also more correct according to the OpenLR spec.
The "OpenlrPoiWithAccessPoint" seems to be very confusing regarding what are the point coordinates. The definition of the class "OpenlrPoiWithAccessPoint" implies there are two points being defined, one for the POI itself and one for the access point from the road network. It has a direct association to the "PointCoordinates" class which I assume defines the actual location of the POI, but this is not explicitly stated in the role.
JJ Added and updated definitions
It also can inherit coordinates via it being a specialisation of the "OpenlrPointAlongLine" class which can add another two pairs of coordinates (assuming multiplicities of [1] on the compositions – need specifying),
JJ Updated multiplicities
one pair for the end of the line and another pair for, I assume, the “access point” from the road network. If this is correct it needs to be explicitly defined. However, I think the specialisation from the "OpenlrPointAlongLine" is wrong.
It should be an association to define that a POI which maybe off network can have an optional access point which is on the road network defined by the "OpenlrPointAlongLine" class.
JJ Agree, but not optional.. But, I am not sure. The OpenLR spec does not have this relation instead it repeats all OpenlrPointAlongLine in the PoiWithAccessPoint. I added the specialization because it had the same content. But, a better solution may be to put the common stuff in a seperate base class.
The definition of the "OpenlrLocationReferencePoint" class is incomplete. “.....All fields are ??”
JJ Updated
enumeration - OpenlrFormOfWay
I know this is what is in the OpenLR specs, so this is more a comment on the specifications than how it has been modelled here.
This list of values seems rather limited. What about tunnel sections, elevated sections, underpasses, service roads, distinction between feeder and exit slips etc. Also why is “motorway” in this enumeration. It is really a definition of the road class and should therefore be in the "OpenlrFunctionalRoadClassEnum", probably defined as equivalent to FRC0.
datatype - AngleInDegreesRestrictedRange
I think the restriction of this data type to angles of between 0 -359 (by use of the facets tag) is what should have been used in the level A model for the "AngleInDegrees" class. That would be in accordance with its definition. Hence there would be no need to define a new data type here. This should be a requested modification to the level A model prior to final standardisation approval.
JJ Agree, that is why we created a new datatype.
General comment
All target multiplicities should be explicitly defined as [1]
JJ Done
The naming of the following three classes relating to points is confusing: "OpenlrPointLocationReference", "OpenlrLocationReferencePoint", "OpenlrBaseLocationReferencePoint".
JJ Restructed the model and added a class OpenlrLastLocationReferencePoint.
Note that the definition of the "OpenlrBaseLocationReferencePoint" says that it is “A last location reference point …..”. What is it? A last location or a base location?
JJ Updated definition.
JJ new version to be released