JOSMissa vakiona olevaan Turun WMS-palveluun on ilmestynyt hiljattain vuoden 2021 ilmakuva. Se kuitenkin näyttää tuolta, kun zoomaa tasoa 17 lähemmäksi. 
Onko vika siis palveluntarjoajan vai JOSMin päässä? Pystyisikö ongelman korjaamaan tason asetuksista JOSMissa, vai pitäisikö Turun kaupungin asiasta vastaavalle valittaa tästä? Lisäksi olisi hyvä saada taso JOSMiin ja iD:hen vakiona listalle. ID kun ei tue WMS endpointteja missään muodossa, eikä itse lisättyjä WMS-tasoja.
Nyt täytyy sanoa, että edes ammatikseni noita käsitelleenä en osaa sanoa mikä on vialla. Valita Turkuun joka valittaa sitten palveluntarjoajalleen. Jos katsoo netissä samaa Turun ilmakuvaa moista ei näy, joten paras arvaus on, että rajapinnasta tulevassa aineistossa on tiilitys sekaisin. Tai sitten JOSM:n taustalla oleva karttamoottori on jotenkin sakannut rajapinnan lukemisessa.
Onko tuo toistunut useammalla koneella ja selaimen välimuistin tms. tyhjennyksen jälkeenkin?
Datavialta tuo ei näytä, eli tuskinpa tuollainen olisi ilmakuvaajan käsien läpi mennyt, eli kyllä tässä on ilmakuvan jakelutien sakkauksesta kyse. Joko Turun rajapinnassa tai sitten rajapintaa lukevassa päässä.
Toistuukohan sama ongelma muilla WMS:ää käyttävillä ohjelmilla? (GIS-softat yms.) Olen kokeillut kahdella eri koneella JOSMissa, ja molemmissa täysin sama ongelma. Espoon vuoden 2019 WMS-tasossa on samantapainen ongelma, mutta vain yhdellä zoomaustasolla, muttei suurimmalla.
Ainakaan nopealla katsomisella QGISissä ei ongelmaa ole - tai ainakaan en tuota paikka löytänyt. Mikä kohta se Turussa on, kun en tunne kaupunkia niin paljoa, että katosta tunnistaisin kadunnimen?
Kuvankaappaus on otettu kauppatorin eteläkulmasta, mutta tuo ongelma näyttää koskevan koko ilmakuvaa.
Millään mittakaavalla en saa samasta aineistosta aikaiseksi moista näkymää QGISissä Turun kauppatorilta, joten täytyy olla JOSM ongelma. Testailen vielä jossain välissä omalla JOSMilla
Turun Ilmakuva 2021 QGISissä Turun WMS palvelusta ja todennäköisesti samasta paikasta, eli rakenteilla olevasta Kauppatorista
1 Like
Avasin tason nyt myös Vespuccilla ja näytti samalta, kuin JOSMissa. Mutta eikö tuo QGISillä otettu kuvankaappaus näytä litistetyltä?
Projektiokysymys, eli olin avannut QGISin googlen 4036 projektioon ja sama näkymä kotimaisessa 3067 projektiossa näyttää siltä miltä pitääkin. 2021 Turun ilmakuva näyttää QGISssä ihan siltä miltä pitääkin ilman ongelmia, eli kyllä se ongelma nyt sinne käyttämiisi softiin paikantuu. Tai saattaapa siinä olla Trimblen palvelullakin jota Turku käyttää osansa, eli onko tuo nyt ihan takuulla ihan standardia WMS karttaa?
Koetin avata sen JOSMissakin, mutta en osannut. Tai siis osasin, mutta en osannut tuota nimenomaan 2021 kuvaa - se Turun Ortokuvaksi nimetty JOSM taso aukeaa kyllä nätisti, mutta taitaa olla eri vuodelta, kun tori näyttää torilta eikä työmaalta. Eli en osannut QGISistä kaivaa suoraa URLia tuolle 2021 tasolle, jotta olisin sen JOSMiin osannut ladata. Onko sinulle sellainen?
Arvelinkin, että oli tuohon liittyvä, piti vain varmistaa 
Turun WMS endpoint on siis kokonaisuudessaan JOSMissa vakiona (kunhan on Turusta/lähiseudulta ladattuna OSMista), englanninkielisessä täällä: imagery-valikko → Map → Turku map service → Turun ilmakuva 2021
Olet oikeassa noin katsottuna 2021 on JOSMissa ihan sekaisin, mutta sama taso QGISssä ei ole.
Tuossa on siis selvä JOSM bugi, joka pitäisi raportoida sen järjestelmissä. Bugi on se, että JOSM menee sekaisin tuon yhden WMS tason kanssa, kun muissa ohjelmissa (QGIS testattu) kyseinen taso ei välttämätä mene sekaisin. Näyttää vähän joltain tiilitys tms. ongelmalta, eli tiilet jotenkin aineistossa sekaisin. Liittyy varmasti kyseiseen aineistoon ja palveluun ja sen yhteensopivuuteen JOSMin kanssa.
Minusta seuraavat askeleet ovat
-
Joku jolla on pääsy muihinkin softiin kuin tässä testatut, kokeilee Turun 2021 ilmakuvaa kaupungin WMS rajapinnasta Turun torin hujakoilta. ESRI käyttäjät voisivat vaikka kokeilla.
-
em. testin perusteella sitten joko
a) Joku osaaja keskustelee Turun kaupungin karttapalveluista vastaavan tahon kassa
b) Raportoi ongelman JOSM bugijärjestelmään
Minä en kumpaakaan osaa, kun WMSää osaan vain käyttää - en lukea rajapinnan vastauksia ja JOSM bugijärjestelmään en takuulla osaa tarpeeksi seikkaperäistä selvitystä kirjoittaa.
Alkuunsa hyvää päivää foorumille. Pitkään tullut OSM:ää kartoitettua, mutta keskusteluihin löytyi tie vasta nyt.
Mielenkiintoinen probleema kyllä. Eilen tätä tutkailin ja tänään aamulla, kun aloin ottamaan screenshotteja liitteeksi, niin sehän olikin sitten ko. WMS-palvelin juntturassa. Toivottavasti ei meikäläinen rikkonut testailulla. Noh, eiköhän se sieltä palaudu.
Jos jaarittelut ei kiinnosta ja haluaa vain kartoittaa Turkua JOSM:lla, niin tilapäisenä ratkaisuna voi kokeilla muuttaa JOSM:n asetuksia seuraavasti:
Asetukset → Imagery → Asetukset → Kuvapalojen koko → 640
Jaaritteluihin:
Kuten tikola testailikin, niin projektio-ongelmasta on pohjimmiltaan kyse ja nimenomaan palvelimen päässä. Seuraavilla parametreillä tämän saanee toistettua kaikilla alustoilla (ei pelkästään JOSM:ssa, myös QGISssa):
* projektio != EPSG:4326. Ainakin 3857 ja 3067 aiheuttavat ongelmia, varmaan monet muutkin.
* kuvatiilen koko <= 512px*512px
* mittakaava <= 1:1000
Jos haluaa virheen esille QGISssa, niin pitää muuttaa nimenomaan WMS-tason projektiota. QGISssahan saa noita projektioita määritettyä vähän joka vaiheeseen (projektille, tasolle, näytölle jne.), mutta ne eivät vaikuta siihen, millaista kuvaa palvelimelta ladataan. WMS-tason asetukset löytyy esim tästä ikkunasta:
Tiilen kooksi laitoin yllä saman, mitä JOSM:ssä oletuksena käytetään, 512x512. Isommilla ei näytä esiintyvän ongelmia.
Sivuhuomiona: jos QGIS:ssa tiilen kokoa ei erikseen määritä, niin kuvat latautuvat sen kokoisissa paloissa, mitä ruudulle tarvitaan. Yleensä palat on silloin suurempia kuin 512x512, jolloin tosiaan ei näy ongelmia.
Eli vaikka vänkyröinnit tuleekin eteen käytännössä vain näissä rajoittuneemmissa softissa kuten JOSM ja Vespucci, niin en silti lähtisi heitä asialla vaivaamaan.
Kyllä ongelma on 100% WMS-rajapinnan suunnalla, jos tuetuilla parametreillä tulee takaisin vääristyneitä kuvapaloja.
Demonstraationa vielä ilmakuva EPSG:3857:lla haettuna QGIS:ssä. Mittakaava 1:1000.
EPSG:3067:lla
Tämä turhanpäiväinen arvailu menee jo palvelimen puolelle, mutta noita ongelman reunaehtoja, kun ynnäilee, niin voisikohan taustalta löytyä jotain tämmöistä:
pienellä tiilenkoolla ja “lähellä maanpintaa” tarvitaan aika liuta merkitseviä desimaaleja koordinaattiin, jotta kuvat pysyvät jiirissä. Jäisikö projektimuunnoksessa, jossain kohtaa desimaaleja puuttumaan? Vai tulisiko siinä jotain pyöristysvirheitä?
Tiedä häntä, viittaisi kumminkin tähän MapServerin bugiin: https://github.com/MapServer/MapServer/issues/5958
Laitan paikkatieto@turku.fi:hin linkin tähän keskusteluun. Jospa asia sieltä löytäisi eteenpäin oikealle taholle ja Larmax saa sitten aikanaan Trimbleltä suklaalevyn kiitoksena hyvästä huomiosta.
No nyt oli seikkaperäinen selvitys. Itse sanoisin kartta-alan ihmisenä että seuraavat faktat pätevät:
-
WMS kykenee tarjoamaan vain jotain projektioita - ei maailman kaikkia ja jos sieltä pyydetään jotain erikoisempaa kaikenlaista voi tapahtua. Tässä tapauksessa ei kyllä mitään ihmekonversioita pyydetty vaan aika standardikamaa, joten eiköhän pyyntö ollut palvelimen tarjoamien tietojen raameissa. Eli pyyntö oli todennäköisesti kunnossa.
-
Sellaista tarkkuutta ja vaativuutta tässä projektiomuunnoksessa ei ole, että desimaalit selittäisivät asian - ainakaan paikkatiedon osalta. Muunnoksen haksahduksen se voisi selittää. Tälle tasolle parinkymmenen sentin sijaintitarkkuus riittää ihan hyvin ja jotta muunnos itsessään aiheuttaisi sellaisen siirtymän puhutaan aika ääritapauksesta. Vähänkin kun ollaan kaistojen keskellä muunnoksen vaikutus sijaintiin on mitätön, mutta jos yritetään samoilla parametreillä muuntaa Eckerössä tai Joensuun Hattuvaarassa niin varmaan kymmeniä senttejä se heittäisi. Tässä tapauksessahan tiilien järjestys menee ihan sekaisin, eli mikään metrin muunnosvirhe ei ole kyseessä vaan muunlainen sekoaminen. Tällaisessa visuaalisessa kartoituksessa projektion muunnosvirhe ei aiheuta ongelmaa vaan ongelma tulee vasta erilaisten kiintopisteiden siirrossa, jossa yksittäiset sentit alkavat olla liikaa epätarkkuutta.
Kaikki minustakin viittaa siihen, että Trimblen palvelin nyt jotenkin sekoaa noiden tiilien kanssa ja siellä voi hyvinkin olla Mapserver taustalla ja sitäkautta sen bugeilla voi olla vaikutusta.
Turun kaupungin paikkatietoporukka ja Trimblen tuki - niistä kahdesta tähän ratkaisu varmaankin löytyy. Tuo äskeinen on aika vakuuttava tarina heille esitettäväksi, jos kerran tuon pystyy toistamaan millä koneella hyvänsä.
Kiitos tästä, näyttää toimivan kuten pitäisikin tuolla asetuksella. Ja hyvä että laitoit sähköpostia asiasta, toivottavasti ongelma korjataan…
Ilmakuva näyttää nyt toimivan oikein 512 resoluutiollakin, joten ongelma taitaa olla ratkaistu. Mitenköhän voisi ehdottaa ilmakuvaa editoreihin, kun kerran Turun kartta-aineistoille on annettu lupa OSMin muokkaukseen?
Ensimmäinen vaihe on aina kysyä lupaa ilmakuvan toimittajalta, jos sellaista ei vielä ole. Sitten kun sellainen on saatu niin sen jälkeen tuonne editor-layer-index-githubiin issue pystyyn tai miksei vaikka pull request jos taidot siihen riittää. Siitä tulikin mieleeni että pitäisi pyytä HSY:ltä vuoden 2021 pk-seudun kuvien käyttölupa. Periaatepäätös on asiasta HSY:n ja kuvaukseen osallistuneiden tahojen suunnalla jo tehty, joten asia olisi oikeastaan enää kysymistä ja sen dokumentointia vaille valmis.
Aiemmat keskustelut pk-seudun ortokuvista löytyvät täältä. Aiemmilla kerroilla on hieman harjoiteltu sitä miten homma toimii ja mitä lupia oikein tarvitaan ja keneltä. 
Turunkin kohdalta löytyi tällainen issue valmiina. Sinne vaan ortoilmakuva muiden jatkoksi?
Nyt kun tutkin asiaa tarkemmin nin onhan Turulla jo ilmakuvat listoilla mukana … https://osmlab.github.io/editor-layer-index/
Vuoden 2018 Turun (seudun) ilmakuva ja true orto samalta vuodelta ovat kyllä, mutta vuoden 2021 ilmakuva pitää itse valita WMS-rajapinnasta, joka ei iD:llä ole edes mahdollista.
E: Varmaankin siis tuonne githubiin pitäisi ehdottaa sen lisäämistä.