Päivitetty ehdotus uusiksi piirto-ohjeiksi pyöräteille, jalkakäytäville ja poluille

Tein tuossa väärän tulkinnan mitä olit sanonut. Kantani kuitenkin käytännössä sama kuin teillä eli Wiki neuvokoon komplementti tagin lisäämisen. Tahdoin sanoa, että jos tuo lisätagi sattuisi puuttumaan niin se ei kuitenkaan ole kovin suuri haitta: En näe tuota ongelmaa mitä kuvaat. Cycleway on väylä joka sopii pyöräilyyn ja jota pitkin voi reitittää myös jalankulkijat koska kyseessä on käytännössä joko yhdistetty / rinnakkainen tai jalkakäytävä on vieressä tai pyörätien reunaa saa lain mukaan kulkea jos muuta ei ole tarjolla - pointtina ei ole siis “mikrotason” absoluuttinen totuus väylästä vaan pragmaattisuus: voiko jalankulkija kulkea tämän reitin. Mielelläni kuulen jos jossakin päin Suomea on cycleway jossa tämä ei toteudu.

Tämä on muuten duck taggingin keskeinen etu: päätagi kertoo olennaisen, lisätagit tarkentavat, mutta lisätägien puuttuminen ei muuta tulkintaa mahdottomaksi.

En ymmärrä mitä tällä ajat takaa. Itse koen ohjeet ja normit osaksi kokonaisuutta, yhteisön toimintaa ja kartoitusprosessia, ja arvioin niitä, kuten muitakin tekijöitä systeemin komponentteina. Tavoitteena globaali optimointi, ei lokaali.

Esim. ohjeita rikkovat toki pitää ohjata lukemaan ohjeita. Se ei kuitenkaan muuta sitä tosiseikkaa, että OSM:ssa ei ole mitään systemaattista laadunvarmistus-mekanismia ja kartoittajien kyky seurata ohjeita on rajallinen. Ts. Jos (ja kun) tavoitteena on laaja JA laadukas (jotka ovat usein konfliktoivia tavoitteita) kartta-data niin pitää miettiä kaikkia mekanismeja yhdessä jotka vaikuttavat tavoitteeseen pääsyyn ja myös niiden keskinäistä dynamiikkaa.

Pahoittelut virheestä kommentissani: use_sidepath ei pitänyt olla listalla vaan cycleway=* tagit. Pointtini oli, että tuo osa tägayksestä on karttahavaintojen mukaan haastavampaa aluetta, mikä johtaa kartoittajien virheisiin. Kartan renderoinnissa osa näistä virheistä on haastavia: miten rakentaa renderointisäännöt jotka eivät tuota kelvotonta sotkua datan virheiden takia.

Tässä ei kyse “kartan koodaamisesta renderoijaa varten”, vaan siitä että mikä tahansa sovellus / palvelu joutuu huomioimaan että datan laatuvajeet: epäkonsistenttius ja suoranaiset virheet. Palaan tähän alempana vielä…

Jos et lukenut duck taggingista sitä koko linkkaamani OSM email-listan keskustelua (ei vain sitä lyhyttä wiki quotea), niin ehdotan että luet sen. Sen jälkeen unohda hetkeksi “täydellisen kartoituksen” utopia, jossa kartoittajat vaivautuvat lukemaan huolella ohjeet ja seuraavat konsistentisti ohjeita tekemättä virheitä tai erilaisia tulkintoja. Ja unohda myös esittämäsi hypoteettinen keissi jossa tarkka ohjeensa lukenut kartoittaja pohtii kahden eri tagaysmallin eroja. Mieti näiden sijaan OSM-data realiteetteja: datan nykytilannetta ja miten se kehittyy laajan, hyvin hyvin löyhästi koordinoidun kartoittajayhteisön toimesta, prosessilla jonka laadunvarmistus on hyvin alkeellinen.

Mieti sitten miten hyödyntäisit OSM-data sovellukseen kuten reitityskone tai kartan renderointi. Huom. ei vain miten hyödynnät dataa omaan käyttöösi, vaan miten teen sovelluksen / palvelun käyttäjille jotka eivät tiedä mitään (eivät myöskään välitä!) OSM-datan eriskummallisuuksista. Miten tuo sovellus käsittelisi OSM-datan laatuongelmia niin, että niistä huolimatta käyttäjät saisivat hyvän käyttökokemuksen?

Vastaus ei voi perustua siihen, että virheet pitäisi korjata. Virheitä ja virheitä tekeviä kartoittajia pitää toki ohjata, mutta fakta on ja tulee olemaan, että virheitä on ja paljon datassa. Voi toki päättää “hylkiä” kaikkia niitä väyliä joita ei ole tagatty täydellisesti tai kohdella niitä “worst case” oletuksin - “been there, done that” ja voin kertoa että tuloksena on reititysalgo joka saa käyttäjät repimään hiukset päästään koska niin moni johonkin reittiin paras väylä ei kelpaakaan reitittimelle.

Tässä kohtaa duck taggingin arvon pitäisi alkaa avautua: cycleway-tagi yksinään jo on hyvin suurella todennäköisyydella kelpo väylä pyörälle ja jalankulkijalle (ts. riski on pieni että se olisikin epäsopiva). Jos sama väylä onkin tagatty path & surface=unpaved (tai gravel) niin mitä siitä voi päätellä? unpaved-tapauksessa ei oikeastaan mitään, gravel voi olla oikeasti isorakeinen gravel tai tyypillisempi väärä tulkinta fine_gravel:sta (näitä muuten riittää…). tracktype-tagi ei tuo merkittävää lisäarvoa. Smoothness ylimmät kaksi arvoa lienee turvallisia tulkita, siitä alaspäin joutuu ottamaan riskiä tulkinnoissa. Ongelma lähtee siitä että päätagi, eli tässä path tai track, ei kerro riittävän kapeata “pääluokkaa” ja näin lisätagit tarkentavat jotain mitä ei alunperinkään tunneta.

2 Likes