Kaupunkien korttelien landuse=* ja muut käytänteet

Terve taas.

Tässä pohtiessani Wiki-säätöä, päätin hieman kokeilla Tampereen keskustan uudelleen kartoittelua Berliinin-oppien pohjalta.

Tässä nyt vielä pikainen linkki alueelle, joka sisältyy tuohon testailuuni.

Alue siis käytännössä rajautuu Hämeenkatu - Hämeenpuisto - Satamakatu - Kirkkokatu rajalle, myös Värjärinkujan kaksi pohjoispuolista taloa.

Aloin työstämään Tampereen kaupungin ilmakuvan sekä virastokartan pohjalta uusiksi aluetta, kun huomasin sen olevan varsin suuripiirteisesti ja osin sekavasti piirrelty. Pian kuitenkin nuo hyvinkin sekalaisilla tavoilla merkatut landuse=commercial ja landuse=residential alkoivat häiritä; toisinaan olivat rakennuksissa kiinni, toisinaan vähän jossain siellä päin.

Ajattelinkin hyödyntäväni tässä(kin) Berliinin-oppeja; ryhdyin merkkaamaan korttelit kadun reunoihin asti käyttäen noita landuse-tageja. Samalla totesin, että merkkaanpa piirtämisen helpottamiseksi myös area:highway-tagit. Kyseiset tägit ovat ainakin Berliinissä (ja Itävallassa?) kovassa käytössä, kun heiltä löytyy aktiivisessa käytössä jokin karttasivusto joka ne myös renderöi. Suomen tapauksessa nuo taitavat olla ns. turhaa infoa, mutta ainakin itselläni selkeyttävät alueiden piirtoa sekä rakennuksien kohdistamista. Samalla nuo tien reunaan asti vedetyt landuse-piirit auttoivat kartoittamisreissulla muistiin laitettujen pisteiden ja valokuvien kohdistamista ainakin suurinpiirtein oikealle kohdalle ilmakuvan kanssa.

Ajattelin nyt jakaa tässä vaiheessa kuitenkin keskustelulle tämän, ennen kuin jatkan raivokkaammin kortteleiden uusimista. Ihan vain, jos jollakulla on näkemyksiä tai sanottavaa asiasta.

Jonkin verran olen lueskellut Berliinin tyylistä kritiikkinä, että se on “kartoittamista ulkonäön takia”, mutta pidän tuota ehkä vähän outona kritiikkinä… tavallaan joo - landuse näyttää katujen muodon tavallaan kiertokautta. Nähdäkseni se on kuitenkin sivutuote tyylissä kartoittaa, joka antaa landuse-tageille selkeän ja hyödyllisen käyttöpohjan pelkän rakenuksiin kiinnitettävän taikka suuripiirteisesti sinne tänne heitettyjen pisteiden sijaan. Ja kuten yllä todettu, ainakin itselleni niistä on ollut suuri apu esimerkiksi lyhtypylväiden, parkkipaikkojen ja highway=footway yms. merkkailussa siististi ja selkeästi.

En usko kuitenkaan, että tämä tyyli välttämättä olisi kovin hyödyllinen kaupunkien keskustojen ulkopuolella, vaan lähinnä pätevä ja selkeyttävä tyyli informaatiotiiviillä alueilla kaupunkien keskustoissa. Niiden ulkopuolella ja/tai harvempaan rakennetussa maastossa laajemmat ja yleisluontoisemmat landuse-tagaukset ovat varmaankin toimivampia.

Että tällaista nyt tällä viikolla nysvätessä tuli mieleen. Saa ottaa kantaa keskustelussa, täällä on varmasti hyviä näkemyksiä ja mielipiteitä asian suhteen, joten käytetään hyödyksi nyt kun olen forumin löytänyt :)

1 Like

Siistin näköistä Cartossa, enpä oikein osaa antaa parempaakaan palautetta sillä detaljitasolla millä tekeminen tässä on :)

@Zarzo trailmapissa kohdealue korostuu mielestäni epätoivottavalla tavalla, mut enpä yhtään muista oliko siellä tuollaista jo ennestään.

Tästä parkkisten renderöinnistä yleisesti on ollut puhetta ennenkin.

2 Likes

