Datastandard för offentliga toaletter

Johan_Bard

Någon som vet ifall det finns någon vedertagen datastandard för offentliga toaletter?

Vi har gjort ett större arbete med inventering för att skapa en egen karta men när det kom till att kratta för att det ska bli öppen data har vi tyvärr gått bet.

Vi har hittat https://www.dataportal.se/sv/datasets?p=1&q=toaletter, så klart, och även https://data.london.gov.uk/blog/new-standard-open-data-format-public-toilets/ men jag upplever att vad vi arbetat fram är mer uttömmande.

FilipDijak

@Johan_Bard

@mattias har du koll på det? Finns ingen specifikation uppladdad på dataportalen, men finns det något att följa?

Johan_Bard

Jag är nu i kontakt med https://www.vgregion.se/ov/dataverkstad/ om möjligheten att ta fram ett första utkast till en standard, baserat på de specar som finns för till exempel badplatser, utegym och lekplatser.

Johan_Bard

Första utkast till specifikation

INAKTUELL - SE ISTÄLLET https://gitlab.com/sarskilt-viktiga-datamangder/public-toilets

#	Kolumnnamn	Datatyp	Exempel och förklaring
1	source	heltal	Obligatoriskt - Ange SCB:s kommunkod för er kommun eller organisationsnumret för verksamheten. Exempel: "1401" för Härryda kommun eller organisationsnummer “21 20 00-12 64”.
2	id	text	Obligatoriskt - Ange en unik och stabil identifierare för utegymmet inom er kommun. Det viktiga är att identifieraren är unik (tänk unik i hela världen), och att den är stabil över tid - dvs att den inte ändras mellan uppdateringar. Om en offentlig toalett avvecklas ska identifieraren inte återanvändas på en annan offentlig toalett.
3	name	text	Obligatoriskt - Den offentliga toalettens namn, exempel för ett en offentlig toalett i Region Gotland "Tingstäde träsk badplats”.
4	latitude	decimaltal	Obligatoriskt - Latitud anges per format som WGS84-specifikation.
5	longitude	decimaltal	Obligatoriskt - Longitud anges per format som WGS84-specifikation.
6	email	text	Obligatoriskt - E-postadress för vidare kontakt, anges med gemener och med @ som avdelare. Använd ej mailto: eller andra HTML-koder. Exempel: info@toreboda.se
7	visit_url	URL	Länk till allmän besöksinformation för platsen, t.ex. verksamhetens öppettider eller liknande.
8	wikidata	text	Referens till Wikidata-artikel/entry om platsen. Se kapitel “3. Wikidata" i detta dokument. Använd den sk. Q-koden till entiteten på Wikidata. Exempel för att länka till offentlig toalett i Raahe, Finland på Wikidata: Q55596141 Q-kod anges utan mellanslag, bindestreck eller skiljetecken och består alltid av bokstaven Q följt av ett antal siffror.
9	updated	datum	Ett datum som anger när informationen om den offentlig toaletten senast uppdaterades.
10	description	text	Kort beskrivning av den specifika offentliga toalettens placering eller särskilda förutsättningar. Exempel: "Ligger på bibliotekets baksida" eller "Felanmäl direkt till verksamhetens personal" Undvik att beskriva sådant som redan framgår i specifikationen.
11	street	text	Gatuadress till platsen, exempelvis “Strandvägen”. Ange inte nummer på gata eller fastighet, det anges i attributet “housenumber”. Mappar mot Open Street Maps “addr:street” läs mer på Key:addr på Open Streetmaps webbplats.
12	housenumber	text	Gatunummer eller husnummer med bokstav. Exempelvis “1” eller “42 E”. Mappar mot Open Street Maps “addr:housenumber” läs mer på: Key:addr på Open Streetmaps webbplats.
13	postcode	text	Postnummer, exempelvis “46430”, mappar mot Open Street Maps “addr:postcode”, läs mer på: Key:addr på Open Streetmaps webbplats.
14	city	text	Postort, exempelvis “Mellerud”. Mappar mot Open Street Maps “addr:city”, läs mer på: Key:addr på Open Streetmaps webbplats.
15	country	text	Land där utegymmet finns. Skall anges enligt ISO3166-1. För Sverige ange “SE”. Fältet mappar mot Open Streetmaps “addr:country”.
16	wc	int	Antal vattenklosetter.
17	urinal	int	Antal urinoarer.
18	outhouse	int	Antal torrklosetter (dass).
19	rwc	int	Antal toaletter som uppfyller Plan- och bygglagens krav på tillgängliga hygienrum. https://www.boverket.se/sv/PBL-kunskapsbanken/regler-om-byggande/boverkets-byggregler/tillganglighet/hygienrum/
20	lighting	boolean	Beskriver om den offentliga toaletten har belysning.
21	water	boolean	Anger om det finns tillgång till vatten för att exempelvis tvätta händerna.
22	drinking_water	boolean	Anger om det finns dricksvatten på platsen i någon form.
23	trashbin	boolean	Anger om det finns en soptunna i någon form på platsen.
24	unisex	boolean	Anger om den offentliga toaletten är unisex.
25	change_table_child	boolean	Anger om det finns ett skötbord anpassat för barn.
26	wc_child	boolean	Anger om toaletten är anpassad för barn, eller att det finns en mindre toalett för barn.
27	change_table_adult	boolean	Anger om det finns ett skötbord anpassat för vuxna.
28	rwc-alarm	boolean	Anger om det finns RWC-larm installerat.
29	door_opener	boolean	Anger om det finns RWC-anpassad automatisk dörröppnare installerad.
30	accessability	text	Ytterligare beskrivning om hur tillgänglighetsanpassad den offentliga toaletten är.
31	open_season	Text ?Datum-standard?	Beskriver när under året den offentliga toaletten är öppen. Exempel: "1 maj - 30 september". Året-runt-öppna lämnas tomma.
32	open_hours	Text ?Tid-standard?	Beskriver när under dygnet den offentliga toaletten är öppen. Exempel: "05:00-22:00" eller "Tillgång endast under bibliotekets öppettider". Dygnet-runt-öppna lämnas tomma.
33	service_interval	UNKNOWN/IRREG/ YEARLY/QUARTERLY/ MONTHLY/WEEKLY/DAILY	Ange i vilken frekvens den offentliga toaletten städas. ?När den senast städades?
34	fee	boolean	Anger om den offentliga toaletten är avgiftsbelagd.
35	fee_description	text	Beskriver avgiften och hur man betalar. Exempel "5kr. Betala med mynt, betalkort eller Swish" Avgiftsfria lämnas tomma.
36	td_url	URL	Länk till Tillgänglighetsdatabasen (TD).
37	Image_url	URL	Länk till en bild i formaten .jpg, .png eller .webp. ?Licens för bild - CC0?
38	report_phone	phone	Telefonnummer för frågor, synpunkter och/eller felanmälan.
39	report_url	URL	Länk till tjänst för frågor, synpunkter och/eller felanmälan.
40	open	boolean	Anger om den offentliga toaletten är tillfälligt stängd, till exempel för underhåll eller ombyggnation.

