GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Tuo koodi on nähtävästi jollekin toiselle GDAL/OGR:n tukemalle tiedostomuodolle, GML-tiedostoja tuolla konvertoitaessa ei niihin saa tageja aikaan.

Otin sitten editorin kauniiseen käteen ja konvertoin wikistä löytyneet kohdeluokka → OSM tagi -taulukot Python-koodiksi. Translaatiokoodi löytyy täältä: https://github.com/tpikonen/ogr2osm-translations (tiedosto on mtk-gml.py).

Sen verran testailin importteja, että ainakin yksinkertaiset konversiot mallia (kohdeluokkanumero → staattinen tagisetti) toimivat. Jos tageihin pitää lisätä tietoja muista geometrian featureista (tekstit yms.), niin voipa sekin toimia, mutta vastuu debuggauksesta on käyttäjällä.

moi,

Ois kiva kokeilla tuota sun scriptiä,… mutta kun ogr2osm antaa:

File “/usr/local/lib/python2.7/dist-packages/osgeo/init.py”, line 21, in
_gdal = swig_import_helper()
File “/usr/local/lib/python2.7/dist-packages/osgeo/init.py”, line 17, in swig_import_helper
_mod = imp.load_module(‘_gdal’, fp, pathname, description)

Mulla on uusin gdal, kännetty phyton lipun kanssa,… voisko tuo olla niin
että .py kirjastosta on jotenkin vanhempi versio koneessa ja sen se löytää
eikä uutta käännettyä???

Phyton sydeemi ei ole tuttu ja juuri nyt en jaksa tuota perkaamaan,…

Niin keimo, sun scriptistä, siis tagit muuttuu osm muotoon tuolla MTK:n *.xml ( GML )
tiedostoista osm kovertoitaessa,… saako sitten osm2prsql:llä sen sitten
tietokantaan niin että mapnikillä onnistuu renderöinti?

Kakkosvaihtoehto ois että
osm2prsql kyllä lukee uuden GDAL ohjelmalla tuon MTK formaatin suoraan tietokantaan mutta sitten tarttis
saada jotenkin tuo mapnik ymmärtää tuon tietokannan rakenne,… sekin voisi toimia,…

Kuitenkin tuo sun skripti vois olla ratkaisu sillä

MTK-GDL (ogr2osm.py)–> OSM
(osm2psql)—> Opentreet Psql
(nominatimin osm importti)—> nominatim
(xxx) —> Android Navigation

joo löytyy noita aplikaatioita joiden pitäisi OSM tietokanta saada Android aplikaation
ymmärtämään muotoon,… eli lähellä ollaan että aineisto on avointa ihan oikeasti.

Pitää saada tuo ogr2osm.py toimimaan niin kokeilen.

Joo,… kannattaa aina tehdä kopio GIS tietokannasta ennenkuin lisää, poistaa tai muokkaa sitä,
ihan aina !

Mulla on ongelmana kun pienet tiet ja maasto kohteet puuttuu paikallisesti,…
maastotietokannasta ne olis kun tulis,…

joo testi ongelma ratkesi:

export PYTHONPATH=/home/joni/src/gdal_26324/lib/python2.7/site-packages/:$PYTHONPATH
export LD_LIBRARY_PATH=“/home/joni/src/gdal_26324/lib”,$LD_LIBRARY_PATH

mutta kimmo, scriptisi herjaa, kunhan sen ekalle riville ekaksi lisää # -- coding: iso-8859-15 -- seuraavaa:

(gdal)joni@mpi1:~/src/ogr2osm$ python ogr2osm.py …/…/MAP-MTK/M5131R.xml -t MTK-GML.py
…
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 18, in filterFeaturePost
feature.tags = mtk_featuresogrfeature[‘kohdeluokka’]
File “/home/joni/src/ogr2osm/translations/MTK-GML.py”, line 258, in
36291 : lambda _: { “ele:n60” : f[‘teksti’], },
NameError: global name ‘f’ is not defined
(gdal)joni@mpi1:~/src/ogr2osm$

