| Re: Feedback from 1st railML 3.1 Workshop 09./10.01.2018 - spot locations [message #1876 is a reply to message #1701] |
Thu, 12 July 2018 17:03  |
Airy Magnien
Messages: 18
Registered: September 2016
|
Junior Member |
|
|
Two questions, two answers:
A1: Indeed, under RTM 1.1, a SpotLocation is related to exactly one positioning system coordinate instance. Not sure there is a "reason" for that, as it is definitely possible to use, concurrently, several positioning systems:
Any given Located Net Entity can reference an unlimited number of entity locations. Let us assume some Entity would be indeed be located, physically, at a certain spot. It is possible to instantiate several SpotLocationCoordinate objects characterizing this physical spot, each one related to a coordinate itself related to another positioning system. In other words, if n positioning systems are of interest and if there are m "spotlike" entities to locate, you could instantiate (m*n) SpotLocationCoordinate objects to fulfil your needs.
The obvious drawback is, it seems uneconomical to instatiate n*m spot location objects when m such objects could do the job. Not sure this would be a real problem, though.
Semantically, the "solution" above is not very clean: if the net entity is associated with several spot locations, nothing tells whether these locations are intended to be coincident. Odds are, when using coordinates from different positioning systems, that they will never coincide exactly (mathematically). This could create an ambiguity, especially if precision and tolerances are not managed.
A possible improvement would consist in sub-classing (or not, to be discussed) SpotLocationCoordinate for holding 1..* references to positioning system coordinates. The implicit rule would be that each coordinate must be associated with a different positioning system, lest a redundance (or, worse, an inconsistency) would appear; for the time being we do not include OCL rules in our modeling, so the constraint should simply be documented in a note, and its enforcement would be user (or developer) responsibility.
A2: Answer 1 above suggests that we are favourably inclined.
|
|
|
|
Members
Search
Help
Login
Home
