Changes to Deckplan wanted bei Ulf

[ue71603]

xsd/netex_framework/netex_reusableComponents/netex_spotEquipment_version.xsd
I lack (optional) attributes/elements indicating the relative position in meters in the X and Y direction compared with the enclosing PASSENGER SPACE left bottom corner when the PASSENGER SPACE is viewed straight from above assuming its normal direction of travel is straight to the left. X is then the distance to the right and Y is the distance upwards. (I note that the Z direction is already handled with the HeightFromFloor.)

xsd/netex_framework/netex_reusableComponents/netex_seatingPlan_version.xsd
I lack (optional) attributes/elements indicating the relative position in meters in the X and Y direction compared with the enclosing DECKs left bottom corner when the DECK is viewed straight from above assuming its normal direction of travel is straight to the left. X is then the distance to the right and Y is the distance upwards.

xsd/netex_framework/netex_reusableComponents/netex_deckPlan_version.xsd
As a DeckEntrance can be referred to from two DeckSpaces I think it should be possible to (also) define them (but not refer them) at DECK level (i.e. in DeckGroup) and not only inside a certain DeckSpace. That means a profile could then require them to be defined at DECK level and forbid that they are defined inside a DeckSpace. Thus always using references (e.g. DeckEntranceRef) inside DeskSpaces.

xsd/netex_framework/netex_reusableComponents/netex_deckPlan_version.xsd

deckEntranceCouples should not be allowed to be defined within a certain DeckSpace as it always refers to two deckEntrances on the same DECK. Instead it should be defined on DECK level. Thus move deckEntranceCouples from DescSpaceEntranceGroup to DeckGroup

[nick-knowles]

Current TRansmodel suggestion is
(a) Revise definition of ZONE to be just an abstract 2d space of any coordinate system
(b) Rename EQUIPABLE SPACE to ONBOARD SPACE (sp that PASSENGER SPACE, SPOT etc have coordinates)
(c) Make both DECK and ONBOARD SPACE as subclasses of ZONE (ie 2d space)
(d) Use DECK ZONE as boynding box for ONBOARD SPACE components

(c) Rename TRAIN STOP ASSIGNMENT to BOARDING POSITION STOP ASSIGNMENT (Will have to keep TrainStopAssignment in netex as deprecated alias)
Q, DECKSs can overlap What happens if an ONBOARD SPACE is on more than one deck eack with a different coordinate bounding box (Poss use ZONE PROJECTION and COMPLEX FEATURES?)
Q2 SHould we also add a height to ONBOARD SPACE so that all spaces have heights
Q4 In TRANSMODEL it makes sense to merge DECK ASSIGNMENT with BOARDING POSITION ASSIGNMENT (formerly TRAIN STOP ASSIGNMENT) and DECK ENTRANCE ASSIGNMENT into a single package (Moving PASSENGER STOP ASSIGNMENT to Part3 since it now depends on SERVICE JOURNEY) . SHoudl we do the same in NeTEx?

[nick-knowles]

You are quite right, there is a gap here as to how to specify the precise location of equipment within an ONBOARD SPACE

1. DECK SPACEs, PASSENGER SPACE, LOCATABLE SPOT etc are all descendants of ONBOARD SPACE which in turn is a specialisation of ZONE , so may be given a bounding polygon and a centroid in coordinates relative to the DECK.

---

2. EQUIPMENT can currently be associated with various deck components, indicating that it is colocated with the component, but precise relative coordinates within the deck component cannot be given

---

3. In the analogous SITE mode, Equipment can be exactly located with an EQUIPMENT PLACE and EQUIPMENT POSITION elements.

---

Solution
We could add a link between ONBOARD SPACE and EQUIPMENT PLACE to allow a precise statement of position in relative coordinates (rQ. elative to the DECK or the parent space?). This is preferable to placing a coordinate on EQUIPMENT (which would mix concerns)