stichting-crow/datastandaard-fietsparkeren

Gegevensprofiel voor uitwisseling informatie van geparkeerde fietsen, in stallingen en op straat

datastandaard-fietsparkeren's Issues

Onduidelijkheid over timestamps

In het document https://github.com/Stichting-CROW/datastandaard-fietsparkeren/blob/gh-pages/spdp-fiets-api-20210224.html wordt voor formaat voor 'timestamp' velden in bepaalde gevallen verwezen naar 'UTC timestamp' en soms naar 'ISO8601'. Dit lijkt dus niet consistent. Zit er daadwerkelijk verschil in de definitie?

In paragraaf 3.4 van bovenstaande document wordt als voorbeeld een timestamp "2020-11-23T11:45:00" vemeld.
In deze timestamp is geen tijdzone of tijd-offset gespecificeerd. Daarmee is het exacte tijdstip dus niet ondubbelzinnig af te leiden.
Ik neem aan dat hier UTC wordt bedoeld, klopt dat?

Het zou ondubbelzinnig gemaakt kunnen worden door bijvoorbeeld een "Z" toe te voegen voor een datum/tijd in UTC: "2020-11-23T11:45:00Z". Zie ook bijvoorbeeld https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

Voertuigtypen: beperkend of beschrijvend

Probleem bij aanpak v2, is dat de voertuigtypering bij de capaciteitsbeschrijving beperkende kwalificaties toevoegt; terwijl je bij een meting van geparkeerde voertuigen niet alle aspecten per se wil opnoemen: dat een fiets in particulier eigendom is, met spierkracht aangedreven, etc.

Hernoem `StaticSection.validUntil` naar `.validThrough`

Dat is namelijk expliciet geldig t/m, zonder ambiguïteit over geldig tot.

`Space.type` `w` ambigu

De waarde w van Space.type is ambigu:

Is "voor fietsenwinkel" gebied met een bestemming (ten behoeve van) of is het een gebied aanpalend aan de winkel.

Links in README.md verwijzen naar niet-bestaande paginas

De links zoals genoemd in de README.md verwijzen naar een niet-bestaande pagina:
https://docs.crow.nl/datastandaard-fietsparkeren/spdp-fiets/
https://docs.crow.nl/datastandaard-fietsparkeren/api-fiets/

Voor implementatie: Bitmasks voor voertuigtype-lijsten

Zijn bitmasks om combinaties van eigenschappen op te slaan mogelijk om te implementeren in vele backends?

Zoeken op zulke combinatiecijfers lijkt me buiten scope.

Voorbeeld:

ID	Hex?	Verschijningsvorm	ProRail
k	0x1	Kinderfiets
r	0x2	Racefiets
l	0x4	Ligfiets
b	0x8	Bakfiets / Transportfiets
f	0x10	Fietskar
v	0x20	Vouwfiets
m	0x40	Mountainbike
d	0x80	Driewieler
t	0x100	Tandem
g	0x200	Gehandicaptenvoertuig
x	0x398 = (dec) 920	Sterk afwijkend: nl. b,f,d,t,g	*

GeoLocation is niet verplicht

geoLocation op Survey en geoLocation op StaticSection zijn beide niet verplicht. Dat is bijv. niet praktisch als er datasets (surveys) zijn waartoe je geen toegang hebt: die kun je dan nooit vinden om toegang te vragen.

De waarde van geoLocation op Survey lijkt me overigens afleidbaar van de waardes van StaticSections, met ST_CONVEXHULL(). Dat lijkt me dan de defaultwaarde van Survey.geoLocation indien niet in POST request.

Alternatief kun je voor API 4 specificeren dat queryparameter ?geopolygon= (net als startdate) ook zoekt in de section-geo's.

Document ‘Dynamische data in de fietsparkeerstandaard’ is niet beschikbaar

Naar verwezen in § 2.3 – Dynamische data.