Data Element for undecorated object id
Closed this issue · 18 comments
In some EU countries (Germany, Austria, Switzerland, UK to name a few) national standards for global identifiers of stops and other important objects existed before the arrival of the EPIP standard. These existing identifiers are used to build the EPIP conformant NeTEx IDs:
For instance Salzburg Hauptbahnhof has national ID at:45:50002, where at is for Austria, 45 is for Oberösterreich (federal state) and 50002 is the local stop number within Oberösterreich. In NeTEx, Salzburg Hauptbahnhof looks like this
The national ID goes into the EPIP technical identifier, but it needs to be transformed to make it EPIP compliant - the ":" need to be replaced by "-" and the at: has to be removed and moved to the front of the EPIP id. Also "svv" as responsible authority is added.
However, all technical systems use the national ID in its original form and they would have to somehow interpret the EPIP id to determine the national ID when importing data. As a workaround, the original national ID is now stored in keyList/keyValue/Key.
The German VDV workgroup proposes to add a dedicated field "technical identifier" or "global id" containing the unmodified id to all NeTEx objects (or at least the relevant ones).
Personally I would prefer this GlobalId to be the identifier of the Quay or StopPlace, regardless of the suggestion to use a specific format. But one could argue: why not use the PrivateCode having the full GlobalId with the type GlobalId. The next version of NeTEx will support multiple privatecodes per element.
In VDV 462, the private code is used to transfer the widely used VDV 452 key fields, so this is already used. Introduction of further private codes might solve the problem, but that would be quite similar to the use of keyList
In VDV 462, the private code is used to transfer the widely used VDV 452 key fields, so this is already used. Introduction of further private codes might solve the problem, but that would be quite similar to the use of keyList
In your VDV 462 example the type in PrivateCode is missing.
Discussed again at VDV group meeting 10.07.2023:
There are already elements
- ExternalLineRef
- ExternalVehicleJourneyRef
- ExternalStopPointRef
- ExternalOperatorRef
- ExternalInterchangeRef
If we could have
- ExternalStopPlaceRef
- ExternalQuayRef
that would nicely solve the problem for us. We would like to raise this request at the next meeting.
So I don't know if requesting a relationship to an external system is the right way, if that could be considered legacy.
It is not "legacy" at all - on the contrary, AVM systems have been extended recently to support "global" IDs for certain well-known objects such as LINE and STOP.
The description of the NeTEx element points to the purpose. We use the "private code" elements to transport the VDV 452 object identifiers which are truly legacy. Their scope is usually much smaller.
So what would ExternalStopPlaceRef and ExternalQuayRef refer to then? Why not load the NeTEx IDs in the AVLs?
To be back to the original question, if you have a national ID that is unique an stable, please use it as if and don't follow that EPIP rule !
This rule is ONLY designed to ensure uniqueness and stability when it is not managed elsewhere (typically for specific data from an operator to avoid colliding id's of another operator). If you have any other system guaranteeing uniqueness and stability , that's fully fine: use it !
If you have a national system, you may just add something "GE:" prefix in case it was not anticipated, to avoid colliding IDs of other countries (I think that for NaPTAN, UK adds a "napt:" prefix... see NeTEx examples).
Christophe, this is an important statement. It would be good to have this in a future version of the EPIP document. However, we already have existing implementations (Austria and Northern Italy), where we use the EPIP rule for building NeTEx element IDs, and changing the NeTEx IDs back to the national identifiers will raise new issues. Therefore I will keep open my request for
elements ExternalStopPlaceRef and ExternalQuayRef.
@skinkie as to why not load the NeTEx IDs into the AVLs: This is what they plan to do in Italy. In Germany, this would break existing data chains between systems and would be difficult to coordinate between vendors and customers.
It would be good to have this in a future version of the EPIP document.
@duexw there is an EPIP action for this planed in the revision, if I remember well
We would recommend something like this
Id=«at:svv:StopPlace:50002» or Id=«at:45:StopPlace:50002»
svv / 45 are the source in Austria, as I understand svv is the source, so the first one should be correct.
Oberösterreich should be an attribute, not part of the id.
In Norway, we didn't have a national ID, so we made a new id structure based on
NSR:StopPlace:1+1, and we should have added a country code. (NSR:NationalStopRegistery)
After we introduced the new national IDs there has been changes in the administrative regions, merging and splitting, and that's fine for us, since it's not part of the IDs. It used to be before and that made a lot of mess.
I would agree with Brede. The StopPlace word has been added to prevent id-collisions for naive systems. But in NeTEx may technically be omitted, since the id-space is unique per object type to start with.
@BredeD the rule is really only to CREATE the ID, and not to update it ... a stable ID cannot obviously be changed
Therefore, even if any of the component used to create the ID is changed, the ID must not be changed ... Also nobody should ever read the content of an ID to get some semantic from it: an ID has no semantic, and all semantic has to be read from attributes (so you are perfectly true when you say Oberösterreich should (must) be an attribute .. but we don't really care if it is also used inside the Id, provided that the ID is unique and stable)
Austria should add the new id "Id=«at:svv:StopPlace:50002" to svv master system, so users could use both the existing "at:45:50002" and merge towards Id=«at:svv:StopPlace:50002". If needed have "at:45:50002" as KeyValue, but they may have come too far in implementation, and need to stick with «at:svv:StopPlace:at-45-50002".
For other countries coming after we should give them my advice.
Yes, this is all correct. The pre-existing global stop it is at:45:50002, and it will not even be changed in the unlikely case that the borders of the federal states are reorganised. The problem is much simpler: Many pre-existing systems use this id already for identifying stops across systems, and it is difficult to relate from at:45:50002 to at:svv:StopPlace:45-50002
@ue71603 will revamp it to make it clearer that it is now a documentation for PrivateCode.
I added an issue to EPIP. NeTEx-CEN/NeTEx-Profile-EPIP#19
PR with better docu made.
Closing here.
To be documented in EPIP with with NeTEx-CEN/NeTEx-Profile-EPIP#19