Kommentoi rajapintatoteutuksen suunnitelmaa

Hei,

Suunnitelma on ihan hyvä. Näkisin kyllä PTA-alustan kannalta järkevänä, että suunnittelette jo tässä vaiheessa tuo tiedonsiirron PTA:lle niin, että kunta voi ylipäänsä hyödyntää Laatuvahtipalvelua ihan yleisemminkin paikkatietoaineistojen tuotannossa. Että se olisi mahdollisimman automaattisesti tai vähäisellä työllä kytkettävissä kuntien ylläpitoprosesseihin. Eli prosessissa olisi selkeästi mahdollisuus, että kaikessa paikkatietoaineistotuotannossa voi käyttää PTA:n laatuvahtipalvelua, joka tuottaa paluuviestinä virheraportin. Sitten on oikeastaan helpompaa aineiston tuottajan vain päättää, että laatuvahtipalvelun jälkeen joko aineistoa korjataan paikallisesti tai sitten sitä myös siirretään osaksi PTA-alustan tarjontaa. Isossa kuvassa tavoite voisi olla, että Laatuvahti on ihan kaikilla kunnilla osa paikkatietoaineistojen tuotantoa, niin silloin saadaan verovaroille huomattavaa vastinetta.

Luonteeltani olen kyllä täysautomatiikan kannalla. Täysautomatiikka hajotti kyllä jo levysoittimen levytkin. Puoliautomatiikalla olisi jotain töitäkin. Tietenkin kuten linja-autojenkin paikannuksessa romun tekeminenkin teettää töitä.

Yleiskommentti: Kaiken kaikkiaan tarjottu dokumentointi on hyvin niukka ja selitykset vähäisiä. Käytettävä tekniikka sinänsä on ok, siinä ei ole mitään uutta ja ihmeellistä.

-Laaduvahdin irrottaminen postaamisesta kantaan on hyvä. Se jää epäselväksi, pystyykö osajoukon (virheettömät) postaamaan kantaan vai onnistuuko massan postaaminen vasta siinä vaiheessa kun kaikki ovat laatuvahdin mukaan virheettömiä.
-"Kuntajärjestelmien integrointi OpenAPI 3.0 mukaisesti kuvatulla REST/JSON API -ratkaisulla" dokumentti: Sivun 2 kuva täysin absurdi ja selitykset liian vähäisiä. Miten prosessi oikeasti menee kuntapäästä, oli tarjolla sitten GML/wfs tai JSON/rest. Kokonaisprosessin hahmottaminen ei onnistu. Missä kohtaa kuvassa on suoraan KMTK editointi kunnassa ja missä kohtaan kuntajärjestelmästä exportataan tietoa KMTK:n?
- Kohteiden identifiointi: miten päivitys (item updated) hoidetaan kannassa? Oletus on että pysyvän ID:n avulla (?)
- Miten pysyvä id hanskataan: Miten se saadaan palautettua takaisin editoivaan kuntajärjestelmään? Paluusanoma puuttuu kuvista. Vai jääkö tämä projektin ulkopuolelle... Ilman tätä ei kuitenkaan kohteiden identifiointi onnistu.

Toiveena on, että kunnan suoritukseksi riittää pitää sovittavan mukainen mahdollisimman standardi rajapinta auki. Ei ylimääräistä työtä. Kunnan rajapinnan tieto voisi välittyä Kuntatietopalvelun kautta KMTK:lle, jolloin KTP voisi osaltaan hoitaa teknistä sovittamista. Itse tietoketju kunnasta MML:n järjestelmiin on epäselvästi kuvattu ja ei oikein ymmärretty niistä kuvista, kuinka se toimii kunnan suunnasta. Tätä pitäisi KMTK:ssa terävöittää. Kunnilla on olemassa olevia totetutuksia rajapinnoista. Uudet toteutukset, vaikka olisivat mahdollisia, maksavat. Olisi syytä pitää palaveri edustavan kuntajoukon teknisten asiantuntijoiden ja PTA:n toteuttajien kesken.
Paluusanoman tarve? Pysyvän id:n kulku?

Koska pienemmillä kunnilla on vähän niukasti osaamista paikkatietojen suhteen, niin olisi erinomaista jos kuntien paikkatietojärjestelmien toimittajat saataisiin aktivoitua ja sitä kautta apua järjestelmätoimittajien puolelta niin, että kunnissa osattaisiin tehdä oikeita asioita aineistojen laadunparantamiseksi. Tarvitaan myös selväkielisiä ohjeita KMTK:n aloittamiseen aivan nollatilanteesta askel kerrallaan. Rest-rajapinta on välittämätön jatkoa ajatellen, jotta tiedot kulkevat eri järjestelmien välillä.

Tervehdys,
Perehdyimme dokumentaatioon ja ajattelimme kommentoida muutamaa asiaa siinä.
Rajapintakuvaus (yaml) tiedosto vastasi hyvin kattavasti pääosaan kysymyksistämme ja voi vastata vielä alla oleviin kommentteihinkin.

1. Pohdimme miten kohteen päivitys pitäisi suorittaa dokumentoiduilla metodeilla.
Pitääkö toimittaa aina koko rakennus, kun esim. yksittäinen ominaisuustieto muuttuu rakennuksessa vai voiko toimittaa tuon yhden ominaisuustiedon tunnisteella varustettuna.
Pitääkö rajapinnan käyttäjän tietää onko kyseessä kohteen päivitys vai uuden kohteen lisäys. Eli hoitaako taustalla oleva palvelu kohteen tunnistuksen ja jaon uusi/päivitys vai ei.
Jos vastaava kohde on tullut jotain muuta kautta KMTK hon, niin voi olla vaikea tietää että kyseessä olisikin päivitys kun kunnan järjestelmässä ei ko. sijainnissa ole kohdetta. Tulee ehkä vastaan pikemminkin muissa kohteissa kuin rakennuksissa.

2. Kommentoinnin ohjeistuksessa puhutaan GeoJSON muodosta, mutta ilmeisimmin tarkoituksella rajapinta ei kuitenkaan noudata GeoJSON standardia eikä siten ole ko. muotoa.
Esim. kmtk_building_openapi_example.json tiedostossa
"type": "Building", ei ole GeoJSON mukainen.
"type"t ovat kiinnitettyjä vakioarvoja GeoJSON määrittelyissä eikä niitä saa laajentaa.
Tämä mm. hankaloittaa yleisten GeoJSON lukijoiden käyttöä, jos tavoitellaan GeoJSON muotoa, mutta ei noudateta määrittelyä.

3. kmtk_building_openapi_example.json esimerkkitiedosto
Hieman ihmettelemme miksi esitystavassa on dynaamisesti muuttuva objektin identiteetti ("building-id-1") eikä
objektin nimettynä ominaisuutena. Rajapintakuvauksessa on kyllä mainittu rakenne, mutta miksi tähän on päädytty?
-miksi features ei ole taulukko kohteita vaan yksittäinen objekti
"features": {
"building-id-1": {
"type": "Building",
"buildingParts": [
"part-id-1"
],

4. Laatuvahdin ohjaamismahdollisuudesta rajapinnan kautta emme täysin saaneet käsitystä.
Pystyykö kutsussa ohjaamaan Laatuvahdin tekemään pelkästään aineiston tarkastustuksen eikä ollenkaan tallennusta tietokantaan? Kaaviokuvasta tällainen löytyy, mutta löytyykö rajapintakuvauksesta?

5. Pohdimme miksi "delete" komentoon ei käytetä http verbin mukaista DELETE metodia