GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

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 ???

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.

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:

  • Pyritään tekemään dokumentaatio pääosin englanninkielellä
  • Lisätään etusivulle linkki importin suunnitteludokumentaatioon (http://wiki.openstreetmap.org/wiki/Fi:Main_Page)
  • Tehdään lyhyehkö pääsivu suomeksi ja siitä linkki englanninkieliseen vastaavaan, josta sitten linkkejä alisivuihin
  • Pääsivulla on kuvattu lisenssi ja siihen liittyvät ongelmat sekä importin vaiheistus
  • Eriytetään mäppäyssivu (sivu, jossa kuvataan kuvaus MML->OSM) omaksi sivukseen, Mäppäys on varmaankin parasta kuvata taulukkona, joka noudattaisi MML:n tietojen järjestystä (tämä vaikuttaa hyvältä pohjalta http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Luokat))
  • Jaetaan mäppäyksen kuvaus kahteen osaan: triviaali osa ja hankalampi osa, jossa jälkimmäinen sisältää aineiston, jossa esim. aluemuotoisten kohteiden ominaisuustietoja on kuvattu ”kartografisesti” tunnuspisteellä tms. kuvaustekstillä ja importissa nämä tiedot pitäisi pystyä yhdistämään

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.

OSM ei talleta korkeuskäyriä. Joitain korkeustietoja on mahdollista tallettaa, mutta ei korkeuskäyriä. Tästä taisi olla muutama sivu aiemmin.

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/

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.

Tuo diffien tuottaminen MML:n aineistoista vertaamalla edelliseen MML:n aineistoversioon on tosiaan helpohko operaatio. Ajatuksena oli toimia about siihen tyyliin kuin yllä kuvasit.

Olen samaa mieltä että tätä ei vielä tässä vaiheessa kannata edes ratkaista, koska ratkaisu saattaa osin tai kokonaan löytyä siinä vaiheessa kun Importin “phase 1”:stä lähdetään jatkamaan, eli siirrytään phase 2:ssa (tms) alueille joissa on jo tiedataa OSM:ssa (jolloin tarvitaan hiukan lisää kehitystyötä MML vs OSM objektien matchaystä varten. Syntynyttä työkalustoa pystyy ehkä hyötykäyttämään myös päivitysvaiheessa.


i.

Kiitos kommenteista ja ajatuksista!

Koitan illalla uudelleenmuotoilla tuota object attribuutiota, mutta kyseessä on wiki joten saat sinäkin siihen koskea :-D.

Uusi accountti per importti voisi olla järkevää, mutta tuossa on vaan se ongelma, että accounteilla pitää olla uniikki email osoite, josta on ainakin muuallapäin maailmaa ollut jonkun verran purnausta. Valitettavasti erillisiä accounteja vaativilla admin puolen kavereilla ei näytä olevan intoa koodata osmiin “secondary usernameja”, missä yhteys varsinaiseen käyttäjään olisi vielä vahvempi (käyttäjien tuntemisen kannalta tuo olisi kiva feature eli tiedettäisiin suhteellisen suoraan että importtaaja x_yzimport on sama käyttäjä joka editoi nimellä x). Secondary usernamet jakaisivat tietenkin sen emailin automaattisesti :-).

Enemmän olen itse koittanut miettiä miten on järkevää tehdä import ja sen jälkeiset käsin yhdistely muutokset suhteessa eri accounttien käyttöön (esim. nuo aliverkko pitää uppimisen jälkeen tietysti yhdistää käsin siltä puuttuvalta 40m+ matkalta OSMissa olevaan dataan, mitä accounttia käytetään tähän?).

Tämä oli myös oma ajatukseni. Aion tehdä oman sivun ohjeistosta “teamille”, jonka linkkaan tuohon planin “step-by-step” kohtaan. Sen team dokkarin suomikäännöstä voi ehkä harkita jos kääntäjiä löytyy avuksi.

Koska tuo plan dokkari on yksi importbyrokratian vaatimus, pidän sen tuollaisena, mutta itse “teamiin” osallistuville toteuttajille tehdään mielummin oma ohje järkevämmällä rakenteella, monet eivät jaksa lukea edes lyhyempää sivua huolellisesti läpi ;-).

Tämä importti jota nyt suunnittelen keskittyy pelkkään tiestöön. Erilliset importit saatte/saadaan suunnitella ja toteuttaa muille luokille (vaikkapa rajat, vesistöt, sähköjohdot, “vuorenhuiput”, suot, jne.). Ehkä jonkinlainen yhteinen lisenssi yms. tietosivu noille voidaan tuosta road sivun rungosta voidaan toki repäistä, jos ja kun joku rupee niitä seuraavia import planeja kirjoittamaan.

