What is the relation with OSLO Mobiliteit Trip en Aanbod? In this AP, "Dienstregeling" is also used and defined as well as stops (routeknoop), transfer points, trip segments,... etc. The goal of OSLO Mobiliteit Trip en Aanbod was to define a profile that could be used across modes hence also cover the NeTeX/PublicTransit case. By starting from scratch again we're building an extra container. https://data.vlaanderen.be/doc/vocabularium/mobiliteit-trips-en-aanbod/kandidaatstandaard/2020-01-12#dienstregeling

Suggestion: extend OSLO Mobiliteit Trip en Aanbod with the topics/structures from this AP or make sure that naming is aligned.

In order to support safety and security regulations bus operators have defined weather plans (see for example)
https://www.letec.be/News/Detail/17587 for each line
wich support 4 levels of weather conditions (1-2-3-4) and level 2 is even broken in several sublevels
althrough we are dealing with a static model, bad weather might persists several days and I recommend supporting this functionality, Especially, TEC has identified alternate routes and stops served/not served for each line

http://www.w3.org/ns/locn#Geometry

Description
Shape and position characteristics of an object.
Usage
Describes these features using points, lines, polygons, and coordinates.
Properties
we have defined the following properties for this datatype: gml, wkt.

-) Shoudn't we want to support geojson as well?

In the Timetables profile, for the entity ServiceJourney, one of the attribute is trainsize
train size
we associate an enumeration to it currently normal short or long
Bus operators might want to also support their vehicule size using this field I suggest to increase the enum with at minimum
doublebus
triplebus
minibus
TEC STIB and Delijn please comment :)

In the timetable model
https://purl.eu/doc/applicationprofile/netex-belgium/timetables-ap/working-draft/2022-04-21
for the following
Journey Frequency

Only Headway Interval is curretly part of the model
but to properly use frequency trip based information in route planners or start time and end time should be supported or start time and number of occurences should be supported
because you define 3 options for HeadwayInterval (max min or scheduled)
Hadway Interval
I recommend to support start time and end time or have a clear linkage with the service calendar

In the StopPlaces model
https://purl.eu/doc/applicationprofile/netex-belgium/stopplaces-ap/
one of the properties of the StopPlace is stopPlaceType
stop place type
that's an enumeration list and I suggest to support

busTerminal
trainTerminal
metroTerminal
tramTerminal
especially in light of supporting deadruns

Is it a wish to NOT support journey parts for train and to NOT support coupled/decoupled train?

In the service
https://purl.eu/ns/mobility/timetables-and-planning#ServiceJourney
we do not support NumberOfCars Is this a wish from SNCB?

What are the plans for developping an accessibility model? The following items from MMTIS delegated regulation 2017/1926 list the following items that I don't see correctly supported.

Level 1

(vii) Stop facilities access nodes (including platform information, help desks/information points, ticket booths,
lifts/stairs, entrances and exit locations)
(viii) Vehicles (low floor; wheelchair accessible.)
(ix) Accessibility of access nodes, and paths within an interchange (such as existence of lifts, escalators)
(x) Existence of assistance services (such as existence of on-site assistance
Level 2
b) Information service:
Where and how to buy tickets for scheduled modes, demand responsive modes
modes and demand-responsive incl. retail channels, fulfilment methods, payment methods)
(ii) Vehicle facilities such as classes of carriage, on-board Wi-Fi.

In term of vehicule facilities we have a nice set of additional facilities that could be included such as
bike allowed
luggage racks and size
quiet vehicle
wifi
toilet
air conditioning
single / double deck

I think one of the properties of the Line is "color" and it seems to be missing. Two examples: Brussels metro, the map is represented by colors that are/could be used by users. Line colors are also used to identify lines for Charleroi Metro

a small list of items that need to be written in English

1. Line String
   Usage
   Een curve is een 1-dimensioneel geometrisch object gedefinieerd als een sequentie van punten. De interpolatie kan op verschillende manieren gebeuren (bv lineair bij een lijnstring).

2. https://purl.eu/ns/mobility/timetables-and-planning#DayTypeAssignment

schematic image for stop places
https://purl.eu/doc/applicationprofile/netex-belgium/stopplaces-ap/working-draft/2022-04-21/html/overview.jpg

two enumerations are not correctly enumerated (first 3 are listed and then etc is used) . Since the image is the only place where we enumerate or we should enumerate everything in it or we should document all enumerations in full details as text outside of the image so that we are complete, or use EU netext reference for them

This specification is defined in English but others (certainly related to mobility) are in Dutch. It's good that finally, we're defining specifications in English. It is important however to try to or translate the other specifications to English too or have a Dutch/multilingual documentation for all specs.

Het call Model komt alleen terug in SIRI, maar in geen van de andere profielen in Europa.

Waarom is er gekozen om Calls te gebruiken ipv timetabled passing time, of timedemandtype?

In het stop places model kom ik geen passanger stop assignment tegen. Hoe wordt de relatie gelegd tussen ScheduledStopPoint, Quay en StopPlace?