Korjasin tuon enkoodauksen ja yo. näppivirheen skriptiin, kiitos vaan bugiraportista. Testasin nyt ogr2osmia tuolla translaatiolla noin puolen karttalehden GML-fileisiin, eikä se ainakaan niillä enää kaatunut. Konversion sisällön tarkkuudesta en mene edelleenkään takuuseen

Jos saat MTK-GML → postGIS importin pelaamaan, niin laittelepa raporttia tänne foorumille. Tällä hetkellä org2osm konversio tosin on sellainen, että suurin osa datasta muuntuu ilman mitään tageja. Tietokantaan tulee siis paljon turhaa kamaa jota ei lopullisessa kartassa näy.

python ogr2osm.py …/…/MAP-MTK/M5131L.xml -t MTK-GML.py

…
UNIT[“metre”,1,
AUTHORITY[“EPSG”,“9001”]],
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 19, in filterFeaturePost
feature.tags = mtk_featuresogrfeature[‘kohdeluokka’]
KeyError: 9325
(jpk)joni@mpi1:~/src/ogr2osm$

Kimmo, jos jaksat testata vaikka MTK:n kartta tiedostolla
https://drive.google.com/folderview?id=0Bw75vZr1UKV-TjFVbXl3MmI1SEU&usp=sharing
niin kun mä testaan niin ollaan jo testaamassa scripitin siirtymistä järjestelmästä toiseen.

Jos tää skulaa niin tää on hieno homma,…

Korjasin tuon fiban, M5131L.xml:n konversio toimii nyt kuin vettä vaan (ainakin täällä ).

joo ei herjaa,… viellä kun mapnik sen renderöi, yritän tuonnempana uudestaan!
osm2prsql luki kyllä yhden palan sisään mutta lisääminen ei onnistunut, johtuisko
palojen reunalla olevien kohteiden samoista nimistä,… mene tiedä tutkitaan,…

Skriptit toimivat myös Windowsilla kun käyttää Tamas Tzekeresin GDAL:in kehitysversiokäännöksiä http://gisinternals.com/sdk/
Muunnetut kohteet menevät täsmälleen oikeille paikoille, tämän voi tarkistaa vaikka käyttämällä JOSM:ssa kapsin WMS-palvelua taustalla. Rakennuksista syntyy jostain syystä sekä viiva että polygoni, joista viivalla on pelkkä source-tagi ja polygonilla lisäksi building-tagi.

Tollanen herjaus tulee kun ekan jälkeen alkaa lisäilee,…

===
joni@mpi1:~/src/ogr2osm$ osm2pgsql -a --database gismtkosm --slim M5134L.osm
osm2pgsql SVN version 0.83.0 (64bit id space)

Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
NOTICE: table “planet_osm_point_tmp” does not exist, skipping
Setting up table: planet_osm_line
NOTICE: table “planet_osm_line_tmp” does not exist, skipping
Setting up table: planet_osm_polygon
NOTICE: table “planet_osm_polygon_tmp” does not exist, skipping
Setting up table: planet_osm_roads
NOTICE: table “planet_osm_roads_tmp” does not exist, skipping
Using built-in tag processing pipeline
Allocating memory for dense node cache
Allocating dense node cache in one big chunk
Allocating memory for sparse node cache
Sharing dense sparse
Node-cache: cache=800MB, maxblocks=102401*8192, allocation method=11
Mid: pgsql, scale=100 cache=800
Setting up table: planet_osm_nodes
Setting up table: planet_osm_ways
Setting up table: planet_osm_rels

Reading in file: M5134L.osm
Processing: Node(209k 209.7k/s) Way(17k 17.00k/s) Relation(0 0.00/s)COPY_END for COPY planet_osm_nodes FROM STDIN;
failed: ERROR: duplicate key value violates unique constraint “planet_osm_nodes_pkey”
DETAIL: Key (id)=(-2) already exists.
CONTEXT: COPY planet_osm_nodes, line 1: “-2 865508874 316732384 \N”

