Clarification required: Identification of multiple StopPlace versions within the same PublicationDelivery

[FlourishingData]

The Swiss NeTEx profile recommends using a stable master identifier (e.g. SLOID) in the StopPlace.id, but does not make this mandatory.
When publishing multiple temporal versions of the same logical StopPlace within a single PublicationDelivery, it is unclear how the identifier should be handled.

If the SLOID is used as the StopPlace.id, all temporal versions would share the same identifier. This raises the question of how multiple versions of the same logical StopPlace should be distinguished within a single publication. Would it be preferable to use a unique Netex id for each published StopPlace version and keep the SLOID as the stable business identifier in privateCodes ?

Example:

<StopPlace id="ch:1:StopPlace:PAG:72203:1" version="1">
        <privateCodes>
              <PrivateCode type="SLOID">ch:1:sloid:72203</PrivateCode>
        </privateCodes>
</StopPlace>

<StopPlace id="ch:1:StopPlace:PAG:72203:2" version="1">
        <privateCodes>
              <PrivateCode type="SLOID">ch:1:sloid:72203</PrivateCode>
        </privateCodes>
</StopPlace>

as far as I understood, the version attribute must be set to "1"

[ue71603]

@FlourishingData the StopPlace are not logical, they are the Haltestellen from Atlas, the Quay are the Haltekanten. So they don't exist as multiple copies. The timetable logical side is done by the ScheduledStopPoints.

What do you mean by temporal versions? Perhaps this helps to clarify it.

[FlourishingData]

@ue71603 SLOID, SLNID and other SwissIdentifiers are versioned, meaning that for the same identifier multiple versions exist.

Example

ch:1:sloid:x (version 1)
  |-- geolocation xyz1

ch:1:sloid:x (version 2)
  |-- geolocation xyz2

The change in version is, based on my understanding, not limited by the timetable change in december. So I would need to reflect the different versions for the same SLOID or SLNID in a publicationDelivery.

How do I do that when the attribute version="1" is fixed?

In my example i solved this by giving the StopPlace and ID which is not the SLOID itself.

[ue71603]

@FlourishingData
I agree that in reality the StopPlace are versioned in Atlas. They are not in HRDF and therefore not in NeTEx. If you really need this, then we can talk about using the version for that. However, in such cases, the StopPlaceRef must have always the right version. Meaning you need to ScheduledStopPoints and two ServiceJourneyPattern.

I think currently NeTEx is flattened in the way, that for the file there is one StopPlace and it has version="1". Otherwise the whole processing chain would need to be adapted.

If you can construct a problematic case, then may soften the usage of version.

[FlourishingData]

If the SLOID is the primary identifier of the StopPlace, I wonder whether we still need to replicate the StopPlace master-data attributes in NeTEx at all.

As I understand it, the authoritative source for StopPlace data is Atlas. If every StopPlace can be uniquely identified through its SLOID, consumers could resolve the current attributes (name, location, accessibility characteristics, etc.) directly from Atlas. Surely some consumers cannot fetch data from Atlas. Why not append all these information, when sending it to "Info+"?

This would avoid having the same information maintained in two places (producer of NeTEx & atlas) and reduce the risk of inconsistencies. Would this be a valid architectural direction, or is there a requirement that a NeTEx PublicationDelivery must be self-contained (including all necessary informations) from each producer and therefore always include the full StopPlace description, location etc. even when a stable SLOID reference exists?

The reason why I introduced versioning is that Atlas versions are not tied to a timetable year. Changes can happen at any point in time and should be reflected accordingly. An example is accessibility improvements. If a StopPlace becomes wheelchair accessible, we would certainly want that information to be available (in the future). From my perspective, this means that multiple versions of the same SLOID may legitimately exist over time, independent of timetable planning.

This brings me back to the question: how should such changes be represented in NeTEx if version="1" is fixed and the SLOID is used directly as the StopPlace.id?

[ue71603]

In the NETWORK_OFFER(s) for PAG you send, you wont' have to do uch of those things.

You only need to provide the ScheduledStopPoints. The StopPlace/Quay/SiteConndection/DefaultConnection will be taken from Atlas (in the things you send to INFO+).
For other stuff like Line, Operator you also won't need to have everything. However, to keep things valid some minimal information needs to be there.

So for Line it is a Name. When the idof the Line is the SLNID we know what it is and can replace it during importation.

So a lot of the very extended stuff is only needed in the files that INFO+ publishes to the world.

One idea we have is, that at some point the SITE_OFFER is mainy done by Atlas directly.

I can tell you how it currently works:
You have a StoPlace that changes at the 1.9.2026. In the timetable export before you get the old one for the whole timetable year. in the export after you get the new one for the whole timetable year.

@soleluna83 pls confirm.

If you want to have full versioning, then we WILL allow for version!="1". However, you will have to split everything accordingly. So more SJP, ScheduledStopPOints etc. So currently nobody wants to go down that road.

We can address it certainly at some point.