Joo, tuo yhdistely MTK:ssakin tuo oman lisänsä haastetta. Mutta nähdäkseni silti suurin haastejakolinja kulkee OSMssa ei mitään ja MTK:ssa ja OSM:ssa on päällekkäisyyksiä välissä.

Joku arvuutteli että MTK:sta kin saisi metsät… “sitä on kaikkialla missä ei oo mitään muuta”, mutta tarkkuudesta en kyllä osaa itse sanoa juuta enkä jaata :-).


i.

Ei pitäisi tuupata testaamatonta koodia… Nyt tuo on korjattu.

OSM ei tosiaan sisällä korkeuskäyriä, mutta esim. Opencyclemapin tiilissä ne on renderöityinä. Datalähde ei ole OSM, vaan NASAn tietokanta SRTM. Tuon wikisivun lukemalla tosin oppii, että onhan tuonkin datasetin jo joku ehtinyt konvertoimaan OSM-formaattiin.

Ei ollut alkuun. Kas, sieltä saa siis päivitetyt versiot. Tai tässä aineistossa taitaa olla siis tien alku- ja loppupään osoitteet. Välit pitää interpoloida.

Tuon taustakartan osoitteet tulevat VRK:stä ja sinne ne tulevat taas kunnista. VRK:n RHR aineisto ei ole ilmaista aineistoa, eikä ilmeisesti ihan nopeasti tulossakaan…

Maastotietokananssa ei ole metsää. Eli kaikki mikä on valkoista on metsää :wink: Pellot ja niityt löytyvät yms.

CorineImport (kun taas jatkan sitä), niin tuo perus-metsämaskin OSM:n Suomen osalta. Sitä voi sitten parantaa MML:n ja Metlan aineistoilla.

Metlan aineiston käyttö edellyttäisi aika vahvaa yleistämistä ja esiprosessointia. Sisältää sen verran paljon OSM:n kannalta turhaa tietoa.

P

Minä aloittaisin poistamalla tähän mennessä tehdyn Corine-importin kokonaan. Seuraavaksi pitäisi laittaa järvien rantaviivat kuntoon maastotietokannasta ja lisätä OSM:sta vielä puuttuvat vedet; tämän jälkeen sama kaikille muille maastotietokannasta löytyville alueille: suot, pellot, kalliot, vesijättö, hiekkakuopat ym. Nämä ovat maastotietokannassa paljon tarkemmin kuin Corinessa ja laatu varmasti kelpaa OSM:iin. Jäljelle jää luokittelematonta metsää, ja sitä voisi sitten pilkkoa Corinen tai Metlan aineiston perusteella tarkempiin maankäyttöluokkiin.

Tämä varmaan kirpaisisi Corine-importteja tehneitä, mutta eihän kukaan muuten ikinä jaksa sovittaa esimerkiksi Corinen metsien ja OSM:n järvien rajoja keskenään, ja jos niitä ei soviteta, niin lopputulos ei näytä kovin laadukkaalta. Tällaisia esimerkkejä ei ole vaikea löytää http://www.openstreetmap.org/#map=14/61.1776/25.8453&layers=N

OSM:n metsätyypit https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dforest:

name=*
type=coniferous
type=broad_leaved
wood=deciduous
wood=mixed
crop=*

con·i·fer (k n-f r, k n-) n. Any of various mostly needle-leaved or scale-leaved, chiefly evergreen, cone-bearing gymnospermous trees or shrubs such as pines, spruces, and firs.

Deciduous means “falling off at maturity”[1] or “tending to fall off”,[2] and is typically used in reference to trees or shrubs that lose their leaves seasonally

Eli havumetsä/lehtimetsä/sekametsä jaon voi tallettaa. Metlan tiedoista saisi mantyvaltaisuus/kuusivaltaisuus -tiedonkin, mutta sen tallentamista OSM ei taida tukea.

Maastotietokannassa näyttäisi olevan päämetsätyyppijako: http://www.maanmittauslaitos.fi/sites/default/files/Maastotietokohteet.pdf ja sieltä “4.5.20 Metsämaan kasvillisuus”:
Havumetsä (32710)
Lehtimetsä (32713)
Sekametsä (32714)
Varvikko (32715)
Pensaikko (32719).

Ehkä sittenkin kannattaa jättää Metla pois importista. Hyvää tietoa siellä on. Jos haluaa nähdä, mitä tietoja Metla tarjoaa, Paikkatietoikkunan karttaikkunasta löytyy, kohdan “Maanpeite” alta. Suurin osa kyseisen alakohdan tasoista on Metlan avointa aineistoa. Tietoa voi käyttää esim. sienestysreissun suunnittelussa, jos ei tiedä sienimetsiä ennestään.