ChristerOlsson

@Johan_Bard En tanke angående fee.

Jag tänker att denna med fördel kan delas upp i en boolean som är lätt att tolka maskinellt och ett text-fält med detaljer om kostnaden om en sådan finns.

Annars kommer någon att skriva "Ingen kostnad", "gratis", "Free" eller dylikt som inte gör någon som försöker tolka det hela automatiskt glad.

Angående URL. Jag har lärt mig den hårda vägen att inte alla inser att den bör vara fullständig som https://site.com/sida utan att de skriver site.com/sida. Så detta kanske kan förtydligas?

Johan_Bard

@ChristerOlsson BRA förslag!

Justerar till:
fee - bool
fee_descripton - text

Rörande URL är jag helt med dig, jag utgår ifrån att när vi går från utkast till specifikation kommer vi ha med ett förtydligande liknande https://lankadedata.se/spec/grillplatser/#url

jonor

@Johan_Bard sa i Datastandard för offentliga toaletter:

fee_description | text | Beskriver avgiften och hur man betalar. Exempel "5kr. Betala med mynt, betalkort eller Swish" Avgiftsfria lämnas tomma.

Finns det några idéer om eller exempel på hur man kan representera avgifter så de kan jämföras?

Ainali

@jonor det skulle kunna vara ett fält till:
fee_size - Avgift i SEK.
Och sedan skulle fee_description kunna användas till att beskriva hur betalning kan ske.

jonor

@Ainali Ja, säg om jag vill räkna ut snittpris/max/min på avgiften, eller se vilka betalningsmetoder som är vanligast, då är det ju bra om de uppgifterna ligger för sig på ett förutbestämt vis.

Det utgör väl också en schema-modul som kunde tillämpas generellt på avgiftsbelagda tjänster.