Error occurred, cleaning up
joni@mpi1:~/src/ogr2osm$

ID on pääavaimena, ja ogr2osm.py aloittaa oletusarvoilla niiden luomisen aina nollasta. Tietokannan eheyssääntöjen takia toista settiä ei voi viedä tauluun, koska pääavaimessa ei voi esiintyä samoja arvoja. Tuossa Paul Normanin versiossa on mahdollista antaa ensimmäiselle muunnetulle kohteelle haluttu ID käyttämällä parametria --id. Kokeile laittaa siihen vaikka miljoona toista ajoa varten, kaksi miljoonaa seuraavalle jne.

–id käyttäen sain useamman karttapalasen luettua tietokantaan. Kuitenkaan mapnik ei uutta dataa renderöinyt, viellä,… voi olla renderd
configurointi ongelma,…

Voisko tuossa olla viellä viilauksen tarve osm.xml,… winter_road, track,… yms puuttui,…
jostain syystä renderd tippuu päältä pois,… niitä on kaksi rullaamassa yksi yhdelle
ja toinen toiselle tietokannalle,

Sain näkymään saimaan maastotietokannan, 23 karttalehteä,… pienien teiden nimet ei näy taitavat olla erilisessä tiedostossa,… seuraavaksi pitää saada
viellä korkeusmallit,…

Vika oli lopulta renderd - apache configuraatiossa,… eli:

• mapnikissä pitää olla vaikka suomi asennettuna ennen kun ajaa maastotietokantaa sisään
• kokeilussa kannattaa käyttää eri tietokantaa kun mitä KÄYTTÄÄ, render.conf configuroi esim.

[mtk]
URI=/osmmtk/
XML=/etc/mapnik-osm-data-mtk/osm.xml
DESCRIPTION=This is the standard osm mapnik style

XML on mapnikstyle, kaikille tietokannalle tai tyylille oma hakemisto paketti, data-settings tulee tietokannan nimi
URI on tile serverin polku palvelinnimen juuresta ja se tuonne openstreetmap java skriptiin, niitäkin omansa jokaiselle kopiolle

Noin lyhytesti, aikaa palo kun dokumentaatio pettää, vinkkejä:
http://geoinformatics.fsv.cvut.cz/gwiki/Custom_OpenStreetMap_Rendering_-_OpenTrackMap_Experience
http://wiki.openstreetmap.org/wiki/PostGIS/Installation
http://sourceforge.net/apps/mediawiki/gpsdrive/index.php?title=Setting_up_Mapnik
http://switch2osm.org/serving-tiles/manually-building-a-tile-server/

Komentoja:

ogr2osm ympäristö:
virtualenv jpk
source jpk/bin/activate
pip install /home/joni/src/gdal_26324/lib/python2.7/site-packages
pip install /home/joni/src/gdal/swig/python/setup.py
export PYTHONPATH=/home/joni/src/gdal_26324/lib/python2.7/site-packages/:$PYTHONPATH
export LD_LIBRARY_PATH= /home/joni/src/gdal_26324/lib:$LD_LIBRARY_PATH
cd gdal
make install
cd …
cd ogr2*
python ogr2osm.py …/…/MAP-MTK/M5411L.osm -t MTK-GML.py --id 22000000000
deactivate

Karttojen tuominen postgrestietokantaan *.osm muodosta

osm2pgsql -a --database gismtkosm --slim M5132R.osm

mistä aineistosta saisi syvyyskäyrät, merikarttamerkit, ne on uusista poistettu ?
onko joku siirtänyt laserkeilaus aineistoa openstreet / mapnik renderöinti , miten ?
oisko ohjetta korkeus käyrälle?

Minne koottaisiin, minne on jo koottu ohjeita maanmittauksen aineistojen siirtoon?

Voisi nääkin kokemukset jalostaa selkokielelle!

Kimmo kiitos muunto scriptistä :):):):)

