* min issue https://github.com/salgo60/Offentliga-to...
* kommunikation med Stockholms stad https://github.com/salgo60/Offentliga-to...

Jag pratade med trafikkontoret om Stockholms offentliga toaletter och att bra/korrekt/tydlig öppna data om offentliga toaletter i karttjänster behövs så att vi kan uppdatera kartan OpenStreetMap (OSM) https://sv.wikipedia.org/wiki/OpenStreet...) med senaste status

Ett antal strukturella brister blivit tydliga, vilket gör datat svårt att felsöka, följa över tid och återanvända korrekt särskilt nu när det händer mycket med publika toaletter.

Nedan sammanfattar jag konkreta förbättringsförslag som skulle höja kvaliteten, spårbarheten och nyttan av datat – både för staden och för externa användare.

Jag nås på 0735152802
email: [email address]

### 1) Felanmälan och spårbarhet per objekt
* ex. https://github.com/salgo60/Offentliga-to...

För att kunna felanmäla specifika toaletter krävs att varje objekt har en publikt exponerad, stabil identifierare.

* Fråga 1: Finns idag någon publik identifierare per toalett som kan användas vid felanmälan?
* Fråga 2: Om inte: hur är tanken att externa användare ska kunna hänvisa till exakt rätt objekt (t.ex. vid statusfel som “ej i drift”)?

Vidare saknas tydlig dokumentation för statusfält, t.ex.:

* Fråga 3: Vad betyder exakt “ej i drift”?
* Fråga 4: Är det tillfälligt eller permanent?
* Fråga 5: Finns någon versions- eller uppdateringshistorik som visar om informationen är aktuell?

### 2. Publik, globalt unik identifierare (URI) per toalett
Varje toalett bör ha en globalt unik, URI-baserad identifierare, inte bara ett internt ID.

Den bör:

* Vara stabil över tid
* Kunna användas direkt i OSM, exempelvis via
* ref:stockholm=

Detta är en etablerad praxis för koppling mellan kommunala register och OSM.

### 3. Tombstone-sidor för borttagna objekt

När en toalett tas bort ur drift eller datamängden bör identifieraren inte försvinna, utan leda till en s.k. tombstone-sida som anger:
* att objektet upphört
* när det upphörde
* vad som eventuellt ersatt det

Detta följer etablerade best practices, t.ex. DataCite, och är avgörande för att undvika brutna länkar och historikförlust.
Se beskrivning av Best Practices for Tombstone Pages https://support.datacite.org/docs/tombst...

### 4. Versionshantering per objekt
För att kunna följa förändringar över tid behövs minst ett av följande per objekt:

* modified (senast ändrad)
* alternativt en enkel changelog

Detta möjliggör:
* bevakningar av förändringar
* notifiering till OSM-mappare
* minskad risk för felaktiga massuppdateringar

Wikidata är ett exempel där förändringar kan följas maskinellt via change API https://stream.wikimedia.org/v2/ui/#/?st...

Fråga 6: Finns motsvarande ändringsström för ändringar Stockholms stads öppna data om toaletter

### 5. Relationer mellan gamla och nya objekt

Om en toalett ersätts av en annan (ny plats, ny byggnad, ny datapost) bör detta uttryckas explicit i datat, t.ex.:
* “ersätter”
* “ersätts av”
* alternativt med etablerade semantiska relationer (t.ex. [sameAs](https://www.w3.org/TR/skos-reference/#L4...) / motsvarande)

Detta är viktigt för långsiktig datakvalitet och historik.

### 6. Enklare och mer konsistent API
I jämförelse med andra datamängder (t.ex. hundrastplatser) upplevs stadens API som relativt komplext att använda för enkla kartapplikationer.

Jag har byggt testkartor som visar både potentialen och svårigheterna:

* Hundrastplatser – färdig testkarta
** https://salgo60.github.io/Dogpark_Sweden...
* Offentliga toaletter – aktuell karta skapad igår
** https://salgo60.github.io/Offentliga-toa...

Ett enklare, mer konsekvent API skulle sänka tröskeln avsevärt för återanvändning.

Mina tester med hundrastplatser ovan så tycker jag Stockholms stad inte är det enklaste
att använda och det borde finnas
a) enklare APIer
b) att allt sker med APIFirst dvs. att datat som visas på web:ar r det datat vi kan hitta som Data som data

### 7) Tydlig livscykelmodell
Inför explicita statusvärden och dokumentera, t.ex.:

* planned
* active
* temporarily_closed
* decommissioned

Detta mappar väl mot etablerade OSM-taggar som:

* [amenity=toilets](https://wiki.openstreetmap.org/wiki/Tag:...)
* [disused](https://wiki.openstreetmap.org/wiki/Key:...
* [removed](https://wiki.openstreetmap.org/wiki/Key:...

En sådan modell minskar tolkningar och manuellt arbete.

Sammanfattningsvis: med stabila identifierare, tydlig livscykel, versionshantering och bättre dokumentation skulle stadens data om offentliga toaletter bli betydligt mer användbar, tillförlitlig och återanvändbar – både internt och externt.

Jag bidrar gärna med dialog, exempel eller testfall om det är intressant.

Vänliga hälsningar,
Magnus Sälgö
0735152802

Min issue https://github.com/salgo60/Offentliga-to...