Egentligen borde väl fälten vara belopp, valuta och en eller flera betalningsmetoder från en uppsättning standardvärden med ett "övrigt"-värde som kunde förklaras i ett beskrivningsfält.

Trycker man in flera uppgifter i ett textfält utan struktur får man tänka på att man överlåter jobbet på någon annan att reda ut vad innehållet betyder. Det är att föredra att ange strukturerade värden eller identifierare för saker.

Johan_Bard

Jag hör er och det låter rimligt. Jag överger nu ovanstående tabell till fördel för att arbeta direkt i den schema.json som finns i https://gitlab.com/sarskilt-viktiga-datamangder/public-toilets. Det ligger en merge request för utkastet med alla era kloka idéer tillagda.

JSON är förvisso lite mer svårläst för gemene man men närmre produktion så jag föredrar att göra så. Vem som helst får dock gärna omvandla schema.json till MD och klistra in här.

Problem alla gärna får klura och svara på:

"open_season" bör vara i ett format för datumperioder (MM-DD till MM-DD). Oklart om en sådan datatype finns eller om det ska hanteras som en array med startdatum och slutdatum.
"open_hours" hade varit fiffigt att ha i ett format för tidsperiod (hh:mm till hh:mm). Oklart om en sådan datatype finns eller om det ska hanteras som en array med starttid och sluttid. Behöver då även kunna kompletteras med textfält för "Tillgång endast under bibliotekets öppettider", vilket är vanligt hos oss.
"fee_sum" satte jag som float begränsad mellan 0.01 och 999 för att öppna upp för andra valutor än SEK. Oklart om det är nödvändigt eller om float ens existerar som datatype i sammanhanget
"fee_payment_method" satte jag som array där man kan välja upp till tre möjliga alternativ - CASH, CARD, SWISH. Oklart vilka alternativ som bör finnas med, till exempel gör man i många länder skillnad på kontokort och kreditkort - ska det reflekteras häri? Oklart om array existerar som datatype i sammanhanget.

jonor

@Johan_Bard Jag är inte så insatt i praxis, men ISO 8601 har specifikationer för datumformat, intervall och perioder.

https://en.wikipedia.org/wiki/ISO_8601#Time_intervals

@Johan_Bard sa:

Oklart om array existerar som datatype i sammanhanget.

Beror kanske på vad som åsyftas med "sammanhanget", är det någon särskild notation för datamodellering, eller scenarier för praktisk användning av datan?

Edit: Om specen gäller ett CSV-format, vilket jag fick intryck av, så fick jag ett förslag från ChatGPT. Jag gissar att propertyUrl pekar på vidare information om vad elementen i listan betyder.