Liikenneviraston merimerkkejä ja syvyyskäyriä ei saa OSM-käyttöön luvallisesti mistään. Aiheesta tästä:
http://maastotiedotauki.blogspot.fi/2012/04/mihin-merimerkit-katosivat.html
Maksua vastaan omaan käyttöön voi tietysti hankkia tuonkin aineiston ja tehdä siitä vaikka Mapnikilla merikortit omaksi ilokseen. Openseamapissa ei liene kovin paljon tietoa vielä http://www.openseamap.org/

Korkeuskäyriin voi soveltaa tätä ohjetta http://wiki.openstreetmap.org/wiki/Contours
Käyrät vain pitää riipiä ogr2ogr:llä MTK-GML:n korkeuskäyrätasolta irti ja kirjoittaa PostGIS-kantaan.

Lähinnä kiinostaa ne vanhat väylä merkinnät, syvyys käyrät, mitkä painetuissa Maanmittauksen
kartoissa ennen oli,… kai jollaakin on 2012 vanhempia karttatietokantoja, saa niitä varmaankin
viellä jaaa, mutta uutta aineistoa ei !

Merikartat on ihan oma juttunsa, niitä ei kannata paljoa värkätä itse kun kustannukset
voivat olla tosi isot!

Hyvä että sait toimimaan. Tuo konversioskripti on tosiaan vielä raakile, mm. nimiä (eli nimi_suomi featurea) ei konvertoida vielä lainkaan. Parantelen kuitenkin tuota kun joudan, ja pätsejä otetaan myös vastaan.

MTK-datan konversio osm-formaattiin ei siis (kohta) ole mikään ongelma, mutta mielenkiintoisempi kysymys on, mitä datalla sitten tehdään? Kiinnostaisiko ketään tileserveri, josta voisi käydä katsomassa minkälainen suomen Openstreetmap voisi olla, jos lisenssit olisivat yhteensopivat? Tai siis kiinnostaisiko ketään niin paljon, että viitsisi hostata sellaista?

Openstreetmap-projektin kannaltahan Maanmittauslaitoksen data on tällä hetkellä lähinnä haitta, motivaatio tehdä kartoitustyötä uudestaan tuskin kasvaa, kun tarjolla on lähes samoin lisenssiehdoin valmis kartta. Toivottavasti lisenssikiemurat joskus saadaan sovittua, muuten saattaa käydä niin, että avoimia karttaprojekteja on tulevaisuudessa useampia. Toisissa mukana eri maiden maanmittauslaitosten avoimet datat, toisissa ei.

Oma motivaatio lähti kun Google:lelta alkoi tulla yksi toisensa jälkeen huonompia versioita Google Earthistä.
Asensi openStreetMap:in ja nominatim 2vk sitten ratkaisuksi.

Ei tässä OpenStreetMAp kartotus työ turhaa ole, karttapohjat pitäisi saada sovitettua ja aina jommassa kumassa on
virheitä, löysin niitä virheitä MTK aineistosta paljon ja OpenStreetMap:issä kun se on tuore ja vähän tietoa niin virheitä
juuri ollut,… maanmittauksen aineistossa on turhaa tietoa useampaan käyttöön,… tile palvelimessa tulee tiilejä eikä
layereitä,…

===

Uskon että kartta pohjasia palveluja tulee räjähdysmäisesti ja monta. Itse tulen pitämään yhtä, keskittyen Saimaa / Suomi / Balttia
ja lähinnä veneilyä ja vesiurheilua tukemaan - lähinnä omaan käyttöön, ilmasta tai edes toimivaa datasiirtoa kun ei ole
Lappeenranssa mun osoitteessa,… niin se jää omaan käyttöön,… mutta kun ohjeet jaossa niin uskoisin useamman yhdityksen
ja yrityksen näitä pystyttävän.

===

Varmaankin tärkein huolenaihe olisi yksinkertaisten toimintatapojen sopiminen miten
postgis tietokantaan:

• lisätävä tieto ideksoidaan, nimetään : eri lähteistä tuleva datan voisi *.osm tiedostoina lisätä, finland-plus-MTK.osm, finland-plus-yachts.osm, finland-contours.osm

• miten se tietokanssa on poistettavissa, pathsättävissä ja korjattavissa : siellä on tai paranettava olemassa olevaa mekanisimia tiedon lähteille, ohjeistettava
  tiedon tuonnissa oikeat tavat

• joku paikka minne ohjeet ja linkit torrenteihin mitä kautta data jaossa, esim: http://www.csc.fi/tutkimus/alat/geotieteet/paikkatieto/aineistot , http://ubuntu.fi
  Openstreet Wiki fi,… omat jorinat laitan aikanaa boy007.dy.fi niin ei ainakaan katoa netsistä vasta kun Googlea harmittaa.

Yhtenäisillä tavoilla saisi käytettävyyden sille tasolle että 4päivän sijasta ihan 20min lähtee postgis palvelin suomesta pystyyn, hyvin pienestä
kiinni että näin olisi, ohjeet ja ohjelmistojen paketoiminen,…

latuviitta ideanahan oli saada osm muodosta taas muihin muotoihin, sieltä löytyy tavat miten tää aineisto lähtee garminiin, androidiin,…
… ne ohjeet voisi nyt paketoida samaan tai mielumminkin patch openstreetmapiin mikä lisää data exportin käyttöliittymään jokaisen ulottuville ilman
scripteihin yms,… puuttumista,…

Openstreet palvelin kehitystyö on kovassa kuohussa ja hankala paketti kokonaisuudessaan pystyttää,… itse tappelen seuraavaksi OAUTH:in pystyyn
ja sitten potlatch2 että voi oman palvelimen dataa muuttaa,… nuo kun asentuu itsestään joskus sudo apt-get openstreet-server paketilla niin
käyttäjiä ja karttoja synttyy joka niemen notkossa talvi iltoina!

Olen edelleen toiveikas siitä, että jonain päivänä MML:n aineiston lisenssiepäyhteensopivuus saadaan ratkaistua ja voimme aloittaa MML:n aineiston importtaamisen. Tuohon päivään voisimme etukäteen varautua sillä, että valmistelisimme importin mahdollisimman pitkälle. Se ei tule olemaan helppoa. Olennaista on tehdä importti siten, että OSM:n olemassaolevia tietoja kunnioitetaan ja importilla ainoastaan täydennettäisiin tai kenties korjattaisiin geometriaa, mikäli se on MML:n aineistossa parempi.

Mikäli importti pystyttäisiin tekemään, OSM-aineisto Suomen osalta muuttuisi kattavaksi ja mahdollisesti myös melko homogeeniseksi. Importin jälkeen aineistoa pystyttäisiin päivittämään yhteisöllisesti ja toivottavasti myös MML:n päivitykset jatkossa myös hyödyntäen.

Yksi merkittävä syy siihen, miksi MML:n aineisto pitäisi saada OSM tietokantaan on se, että OSM sisältää valtavan määrän erilaisia työkaluja aineiston ylläpitämiseen, visualisointiin, hyödyntämiseen ja esim. kyselyihin. Jos MML:n aineisto olisi OSM:ssa, nämä kaikki työkalut olisivat käytettävissä MML.n aineiston kanssa.

Lisäksi kannattaisi harkita kansallisen openstreetmap sivuston perustamista. Sellainenhan on jo usealla maalla, ainakin Saksalla (http://openstreetmap.de/), Ranskalla (http://openstreetmap.fr/), Espanjalla (http://www.openstreetmap.es/) Venäjällä (http://openstreetmap.ru/), muistaakseni myös Irlannilla ja varmaankin monella muullakin maalla. Sivusto tarjoaisi OSM-aineiston meikäläisiin oloihin tiilitettynä (väritettynä) ja ohjeita kotimaisilla kielillä.

Mikä MTK lisensissä on ongelmana?