Juu, tässä toteutuu vähän muna-ja-kana -ongelma. Kun ei ole helposti saatavilla olevaa karttatasoa, joka renderöisi tageja, niin ne jäävät alikäytölle vaikka olisivatkin käteviä. osm.org-sivun oletuskartan, eli Carton ja Mapnik-renderöijän, kehitystyö on kaiketi aika jumissa. Toinen ongelma on, että haja-asutusalueille ei ole saatavilla riittävän tarkkoja ilmakuvia, joiden kautta tarkkojen geometrioiden piirtämien ja mikromappaaminen olisi kätevää ja helppoa.

Ihan vain vinkkinä: kannattaa ehkä katsoa esim. omasta mielestäni erittäin mielenkiintoinen taltiointi Dustin Carlinon samasta aiheesta tekemästä esityksestä SOTM 2022 -konferenssista.

Juu, samaa mieltä noin ylipäätään! En sitten tiedä, sotkeeko tämä tagitus pahasti joitain reititysalgoja. Osaisikohan vaikka @houtari ottaa kantaa HSL:n ja OTP:n kannalta?

Ihan yksinkertaisena esimerkkinä vaikkapa ei-ympyrämäiset, isot kääntöympyrät, kuten tämä Lauttasaaressa. Tietysti turning_circle-noodi Katajaharjuntien ja Koilisväylän risteävässä pisteessä ajaisi topologisesti saman asian, mutta tuo area kertoo, että kyseessä ei ole suorakulmainen T-risteys (tai ⊢-risteys)—ja alue, jossa bussi mahtuu kääntymään—vaan Katajaharjuntieltä pääsee viistämään loivassa kaaressa ja isollakin nopeudella Koillisväylälle. Pyörällä ihan hauskaa, koska Katajaharjuntiellä on pohjoiseen päin mukavan loiva mutta pitkä alamäki :wink: .

Joo, meikäläisestä on vähän hassua, että access=private jne. pysäköintialueet paukahtaa renderöinneissä herkästi näkyville… Japanin osalta on esimerkiksi ollut neuvona merkata vain kaikki kartalle, joka tekee kyllä melkoista sillisalaattia aktiivisesti tagatyistä paikoista, kun parin ruudun parkkipaikkoja on joka nurkassa ja niiden välissä.

Ehkäpä voisin tyytyä merkkaamaan ainakin toistaiseksi vain nuo julkiset/avoimet/maksulliset, joista on ehkä enemmnän hyötyä yleisessä käytössä.

Menee heti katseluun, katsotaanpa mitä sieltä löytyy!

Aivan, eipä käynyt mielessä että tuo area:highway on tosiaan arean… alitagi?

Nuo ovat kuitenkin merkattu ainoastaan area:highway=residential tai area:highway=primary jne. tageilla, ei erikseen highway-tagilla, joten ei pitäisi käsittääkseni sekoittaa reitittelyä?

Toki en ymmärrä tarpeeksi tuosta reitinhausta vielä, joten tosiaan hyvä huomio tuoda esille jota en edes ajatellut! Jos tuo sotkee reitinhakua, kannattanee ne jättää tekemättä ellei ole satoja kiinnostuneita korjaajia käytössä… :smiley:

Lisämainintana tähän vielä siis se, että olen toistaiseksi vain rajannut nuo landuse=* tagit uusiksi, sekä oikonut ja korjannut teiden ja jalankulkureittien jne. reittejä. En ole puuttunut vielä varsinaisesti tietason tägeihin ja niissä olevaan informaatioon, enkä esimerkiksi korjannut sen kummemmin risteyksien ja suojateiden yms. tagajä. Otan ehkä niihinkin kantaa, kunhan nyt rakennukset on ensin päivitelty siltä osin, kuin jaksan, pystyn ja osaan.

osm2streets-projekti näyttäisi keskittyvän noihin teiden way-tagayksiin, joten täytyypä lueskella aiheesta lisää kun pääsen niin pitkälle. Onko siis tuon tyylinen tagaily se tavoite, sen sijaan että esimerkiksi kadunvarsipysäköintejä merkittäisiin alueina?

Suunnilleen näin minäkin asian järkeilin, mutta vaikea sanoa pitääkö tämä universaalisti paikkaansa.

Mainitsin tämän osm2streets-projektin—ja videossa viitataan vissiin itsekin viittaamasi Straßenraumkarteen—koska minusta molemmat tarjoavat mielenkiintoisen ja vaihtoehtoisen näkökulman OSM dataan. Molemmat yrittävät ratkaista juuri tuota muna-kana -ongelmaa tuomalla esiin eri tageja ja eri tagitustyylien mukanaan tuomia ongelmia datan tulkitsemisessa.

