Kuten kirjoitin, en oikein tunne noita relaatioita, mutta sellainen käsitys minulle on tullut, että niitä tarvitaan mm. pitkien rantaviivojen kanssa.
Kun importointia lähdetään oikeasti toteuttamaan, olisi seuraavankaltainen palvelu hyvä olla olemassa:
palveluun tallentuisi ne MML:n aineiston kohteet, joita ei ole saatu talletettua OSM:iin
palvelu tarjoaisi aineiston WFS- tms. muodossa, josta aineiston voisi kopioida jotenkin interaktiivisesti OSM:iin (taustakarttana tms.)
jos käyttäjä saa kohteen kopioitua, se ei enää palvelussa näkyisi.
Edellä on alustavaa ajattelua, jonka tarkoituksena on pyrkiä maksimoimaan MML:n aineiston hyödyntäminen.
Lisäksi tarvitaan toinen palvelu, jossa säilytetään pelkästään MML:n aineistoa ja josta saadaan tulevaisuudessa ne toivotut diffit, eli kun MML päivittää aineistoaan, tämä palvelu jotenkin ylimaagisesti pystyisi tuottamaan esim. WFS- tms. jossain vastaavassa käyttökelpoisessa muodossa ainoastaan muutokset edelliseen MML:n toimitukseen. Tai vaihtoehtoisesti MML itse toteuttaisi tällaisen palvelun.
Reikäisiin alueisiin (pelto keskellä metsää tai metsä keskellä peltoa tai saari keskellä järveä) tarvitaan multipolygon-relaatioita. Muita relaatioita ei taida MML:n aineistosta muodostua, paitsi tietysti boundary-relaatiot aluerajoja varten. Muita relaatioita ovat muunmuassa reittirelaatiot, esimerkiksi bussireitit tai vaikka eurooppatiet (E75 yms.).
Tuota importointia voisi tosiaankin harjoitella omalla OSM-palvelimella. Voin osallistua testaamiseen ajamalla dumpista mkgmapia ja OsmAnd-kartankääntäjää ja raportoimalla virheistä. Luulen, että importteja pitää ajaa monta kertaa ’puhtaalta pöydältä’ uusiksi, ennen kuin tuontialgoritmit ovat kunnossa. Käsisäätöä kannattaa tehdä vasta sitten, kun automaatti toimii riittävän hyvin.
Revertoinnissa ei ollut mitään ylitsepääsemättömiä ongelmia ja kaikki changesetit on nyt järjestelmällisesti revertoitu lopusta alkuun. Vertasin Kemijärven nykytilannetta alkutilanteeseen enkä nähnyt mitään muutosta JOSMin eri layereiden välillä. Mikäli jotain kuitenkin puuttuu/on muuttunut saadaan se palautettua kyseisen objektin ID:n avulla.
Jeps, tosi iso järvi tarvitsee multipolygonia mutta niissä lienee joka tapauksessa saaria ja kait isohkot järvet ovat kai jo osmissa jotenkuten piirrettynä joten se menee kuitenkin käsityöksi pääosin? Vetäisin raakan importtina vain niitä ei overlappaavia ja muut ihmisharkinnan jälkeen (osa rantaviivasta voi olla hyvästäkin ilmakuvasta joten ei voi ihan suoraan sanoa että kaikki rannat on huonosti).
Olisihan tuolla tuo dev apikin olemassa. Sinne tosin pitää ensin itse kait uppia myös suomen osm kopiota jos siellä harjoittelee koska se ei kai mitenkään trackkää db:tä.
TASTAR on horisontaalista tavaraa. Tuolla on näemmä KORTAR kanssa mutta en muista siitä mitään, en ole ehkä edes katsonut.
No niinhän olen jo tehnytkin :-). Pikkasen vielä kun jatkan jo tehtyjä juttujan niin saan ulostettu myös niin ei-overlappaavien osien .osm tiedostoja joita on varsin helppoa arvioida juurikin “omalla koneella”, Mutta vain siihen asti minusta “kokeilu” on mielekäs ja hyödyllinen (voi tarkistaa että oikeasti ovat ei overlappaavaa tavaraa ja oikein kiinni toisissaan jne.). …Ei upload vaiheen “kokeilussa” minusta ole paljoa mieltä, se on itsessään mekaaninen operaatio josmilla jonka “testaamiseen omalla koneella” en näe mitään syytä. Lisäksi niitä .osm:eja pystyn toki takaisinkytkemään tietokantaani jos tarvitsen jotain yhdistelytestiä varten.
Vähän epäilen että jäävät kyllä toteuttamatta. Vaikka nuo ei tallennetut kohteet ovat jotenkuten laskettavissa, se ei ole hirveän halpa operaatio ja vaatisi käytännössä jotain conflation algoritmia toimiakseen “alkuvaiheessa” jolloin tiet ovat vielä vähän vinksin vonksin, ja sille ei ainakaan vielä ole täällä ilmoittautunut vapaaehtoista toteuttajaa ;-). Se openjump moduuli on ilmeisesti suljettua koodia(?) joten siitä ei välttämättä ole kauheasti hyötyä jos sitä nyt muutenkaan saisi tietokantaan järkevästi kytkettyä automaattiin kiinni. Periaatteessa jotain ajatuksia conflation algoritmista löysin kyllä, mutta vaatisivat ilmeisesti jotain clusterointi lisäosaa postgisiin niin ole antanut asian olla, ainakin toistaiseksi omalta osaltani. Siinä vaiheessa kun tavara alkaa olemaan about kohdallaan tuo matchays helpottunee.
MML:llä on muuten joku beta muutos palvelukin nykyään, en ole perehtynyt mutta huomasin joku viikko sitten. MML old vs MML new diffaus olisi kuitenkin toteutettavissa ilman että he toimittaisivat diffejä joten en ole siitä hirveän huolissani vaikkeivat diffejä tarjoaisikaan.
Paikallisesti minulla oikeastaan toki on “palvelu” jolla pystyn tuollaisia laskemaan, mutta se ei ole mikään n kertaa sekunnissa raksutettava operaatio miltään hiukankaan suuremmalta alueelta. Suomen prosessointi kesti 30min-1h iirc ja siinä oli ihan triviaalitarkistuksia vasta tehtynä. Monimutkaisempi analyysi vaatii vielä huomattavasti lisää laskentaa. Voin toki postgis queryitä laittaa jahka ehdin saatavillekin, mutta en pidä todennäköisenä että siitäkään huolimatta tuollaista palvelua jostain nurkan takaa ilmaantuu, ehkä muutama muu kaveri saattaa samantyylisesti omalla koneellaan päätyä niitä kokeilemaan mutta julkisemman “palvelun” virittämiseen voipi olla huomattavasti isompi kynnys.
OpenJUMP ja suurin osa sen plugin:eista on GPL-lisenssillä. Road Matcherillä on kaksoislisenssi, koska alkuperäisen JUMP:in tekijä Vivid Solutions on kirjoittanut myös sen, mutta sekin on saatavilla GPL:nä. Suosittelisin kuitenkin uudempaa Matching-laajennosta, koska Michael Michaud on aktiivinen OpenJUMP:in kehittäjä ja erittäin pätevä. Laajennoksen käyttöohje on täällä: https://sourceforge.net/projects/jump-pilot/files/OpenJUMP_plugins/More%20Plugins/Matching%20PlugIn/MatchingPlugIn0.5.5.pdf/download
OpenJUMP lukee PostGIS:iä luonnostaan ja on yksi parhaista mitä on olemassa siihen tarkoitukseen. Päivittämisen kanssa on vähän niin ja näin, se ei ole kuulunut vakio-ominaisuuksiin eikä taida vieläkään olla kaikkein sujuvinta.
Ah, ok. Oli sitten joku muu juttu mitä katsoin kuukausia sitten tai en vaan osannut keksiä mistä downloadata pluginin koodin. OpenJUMP:n nyt tiesinkin olevan vapaata koodia toki.
1 ja 3 merkitys selvittämättä. Kuvaus puhuu että suunnitelman ovat vain poikkeustapauksissa (merkittävä hanke, kehä II; jatko esimerkkinä). Yllättävän vähän noita kaikkiaan on ja taas melkein yhtä paljon joten vaikea uskoa että 180 olisi kaikki poikkeustapaukset.
Tein nyt pari yksinkertaista koetta tuolla kemijärven ympäristössä (näemmä extractini oli sellainen jossa oli vielä ei-revertoituna tuo kemijärvi ainakin pääosin, joten siinä on “aukko” nyt sitten overlappitestin takia ja jotain myöhemmin palautettuja unclassified overlappejä lähellä noita revertoidun alueen reunoja):
http://www.cs.helsinki.fi/u/ijjarvin/osm/kemijtestnosnowmob.osm - Koska näytti siltä että nuo highway=path snowmobile reitit estivät isohkoa osaa teistä tulemasta mukaan kokeilin tässä filtteröidä niitä pois niin että overlapit niiden kanssa eivät haittaa.
Laskenta kesti 3-2.5minuuttia (T52 ruudun alueen kaikki mml objektit tarkistettiin).
Joillain alueilla syntyy noissa aika suuriakin verkkoja tuolla suoraan. Jos haluaisi hienostelemaan ryhtyä voisi noita ehkä erotella jopa jokaisen omaksi verkokseenkin.
LineMergeä en vielä ajanut noille, mutta se ei ole kovinkaan monimutkainen operaatio. Pitäisi vielä koittaa “putsata” overlap testeista mml;ään täysin matchaavat aineisto ennen ku ajaisi tuota overlap testiä niin saisi mml tavaran kauniisti yhteen itsensä kanssa automaattisesti.
Luin jostakin, että virallinen planet.osm on vaihtanut paikkaa muutama päivä sitten. Vanhassa osoitteessa olisi viimeinen CC-BY-SA-lisensoitu kartta.
Latasin eilen ja tänään Geofabrikista finland.osm.pbf:n. Korjasin eilen yhden rikkinäisen (väärin päin osoittavan) merenrantaviivan, mutta virhe on mkgmapin mukaan tänäänkin siellä. Jo eilen kokeilin ladata muutamia MML-tuotuja kohteita, joista mkgmap narisi, eikä niitä enää ollut tietokannassa.
Täytynee odotella muutama päivä, kunnes Geofabrikin väki on palannut SoTM12:sta, ja kysellä vasta sitten, saisiko kartan taas päivittymään.
Kävin automaatilla läpi kaikki nuo > v1 objektit. Ainoat muutokset nodeissa / wayssa olivat created_by tagien katoamisia, joten homma on hyvin hoidettu. Kiitos. Relaatioita, 5kpl, en jaksanut tarkistella, olivat multipolygoneja ja rata routeja + E-tie relaatio, mutta ei ole mitään syytä olettaa että ne olisivat väärin.
Openstreetmapin vahvuus on siinä, että sinne ilmestyy hyvin äkkiä uudet tai jopa vasta suunniteltavat tiet, jos ihmiset vain vaivautuu niitä lisäämään oman paikallistuntemukseensa perustuen ja muutokset ilmestyvät saman tien karttoihin. Tätä vahvuutta ei ole millään kaupallisella toimijalla. Niiden kartat on aina vanhoja jo ilmestyessään.
Jos nyt valitaan se tie, että kaikki käyttäjien syöttämä data jyrätään yli vaikkapa kerran vuodessa, kun MML:ltä ilmestyy “oikeampi/tarkempi” tämän vuoden kirjasto, niin tämä vahvuus menetetään. Kukaan ei enää vaivaudu lisäämään karttaan yhtään mitään, kun tiedossa on, että kaikki jyrätään kuitenkin yli.
Mitä enemmän olen katsonut tuota osm sisältöä, sitä enemmän olen alkanut inhoamaan juuri tätä keskustelun alla olevaa suunnitelmaa tehdä tästä vain “yet another outdated copy of a generic map”.
Liikenneympyrä on kyllä mielestäni tullut ihan jäädäkseen, ollut käytössä vajaat kaksi viikkoa. Oli aikansa ‘construction’, kunnes tuli virallisesti käyttöön. Sitä tilapäistä ajoreittiä en viitsinyt piirrellä kun se ei hirveästi poikennut alkuperäisestä tielinjauksesta.
Tämä lähes reaaliaikaisuus on minunkin mielestäni OSM:n ehdoton vahvuus muihin karttapalveluihin nähden. Jopa kaupungin (Savonlinna siis) nettisivuilta linkitetään karttoihin joissa osa zoomaustasoista käyttää ilmeisesti MML:n vanhoja tietoja ja näyttää mm. muutama vuosi sitten käytöstä poistettuja tasoristeyksiä kulkukelpoisina, seikka jonka sain itse aikanaan karvaasti kokea.
MML:n materiaalilla olisi toki kiva tilkitä niitä alueita joille OSM-kartoittajat eivät satu eksymään.
Paljonkos teollisuus sallit tossa importissaan teiden oikovan simplifioinnin seurauksena? Löydän varsin suuriakin etäisyyksiä (~3m) mikä alkaa olemaan jo aika reipasta heittoa.
Ensimmäisissä tuonneissa käytin JOSM default työkalua"Yksinkertaista polku" ajatuksena, että kyseisessä työkalussa lienee taustalla jonkinlainen yhteisötasolla tehty yhteisymmärrys sopivasta pistetarkkuudesta OSMiin. Koska kyseisen työkalun parametreja ei voinut muuttaa rupesin myöhemmin käyttämään SimplifyArea-pluginia, jossa pienimpää etäisyyttä, pienintä alaa ja pienintä kulmaa pystyy itse säätelemään. SimplifyArea pureutui paremmin myös useamman viivan jaettuihin nodeihin joihin default-työkalu ei koskenut. Näitä jaettuja pisteitä esiintyi lähinnä maankäytön luokittelualueiden välissä. SimplifyArean parametreissa oli melko vapaat asetukset, joten 3m heitto kuulostaa tuolta perustyökalun tekosilta. Tässä lienee opetuksena se, että teitä ei tarvitse yksinkertaistaa niin paljon kuin maa-alueita.
Katoin että noissa teissä on kaikkiaan vain ~40 miljoonaa pistettä == ei mitään, joten ei niitä ehkä tässä vaiheessa kannata alkaa yksinkertaistamaan mitenkään ainakaan määrän takia. Artifaktit esim. tarkkuuserojen mml vs osm takia pitäisi ehkä tarkistaa ennenkuin ne upitaaan osmiin, mutta ainakin jos noita tekee kannasta noita .osm:ja luulisi huippulyhyiden segmenttien poiston olevan pilipali simppeli operaatio. Niitä on kuitenkin ilmeisesti <1% tms (todella vähän olen niitä nähnyt) joten ei siinä suurta pienennystä saataisi kuitenkaan aikaan. Pikemminkin wayt tuntuvat välillä tosi karkeilta mutkissa joten niistä ei ainakaan kannata poistaa yhtään lisää nodeja.
Osaan nyt matchata kiertoliittymät aineistojen välillä (täytyi tehdä “esiprosessointina” kun muuten tulee muissa matchayksissä ongelmia). Totesin että osmissa on pääsääntöisesti kiertoliittymien geometriat huomattavasti paremmin kuin mml:llä, niiden geometrioita ei kannata siis tuoda ilmeisesti lainkaan. Parempi piirtää käsin mml:n ortokuvista kunnolla jossei huippubingiä ole saatavilla (jos osmin ympyrä nyt ensinnäkään on sivussa).
Myös ref < 1000 teiden matchaystä olen aika paljon viritellyt. Ongelmina ovat tällä hetkellä enää risteykset joissa ref kääntyy suurikulmaisesti ja itsensä kanssa ristiinkulkevat tiet. Nuo ympyrät tuottivat myös ongelmia mutta nyt saan ne filteröityä pois matchattavasta setistä,
Käytännön toimia ajatellen, talk-postituslistalla on ollut viime päivinä vilkas viestiketju importeista, lähinnä vaatimuksesta käyttää erillistä tunnusta. Myös jos tuonti hajautettu ja vaatii käyttäjien manuaalista tarkistelua ja sovitusta (vaikka oikeastaan ainahan se vaatii).
Import Guidelines -sivulla luki aikoinaan jokseenkin “suositellaan erillistä tunnusta”, sittemmin “täytyy käyttää erillistä tunnusta”. Britit meinaavat että edellinenkin on natiiville velvoittava, asiat vaan sanotaan kohteliaasti vaikka sääntö olisi tiukka.
Ranskassa on jo pidempään “tuotu” heidän kiinteistörekisterististä (cadastre) mm. talojen ääriviivoja siten, että vapaaehtoinen käyttäjä yhdistää tiedot josmissa nykyiseen pieneltä alueelta (“kunta”, meikäläistä pienempiä moni) ja lähettää sitten.
Yksi aktiivinen klikkaili kerran väärin, ja lähetti ensin cadastren talot yhdistämättä nykydataan, ja sitten poisti alueen vanhat talot kerralla.
Poisto huomattiin ja epäiltiin ensin vandaaliksi, mutta huomattiin importiksi; ed. rivin käyttäjä ei vastannut kun Data Working Group (DWG) lähestyi häntä kolmesti ja vaati käyttämään erillistä import-tunnusta. DWG esti tunnusta muokkaamasta muutamaksi päiväksi, kun mitään kontaktia ei saatu.
Viestiketju alkoi syyttelynä jne., mutta sisältää myös järjellistä keskustelua asiasta.
Käytännössä, jos tähän joskus päästään MTK-datan kanssa, pitää olla erilliset tunnukset joilla dataa tuodaan. Oli ne sitten kuntakohtaiset, joihin saa tunnukset joltain aktiiviryhmältä, tai jokaisen aktiivin oma esim. mallia “MTK_import_alv”.