gemma-zaken
gemma-zaken copied to clipboard
Als consumer wil ik geogegevens in RD-formaat kunnen opvragen
...zodat ik BAG/BGT kaarten kan gebruiken en gegevens afbeelden.
Op dit moment ondersteunen de referentieimplementaties enkel WSG84, wat de internationale, onnauwkeurige standaard is (voor Nederland dan). RD is eigenlijk essentieel. Daarnaast vraagt de DSO ook om ontsluiting in een Europese standaard.
Momenteel bieden we de RD optie niet omdat deze niet geimplementeerd is in de referentie-implementatie.
Onderstaande "vink-lijst" is voor het team zelf om in te vullen en hoeft niet door de indiender te worden ingevuld.
Bepaling prioriteit door PO
- [ ] verbreding of verdieping API's
- [ ] stimuleert gebruik door gemeenten
- [ ] stimuleert gebruik door leveranciers
... eventueel nog toelichting door PO
Definition of ready
- [ ] Iedereen in het team begrijpt de user story
- [ ] de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
- [ ] Is klein genoeg (maximaal 1/5 van sprint)
- [ ] Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door PO)
- [ ] Idee hebben van hoe deze user story kan worden gedemonstreerd.
- [ ] Globale oplossingsrichting bekend
- [ ] Vastgelegd in Github en geplaatst in kolom ready
Definition of done
- [ ] Er is een OAS 3.0 specificatie
- [ ] Er is een referentieimplementatie
- [ ] Er zijn tests(cases) aanwezig die de wijziging aantonen en waarmee de user story getest kan worden.
- [ ] De technische specificatie (standaard.md) is gepubliceerd leesbaar
- [ ] Gebruikte gegevensmodel is na iedere sprint bijgewerkt.
Acceptatiecriteria
- [ ] De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
- [ ] Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.
Taken
- [ ] Implementeren in referentie-implementatie [verantwoordelijke]
- [ ] Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
- [ ] Genereren/opstellen van OAS 3.0 [verantwoordelijke]
- [ ] Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]
- [ ] Documentatie bijwerken
- [ ] Gegevensmodel bijwerken
/cc @EduardWitteveen
Van Andy Verberne:
In het triggerbericht (DSO verzoeken) staat de locatie van de zaak. Nu wordt alleen het referentiestelsel "EPSG:4326 (WSG84)" ondersteund omdat dit het enige stelsel is wat wordt ondersteund in ZGW API. In het triggerbericht ontvangen van DSO zit echter ETRS89.
Quick info over verschillende stelsels: https://io.osgeo.nl/sitecontent/events/RDMiniSeminar2016/LennardHuisman.pdf
Besluit om drie projecties te ondersteunen: WSG84, RD en ETRS89. Consumers moeten in elk projectie kunnen aanbieden en opvragen.
Nog niet ready: kun je opvragen in een nauwkeuriger formaat dan oorspronkelijk is opgeslagen?
Nog niet ready: kun je opvragen in een nauwkeuriger formaat dan oorspronkelijk is opgeslagen?
Begrijp ik hieruit dat bij opslag niet de originele waarde wordt opgeslagen met de project, maar al reeds een transformatie wordt gedaan?
Voor de duidelijkheid, als ik een RD-polygoon aanlever, krijg ik deze dan op dezelfde manier terug? (significatie van de coordinaten en volgorde van de coordinaten)
Omdat dit over het gedrag en referentie implementatie gaat graag hier een uitspraak over. Met de BAG/BGT gaf dit nog wel eens wat uitdagingen in het verleden.
Nog niet ready: kun je opvragen in een nauwkeuriger formaat dan oorspronkelijk is opgeslagen?
Rijksdriehoek wordt uitgedrukt in proj4 als een transformatie. Die is enkel nauwkeurig binnen Nederland. (zie ook https://www.spatialreference.org/ref/epsg/amersfoort-rd-new/)
Er is dus niet per se een "nauwkeuriger" formaat. Mijn begrip nu is dat transformeren van het ene CRS naar het andere CRS geen verlies van nauwkeurigheid heeft zolang je maar binnen de bounds blijft.
Voor de duidelijkheid, als ik een RD-polygoon aanlever, krijg ik deze dan op dezelfde manier terug?
Als je opvoert met CRS RD en opvraagt met CRS RD, dan verwacht ik dat je dezelfde waarden terugkrijgt.
Uit de Omgevingswet-documentatie Standaard en informatiemodel aanvragen en meldingen (STAM en IMAM), p. 18:
Coördinaten ETRS. Dit zijn intern door de DSO-LV gebruikte coördinaten van de projectlocatie, bijvoorbeeld gebruikt door de component waarmee bepaald wordt welke regels gelden op de betreffende locatie. De DSO-LV rekent alle door de Initiatiefnemer opgeven Project Locaties, of dat nou in de vorm van een Adresaanduiding, Kadastrale Aanduiding, of Coördinaten is opgegeven, om naar deze Coördinaten ETRS.
Daarbij aansluiten en ETRS als basis/bronformaat hanteren?
Team overweegt om de drie genoemde coordinatenstelsels te ondersteunen voor opslaan en ophalen, en dan zonder conversie. Je krijgt het stelsel terug wat eerder is opgeslagen. Voordat we dit toevoegen aan de standaard moet er eerst nog een analyse worden gedaan van de voors en tegens.