{
  "@context": "http://www.w3.org/ns/csvw"
  ...
      {
        "name": "tags",
        "datatype": "string",
        "propertyUrl": "http://example.org/tags",
        "separator": ";"
      }

Det behövs ju en metod för att kunna ange fler än ett element om man inte för alltid ska vara hänvisad till att skjuta in extra fält i stil med "betalningsmetod 1", "betalningsmetod 2", "betalningsmetod 3" (hoppas ingen har användning för fler än tre betalningsmetoder).

Finns det i nuläget någon befintlig data tillgänglig för området, och hur ser den isf. ut?

jonor

Egentligen borde väl DIGG ha någon guide och exempel för hur man modellerar och specificerar olika typer av data och relationer, som är tillämplig i ett sådant här fall?

Johan_Bard

@jonor @jonor Ja jag vet inte riktigt, jag har utgått ifrån specifikationer för badplatser, utegym, lekplatser och grillplatser. Ingen av dem innehåller array eller tidsperioder vad jag kan se.

ISO 8601 låter klockrent (tihi) för att standardisera tids- och datumperioder.

Kan bara hålla med om att det borde finnas guide och exempel. En sträng med specad separator är ett bra sätt i brist på annat.

ChristerOlsson

@Johan_Bard Kan bara hålla med om att ett json-schema kan vara rätt väg. Möjligen kan det vara ännu bättre att använda geojson eftersom det då finns gott om färdigskriven kod för att läsa och tolka innehållet.

Det sagt så är ändå json väldigt mycket bättre än csv.

almeta

@Johan_Bard du kan titta på dessa CSV scheman gällande datatyper för tid och datum

https://gitlab.com/sarskilt-viktiga-datamangder/point-of-interest/-/blob/main/schema.json?ref_type=heads
https://gitlab.com/sarskilt-viktiga-datamangder/evenemang/-/blob/main/schema.json?ref_type=heads

Gällande "fee_payment_method" satte jag som array där man kan välja upp till tre möjliga alternativ - CASH, CARD, SWISH. Oklart vilka alternativ som bör finnas med, till exempel gör man i många länder skillnad på kontokort och kreditkort - ska det reflekteras häri? Oklart om array existerar som datatype i sammanhanget."

Du kan hitta inspiration i schemat från Points-of-interest, se exempel nedan med schema.org's vokabulär där jag utgått ifrån https://schema.org/PaymentMethod
json

           {
              "name": "payment_method",
              "titles": "Betalning",
              "dc:description": "Betalningstyp.",
              "datatype": {
                "base": "string",
                "format": "Cash|DirectDebit"
              },
              "required": true,
              "valueUrl": "http://purl.org/goodrelations/v1#{type}",
              "propertyUrl": "schema:acceptedPaymentMethod"
            },

Johan_Bard

@almeta Om jag läser payment_method rätt finns det bara möjlighet att välja en av dem, Cash eller DirectDebit?

Hur gör man när man behöver välja flera av alternativen, Cash och DirectDebit?

almeta

@Johan_Bard kardinaliteten beskrivs inte i CSV schemat utan anges i dokumentationen (specifikationen) för det specifika attributet, i det här fallet payment_method

För att tillåta flera värden än 1 bör ni uttrycka det enligt nedan.

Obligatorisk egenskap (det givna exemplet ovan) - 1..*
Rekommenderad egenskap - 0..*

jonor

@almeta Det ska alltså finnas både en "specifikation" som beskriver datamodellen, och ett JSON-schema som beskriver ett CSV-format?

Hur fungerar det i praktiken, är kardinaliteten i en relation maskinläsbar? Tänker om man vill validera att data följer specifikationen? Från JSON-schemat kan man då bara läsa ut om egenskapen är obligatorisk/"required" i tabellformatet, dvs. antingen 0..*, eller 1..*?

@almeta sa i Datastandard för offentliga toaletter:

du kan titta på dessa CSV scheman gällande datatyper för tid och datum

https://gitlab.com/sarskilt-viktiga-datamangder/point-of-interest/-/blob/main/schema.json?ref_type=heads
https://gitlab.com/sarskilt-viktiga-datamangder/evenemang/-/blob/main/schema.json?ref_type=heads

Förmodar att dessa är specifikationer för datamodeller för ovanstående exempel:

Schemaexemplen verkar i en del avseeenden vara förenklingar som inte täcker in vanliga omständigheter i verkligheten.

Hur är det med fälten "opens" och "closes", är dessa standardegenskaper för öppettider så att det går att härleda ett tidsintervall för olika typer av verksamheter? Det finns väl annars inget i själva schemat som beskriver att de hör ihop som tidpunkter i ett intervall?

Det är vanligt att öppettider varierar över olika veckodagar, schemat för POI fångar inte den aspekten på ett strukturerat sätt. Fältet "openinghours" är ett strängvärde med risken att man skriver in varierande öppettider på ett ostrukturerat vis.

När det gäller fältet "price" är det väl på motsvarande vis vanligt att inträde kan variera för olika åldersgrupper eller andra kategorier. Där skulle också behövas ett sätt att strukturera detta, ett heltalsfält är troligen otillräckligt för att beskriva den prisinformation man ofta ser på informationssidor.

Johan_Bard

Vill bara meddela att jag uppdaterat schemat, men att det ännu inte är mergat.

https://gitlab.com/sarskilt-viktiga-datamangder/public-toilets/-/merge_requests/1/diffs?commit_id=0aee90c1f778edf0b486e0fee6aa9a564fcb095d

Vi på Region Gotland har för avsikt att släppa öppna data för våra offentliga toaletter, baserat på den standard vi fortfarande diskuterar, på https://sv.wikipedia.org/wiki/Världstoalettdagen. Skämten till den externa nyheten skriver sig själva.

jonor

@almeta Är du sakkunnig / representerar DIGG?

Finns det exempel på hur man representerar många-relationer och sammansatta datatyper i en specifikation resp. schema och data för ett format, som i detta fall CSVW?

Tror det är viktigt med vägledning och exempel för komma fram till datamodeller som kan representera verkliga förhållanden.

@almeta sa i Datastandard för offentliga toaletter:

kardinaliteten beskrivs inte i CSV schemat utan anges i dokumentationen (specifikationen) för det specifika attributet, i det här fallet payment_method

Community på Sveriges dataportal

Datastandard för offentliga toaletter

Första utkast till specifikation