Too generic type for stop places in SiteFrame
Closed this issue · 11 comments
The pull request introducing new modes (147c902)
modified the type of stop places in a site frame fromStopPlaceto the more generic StopPlace_ :
where:
<xsd:element ref="StopPlace" maxOccurs="unbounded"/>
became:
<xsd:element ref="StopPlace_" maxOccurs="unbounded"/>
As a result, type checking is relaxed and it is now possible to refer to other types in SiteFrame/stopPlaces, such as:
<SiteFrame>
<stopPlaces>
<Parking/>
<PointOfInterest/>
</stopPlaces>
</SiteFrame>
These types have their own containers (<parkings>, <pointOfInterests>, ...) and should not be mixed with <stopPlaces>
We believe that this change was not intended and should be reverted.
If I remember well, the triggering point here was that "New Modes" (vehicle pooling, vehicle sharing, etc.) sometimes need to define Stop Places (carpooling lines for example) that can then be Parkings, Car Pooling Areas or POIs ... but also Taxi Ranks (not for new modes, but some replacement lines, or some on demand services).
But I agree that in the SiteFrame that is not relevant since we already have , , ... and since stopPlacesInFrame_RelStructure is only used in SiteFrame, we should be able to revert this safely ...
@nick-knowles @ue71603 do you see any side effect from your current usages (accessibility or new modes) ?
The change would fail https://github.com/NeTEx-CEN/NeTEx/blob/master/examples/functions/newModes/NewModes-CarPoolingExample.xml#L265
@Aurige is there any taxiRankInFrame forseen?
not that I know !
I looked around, and I can't find a really easy solution (we are facing XLM inheritance limitation here: the inheritance linked between StopPlace and TaxiRank was initially designed to solve this, but for some reason it does not)
Adding a taxiRankInFrame would work, or allow StopPlaces and TaxiRank in stopPlacesInFrame_RelStructure (100% backward compatible and follows the initial intention) ... but that will only solve that case, and will not cover the generic VehicleMeeting Place .... we could add an xxxInFrame dedicated to _StopPlace, but it will overlap StopPlaceInFrame
Nothing I prefer to the current implementation in all these workarounds
Lets discuss the 'why' first. Why are StopPlaces made generic to facilitate TaxiRank, is TaxiRank in Transmodel to be considered a StopPlace?
As explained above, it is not only TaxiRank : for new modes, a lot of Sites can be stop places (car pooling areas, parking areas, any VehicleMeetingPoint in fact).
Again, are they modelled in Transmodel in the same way?
I have a problem there:
-
Sharing is related to SITE not STOP PLACE also PARKING is more SITE than STOP PLACE
-
VEHICLE MEETING POINT is NOT related to STOP PLACE but to POINT
-
TAXI RANK is a STOP PLACE according to the definition.
But otherwise it has zero other connections in the model.
The modelling of TAXI SERVICE PLACE ASSIGNMENT then would be wrong, because the equivalent in STOP PLACE can be assigned to a QUAY or STOP PLACE (TAXI RANK). Here it is only to the TAXI STAND
VEHICLE POOLING is then modeled differently, even when TAXI SERVICE is a specialisation of a POOLIING SERVICE:
Also, in VEHICLE POOLING there are services with very clearly defined stops as you pointed out to me Christophe in an email earlier this week.
- Using STOP PLACE would not account for the dynamic versions of sharing and pooiling
Even when a STOP PLACE is a SITE, the opposite is not true.
Yes yes, I know ... no issue on the modelling side ! The question is only about explicit Frames and where to put the corresponding data.
Up to now, all stops, pick-up and drop-off locations are available from the SiteFrame, under the tag ... it could (should?) have been different, but that's the way it currently is.
The proposed revert will result in the fact that there is no more explicit Frame to host these objects... so we need to find a better way !