Jossain SOTM-konferenssissa oli myös yksi puhe, joka käsitteli area:-tagin käyttöä myös mm. =cycleway ja =footway -arvojen kanssa. En heti löytänyt linkkiä, muistaakohan joku muu?

1 Like

Katsoin tätä @aktiivimallikansalainen nostoa vain pikaisesti, pahoittelut jos kommentointi epätarkkaa kun en ehättänyt perehtyä kaikkiin yksityiskohtiin.

Oliko tuon parin korttelin alueella siis lisätty kattavasti area / amenity=parking kadunvarsipaikoista? Kuten @aktiivimallikansalainen laittamasta Trailmapin kartan kuvakaappauksesta näkyy niin tekee kartasta tosiaan aivan liian tukkoisen tuolle alueelle.

Aiemmin käytetyt oletukset tagayksesta on ollut, että amenity=parking käytetään lähinnä isommista parkki-alueista, jolloin on ollut mielekästä renderoida ne isommalla P-merkillä helpottamaan niiden löytämistä karttaa nopeasti vilkaisemalla. Havainto on ollut jo aiemmin, että Euroopankin osalta eroja on paljon eri kaupungien osalta - siksi karttatyyli on nyt jo erotettu Suomi vs. Eurooppa ja jälkimmäisen osalta optimointityötä on vielä enemmän tehtävänä. Eli tuttua sovelluskehittäjän haastetta OSM-datan kanssa kun sekä data-skeema, kattavuus ja laatu vaihtelevat huimasti eri alueilla.

Täytyy jossakin välissä katsoa onnistuuko kartan pohjana olevan vektoritiiligeneroinnin yhteydessä tai sitten tagien pohjalta erottaa nämä kadunvarsipaikat, jotta ne voisi suodattaa pois.

Väylien geometrioista (osin tagayksesta) ja tuosta osm2streets-hankkeesta. @Tolstoi21 kiinnostava nosto! Täytyypä tutustua jossakin välissä kunnolla, nyt selailin vain nopeasti videon kelmuja lävitse.

Trailmap-sovellukseni osalta kevään iso ponnistus oli toteuttaa “käännös käännökseltä”-navigoinnin opastus (eli autonaveista tuttu ns. Turn-by-Turn navigointi). Julkaistu nyt Trailmapin mobiilisovelluksessa. Tavoitteena oli helpottaa erityisesti pyöräreittien navigointia, vaikka sopii kyllä tossuillakin liikkumiseen. Trailmapin fokuksen mukaisesti pyrin ratkomaan sekä “urbaanien katujen” ongelmaa, mutta erityisesti kulkua ulkoiluväylillä, poluilla ja hiljaisemmilla teillä.

Osasin arvella ym. toimintoa isoksi haasteeksi, mutta kyllä se vielä hieman pääsi silti yllättämään mittakaavaltaan. Reititysmoottoria (Graphhopper OSS) on tullut jo aiemmin modattua kattavasti, tämän askeleen myötä on jo hyvin kaukana alkuperäisestä.

Yksinkertaistettuna isoin haaste on tulkita OSM-dataa (geometriat ennen kaikkea) vastaamaan sitä mitä kulkijat oikeasti kohtaavat ulkona kulkiessaan. Yksi osa haastetta on tuo osm2-streets-projektin fokuksessa olevat monimutkaiset rakennetut risteykset. Aivan toinen haaste on sitten kevyen liikenteen väylät, ulkoiluväylät jne.

Vaikka OSMssa on monasti geometriat väylillä “roughly right”, niin risteyksissä laatu on huomattavan heikkoa - veikkaisin keskeiseksi syyksi sen, että hyvin harva on joutunut miettimään miten TbT-navigoinnissa joudutaan tekemään päätelmien risteyksien väylien kohtauskulmista ja onko esim. 4-väylän risteys “yksi risteys” vai 2 hyvin lähellä toisiaan olevaa erillistä risteystä. Kartan renderoinnissa nämä ongelmat eivät niinkään ilmene, koska kartan visualisointia ihmiset tulkitsevat väljästi. Navigoinnissa käännösopasteet taas joudutaan generoimaan hyvin tiukasta karttadatan perusteella ja vaikka päälle voi lisätä erilaista heuristiikkaa niin se on hyvin kompleksista ja vikaherkkää.