Voisiko tuon yhdistää osaksi MTK-importin suunnitelmaa? Turha niitä Corine importteja on poistaa ennen kuin MTK-importtia päästään oikeasti toteuttamaan.

Yksi asia, mistä ei ole ollut (luullakseni) puhetta MTK-importiin liittyen on aineiston tarkkuus: Onko MTK-aineisto liian tarkkaa OSM:lle esim. haja-asutusalueilla? Pitäisikö sitä yleistää? Kyseessä on kuitenkin, kuten nimikin antaa ymmärtää, tiekartta.

Niin minustakin olisi paras toimia. Mutta poistossa pitää huomioida se että niitä on siellä täällä joku saattanut parannellakin. Eli vain pelkästään import versioista koostuvat objektit (kaikkine aliobjekteineen) voidaan surutta poistaa.

Maastokohteista varmaan joutunee karsimaan pisteitä (koitin jossain toisessa threadissä kysellä joltain lukuja paljonko järvistä katoaa pisteitä jos niitä yksinkertaistaa eri kokoisilla virhesallimuskriteerillä, mutta en saanut silloin vastausta miten se vaikuttaa node määriin). Noissa teissä liikanodeisuus ongelmaa ei juurikaan ole näkyny (muutaman noden lähellä toista olen bongannut, mutta niitä on todella vähän suhteessa siihen kuinka paljon olen noita eri puolilta jo ehtinyt vilkuilemaan).

Poisto voi ehkä mennä “samassa”, mutta toteutuksellisesti se on kuitenkin oma operaationsa, joka suoritetaan ensin ja sitten ajetaan varsinaista importtia sisään vasta.


i.

Niin eikö MML maastotietokannassa olekkin korkeuskäyrä,… aiankin tägi löytyy.

Eikö tuon voi talettaa samaan finland-mml.osm tiedostoon ja se vaatii mapnikissä
käsittääkseni korkeuskäyrälle oma määrittely, eikö tuo käyrä ole datana
ihan samalainen kuin kaikki way ???

Päivitys rumban saisi toimimaan objektien nimellä ja kyllä ohjelmisto osaa
tietokannasta poistaa saman kaltaisen objektin, ettei oo kahteen kertaan.
Siinä voisi sitten käyttää järkeä ja suosia osm:ss olevaa dataa, noin nopsasti
katsottuna sieltä mistä sitä on se tuoreempaa.

Syvyyskäyrät on vanhoissa tiedostoissa ja sellaista kaipaisin, niitä ei tarvitse
OpenStreetMap:iin viedä. Omaan käyttöön ne saa varmasti ottaa ja kun
lisenssin saa käsiin voihan se olla että yhdistely on mahdollista julkisestikkin.
Syvyyskäyrä kun on korkeuskäyrän jatko,…

Tää thread ei ole OpenStreet map MML import vaan että aineistoa voi käyttää ja jatkojalostaa,…
ja miten se saadaan eteenpäin.

Itse en halua MML aineistosta jättää mitään pois, filtteroinin voi tehdä mapnikin filttereillä,…

ITSE EN OLE RAKENTAMASSA OPENSTREETMAP:iä vaan hyvää karttaa omiin harrastuksiin
missä on kaikki tarpeellinen,… se varmaan muillakin?

Kyllä ainakin tällä karttalehdellä on kapsissa syvyyskäyrät mukana

ogrinfo /vsizip/vsicurl/http://kartat.kapsi.fi/files/maastotietokanta/kaikki/etrs89/gml/M5/M52/M5222R_mtk.zip Syvyyskayra |more

Jos syvyyskäyriä aikoo käyttää Mapnik-kartalla, niin minä en muuntaisi niitä ensin osm-xml-muotoon ja siitä osm2pgsql:llä tietokantaan, koska ogr2ogr:llä käyrät voisi viedä suoraan kantaan tai shapefileiksi. Niistä pitää sitten vain tehdä “datasource” Mapnikin määrittelyihin, mallia voi ottaa jostain valmiista shapefilejä käyttävästä tasosta, kuten tämä, joka löytyi jostain 5 vuotta vanhasta Mapnikin tyylitiedostosta

<Layer name="world-1" status="on" srs="+proj=merc +datum=WGS84 +over">
    <StyleName>world-1</StyleName>
    <Datasource>
      <Parameter name="type">shape</Parameter>
      <Parameter name="file">c:/data/world_boundaries/world_boundaries_m</Parameter>
    </Datasource>
  </Layer>

