Pitää laittaa paremmat miehet kehiin. Tuon viestin välitin, mutta mulla ei ollut sitten mustaa-valkoisella.
P
Pitää laittaa paremmat miehet kehiin. Tuon viestin välitin, mutta mulla ei ollut sitten mustaa-valkoisella.
P
MML:lta voisi kysyä, mitä seuraava kohta lisenssissään heidän mielestään tarkoittaa:
(siis OSM:n tapauksessa, eli miten OSM voisi vaatimuksen esittää)
ja mitä “same information” tarkalleen ottaen tarkoittaa.
Kysymys kannattaa tietysti esittää ystävällisesti, muistaen, että MML on tehnyt meille todella ison lahjoituksen puolitoista vuotta sitten.
Huutelen täältä sivusta, mutta lopettakaa jo tuo vatulointi lisenssistä. MML:n johtaja käytännössä juuri vahvisti, että no problem, siitä vaan.
Kysymys kannattaa tietysti esittää ystävällisesti, muistaen, että MML on tehnyt meille todella ison lahjoituksen puolitoista vuotta sitten.
Väärin, aivan väärin. Kyseinen aineisto on veronmaksajien kustantama ja MML esti maksajalta pääsyn aineistoon (tolkuttomalla hinnoittelulla) kunnes oli aivan pakko se sallia. On hienoa, että vihdoinkin veronmaksajat saavat kustantamansa tuotokset käyttöönsä. On myös hienoa, että viranomaisessa on havaittavissa totaalinen asennemuutos datan jakamista kohtaan.
En ole tarkemmin lisenssiasiaan perehtynyt, mutta olen samoilla linjoilla [jsl]:n kanssa näin sivustaseuraajana. Importti mahdollistuessaan tulee olemaan niin iso urakka, että olisi hyvä, jos tämä sotku nyt selviäisi ja pääsisimme perehtymään itse hommaan.
Sivulta https://wiki.openstreetmap.org/wiki/Legal_FAQ#2b._XYZ_Organisation_has_data_for_free_download_under_licence_N._Can_I_use_it_in_OSM.3F lainaus:
2b. XYZ Organisation has data for free download under licence N. Can I use it in OSM?
Approach the data owners, explain OSM, and seek written permission to licence their data under our licence and contributor terms.
Unless the data is genuinely offered without any restrictions on use at all (i.e. public domain), please contact the Licensing Working Group for advice. Do not rely on your own legal interpretation of the licence. OSM is all about creating a freely and easily redistributable data set. Anything which taints the dataset or exposes OSM to possible legal action interferes with that objective.
Even if you only want to use a minor part, or compare the sources, you should still seek approval in writing. The legal principles involved are not well developed, and the OSM community wants to develop a free and untainted dataset and not test any of the legal issues involved here.
In short: be ultra-cautious.
ja laitetaas vielä kerran jo useaan kertaan lainattu:
(https://wiki.openstreetmap.org/wiki/Import/Guidelines#Make_sure_data_license_is_OK)
Please also note the details of attribution requirement. We can offer some attribution: we can credit them on our website (not on the homepage, but in the Contributors page here on the wiki, and on www.openstreetmap.org/copyright for very large-scale contributions). We can link information about them in relation to the user account performing import edits, meaning the editing history will allow people to trace the source of the data donation. We can also set their name in the ‘source’ tags of our underlying data. This is perhaps more prominent, but may be removed by editors doing further mapping work. The credit to the “author” stops there. **What we certainly cannot do is require end-users of our data/renderings to give credit to the particular data donor. **With this in mind, our attribution may not be sufficient legally speaking and might actually be considered unsatisfactory by the original “authors” of the data.
Edellinen koskettaa juurikin MML:n lisenssin kohtaa: “require third parties to provide the same information when granting rights to copies of dataset(s) or products and services containing such data”
Asia saattaisi selvitä sillä, että MML tarkentaisi mitä tuo edellinen lisenssissän tarkalleen ottaen tarkoittaa. Mielestäni “third parties” tarkoittaa jotakuta, joka edelleenkäyttää OSM tietoa (1st party ollen MML, ja 2nd party olisi OSM). Eli itse tulkitsen asian siten, että MML vaatii (jos MML:n data on importoitu OSM -kantaan), että OSM-aineiston hyödyntäjän tulisi jotenkin tuo MML:n lisenssi huomioida. Saatan tietysti tulkita väärinkin.
Ei tämän tarvitsisi olla näin vaikeaa. Asia selviäisi, jos MML ottaisi selkeän kannan sille, mitä kyseinen kohta lisenssissä tarkoittaa OSM:n kannalta, mihin se velvoittaa OSM:n.
Minusta CC-BY:ssa on samanlainen vaatimus siitä, että myös viittaus alkuperäiseen lisenssiin periytyy
http://creativecommons.org/licenses/by/3.0/"Notice — For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page. "
Eiköhän tuossa ainoastaan haluta sanoa sitä, että jotta lisenssi tulisi mahdollisille tekstin tms. uudelleenkäyttäjille selväksi, pelkän CC-BY:n tekstin (lyhenteen) sijasta (tai sen lisäksi) sivulle laitetaan myös linkki lisenssisivuun. Ei tarvitse erikseen lähteä etsimään, että mistähän lisenssistä olikaan kyse, vaan linkin kautta pääsee lisenssiin heti ja helposti käsiksi.
Varmaan joo, siinä ei käsitellä lähdeviittauksen periytymistä. Tätä aihetta on pohdiskeltu blogissa http://infotrope.net/2012/11/30/importing-data-is-hard/
Taidan palata tähän lisenssikeskusteluun taas vuoden tai parin päästä. Ne jotka eivät luota siihen, että “MML:lle riittää aivan samanlainen viittaus alkuperäislähteeseen kuin esim. muillakin aineistoja luovuttaneilla tahoilla on OSM:n sivuilla http://www.openstreetmap.org/copyright (Esim. Sisältää Maanmittauslaitoksen maastotietokannan tietoja, 2013)”, voivat antaa lisenssille mielessään nimen “Avoimen tietoaineiston pitäkää tunkkinne -lisenssi” ja jäädä odottamaan uutta CC 4.0 -lisenssiä. Ehkäpä siitä tulee CC-Less, ja keskustelu jatkuu http://www.dailywritingtips.com/could-care-less-versus-couldnt-care-less/
Se on ollut alusta alkaen tiedossa, että MML:lla ei ole mitään sitä vastaan, että heidän dataansa talletetaan OSM:iin. Ongelma on ollut alusta alkaen kyseisen datan lisenssi ja siinä maininnat:
"require third parties to provide the same information when granting rights to copies of dataset(s) or products and services containing such data "
ja ehkä myös “and remove the name of the Licensor from the product or service, if required to do so by the Licensor.”, tosin itse en usko tämän jälkimmäisen olevan mikään ongelma.
Tässä ketjussa ei ole vielä ollut viittausta Memorandum of Understanding keskusteluun, jonka Pekka aloitti OSM-legal-talk postituslistalla (http://lists.openstreetmap.org/pipermail/legal-talk/2012-July/007122.html). Keskustelu jäi varsin lyhyeksi, mutta yhdessä vastauksista (http://lists.openstreetmap.org/pipermail/legal-talk/2012-July/007129.html) sanotaan:
Get a letter / email saying the National Land Survey of Finland accepts
that their open data can be used in OSM if you want, but don’t go any
further than that. If there is any doubt about this, or any further
strings attached, then don’t use the data.
Ratkeaisiko ongelma sillä, että jos MML ilmoittaisi, että tässä tapauksessa vaatimus “require third parties to provide the same information …” ei olisi mikään ongelma. Vai pitääkö tässä sitten todella odotella sitä CC 4.0 lisenssiä ja sitä, että MML luovuttaa aineistonsa sen alla ja sitä, että onko kyseinen lisenssi edelleenkään yhteensopiva? Odotellessa saadaan taas hyvinkin toinen lähes puolitoista vuotta kulumaan ja sen aikana itse en ainakaan ole kovinkaan kiinnostunut OSM aineiston kartoituksesta, koska aineisto olisi valmiina, sen kun importtaisi.
Lopuksi voisin vielä kerran toistaa itseäni ja todeta sen, että valmistelut MML:n aineiston importoimiseksi kannattaa aloittaa pikimmiten. Lisenssiasia ratkeaa kyllä joskus. Ja kun se ratkeaa, tekniikka olisi valmiiksi mietittynä.
Eiköhän tosiaan kysäistä MML:ltä, mitä tuo “require third parties to provide the same information when granting rights to copies of dataset(s) or products and services containing such data” tarkoittaa OSM:n tapauksessa. Kuka lähettää viestiä?
moi,
MML:än pomolta saatu viesti on selkokielinen.
Siinä on kerrottu miten tulee mainita eli niinkuin on
muutenkin OSM:ssä lähteet mainittu.
On kerrottu että tulee uusi lisenssi ja mikä.
Nyt keskitytte tuohon muunto scriptiin että KAIKKI
tietotyypit siirtyvät,…
MTK-GML.py
https://github.com/tpikonen/ogr2osm-translations
===
Itse OSM kantaan kaikkea ei kannata siirtää tarvitaan
erikseen distribuution Finland-MML, ehkäpä eri alueille
omat OSM:ät,… Finland-SW-MML ,…
Systeemi/sopimus miten data pysyy tietokanssa erillään
ja päivitetävissä eri lähteistä.
Joku systeemi millä voi valita kumpaan luotetaan,
MML aineistoon vai OSM:ään,…
Postresql tietokannassa voisi ajoilla poistaa päällekyydet
ja suosia *.OSM aineistoa ja MML paikata puuttuvaa,…
Takasin aiheeseen eli miten saadaan GDAL:illa MML ainesto avoimeksi.
Mun ratkaisu oli tuoda se *.osm muotoon ja siitä postgres kantaan ja renderöidä manik;illä.
Keimo voisitko avata pikkusen tuota MTK-GML.py scrptiä ja miten siihen
tietotyyppejä voi lisätä,… pitäisi ymmärtää edes tietojen muodot,… lähteitä,…:
-mitä maastotietokanssa on
-mitä on OSM:ssä
-miten nuo näkyy postresql:ässä ja siirtyy mapnik:iin
Olit sitä mieltä että kaikkea ei kannata siirtää,… uskon
että eri ihmiset etsii eriasioita ja jonkinlainen valintamekansismi, layerit MAPNIK päässä tai
erinlaisia muunnos scripptejä eri käyttöön?
Tää on hankala juttu hallinoida monikäyttöisyyttä ja jakelua,…
jos sen sellaiseksi haluaa ?
Päivitin taas translaatioskriptiä (joka on siis saatavilla githubista: https://github.com/tpikonen/ogr2osm-translations ) ja nyt se alkaa olla aika lähellä niin täydellistä kuin yksinkertaisella kohdeluokka → tagisetti -muunnoksella on mahdollista saada aikaan. Tarkempi konversio vaatisi mm. tekstipisteiden yhdistämistä vastaaviin maastogeometrioihin, ynnä muuta heuristiikkaa. Sinänsä varsin yksinkertaista, mutta jonkin verran työlästä kirjoittaa, eikä sataprosenttisesta toimivuudesta ole takuita.
Muunnos pohjautuu wikistä löytyvään taulukkoon http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Luokat jota on jonkin verran täydennetty mm. teiden luokitusten osalta ja importoimalla ‘nimi’-pisteet erillisiksi OSM-nodeiksi, jolloin karttaan saadaan paikannimet näkyviin. MTK:n tieluokat muunnetaan OSM tieluokituksiin, mutta koska MTK:n luokitus perustuu ainoastaan tien geometriaan (kaistojen lukumäärä ja tien leveys), lopputuloksessa on tiettyjä puutteita.
Testirendaukset mapnikillä näyttävät kuitenkin varsin hyviltä ja suurten kaupunkien keskustojen ulkopuolella kartta on huomattavasti OSM:ia parempi. Tämä ei varmaankaan yllätä ketään.
Konvertoin tod. näk. lähipäivinä koko MTK:n paikalliseen tietokantaan, ja jos se toimii, pitää alkaa tosissaan miettimään oman leaflet-kartan hostaamista.
keimo,… kun kuitenkin joudutaan yhdistelemään muotono ja nimi konversion lisäksi,… miltä tuntuis päällekkyyksien ja
niitten kartan yksityiskohtien viimeistely sql:ssä,… tuntuisi musta luontevimmalta ?
Minulla on jo tuotettuna .osm filejä, joissa on aliverkkoja MML:n tiestö osoitteilla aineistossa (tietääkseni ainoa jossa tiennimet yms tiedot löytyvät, ei taida saada latauspalvelusta?), jotka eivät overlappaa OSM:ssa minkään oleellisen kanssa. Verkkoja on n. 170k joten siinä riittää varmasti hommaa jaettavaksi, jahka saisivat tuon copyright merkinnän lisättyä + kaikki importtiin liittyvä byrokratia on hoitettu asianmukaisessa järjestyksessä (tosin iso osa on suhteellisen pieniä, joita kannattaisi varmaan bundlettaa jotenkin yhteen, mutta tapaa täytyy ehkä vielä hetki pohtia). Suurimmat verkot olivat yhteismitaltaan n. 624km, mikä ehkä tuntuu suurelta, mutta koot pienenevät nopeasti ja n. 40km verkkoa kun koitin, sen käy jo muutamassa minuutissa läpi ilmakuvien kanssa. Isoimmissa verkoissa luulen että aikaa kuluu tunteja.
Käytännössä teiden luokittelua joudutaan varsin paljon tekemään käsin, mutta tuo näytti olevan suhteellisen yksinkertainen ja nopeahko operaatio muutaman kymmenen kilometrinkin kokoiselle verkolle jos ilmakuvat ovat alueelle saatavilla. Tuo “arvontaluokittelu” esim. tracktype:ille yms, mitä tuolla ogr2osm muunnoksessa on käytetty kannattaa kyllä hylätä suoraan ja myöntää se että MML:n luokittelusta ei läheskään täydellistä OSM-tavaraa vaivatta synny vaan dataa joudutaan ihan oikeasti katsomaan ihmissilmin! Lisäksi geometriavirheet MML:n tiestön yhteenkytkennöissä ovat pikemminkin sääntö kuin poikkeus, joten JOSMin validaattorilla tarkistelu ja jokaisen löydetyn arveluttavan kohdan läpikoluaminen on aivan välttämätöntä ennen uppimista.
Olen jo tällä hetkellä valmistelemassa tuota import-kuvausta ja koitan myös kirjoittaa importista kiinnostuineita varten oman ohjesivun tuon tekemisen jälkeen (mutta painan vain upload-nappia tyylistä ratkaisua ei valitettavasti ole niistä kiinnostuneiden iloksi tarjota):
http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Road_Import_Stage1_Plan
Saapi heittää kommentteja, vaikken tuota loppupuolta vielä ihan ehtinyt saamaan valmiiksi.
Tämä on siis ensimmäisen vaiheen operaatio niille alueille, jotka ovat tällä hetkellä tyhjiä OSMissa. Seuraavassa vaiheessa pitää sitten miettiä olemassaolevaan dataan tietojen liittämistä, mutta se on huomattavasti haasteellisempi operaatio (jotain yritystä mulla on matchayksenkin suhteen olemassa, mutta se on vähän vielä vaiheessa se koodi).
–
i.
MML:n tiestö osoitteilla aineistossa (tietääkseni ainoa jossa tiennimet yms tiedot löytyvät, ei taida saada latauspalvelusta?),
Latauspalvelusta on nykyään saatavana tiestö osoitteilla: http://www.maanmittauslaitos.fi/aineistot-palvelut/latauspalvelut/avoimien-aineistojen-tiedostopalvelu “Maastotietokanta kaikki kohteet, tiestö osoitteilla”. Muistaakseni tiestö osoitteilla ei ollut latauspalvelussa alusta alkaen.
Edit: http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Road_Import_Stage1_Plan on kohta “Address data”. Onko kellään tietoa mistä MML saa pohjakarttaansa osoitteet talojen kohdalle? Esimerkin saa helposti, jos avaa Paikkatietoikkuna.fi:n Karttaikkunan (http://www.paikkatietoikkuna.fi/web/fi/kartta) ja zoomaa riittävän lähelle oletuspohjakartan ollessa päällä. Osoitenumerot ovat talon kohdalla. Joissain tapauksissa saattaa tietysti olla hankalaa kohdistaa numero oikeaan tiehen, mutta muuten kyseinen aineisto sopisi varmaan hyvin OSM:n osoiteaineiston pohjaksi. Saattaisiko lähtöaineistona olla rakennus- ja huoneistorekisteri (http://www.vaestorekisterikeskus.fi/default.aspx?id=175) vai joku muu aineisto?
Käsityö kuulostaa pahalata, kaikissa systeemeissä järjestelmän saaminen pystyyn on helppo juttu verattuna siihen
että se on pystyssä 10 ehkä 50 vuoden päästä ja toimii vielläkin.
NIIN Maanmittaushallitus PÄIVITTÄÄ TIETOKANTAANSA KOKO AJAN, PÄIVITYKSET PITÄISI SAADA SIIRTYMÄÄN
MAHDOLLISIMMAN AUTOMAATTISESTI !
En ole ehtinyt, enkä ihan heti ehdi, kun tappelen rinakkain laskenta ongelmien kanssa, perehtyä OSM päivitys mekanismeihin mutta näillä vilasuilla on sellainen
tunuma että siellä on joku osm_id mikä yksilöi yksittäisen objektin päivitystä varten. Joten MML tietokannalle pitäisi
saada varmaan jostakin oma “id avaruus” ?
Päällekäiset tiet, ja nimistön puhdistus pitäisi onnistua ihan SQL:llä, voisi olla toimiva,…
Voisko tuotanto olla tällänen:
OMAT KARTTAT, KARTAN JAKELU PALEVLUT MUODOSTAMINEN JA PÄIVITYS:
OSM materiaali, esim. finland-latest.osm.pdf —> osm2prsql -append
Omat OSM lisäykset ----> osm2prsql -append
ja
MKL aineisto → gdal → ogr2osm -append MTK.py ( JOKU TÄGI MIKÄ MTK VERSIO JA PÄIVITYS PSM ) → osm2prsql → sql käsittelyllä päällekkyydet pois
ko. muodostettu tietokanta takasin OSM muotoon ja edelleen Nominatimille ja esim. android/Iphone/garmin karttojen tuotantoon ja
itse OSM viimesimmäksi finland-latest.osm versioksi ??? Ja sama uudestaan taas kun MTK tietokanta riittävästi muuttunut vai saako
MTK:lta pelkät muutokset ???
Tietysti muodostuneen tietokannan voisi käsintarkastelun jälkeen viedä takasin OSM:äksi.
Niin lisenssistä viellä, musta tuo vastaus oli selkeä, nykynen on riittävä ja mitään erillistä sopparia ei tule.
Viimesin MTKGML.py antaa virheen:
AXIS[“Easting”,EAST],
AXIS[“Northing”,NORTH],
AUTHORITY[“EPSG”,“3067”]]
Traceback (most recent call last):
File “ogr2osm.py”, line 656, in
parseData(data)
File “ogr2osm.py”, line 336, in parseData
parseLayer(translations.filterLayer(layer))
File “ogr2osm.py”, line 397, in parseLayer
parseFeature(translations.filterFeature(ogrfeature, fieldNames, reproject), fieldNames, reproject)
File “ogr2osm.py”, line 418, in parseFeature
translations.filterFeaturePost(feature, ogrfeature, ogrgeometry)
File “/home/joni/src/ogr2osm/translations/MTK-GML.py”, line 47, in filterFeaturePost
feature.tags = mtk_features.get(ogrfeature[‘kohdeluokka’], mtk_default)(ogrfeature)
File “/home/joni/src/ogr2osm/translations/MTK-GML.py”, line 587, in
44803 : lambda f: { “man_made” : “tower”, “height” : ustr(float(fget(‘korkeusarvo’, 0.0))/1000.0), },
File “/home/joni/src/ogr2osm/translations/MTK-GML.py”, line 58, in fget
val = ogrfeature[key]
TypeError: string indices must be integers, not float
(jpk)joni@mpi1:~/src/ogr2osm$
keimo, siirtyykö korkeyskäyräkin ? Eli riittääkö osm-xml uuden tyylin lisäys, ilmeisesti OSM DATA
ei tunne korkeus käyrää, niinkö ??? Pitäiskö tyyleille antaa yhteiset nimet jostain ?
Mistä saataisiin vanha tietokanta syvyyskäyrillä,… missä jaossa ???
NIIN Maanmittaushallitus PÄIVITTÄÄ TIETOKANTAANSA KOKO AJAN, PÄIVITYKSET PITÄISI SAADA SIIRTYMÄÄN
MAHDOLLISIMMAN AUTOMAATTISESTI !
Toisaalta voi olla niinkin, että voimme jättää tämän ongelman ratkaisemisen myöhemmäksi. Näin siksi, että MML ei (tietääkseni) mitään diffejä pysty toimittamaan, joten se jäisi joka tapauksessa meidän tehtäväksemme. En tiedä miten “diffit” voisi tehdä, mutta joka tapauksessa se aineisto, josta importti tehdään, pitää tallentaa johonkin säilöön, esimerkiksi torrentteina, joita importoijat sitoutuvat säilyttämään, kunnes seuraava importti tehdään. Siinä vaiheessa voi sitten yrittään jotenkin selvittää muutoksia edellisen importin lähdeaineistoon.
Niin lisenssistä viellä, musta tuo vastaus oli selkeä, nykynen on riittävä ja mitään erillistä sopparia ei tule.
Ei lisenssiasia ole vielä selvä, mutta jos MML:ta saisi vastauksen, että “vaadittava vastaavat maininnat …” ei kosketa OSM:ia, niin sitten lisenssiongelma saattaisi olla ratkaistu. Tavallaan kyseessä olisi erikoislisenssi OSM:lle.
Muuta:
Dokumentissa http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Road_Import_Stage1_Plan#Tagging_Plans on kirjattu, että “We feel no need to have source attribution in each object. It would just bloat the database unnecessarily and the current requirement for a separate import account should be enough to distinguish imported data from the other edits.”
Laittaisin tuon edellisen toiseen järjestykseen siten, että aloitetaan tuolla “separate import account”:lla ja sen jälkeen todetaan, että source attributionia ei siten tarvita. Olisikohan tarvetta käyttää useita “separate import accunteja”?
Ehdotan seuraavaa importin suunnitteluun liittyen:
Jos MML:n lisenssiongelma ratkeaa myös Metlan lisenssiongelma saattaisi olla ratkaistavissa samalla periaatteella. Metlan avointen aineistojen lisenssi on kutakuinkin ellei sama kuin MML:lla (http://kartta.metla.fi/). Metlan aineistosta voisi tuoda metsäkuviotietoja ja metsän maapohjatietoja. Metlan aineistojen importtauksen voisi ehkä ottaa samaan prosessiin mukaan.
keimo, siirtyykö korkeyskäyräkin ? Eli riittääkö osm-xml uuden tyylin lisäys, ilmeisesti OSM DATA
ei tunne korkeus käyrää, niinkö ???
OSM ei talleta korkeuskäyriä. Joitain korkeustietoja on mahdollista tallettaa, mutta ei korkeuskäyriä. Tästä taisi olla muutama sivu aiemmin.
Mistä saataisiin vanha tietokanta syvyyskäyrillä,… missä jaossa ???
Ei ainakaan vapaasti taida olla missään tarjolla. MML poisti vesistöön (veneilyyn) liittyvät tiedot aineistosta ennen aineiston vapautusta. Eikös tästäkin ollut jotain sivu pari aiemmin tai jossain toisessa ketjussa.
Siinä olisikin uudelle yhteisöprojektille paikka: syvyystietojen kartoittaminen. Näyttäisi siltä, että OpenSeaMap ei sekään taida tallettaa syvyystietoja, eli perustuisiko kokonaan OSM aineistoon: http://openseamap.org/
Käsityö kuulostaa pahalta,
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.
kaikissa systeemeissä järjestelmän saaminen pystyyn on helppo juttu verrattuna siihen
että se on pystyssä 10 ehkä 50 vuoden päästä ja toimii vielläkin.
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.
NIIN Maanmittaushallitus PÄIVITTÄÄ TIETOKANTAANSA KOKO AJAN, PÄIVITYKSET PITÄISI SAADA SIIRTYMÄÄN
MAHDOLLISIMMAN AUTOMAATTISESTI !
Heh-heh. Moni koodipuolellakin varmasti maksaisi maltaita jos saisi aukottomasti toimivan automaatin joka huolehtii esim. confliktit. Muistathan että myös OSM päivittyy jatkuvasti!
En ole ehtinyt, enkä ihan heti ehdi, kun tappelen rinnakkain laskenta ongelmien kanssa, perehtyä OSM päivitys mekanismeihin mutta näillä vilasuilla on sellainen
tunuma että siellä on joku osm_id mikä yksilöi yksittäisen objektin päivitystä varten. Joten MML tietokannalle pitäisi
saada varmaan jostakin oma “id avaruus” ?
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!
Päällekäiset tiet, ja nimistön puhdistus pitäisi onnistua ihan SQL:llä, voisi olla toimiva,…
Voisko tuotanto olla tällänen:
OMAT KARTTAT, KARTAN JAKELU PALEVLUT MUODOSTAMINEN JA PÄIVITYS:
OSM materiaali, esim. finland-latest.osm.pdf —> osm2prsql -append
Omat OSM lisäykset ----> osm2prsql -append
ja
MKL aineisto → gdal → ogr2osm -append MTK.py ( JOKU TÄGI MIKÄ MTK VERSIO JA PÄIVITYS PSM ) → osm2prsql → sql käsittelyllä päällekkyydet poisko. muodostettu tietokanta takasin OSM muotoon ja edelleen Nominatimille ja esim. android/Iphone/garmin karttojen tuotantoon ja
itse OSM viimesimmäksi finland-latest.osm versioksi ??? Ja sama uudestaan taas kun MTK tietokanta riittävästi muuttunut vai saako
MTK:lta pelkät muutokset ???Tietysti muodostuneen tietokannan voisi käsintarkastelun jälkeen viedä takasin OSM:äksi.
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ä” ;-).
Niin lisenssistä viellä, musta tuo vastaus oli selkeä, nykynen on riittävä ja mitään erillistä sopparia ei tule.
Olen samaa mieltä tuosta MML:n vastauksesta, ei se sinänsä ollut mitenkään yllättävä (suullisesti sama viesti onkin jo kuultu).
–
i.