Jos aihe kiinnostaa tällä foorumilla, niin voin tästä hieman brieffausta kirjoitella lisäämään ymmärrystä siitä miltä OSM-data näyttää navigaattorin näkökulmasta.

Lisäsin kaikki kadunvarsipaikat alueina SEKÄ kerrostalojen yms. yksityiset parkkipaikat.

Tämä siis periaatteella “all data is good data, if it’s correct”, mutta vähän tuossa rupesi jo käymään mielessä, että tässä tapauksessa täytyy ehkä “map for the renderer”. Ainakin toistaiseksi.

En tiedä, onko kadunvarsipaikat tuossa varsinaisesti se ongelma, vaiko sitten nuo talojen keskellä olevat yksityiset, jotka ei kyllä ainakaan reittihakusovelluksissa ja muissa sellaisissa ole hyödyllisiä. Jossain muussa käytössä kyllä. Olen ne merkannut access=private, joten sen perusteella tietysti pystyy niitä sulkemaan pois, kun täyttyy kaksi ehtoa.

Itse highwayhin merkatut parkkipaikkatiedot on taas ongelmallisia, ellei käytä jotain erillisiä plugareita (?) kartoitusapuna, koska ainakin itselle aiheuttaa harmaita hiuksia löytää nuo tuolta seasta äkkiseltään. Ajattelin kyllä käydä nuo läpi ja lisätä vielä itse teihin(kin), kun vähän pidemmälle kartoittanut tuota keskustaa uusiksi.

En tiedä, missä tällainen oletus on kerrottu. Ei ainakaan wikissä?

Ja tästä taas päästään siihen, että pitäisi ehkä jaksaaehtiä tehdä se selkeä luettelointimallinen tyyliohje… :)

“Aiemmin käytetty oletus tagayksesta…” viittasi Trailmap-tiimimme oletukseen, joka tehty OSM-dataa tarkastelemalla. Ei siis suoraan viittaus Wikiin tms.

OSM-datan hyödyntämisessä (esim. sovelluksissa tai palveluissa) käytännössä luetaan ensin eri wiki-artikkeleita ja usein sen päälle OSM-foorumien keskusteluita, jotta ymmärretään ohjeistuksen lähtökohdat: Kuinka tarkka ohjeistus on, onko konfliktoivaa ohjeistusta, mitkä asiat jäävät auki jne.

Sitten katsotaan dataa (Overpass, TagInfo ja omat työkalut) eli miltä kartoituksen käytäntö näyttää (erityisesti variaatio ohjeiden tulkinnoissa) ja mahdolliset muutossuunnat.

Tämän pohjalta sitten rakennetaan omat oletukset datan kattavuudesta, tarkkuudesta, kehityksestä ja riskeistä. Joskus rakennetaan myös oma malli datasta, tavallaan käännöskerros, joka ottaa sisään raakaa OSM-dataa ja tuottaa siitä laadukkaamman lopputuloksen - esimerkiksi väylien “surface”-tagin hyödyntäminen vaatii käytännössä tälläisen, jos tuosta tagista jotain hyötyä haluaa saada.

“Map for the renderer” on tässä mielessä monitulkintainen käsite. Sen paras tulkinta on mielestäni se, että ei vääristellä (tagata väärin) dataa, jotta jokin yksittäinen sovellus näyttäisi ja käyttäisi dataa halutulla tavalla. Toisaalta kys. ohjetta on välillä tulkittu laajemmin niin, että kartoittajan tehtävä ei ole murehtia dataa hyödyntävien (“consumers”) sovellusten asioista - tämä taas mielestäni turhaan rajaa kartoituksen hyötyjä, joka on mielestäni jo nyt iso OSM:n keskeisin haaste - eli vaikka dataa ja kartoittajia on paljon, niin merkittävästä osasta dataa saadaan varsin vähäistä hyötyä muille kuin kartoittajille.

2 Likes

Aivan, aivan. Selkiytti heti. Aika usein tulee vastaan vain kommentointeja tuolla samalla maininnalla, jolloin viittaillaan jossakin käytyyn keskusteluun, mistä ei kuitenkaan löydy mainintaa wikistä jne. Tämä hämäsi.

Tästä olen samaa mieltä.