Attributen optioneel maken bij Reis, Route en Routesegment

[brechtvdv]

Een aantal attributen zouden optioneel gemaakt kunnen worden om zo weinig mogelijk duplicatie van dezelfde informatie te hebben. Dit naar aanleiding van een specificatie die ik aan het opstellen ben: https://github.com/brechtvdv/third-party-support-maas-specification/tree/master/provider

• [ ] Reis:reisweg. Bij gebruik van routesegmenten is dit overbodig.
• [ ] Route: vertrek- en aankomstpunt. Kan afgeleid worden uit de gesorteerde lijst van routesegmenten.
• [ ] Route:reisduur. Kan afgeleid worden uit Route:vertrek- en aankomsttijdstip.
• [ ] Link:aankomst- en vertrekknoop. Kan afgeleid worden uit Link:geometriemiddenlijn + GerichteLink:richting.

[GeertThijs]

Is duplicatie van informatie een voldoende argument om de semantische kardinaliteit af te zwakken? Want dat heeft belangrijke nadelen:

• Wie bv louter Reizen wil analyseren (bv om er de meest populaire bestemmingen uit te halen) moet informatie (bv aankomstpunt) gaan halen in Route of Routesegment. Meer werk voor de ontwikkelaar.

• En wat als er meerdere Routes zijn? Reis.reisweg geeft aan welke verplaatsing men wou uitvoeren, niet noodzakelijk diegene die ook is uitgevoerd of de routes die door de Routeplanner werden voorgesteld.

• Route en Routesegment moet dan ook wel aanwezig zijn. Iets wat we momenteel enkel informeel in een usageNote kunnen aangeven (formeel beschreven UML constraints worden in de spec niet getoond). Ook de validator kan dit niet afdwingen momenteel.

[brechtvdv]

1) Optioneel maken is minder werk voor de ontwikkelaar die de data moet publiceren, maar inderdaad meer werk voor de afnemer van de informatie. Ik zou echter de last op de schouders van de publiceerder zo klein mogelijk proberen maken, want deze groep moet hiermee eerst aan de slag.

2) Oei, ik had dit niet door bij Reis.reisweg. Ik dacht dat dit de uitgevoerde/te uitvoeren reisweg was. Dan zou ik dit inderdaad niet optioneel maken.

[GeertThijs]

Oké, als we Reis.reisweg erbuiten laten wil ik jouw voorstel wel volgen. Iets meer beargumenteerd dan wel:

• Route.aankomstpunt en Route.vertrekpunt optioneel: Bedoeling daarvan was vooral om vertrek- en aankomstplaats indien gewenst ook niet-geometrisch te kunnen beschrijven (bv dmv een adres of plaatsnaam). Je kan ze inderdaad afleiden uit de lijst van Routesegmenten, maar als we Route.aankomst-/vertrekpunt optioneel maken dan is ook Routesegment.^aankomst-/vertrekpunt optioneel en blijft enkel de mogelijkheid om ze uit de set van GerichteLinks af te leiden die (wel verplicht) de geometrie van de individuele Routesegmenten beschrijft. Maw: de locatie vh vertrek- en aankomstpunt is dan enkel geometrisch beschreven. Wie dan nog wil weten welk adres of plaatsnaam erachter zit zal deze zelf moeten achterhalen op basis van coordinaten of evt uit Reis.aankomst-/vertrekpunt (maar dan gaat het wel over het intentionele vertek- en aankomstpunt. Bovendien kan een Reis meerdere locaties omvatten, de relatie tussen reisweg en Route(segment) is niet ondubbelzinnig.

• Reisduur optioneel: Kan inderdaad afgeleid worden uit vertrek- en aankomsttijdstip. Het diagram gaf zelfs aan dat het moest afgeleid worden: er stond een /-teken voor reisduur. Dit om inconsistentie te vermijden (een reistijd die bv langer is dan aangegeven door vertrek- en aankomsttijdstip).

• Link.aankomstknoop en Link.vertrekknoop optioneel: Ik dacht dat INSPIRE dat oplegde, maar dat blijkt dus niet te kloppen: beide zijn optioneel. Mogelijk om dezelfde reden als jij aanhaalt: het kan afgeleid worden uit de geometriemidellijn. Maar eerder denk ik omdat knopen enkel nuttig zijn in het geval van routering en er ook nog andere use cases zijn voor netwerken (bv cartografische voorstelling). In één moeite door zou ik dan ook Routesegment.aankomstknoop en Routesegment.vertrekknoop optioneel zetten, aangezien Routesegment gemodelleerd is op INSPIRE:Linksequentie en al wat verplicht is bij een linksequentie is de set van GerichteLinks die de route beschrijft.

[GeertThijs]

DONE, zie https://test.data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/kandidaatstandaard/2020-04-09.