Hankalampi tilanne on sitten, jos samaa tavaraa on sekä OSM:ssa että maastotietokannassa tarjolla. Niistä sitten joutuu joko valitsemaan jomman kumman käyttöön tai yhdistämällä aineistoja joka tekemällä importteja OSM:in tietokantaan tai sitten viekkaalla SQL:llä omassa kannassa. Miettimistä tulee riittämään, mutta kyllä siitä jotain hupiakin saattaa saada irti. Onneksi ketään ei tiettävästi pakoteta tekemään töitä tällaisessa ympäristössä.

Niin, sitten tullaan siihen entä jos koko Maanmittaus aineiston tuo ogr2ogr:llä ja tekee mapnikiin
määrrittelyt sen käyttämiseksi. Oisko siihen ohjetta ettei pioneeriksi tarvitse käydä,…

Silloin nuo pysyisi erillään,… mutta ei saa siirtymään samaa karttaa androidille eikä nimistö dataa
nomatimille!

Toisaalta syvyys, korkeus ja muudata tulee yhdellä kertaa osm2ogr → osm"postresrg kautta ja
välissä syntyy jaeltava tavara.

Noin jakelun kannalta yksi tiedosto muoto on ja importti on helpompi kuin monta.

KYSYMYKSEEN "Onneksi ketään ei tiettävästi pakoteta tekemään töitä tällaisessa ympäristössä. " ANNAN AUTORATIIVISEN VASTAUKSEN,
ON PAKKO, EI VAPAAEHTOISTA. Kaikki jotka komntoivat threadissä ON PAKOTETTU, PAKOTETAAN JA ON AINA, HETI NYT KÄYTETTÄVISSÄ.

Kyllä tässä on ihan mietittävä juttu, katsotaan keneltä tulee se paras idea!

Minun tekemät Corine importit (FinCorineImport -tunnuksella tehdyt) voi poistaa kokonaan OSM:stä, heti kun on korvaava aineistoa laittaa tilalle. Mielellään ei niin, että otetaan pois ja sitten odotellaan skriptiä/MML:n lisenssiä/aikaa/tms. muutama vuosi…

Ei kirpaise missään. Ei näillä kilometreillä. Mua kirpaisee se metsäraja Suomen OSM:ssä :frowning:

P

Näinköhän? Voisit olla ihan tyytyväinen, jos kartan taustavärinä olisi vihreä. Kokeile laittaa landuse=forest Suomen rajarelaatiolle :wink: - Don’t import for rendering.

Suomi ON pääsääntöisesti metsää ja jos Suomen alue kartoitetaan tarkasti, niin vihreäksihän Suomi OSM kartalla muuttuu.
Vihreä väri on luullakseni perua UK:sta tai jostain sieltä suunnasta, missä metsät ovat harvinaisuuksia ja niille harvoille jäljellä oleville metsille on ANNETTU JOPA NIMET!

Suomalaisessa tiekartassa metsä on vaaleaa, ei ehkä ihan valkoista, mutta vaaleaa kuitenkin. Katsokaapa vaikkapa gt-karttaa (esimerkkejä löytyy googlen images -haulla).

Siitä syystä olisikin hyvä, jos perustaisimme oman sivuston OSM:lle ja tuottaisiin karttatiilet suomalaiseen makuun sopivana.

Ja, kyllä, ne metsät kartoitetaan vielä, kunhan ehditään. Viimeistään NLS-importissa.

a) M5132L kartalla ei näy Pilkonlahdentie,… siis pikkuiteiden nimet ei siirry tietokantaan,… puuttuuko noi kokonaan
maastotietokannasta ?

b) WINTER_ROAD päätyi isona tienä vedenpäälle mapnikissä, yritin muutta osm.xml väriä siniseksi mutta se ei ilmeisesti ole WINTER_ROAD tagillä.

c) Nomatim ei muuten suostu lukemaan kuin yhden *.osm:än mikä oli yllätys. Jotta haun saa toimimaan pitäisi
postgsql kanta tuoda ulos osmsis tai ogr2ogr ja rakentaa uudestaan osm:äksi jonka vie nominatimille, keksiikö
kukaan helpompaa tapaa ??

d) OSM ja MTK-,py scriptin tagit eivät ole yhteensopivia, tuottavat eri tasoisia tägejä samoille teille,… eli scripti translaatio file
tekee tiet isommiksi ?

e) osm2prsql alkaa valittamaan useamman importin jälkeen päälekkäisyyksistä, epävarma on uudet tietotypit siirtynyt