Uudistetussa ehdotuksessa otetaan erityisesti huomioon ns. Duck Typing -mahdollisuus, eli highway=cycleway ja highway=footway -tagien käyttö liikennemerkittömillä alimman tieverkoston poluilla (higway=path -tagin asemesta). Tajusin, että liikennemerkittömillä, mutta highway=cycleway -tagatuilla teillä ei voi olla oneway-tagia lainkaan, mutta pyörätien liikennemerkillä merkityillä teillä sellainen on aina oltava. Siten, liikennemerkityillä hihgway=cycleway teillä oneway-tagi riittää osoittamaan myös pyörätien liikennemerkin olemassaolon (eli traffic_sign=yes -lisätagia ei tarvita), mutta liikennemerkittömillä, mutta cycleway-tagatuilla teillä traffic_sign=no -lisätagi olisi erittäin tervetullut tai oikeastaan välttämätön.
Lisäksi lyhensin ehdotustekstiä poistamalla siitä C2-liikennemerkittyjä ja pyörätiemerkittyjä teitä (ja pyörätiemerkittyjä hevosteitä) koskevan osuuden. Oli tällä foorumilla ja ehdotussivun keskustelusivulla käydyn viestinvaihdon perusteella epäselvää, miten tällaisiin teihin tulisi suhtautua (ja onko pyöräilylle sallittuja hevosteitä olemassakaan, ainakaan kovin montaa). Samalla kieltomerkkejä koskeva ohjeistus yksinkertaistui merkittävästi.
Lisäksi poistin pyörätieosuudesta Baanoja/laatukäytäviä koskevan osuuden liian spesifinä tällaisille ohjeille.
Ylijatkettu jalkakäytävä pitäisi varmaan lisätä nopeasti sopivaan kohtaan.
Kommentteja ja muutosehdotuksia otetaan edelleen erittäin mielellään vastaan!
Hei, ja kiitokset keskustelun uudesta avaamisesta.
Totesit, ettei liikennemerkittömällä, silti cycleway:ksi merkityllä tiellä, pitäisi olla oneway-tietoa. Tällä voi (siirtymäajan jälkeen) erottaa pyörätien ja liikennemerkittömän, kuitenkin autoliikenteelle liian kapean, tien. Tähän haluaisin lisätä, että highway=cycleway/footway implikoi ominaisuustiedon bicycle/foot=designated. Tämä implisiittinen ominaisuustieto on väärin, jos oletamme tuon ominaisuustiedon syntyvän symboleista tiessä tai liikennemerkissä. Siispä liikennemerkittömälle väylälle, joka on highway=cycleway/footway, tulisi laittaa eksplisiittisesti bicycle=yesjafoot=yes, jotta implikoitu designated-arvo kumoutuu. Tämä tietysti vain silloin, jos samaan aikaan tiellä ei ole erillistä opasteviittaa.
traffic_sign=no, foot=yes ja bicycle=yes yhdistelmänä saattaisi toimia ihan hyvin rakennetuille, liikennemerkittömille väylille (joille ei mahdu autoilemaan). Mutta nyt wikissä ohjeistetaan valitsemaan path:in, footway:n ja cycleway:n välillä. Path kulumalla syntyneille väylille, footway rakennetuille? Jos cycleway pidetään mukana, mikä on liikennemerkittömän footway:n ja cycleway:n ero, "riittävän hyvä" geometria ja päällystys nopeaan pyöräilyyn? Path:in käytöstä ja siihen liittyvistä ongelmista keskusteltiin syksyllä ja itse en enää käyttäisi sitä rakennetuilla väylillä.
C2-merkin tulkinta tuntuu olevan tässä haastavinta. Ehdottaisin tässä vaiheessa, että nyt katsottaisiin piirto-ohjeet muilta osin sellaisiksi, että ne voidaan saattaa voimaan (kuvia toki voi lisäillä myöhemmin). Esimerkiksi väistämisvelvollisuus pyöräilijän tienylityspaikassa -merkistä ei juuri ole keskustelua käyty nyt puoleen vuoteen ja olisi syytä saada se piirto-ohjeisiin. Sitten voitaisiin palata C2-liikennemerkkiin ja muihin kieltomerkkeihin. Pyörätiemerkitty ratsastustie vaikuttaa olevan melko harvinainen ja ne voitaisiin ottaa käsittelyyn, jos joku löytää sellaisen ja ottaa siitä kuvan. Tampereen lähistöllä kuulemma oli sellainen?
Lisäsin wikisivulle vielä yhteenvedon muutoksista, niistä käyty keskustelu kun on levinnyt jo viiteen erilliseen foorumiketjuun. Toivottavasti sain kaiken oikein, korjatkaa rohkeasti jos ei. Nyt kun C2-merkki on otettu wikin piirto-ohje-ehdotuksesta kokonaan pois, minulla ei ole oikeastaan muuta kommentoitavaa.
Juu, tai itse sanoisin vähän tarkemmin, että tämä ongelma tai epäselvyys syntyy välittömästi Duck Tagging -periaatteen hyväksymisestä. Jos siis Duck Tagging hyväksytään, ei nimenomaan enään pidä paikkaansa että ominaisuustieto cycleway syntyy yksinomaan liikennemerkistä, joten se ei nimenomaan myöskään enään implikoi suoraandesignated-arvoa. Siis designated-arvo syntyy vain liikennemerkistä tai reittimerkistä. En ole ihan varma, ajoitko itsekin tätä takaa. Tämän huomion voisi muuten korjata pyöräteitä koskevaan osuuteen, nykyisellään se on ehkä tämän yksityiskohdan suhteen hieman moniselitteinen!
Niin, ei tietenkään ole missään nimessä virheellistä laittaa liikennemerkittömälle, mutta highway=cycleway -tagatulle polulle bicycle=yes tagia (ja mutatis mutandisfootwaylle). Itse ajattelen, että ne ovat lisätageina kuitenkin tautologisia ja redundantteja aivan samalla perusteella kuin ne ovat tautologisia ja redundantteja highway=path-teille. Siksi niitä ei mielestäni ehkä kannata laittaa ohjeeseen ikäänkuin ‘pakollisina’ lisätageina.
Ohimennen: highway=footway ja bicycle=no -yhdistelmä ei ole liikennemerkitylle tai lain tarkoittamalle jalkakäytävälle ihan samalla tavalla tautologinen pari, sillä aikuisten pyöräilykielto jalankulkuun tarkoitetuilla väylillä ei ole itsestään selvästi universaali juridinen normi, ja Suomessakin se toteutuu riippumatta pyöräkieltomerkistä.
Jos ja kun Duck Tagging -skeema hyväksytään vaihtoehdoksi, niin highway=cycleway + bicycle=designated -tagipari riittää kuitenkin erottamaan liikennemerkityt cyclewayt liikennemerkittömistä. Myös oneway=yes/no-tagi toki riippuu (myös ihan konkreettisesti) liikennemerkistä, mutta ilmaisee lisäksi siitä erillisen ominaisuuden.
En ehkä välttämättä täysin tavoittanut, mitä tarkoitit tällä kohdalla, mutta—edelleen—tässä on omasta mielestäni jälleen perusongelmana Duck Tagging -periaatteen hyväksyminen. Aiemmassa keskustelussa mainittiin, että myös highway=footway pitäisi jostain syystä olla mahdollinen arvo liikennemerkittömälle, mutta jollain epämääräisellä tavalla jalankululle ensisijaisesti tarkoitetulle väylälle. Kuten hyvin asian ilmaiset, en itsekään kyllä pysty hyvällä tahdollakaan hahmottamaan mitään mahdollisia, systemaattisia erotuskriteereitä highway=footwayn ja highway=cyclewayn välille liikennemerkittömällä tiellä. Ajatus tosiaan lienee, että kukin kartoittaja varmaan arpoo mielessään sopivan arvon. Tämä on toki erittäin epäoptimaalinen ja mielestäni lisäksi täysin tarpeettomasti epäjohdonmukainen tilanne (eritoten kun meillä on kuitenkin olemassa liikennemerkit). Itse en siis ylipäätään puolusta Duck Tagging -käytäntöä lainkaan, joten olen vähän jäävi kommentoimaan tätä kohtaa tai tuon footway-vaihtroehdon tarvetta tarkemmin.
Yksi mahdollinen ratkaisu—tai ainakin parannus—olisikin, että Duck Tagging -vaihtoehto hyväksyttäisiin vain highway=cycleway-arvolla. Sillion arvontaa footway-tagin kanssa ei tapahtuisi, vaan vaihtoehtoina liikennemerkittömälle väylälle olisi jokohighway=path + ominaisuustagit taihighway=cycleway ja foot, ym lisätagit. Oma ajatukseni on, että path-arvo (ja lisäkuvailutagit) olisi joka tapauksessa ensisijainen ja suositeltu tagitustapa, mutta cycleway (+ muut tagit) sisällytettäisiin ohjeissakin kompromissivaihtoehtona.
[EDIT:] Lisättäköön vielä highway=path-arvon ensisijaisuuteen liittyen, että bicycle=designated-arvo voi seurata myös reittimerkistä, ja on siten siis myös mahdollinen arvo highway=path-tielle. Aika monet erityisen hyvin pyöräilylle soveltuvat polut on myös reittimerkitty, joten highway=cycleway arvoa ei ehkä ihan välttämättä tarvittaisi erikseen merkkaamaan nimenomaan tätä ideaa. Ainakin tagitusperiaatteena se olisi johdonmukaisempi ja tarvittaisiin vähemmän ‘arvontaa’ tagien suhteen.
Juu, tämä on hyvä idea! Vanhan Wikikoodin tälle osuudellehan löytää, tarvittaessa, jatkossakin tuon wikisivun muutoshistoriasta, vuoden 2023 viimeisestä versiosta.
Yksi vaihtoehto voisi olla, että myös tiemerkinnät hyväksytään highway=cycleway-arvolle liikennemerkkien ohella OSMissa, vaikka pyörätiemaalauksilla ei lain voimaa olekaan. Tiemaalaukset, kuten suojatiet ja sulkuviivat, ovat osana tieliikennelakia, joten periaatteellisella tasolla tämä ei ehkä olisi suurensuuri lisäys OSMin tagitusperiaatteisiin. Tällöin cycleway ja service-arvot olisivat sekä intuitiivisia (esimerkiksi Baana säilyisi cyclewayna C2-merkeistä huolimatta, mutta päällystämättömät tai tiemerkitsemättömät tiet muuttuisivat service-teiksi C2-liikennemerkin takia) että tagituskriteerit johdonmukaisia (koska ne seuraisivat yksiselitteisesti tiemerkinnöistä ja liikennemerkeistä).
Hienoa @Tolstoi21 että innostuit tarttumaan uudestaan tähän syksyllä auki jääneeseen ohjeiden uudistukseen. Ajoituskin sopivasti juuri kun väylät taas kattavasti avautuvat lumen (ja sepelin) alta.
Tunnustan heti kärkeen olevani Duck Tagging -periaatteen kannattaja (linkiksi muillekin Richard Fairhurstin erinomainen argumentaatio, jossa osuvasti myös esimerkkinä cycleway vs. path: [OSM-talk] Fwd: Nav4All navigation shut down by Navteq). Richard tuntee erinomaisen hyvin OSM Data Consumer problematiikan, joka pohjana argumentaatiolleen.
Uusin ehdotus on (minun näkökulmastani) positiivinen loikka oikeaan suuntaan. Muutama kommentti kuitenkin ehdotuksen “pihviin”, sekä keskusteluun tässä säikeessä ylempänä:
Käyttäisin @Viiman tapaan ohjeellisena jakona: Tarkoitettu (liikennemerkillä osoitettu) vs. rakennettu (eli soveltuva) vs. sallittu (oletus, ei tietoa mille / kenelle soveltuu)
Tarkoitettu = liikennemerkein osoitettu, bicycle/foot=designated tagatty
Rakennettu = cycleway tai footway. Ehdotan että oletuksena on cycleway, koska se implikoi pyörän ja käytännössä myös jalankulun (kun ei ole designated eli liikennemerkkiä joka se kieltäisi!). Käytännössä olen siis samalla kannalla kuin @Tolstoi21 vaikkakin hieman perusteluissa variaatiota.
Sallittu, jäljelle jäävä kategoria eli @Viima sanoin “kulumalla syntynyt” = path / track
OSM-wikissä kieltämättä sanotaan että cycleway implikoi “designated”, joten ohjeissa voi hyvin sanoa, että tulisi lisätä bicycle ja foot tagit, mutta tärkeä huomio on, että vaikka ne tagit puuttuisivat niin siitä ei juuri tule harmia “Data Consumer” esim. reititysalgo tai karttatyyli tulkintoihin! Ts. ymmärrän tässä @Viima huolen, vaikkakin pragmaattisesti olen samalla kannalla @Tolstoi21 kanssa että nämä ovat redundantteja.
Lisäksi alla muutama pienempi / täydentävä huomio ehdotukseen:
“Pyöräilyjärjestelyt ajoradalla” on paljon vaihtoehtoja ja lisäksi sitä vaivaa OSM-datassa oleva ongelma jossa itse autotiellä on use_sidepath, cycleway:right tms. kaltainen tagays JA lisäksi on piirretty oma way pyörätielle / klv:lle. Nämä haasteet yhdessä ovat kartan renderoinnissa todella hankalia käsitellä, jotta kartta ei sotkuuntuisi tai olisi epäkonsistentti kirjavan OSM-datan takia.
Track ja Path kuvaukset lopussa: Ensisijainen tavoite on, että näitä käytettäisiin vain kulumalla syntyneihin (ml. traktorien tms. työn myötä) uriin. Sen lisäksi pitäisi kuitenkin tarkentaa ehdotuksen ohjeita: surface=unpaved ei kerro muuta kuin että ei ole asfalttia, ts. se voi olla myös gravel, ground, gravel tms. arkipyöräilyyn kelpaamaton. mtb:scale validit luokat ovat 0- ja 0.
Ylipäätään kartoittajien keskimääräinen kyky saada surface (muu kuin paved-luokat) ja smoothness tagays kohdilleen on tyydyttävän ja heikon välimaastossa, tehden näiden tagien hyödyntämisestä hyvin haastavaa. Ja siksi Duck Tagging on niin arvokasta.
Kiitos paljon myös @Zarzo lle erinomaisista kommenteista!
Ja sitten on vielä meitä hulluja, jotka ajamme pyörällä talven läpi, lumesta ja loskasta välittämättä .
Ja juu, Duck Tagging -periaate tosiaan jakaa mielipiteitä. Molemmilla puolille löytyy argumentteja. Ymmärrän osan argumenteista Duck Taggingin puolesta, vaikken niitä puolustakaan. Lopussa onkin tähän liittyvä kysymys.
Mutta aluksi enemmän (kiittäviä) kommentteja ja yhden väärinkäsityksen korjaus:
Hauska kuulla! Tämä tekisi tosiaan tagaamisesta yhdenmukaisempaa. Tämä tarkoittaisi myös sitä, että highay=footway jäisi jatkossa arvoksi vain ja ainoastaan liikennemerkityille tai lain tarkoittamille jalkakäytäville. Tämä olisi kyllä jo merkittävä parannus nykytilanteeseen!
Tähän sellainen tarkennus, että ymmärtääkseni Wikinkin mukaan tuo implikaatio seuraa joss Duck Taggingia ei hyväksytä. Myöskään itseen siis ole sitä mieltä, että molemmat access-arvot olisivat redundantteja. Ilmiselvästi redundantteja ja tautologisia pareja on ainoastaan foot=yes -tagi highway=footwaylla ja toisaalta bicycle=yes -tagi highway=cycleway-tiellä. cycleway ja footway -arvolle komplementti access tagi on olennaisen tärkeä lisätagi! Vielä toistona, tämän komplementtitagin tärkeys seuraa nimenomaan Duck Tagging -periaatteen hyväksymisestä: tässä tapauksessa, jos tiellä on ainoastaanhighway=cycleway-tagi (eikä siis mitään muita tageja), on epäselvää onko kyseessä liikennemerkitty pyörätie jolle ei ole lisätty oneway=*, ym. tageja vai juurikin Duck Tagattu liikennemerkitön polku, jolle ei ole lisätty foot=yes ja traffic_sign=no -tageja. Ainoa järkevä tulkinta on, että kyseessä on pyörätie (täsmälleen samasta syystä kuin pelkkä highway=path on pakko tulkita juurakkoiseksi kinttupoluksi). Pyörätiellä ei saa lain mukaan pääsääntöisesti kävellä. Eli haittaa kyllä tulee reititysalgoritmienkin kannalta, elleivät ne aika rohkeasti ohjaa epäselvässä tilanteessa lainvastaisesti kävelemään pyörätiellä.
Juu, jos ja kun Duck Tagging hyväksytään, tämä on se toinen tapa tehdä jotenkuten yksiselitteinen ja konsistentti jaottelu. Siinä tapauksessa ehdotuksen tekstiä pitää tosiaan vähän muokata. Toinen tapa olisi suosia pathia yhdenmukaisesti kaikille liikennemerkittömille poluille. Mutta ehkä tälle ei löydy enempää kannatusta? Seurataan tilannetta ja kommentteja saa laittaa puolesta ja vastaan!
Ja kiitokset @Viima lle muuten lisäyksistä ehdotussivun alkuun. Erityisesti liikennemerkkien vaikutusaluetta ja teiden haarautumista koskevat kohdat pitää siirtää itse ehdotustekstiin! Teen jossain vaiheessa.
Tämä on erinomainen ja osuva huomio! paved-arvo on mahdollinen ja marginaalisesti informatiivinen myös path-teillä, mutta koska unpaved sisältää yläkategoriana myös epätasaisia ja upottavia päällysteitä, sitä ei voi ohjeeseen sisällyttää. Kiitos!
Seuraavaksi vähän yleisempi pointti:
Olisi hyvä myös löytää myös konsensusta siitä, mihin tällaisilla ohjeilla ja normeilla pyritään. Omasta mielestäni selkeät ja mahdollisimman yksiselitteiset ohjeet ja normit ovat erinomaisen tärkeitä ohjaamaan tagitusta. On tästä tavoitteesta riippumaton seikka, kuinka hyvin näitä ohjeita tai normeja välttämättä aina käytännössä seurataan. Tämä ero on minusta ylätasolla aika tärkeä tunnustaa. Ohjeita ja normeja rikkovat voi kohteliaasti ohjata lukemaan ohjeistusta tarkemmin.
Joss ajoradan vieressä kulkee pyörätie, tielle kuuluu bicycle=use_sidepath-tagi. Joss ajoradalla on pyöräkaista, sille kuuluu cycleway:*=lane-tagi. On yksiselitteisesti virheellistä piirtää tielle, jolla on pyöräkaista, pyörätie erillisenä viivana. use_sidepath ja cycleway:*=lane -tagit ovat toisensa poissulkevia. Käytännössä tällaisia virheitä ehkä datasta edelleen löytyy, mutta sitten piirto-ohjeiden tarkoituksena onkin olla paikka, josta löytyy yksiselitteinen ja oikea ratkaisu tämän virheen korjaamiseen (nyt kuvineen ja esimerkkitapauksineen).
Toistettakoon, että olen itsekin korjannut muutaman kerran aloittelevan kartoittajan virheellisesti pyörätieksi piirtämän viivan paikasta, jossa tiellä on pyöräkaista. Pyöräkaistan ja pyörätien ero on ihan olennaisen tärkeä pyöräilijöille (monestakin syystä—ja ihan jo periaatteellisestikin—mutta konkreettisesti, esimerkiksi, vaikkapa siksi että pyöräkaistat ovat talvella usein täynnä ajoradalta aurattua lunta ja siksi ajoittain käyttökelvottomia, toisin kuin useimmat pyörätiet).
Mutta ehkä tämä olikin pointtisi, ja minä ymmärsin väärin?
Karttaa ei pidä koodata renderöijää varten. Datan epäkonsistenttiuteen auttaa paikka, josta löytää oikean tagaustavan, ja oikeat tagit. Piirto-ohje on yksi paikka tälle. Aiemmassa keskustelussa mainitut presetit koodaustyökaluihin ja -ohjelmiin esimerkiksi toinen. Vastaus kirjavan datan ongelmaan ei voi olla, että nostetaan kädet pystyyn ja annetaan kaikkien kukkien kukkia. Virheet pitää korjata. Yksiselitteiset ohjeet ja työkalujen presetit kertovat, miten.
Lopuksi vielä:
Minun on edelleen mahdotonta ymmärtää, miten voi yhtäaikaisesti olla toisaalta täysin ongelmatonta Duck Tagata tie cyclewayksi tarkastelemalla tien tai polun fyysisiä ominaisuuksia (kuten sen leveyttä ja tien pinnan tasaisuutta ja upottavuutta, kuten ohjekin nyt neuvoo) ja toisaalta jotenkin mahdoton ja ylitsepääsemätön ongelma tagittaa path-tie lisäämällä nuo täsmälleen samat tien tai polun fyysiset ominaisuudet niitä kuvailevilla ja koodaavilla eri tageille. Edes tarvittavien tagien lukumäärä ei ole olennaisesti eri. Vai perustuuko Duck Tagging johonkin muuhun kuin tien tai polun fyysisiin ominaisuuksiin? Mihin siis? Metafyysisiin ominaisuuksiin? Mututuntumaan ja kulloisenkin päivän fiilikseen? Tuo path tapaus ainakin olisi tagien suhteen johdonmukaisempi ja yksinkertaisempi (koska @Viima n ja Wikinkin mainitsemat implikaatiot suoraan highway-tagin arvosta pätisivät ja sen arvot seuraisivat liikennemerkkien olemassaolosta ja puutteesta), ja lisäksi jokainen voisi etsiä ja tarkata datasta juuri itseä kiinnostavat arvot.
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.
Ja kiitokset @Zarzo lle vielä vastauksesta ja selvennyksistä!
Tosiaan, päivitettyjen ohjeiden spesifeistä yksityiskohdista taidetaan olla tähän mennessä keskusteluun osallistuneiden kesken jo melko samaa mieltä ja niissä lähempänä konsensusta. Erimielisyydet koskevat enemmänkin ylätason periaatteita.
Duck Tagging -tapauksesta voisi siis seuraavaan päivitettyyn ehdotukseen poistaa highway=footway -mahdollisuuden. Ohjetekstiä pitää samalla vielä vähän viilata ottamaan paremmin huomioon tuon “Tarkoitettu ja liikenne- tai reittimerkitty/Rakennettu ja soveltuva/sallittu (ja kenties rakennettukin) mutta pyörälle epäsopiva” -kolmikon.
Mutta sitä ennen, lisämielipiteet nykyisestä päivityksestä ovat erittäin tervetulleita!
Jos ja kun footway poistuu Duck Tagattavien kohteiden joukosta, on mahdollista että löytyy sinänsä rakennettuja, mutta pyörälle epäsopivia teitä (joita ei siis siksi voi Duck Tagata highway=cycleway, vaan ainoaksi mahdollisuudeksi jää highway=path). Toisin sanoen, myös highway=pathvoi edelleen olla rakennettu, mutta pyörälle soveltumaton. Tämä vähän rikkoo tuota kaunista kolmijakoa, mutta ei ole sinänsä paha rasti. Voisin kevään ja kesän edetessä kuvata ja lisätä tällaisia kohteita ehdotukseen. Ensimmäisenä tulee mieleen vaikkapa—kylläkin rakennetut ja esimerkiksi päällystetyt—mutta hyvin kapeat (piha)polut, tai rakennetut ja leveät, mutta pienen nyrkin kokoisilla kivillä tai paksulla purukerroksella päällystetyt (ja siksi kapearenkaiselle kaupunkipyörälle upottavat) polut tai latupohjat (jotka on aika usein ehkä merkattu C2-liikennemerkillä ilman huoltoajo-oikeutta, joten track ei myöskään sovellu).
Myös tien fyyysisten ominaisuuksien kriteerit Duck Tagattavalle cyclewaylle täytyy ottaa ehkä paremmin huomioon tuossa osuudessa. Ne on toki mainittu path-osuudessa, mutta voisi vielä tiiviisti ja lyhyesti mutta nykyistä eksplisiittisemmin toistaa Duck Tagging -osuudessa.
Lisään kokonaan uutta päivitystä ennen vielä nykyiseen ehdotukseen @Viima n tekemät huomiot liikennemerkkien vaiokutusalueesta ja teiden haarautumisista itse ehdotustekstiin, ja poistan sufrace=unpaved -arvon osasta path-tapauksia.
Ihan muutama sananen vielä noista erimielisyyksistä:
Tällaisen tulkinnan voi tietysti tehdä. Ja kuten hyvin kuvaat, varmaan näin on joskus käytännön syistä pakkokin tehdä. Itse ajattelen, että pelkällä highway=cycleway-tagilla tagattuun tiehen tulisi suhtautua vähintäänkin selvästi epätäydellisenä, oikeastaan suorastaan virheellisenä tapauksena. Pelkästä cycleway-tagista kun ei voi totuudensäilyttävästi päätellä mitään siltä puuttuvia tageja, eli ominaisuuksia (siis, erityisesti jos ja kun Duck Tagging hyväksytään). Laadunvarmistusta ei kukaan voikaan tehdä, jos tällaiset tapaukset hyväksytään hiljaisesti, eikä ole selvää ohjetta, miten ne tulisi korjata.
Näkökulmia on erilaisia. Pyöräilijänä haluaisin tietää, onko pelkällä highway=cycleway-tagilla tagattu tie liikennemerkin määräämä pyörätie, yhdistetty jalkakäytävä ja pyörätie, vai liikennemerkitön polku. Tämä tieto käytännössä implikoi esimerkiksi (suurta tai pientä) keskinopeutta. Kun polkee pari sataa kilometeriä pitkää matkaa, mm. keskinopeusarvio on tärkeä. Nykyään suosin OSMin perusteella ajoratoja ja seututeiden piennarta, koska pelkkä cycleway on epäluotettava tagi. Ne pientareet ovat tulleet liiankin tutuiksi .
Ohjeisiin ja normeihin liittyen kieltämättä puhumme varmaankin vähän toistemme ohi. Mutta ehkä vain vähän.
Minusta OSM-datan realiteetti ja huono laadunvarmistus on (ainakin osittain, ehkä merkittävässäkin määrin) suoraa seurausta kelvottomasta ohjeistuksesta, joka ei nykyisellään ota oikeastaan ollenkaan kantaa tieverkoston alimman tason tagaukseen. Huonosta ohjeistuksesta seuraa suoraan myös esimerkiksi stabiilien presettien puute koodaustyökaluissa. Edelleen: laadunvarmistusta on mahdoton tehdä ilman sitä ohjaavaa kriteeristöä
Oma pointtini tuossa normien ja niiden toteutumisen erossa on se, ettei nykyisestä datan epäkonsistentista tilasta voi päätellä sitä, etteikö parempaankin pystyttäisi. Helppoa tai nopeaa tämä laadunvarmistus ei tietenkään (koskaan) ole, mutta tyhjän saa pyytämättäkin. Oma perspektiivini on, että kuudessatoista vuodessa on tultu pitkälle tyhjästä, valkoisesta karttapohjasta josta silloin aloitettiin. Ehkä kuudentoista vuoden päästä ollaan päästy polkujenkin tagauksessa pidemmälle. Tietenkään tämä ei ole mahdollista ilman selkeitä ohjeita ja normeja. Melko yksinkertainen keino asteittaisiin parannuksiin olisi jo, jos (esimerkiksi) pelkällä highway=cycleway-tagilla varustetusta viivasta tulisi virheilmoitus (ja viittaus ohjeisiin).
Tämän kehityksen myötä voin laittaa seuraavan iteraation “OSM Finland Trails” ryhmään - siellä muutama sata polkukartoittajaa, joista hyvin harva josko kukaan seuraa aktiivisesti tätä foorumia - mutta mukana on paljon pyörällä (maantie, gravel, mtb, työmatka) liikkuvia.
Samaa mieltä noista haastepaikoista eli “rakennettu” ei ole ihan absoluuttinen määrite joka sopii synonyymiksi “arkipyörälle soveltuva”. Ylipäänsä nämä kuntopolut jne. on hyvin kirjavasti nykyäänkin tagatty: siellä on cycleway, track, path, footway ristiinrastiin käytössä jopa samalla alueella. Onneksi suosituimmilla väylillä on kuitenkin lisätagit yleensä aika hyvin kohdillansa.
Olen samaa mieltä, että pelkkä päätagilla tagatty tie highway=cycleway ei ole tavoitetila (ja tämä pitää ohjeissa selvästi ilmaista) ja siinä myöskin on pieni epäilyn tuoksu leijumassa. Mutta en muista vielä törmänneeni tällä tavalla tagattyyn väylään joka ei olisi kelvollinen arkipyörällä liikkumiseen ts. siitä tehty oletus on ollut tähän asti turvallinen (mikä ei tietenkään tarkoita etteikö ongelmallisia väyliä olisi, mutta niitä ei ole helppo löytää).
Tältä pohjalta ymmärrän myös tuon toisen kommenttisi: silloin kuin on mahdollisuus ja aikaa katsoa tagit tarkkaan niin voi tehdä valintaa hienojakoisesti. Mutta kun annetaan tämä työ algoritmille niin joutuu hyväksymään seuraukset. Omassa fillaroinnissa (paikalliseen) keskinopeuteen kyllä enemmän vaikuttavat muut tekijät kuin mitä noista tageista voi yleensä päätellä ja ongelmat ovat myös erilaisia silloin kun liikutaan n. 23kmh vs. +33kmh nopeuksilla ts. päättely vaatii yleensä kartan katsomista kokonaisuutena ml. korkeuserot, ei pelkkä väyliä tägeineen.
Olen samaa mieltä että osittainen syy löytyy ohjeistuksesta ja siksi sen parantaminen on tärkeä asia. Sen arviointi miten hyvään on mahdollista päästä ohjeistuksen voimin ei ole helppoa. Yksi referenssi on surface-tagin käyttö: OSM-wiki ohjeistaa ponnekkaasti ja perustellen, miksi highway=* ei riitä vaan lisätagit, ml. / erityisesti surface olisivat tarpeellisia. Ja surface-tagin OSM-wiki on myös ihan kelpo. Liikenneväylät ovat myös karttaobjekti jota tutkii “monet silmät”.
Kun ajat Overpass haun ja katsot paljonko liikenneväyliä (pl. track & path) on ilman tai niissä on pätkiä ilman surface-tagia tai surface=unpaved niin kartta täyttyy huomattavan runsaalla sinisellä värillä…Kartan renderoinnissa tuota voi kiertää, moni karttatyyli ml. osm.org Carto ohittaa surface-tagin olkaa kohauttamalla. Reititysalgon kanssa ei näin voi tehdä. Ja kun sitten yritetään tehdä vaikkapa maantiepyörällä reititysprofiilia niin eri sovellukset käyttävät eri heuristiikkaa ongelman ratkomiseen ja Mapboxin kaltaiset toimijat korjaavat näitä puutteita jälkiprosessoinnilla & ottavat $$$ lopputuloksesta.
Miksi tämä laatuongelma? Itse uskon, että syyt ovat syvällä OSM:n rakenteissa (arvot, toimintamallit jne.) eikä ole näköpiirissä että ne korjautuisivat. Tästä muuten hyvää keskustelua globaalin OSM-foorumin Overture-keskusteluissa - osa näkee ym. perusteet Overturen syntymiseen, perinteisen linjan OSM-kannattajat eivät näe syitä, eivätkä siksi myöskään juuri perusteita kehittää mitään OSM:n tavassa toimia.
.