Se vaan on valitettavasti niin etteivät nuo classifioinnit sovi yhteen (MML vs OSM). Tätä ongelmaa ei pidä sivuuttaa sillä että valitaan Garbage In Garbage Out ratkaisu (ja päästään bad imports hall-of-shame listalle :-))! Muistutan toki että sinun henkilökohtaisesti ei ole mikään pakko osallistua, jos haluat pitäytyä tahrimasta käsiäsi mihinkään käsityöhön ;-), uskon kyllä että riittävästi halukkaita löytyy muutenkin että homma saadaan toimimaan.
Aivan, mutta kannattaa myös muistaa se tosiasia, että maasto pysyy loppuen lopuksi varsin stabiilina muutoksista huolimatta. Elikkä ei Suomen kaikkia teitä tai vaikkapa taloja kerran vuodessa laiteta uusiksi. Nähdäkseni tässä on nyt hiukan liioiteltu muuttumisen mittakaavaa.
Heh-heh. Moni koodipuolellakin varmasti maksaisi maltaita jos saisi aukottomasti toimivan automaatin joka huolehtii esim. confliktit. Muistathan että myös OSM päivittyy jatkuvasti!
OSMissa on ID-avaruus (osm_id column jos osm2pgsql:llä importtaat). Mutta mutta, OSMin puolella ID:iden pysyvyydestä ei ole mitään takeita, seuraava editoija saattaa laittaa editoidessaan ID:t piu-pau-poks. Toki sitä voidaan .osc diffejä processoidessa vielä käyttää kontrolloidusti hyödyksi mutta muuten siitä ei ole hirveästi muutosidentifiointiin avuksi (eli poistetut objektit “katoavat” kannastasi jos ne poistetaan osmista ja ajoit diffit sisään). Vähän sama homma MML:n puolelta vai oletko löytänyt jostain dokumentaatiota miten heidän ID:t käyttäytyisivät muutoksien yhteydessä? IMHO, kaikki ID:t jotka eivät perustu objektien geometriaan ovat tuhoontuomittu yritys tällä pohjalla. Lisäksi geometria on mielestäni täysin riittävä, joskaan ei täysin helppo ID noin niinku laskennan vaativuutta ajatellen, mutta nähdäkseni ainakin tieverkon tapauksessa se pitäisi olla varsin mahdollista ratkaista riittävällä tarkkuudella! Lisäksi MML:llä tiet on pilkottu pieniin osiin vaikkei mikään attribuutti muuttuisikaan, OSMissa wayt ovat pitempiä jos tien attribuutit pysyvät samana.
Käytännössä MML:n aineistosta on helpohkoa laskea diffit edelliseen MML:n versioon nähden tietokannassa, muutoksien määrä ei tule olemaan järin suuri vaikka sitä pelkäsitkin. Tämä vaihe on varsin helppo automatisoida!
Itse lähtisin kuitenkin mielummin siitä, että MTK:n aineisto pyritään yhdistämään uppimalla se järkevästi suunniteltuna suoraan OSMiin (mutta tässä tarvitaan sekä harkintaa, että jonkun verran aikaakin, sitä ei saa aikaan yhdessä yössä). Toki en kiellä sinua koitamasta tehdä yhdistämistä täysin OSMista riippumatta :-). Ongelmana tuossa yhdistelyssä, jota ilmeisesti toivot mahdollisimman automaattiseksi ovat OSM:in laatuvaihtelut. Tieverkkojen yhdistäminen automaattisesti riittävän hyvällä onnistumisprosentilla voi osoittautua jossain määrin haastavaksi, erityisesti jos sinulla ei ole erittäin vahvaa pohjaa conflation-algoritmeista etukäteen - juu olen miettinyt näitä itse jonkun verran ja tiedän kyllä jotain siitä mitä sieltä tulee vastaan, vaikka pahimpia juttuja olenkin jo kauan sitten OSMista korjaillut “käsityönä” ;-).
Olen samaa mieltä tuosta MML:n vastauksesta, ei se sinänsä ollut mitenkään yllättävä (suullisesti sama viesti onkin jo kuultu).
–
i.