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
Paikkatietojärjestelmätoimittajan kommentti suunnitelmaan
Trimble Solutions
18. tammikuuta 2019 kello 17.14.55
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