Saksankielisellä foorumin osalla näkyy olevan ketju pienille kysymyksille, eli varmaankin sellaisille, jotka eivät esittäjän mielestä tunnu oman ketjunsa perustamisen arvoisilta, mutta joihin olisi mukava saada vastaus. Pitäisikö kokeilla lainata ideaa?
Aloitan pelin: onko olemassa jokin tapa, millä osmin wikiin voisi tehdä karttalinkin osoittamaan tiettyä katua? Johonkin yksittäiseen wayhin linkittäminen onnistuu kyllä, mutta katu (esim. Mannerheimintie) voi koostua useista pätkistä. Onkohan yhden nimen alla oleville kadun pätkille kehitelty jokin relaatio, johonka sitten voisi linkittää?
Kysymyksen taustalla oli tuosta katunimien vaihtumista koskevasta ketjusta syntynyt ajatus, että wikiin voisi olla kätevä linkittää kunnittain kaikki tiedossa olevat kadut, joiden nimi esim. kuntaliitoksen vuoksi on vaihtunut. Näin olisi helpompi todeta ja tarkistaa vanhojen katunimien löytyminen osmista old_name-tägättyinä. Saa toki kommentoida olisiko tällaisessa listassa mieltä
Miettynyt joskus samaa, kun maastotutkimusten lomassa syntyy kysyttävää. Mutta kymysykset pääsee unohtumaan, kun on päässyt koneelle asti.
Mielestäni “talonumerorelaatiota” voi käyttää mainitsemaasi linkitykseen. Tosin myös kadun/tienvarren rakennuksetkin korostuu kartassa tyyliin Suonenjoentie, Äänekoski.
Mieltä ehkä, mutta taidamme olla liian laiskoja ylläpitämään niitä. Nimim. kokemusta on
Tietyn yhtenäisenkin kadun linkittäminen relaatiolla on parempi kuin mainitsemasi way-linkki. Jos joku katkaisee kadun esim muuttuvan nopeusrajoituksen takia tms. niin katkoskohdan molemmat puolet kuuluvat vielä automaattisesti siihen relaatioon. Ainakain noilla editoreilla, mitä olen käyttänyt. Eli katkaisun jälkeen way-linkki näyttää vain osan kadusta mutta relaatiolinkki näyttää yhä koko kadun.
Totta, relaatio on ehdottomasti paras ratkaisu. Pienen selailun perusteella relaatio “type=street” vaikuttaisi sopivalta yleiskäyttöiseltä tierelaatiolta, joka jossain määrin on jo käytössä. associatedStreet-relaatiossa ei saisi olla kuin yksi way-elementti, joten tässä olisi sama ongelma kuin pelkän wayn linkkamisessa.
Kuten kaikilla muillakin ehdottomasti parhailla ratkaisuilla, niin kyllä tässäkin on myös omat huonot puolensa. Suomen aineistossa on nyt kai reilut 13000 relaatiota ja muunnosohjelmilla menee niiden käsittelemiseen karkeasti ottaen puolet ajasta. Muutama kymmenen tuhatta street-relaatiota lisää luultavasti kaksinkertaistaisi tai moninkertaistaisi aineiston lukemiseen tarvittavan ajan. Sinänsä on ihan mielenkiintoinen ajatus koota tiet yhteen relaatioiden avulla. Tämä on ikään kuin käänteinen ratkaisu verrattuna esimerkiksi Digiroadissa käytettävään dynaamiseen segmentointiin, jossa tiet on tallennettu kokonaisina ja ominaisuustietojen vaikutusalue kerrotaan etäisyyksinä tien alkupisteestä (nopeusrajoitus alkaa pisteestä, jonne on lähtöpisteestä matkaa 20 % tien kokonaispituudesta, ja loppuu siinä, missä etäisyyttä on 30 %).
Jos tälle hyvälle ominaisuudelle ei ole vielä tiedossa tuon linkittämisen lisäksi muuta hyötykäyttöä, niin voisi ehkä ensin harkita, kannattaako siitä maksaa sitä hintaa, mikä tulee tietojen hitaammasta prosessoinnista ja siitä, että muokkausohjelmat edelleen joskus rikkovat relaatioita. Toisaalta, mitä nopeammin OSM:ille luodaan ongelmia, sitä nopeammin joku keksii ratkaisuja joilla niistä selvitään.
Millä tavalla merkitään saman kohteen eri osastojen aukioloajat? Tämä siksi, koska esim. Äänekosken (pää)kirjastossa lehtisalilla on eri aukioloajat kuin lainausosastolla, jonka aukioloajat poikkeavat taas musiikkiosaston vastaavista.
Mitäs mieltä olette “keksimästäni” admin=ref -avaimesta? Olen tässä ehkä noin kuukauden ajan merkinnyt viisinumeroisia seututeitä tuolla avaimella (tyyliin admin_ref=12345). Tarkistin äsken tägi-infosta ja huomasin, että en ole ainoa avaimen käyttäjä. admin_ref -teitä löytyy myös Californiasta, Walesista sekä Benelux-maista. Suomi on yliedustetusti hyvänä ykkösenä (86 kpl/109 kpl)
Relaatioiden käsittelyn raskautta ei ole tullutkaan ajateltua, kun muunnoksille ei itsellä kovin usein ole ollut tarvetta. Hyvä että otit esille. Millä muunnostyökaluilla relaatiot aiheuttavat eniten ongelmia hidasteena?
Tuohon mainittuun linkittämistarkoitukseen voisi toki käyttää ihan osmin pääsivun kartan permalink-linkkejäkin, jotka avaisivat aina saman kohdan kartalta halutulta zoom-tasolta. Tagien sisällön saisi sitten tarvittaessa näkyviin “Edit | Browse map data” -toiminnolla tai avaamalla Potlatchin tai muun editorin. Vanhanaikainen mutta kenties tässä tapauksessa asiansa ajava ratkaisu.
Kommentistasi nousi mieleen heti pikkukyssäri jatkoksi: Millä työkaluilla on kätevintä erottaa OSM-raakadatasta omaan käsittelyyn tarpeeton materiaali irti (esim. massiiviset määrät landuse-tägättyjä alueita)? Josko jollain tagien nimiin perustuvalla leikkelytyökalulla saisi karsittua myös ei-toivotut raskaat relaatiotkin pois, jos niitä jatkossa enenevissä määrin luodaan eri tarpeisiin. Mahtanevatko mahdolliset MML-aineistojen importit hamassa tulevaisuudessa vaikuttaa relaatioiden määrään missä määrin.
Kaikilla työkaluilla, jotka yrittävät ratkaista relaatioiden ongelman, mutta erityisesti niillä, jotka muuntavat tietoa OSM-tietomallista perinteiseen GIS-tietomalliin, kuten osm2pgsql:llä. Relaatiothan koostuvat node- ja way-osista ja pahimmillaan vielä toisista relaatioista. http://wiki.openstreetmap.org/wiki/OSM_XML
Relaatioita ratkottaessa kaikki node:t, way:t ja relaatiot on oltava saatavilla, eikä yhtään niistä voida heittää pois ennen kuin kaikki relaatiot on kahlattu läpi, koska viimeisen relaation viimeisenä jäsenenä voi olla koko tietopaketin ensimmäinen node. Muistista ja SSD-levyltä relaation jäsenten poiminta onnistuu nopeasti, mutta jos joudutaan käyttämään hidasta levyä tai tietokantaa välimuistina, niin homma hidastuu.
OSM:in multipolygonirelaatioiden muuntaminen GIS-maailman polygoneiksi on kaikkein hitainta, koska GIS-polygonien rakentaminen viivanpätkistä ei ole ihan suoraviivaista hommaa. Heh.
Viivamaisten relaatioiden ratkaiseminen on nopeampaa, mutta en osaa sanoa kuinka paljon nopeampaa. Siihen vaikuttaa myös valittu strategia, jos relaatioiden viivoista vain koostetaan MultiLinestring niin se on nopeampaa kuin jos viivat sulautetaan yhdeksi Linestringiksi.
MML:n aineiston vaikutus relaatioihin tulee ehkä siitä, että järvien rantaviivat tarkentuvat ja yhdellä rinkulalla piirretyt järvet täytyy muuttaa relaatioiksi. Saaria puuttuu varmaan valtavia määriä ja niistä jokaisesta tulee myös relaation osa. Muuten kai maastotietokannassa ei ole hirveästi mitään mistä pitäisi tehdä relaatioita.
Er… Tuo eri osista koostettu kokonaisuushan (eli malliesimerkkinä juuri tiepätkistä koostuva tie) on se jota varten relaatio on kehitetty. Se määrittelee osista koostuvan, myös mahdollisesti kartalla näkyvän kokonaisuuden. On aika rankka vaatimus, että OSM:n ulkopuolisen muunnosohjelman rajoitteet rajoittaa mitä OSM kantaan saa laittaa ja mitä ei.
En minä ainakaan ole vaatinut, ettei relaatioita saa tehdä. Mutta tuskin siitä on suurta haittaa, jos etukäteen miettii mitä sivuvaikutuksia suuresta määrästä uusia relaatioita mahdollisesti seuraa. Eihän esimerkiksi multipolygonirelaation käyttöä ei voi edes välttää, mutta kyllä siitä huolimatta on lupa olla sitä mieltä, että hyödyllisyydestään huolimatta multipolygonirelaatio ei ollut täydellinen keksintö http://wiki.openstreetmap.org/wiki/The_Future_of_Areas
Ohjelmistojen asettamat rajoitteet on otettu OSM:ssa huomioon esimerkiksi rantaviivan käsittelyssä, josta ei ole tehty relaatiota, vaikka se onkin osista koostuva ja kartalla näkyvä kokonaisuus. Yleisesti hyväksytty periaate tuntuu olevan sekin, että korkeuskäyriä ei tuoda OSM:iin. Mutta sitten ei enää löydykään yhteistä käsitystä siitä, onko kiva, että Ranskan data muodostaa noin 1/6 koko maailman OSM-datasta ja suurelta osalta Ranskan kiinteistörekisteritietojen tuonnin ansiosta.
Minulle OSM on vain paikkatietoa, enkä oikein osaa sanoa mikä olisi OSM:n ulkopuolinen muunnosohjelma. Eihän OSM-tietoja OSM-XML tai pbf-muodossa oikeastaan käytä mitkään muut ohjelmat kuin OSM-editorit. Kaikessa muussa minun mieleeni tulevassa käytössä XML ja pbf ovat vain siirtoformaatteja. Mutta ei siis mitään pahaa sanottavaa relaatioista, varsinkaan, jos on mielessä joku hauska käyttötapaus niille. OSM:in mallista, jossa työnnetään ihan kaikki tieto samaan kasaan josta sitä sitten lajitellaan tagien perusteella, seuraa lähes väistämättä myös se, että relaatioiden lisääntyminen tekee kaiken OSM:iin liittyvän tekemisen raskaammaksi, mutta edut voivat hyvinkin voittaa pienestä hidastumisesta aiheutuvat haitat.
Taisit unohtaa muuntimet, kuten mkgmap (Garmin-muotoon) ja eri karttasovellusten omat muuntimet (OsmAndMapCreator yms.).
Totta. Kaikki tavara (vaikkapa tagittomat viivat) on luettava sisään ’varmuuden vuoksi’, koska jokin kiinnostava relaatio saattaa tarvita niitä. Samaten relaatiot hankaloittavat elämää silloin, kun kartta on jaettava palasiin esimerkiksi Garminin kokorajoitusten vuoksi.
Hyvä, Oli mahdollista tulkita myös että relaatioita ei ainakaan rohkaista tekemään "Jos … ei ole vielä tiedossa tuon linkittämisen lisäksi muuta hyötykäyttöä, niin voisi ehkä ensin harkita… "
Mutta olen myös sitä mieltä, että kaikkea, josta voi tehdä relaation ei välttämättä kannata tehdä relaatiota. ja kaikkea mitä voi syöttää OSM kantaan ei ehkä kannata sinne syöttää.
Ai? Tein muuten toissatalvena suoraan tuota OSM XML:ää läpikäyvän ohjelman, joka kaivoi syötetyistä moottorikelkkareiteistä risteykset, umpikujat ja tuplapisteet. Ne kun sitten piirteli kartalle, niin pystyi hyvin havainnollistamaan missä on reitillä katkoksia ( kaksi umpikujaa vierekkäin) missä on syötetty sama reitti useaan kertaan (tuplapisteitä) ja mihin reittien risteämisiin olisi tarve lisätä risteys (risteys puuttui). Lopputulos oli OSM XML kanssa riittävän samankaltaista, että Maperitivella sain piirrettyä haluamani asiat kartalle.
Mitä olen osm2pgsql:n koodia katsonut. Ainakin route relaatiot parsitaan yhteen jo ennen kantaan tunkemista niin että kaikki suoraviivaisesti joinittavissa olevat osat yhdistetään yhdeksi LineString:ksi. Käytännössä Y/X/jne. -haaroista menevät siis poikki ellei joku way jatku risteyksen “läpi”. Muista type:istä en osaa sanoa mitä tehdään.
Yksi, ei tosin ehkä monen mielestä kauhean helppo tai elegantti, vaihtoehto olisi toteuttaa tuo tekemällä kadusta geojson:ia tms ja lataamalla se staattisesta filestä sitten openlayersillä. Huonona puolena tuossa tietenkin olisi se että geojson olisi staattinen file joten jos osmissa joku way vähän siirtyy se ei olisi enää ihan kohdallaan. Tämänkaltaisessa käyttötapauksessa sillä toki olisi ehkä suurta väliä mutta yleistä ratkaisua tuosta ei kyllä ehkä irtoa (jos on oletettavissa että relaation sisältö on dynaamisempaa).
Minä tulkitsen omaa kirjoitustani, joka on yllä lainattuna kokonaisuudessaan, niin, että en rohkaise tekemään relaatioita miettimättä, mitä hyviä ja huonoja vaikutuksia niiden lisäämisellä on. Faktoja miettimisen pohjaksi minulla ei ole kovin paljon tarjota, kunhan mietiskelen. Otin kuitenkin jotain numeroita talteen tämän hetken tilanteesta. Kannassa näyttäisi nyt olevan 1984 kpl route-tyypin relaatiota, jotka ovat sisältönsä puolesta samanlaisia kuin nuo street-relaatiot. Niiden muuntaminen GDAL:in OSM-ajurilla kesti omalla standarditietokoneellani 9 minuuttia ja 35 sekuntia. Voin ottaa uuden kellotuksen sitten, kun street-relaatioita on myös pari tuhatta; erotuksen voisi olettaa kuvaavan edes jossain määrin raskauden lisääntymistä; ei varmasti kovin hyvin, koska kuten aikaisemmin on ollut puhetta, ennen ensimmäisen relaation selvittämistä on selvitettävä kaikki tutkittavan alueen nodet ja wayt ja valtaosa tuosta mittaamastani ajasta varmaankin kuluu siihen. Parempi silti elää puutteellistenkin faktojen kanssa kuin kokonaan ilman faktoja, kunhan tiedonkeruumenetelmä on kaikkien tiedossa.
Minä en tarkoita sanoa, että mahdollisesti rikki oleva pyöräilymatkailureitti olisi syy kieltää katurelaatioiden tekemistä. Minulle se on kuitenkin vihje siitä, että kerran tehty relaatio ei välttämättä pysy ikuisesti kunnossa ilman huolenpitoa. Sitä voi sitten harkita, että onko siitä mitään haittaa, vaikka joku katurelaatio olisikin välillä rikki, kun todennäköisesti valtaosa niistä pysyy jatkuvasti huippukunnossa.
Olisikohan kuitenkin oikein sanoa, että ei ole monta sellaista ohjelmaa, joka käyttää noita tiedostomuotoja silloinkin, kun tiedot eivät enää mahdu ohjelman muistiin yhdellä kertaa? Maperative on sellainen kuten myös ehkä jo muinainen Osmarender. Muunnosohjelmat kuten osm2pgsql ja myös mkgmap eivät mielestäni kuulu tuohon joukkoon koska niiden tarkoitus on nimeomaan lukea OSM-formaattia ja tehdä siitä jotain, joka toimii tehokkaammin jollakin muulla ohjelmalla.
Mietin tässä esimerkkinä toimivan associatedstreet -relaation funktioita. Mitä lisäarvoa se tuokaan meille. Tuolla Suonenjoen tien pätkällä ei kauheasti ole osoiterakennuksia. Nyt siihen on jäsennetty osuuskauppaliikkeen bensisräkäläostoshelvetti. Samoissa maisemissa on myös kohta Suomesta katoavan simpukkapuljun bensisräkälä (ei ole jäsennetty). Suoralta kädeltä muistelin väärin; tien varrella onkin toistakymmentä osoitekohdetta.
Toisekseen arvelen, että tuo relaatio jatkuu liian pitkälle itään. Relaation suurin osa sijaitsee postinumeroalueella 44250 (Äänekoivisto), kun taas viimeistään idemmän rajanylityksen kohdalla postinumero olisi 44200 (Suolahti), jos rajan ja seututie 642:n välisellä osuudella olisi osoitteita. Epäselvää on myös Laukaan kiilassa sijaitseva Äänenkoskentie 830, että onko se kuitenkin alueella 41370 (Kuusa)?
Niin se on. Kukahan tekisi vaikkapa automaattisen bussireittitarkistimen? Huomasin tänään, että piirtämäni HSL 731 ja 731N oli rikottu molemmissa päissään sekä Mikkolassa. Tarkoitukseni oli vain vahvistaa syksyn reittimuutokset eli poistaa 731 ja nimetä 731N 731:ksi, mutta sainkin huhkia pidempään JOSMin varressa. Syyllinen näyttäisi olevan uusi Potlatch 2 -käyttäjä. Kirjoitanpa ystävällisen kehotuksen kokeilla JOSMia.
Lisäys: Mikään ohjelma ei voi suojella relaatioita käyttäjien virheiltä. Jos käyttäjä päättää poistaa tien ja piirtää tilalle uuden piirtämättä kaikkia risteyksiä ja kirjoittamalla nimet väärin ja jättämällä osan määreistä pois, niin sitten mikä tahansa työkalu kiltisti rikkoo kartan. Pitäisiköhän OSM:issakin kohta ottaa käyttöön joitain Wikipedia-tyylisiä rajoituksia, etteivät aloittelijat pääse mellastamaan ihan vapaasti? Vai onko vaarana, että kartanteko tyssää siihen? Enpä ole Wikipediaan sen jälkeen yrittänyt mitään tehdä, kun sen muokkaamista hieman tiukennettiin.
Pyörämatkailureiteillä on vielä puutteita, monia pätkiä ei ole kukaan käynyt polkemassa, tai autosta havainnut ainakaan sikäli kuin ne poikkeavat pääteiltä. Erityisesti pohjoisimmassa Suomessa.
