Hej
Ser intressant ut. Här kommer först några generella kommentarer utifrån erfarenheter av att utveckla dataprodukter till NVDB (nationella vägdatabasen)
- Antal attribut, ju fler, deto tyngre blir ajourhållningsbördan. Tydligt definiera vad produkten ska användas till och vilka attribut som då krävs jämfört med attribut som är "bra att ha".
- Undvik beksrivande fritext-fält. Sträva efter att göra datan maskinläsbar.
2b) Fasta värdemängder för t.ex. postort då undviker man felstavningar och blanktecken) - bestämma antal tecken ett heltal attribut kan ha minskar risken av felinmatning.
- tydlighet i beskrivning av attributen, kan något misstolkas så kommer det att ske.
Specifika kommentarer
Om jag har parkering på båda sidor av en lång gata blir det 1 punkt?
IDt; sätts det av systemet, så att det säkerställs att det är unikt?
name; namn på verksamhet (är detta verkligen ett obligatoriskt attribut?)
type; behöver definiera de tre typerna
Tydligare förklara skillnaderna för de olika typerna av parkeringsplatser samt hur man förväntas redovisar totalen. Säg att det finns 2st HCP-platser och 10 vanliga parkeringar, är det då 12 st om är totala antalet platser?
prohibition; bör inte vara text. Svårt attribut att modellera bra då det säkert finns både, datum, tid och veckodag
updated, borde nog vara datumfält istället för text
Överväg att lägga till ett attribut som ger löpnummret ur STFS för parkeringar som är föreskrivna
Ett löpnummer för trafikföreskriften i STFS som tilldelas av beslutsmyndigheten, består av organisationskod, årtal och ett nummer som är löpande för kalenderår och åtskiljs från årtalet genom kolon. Dessa löpnummer kan se lite olika ut så här måste det tyvärr vara text...
mvh
Jonas Almqvist