Gebruiker mag niet worden verplicht om Accept-Crs te definieren

[melsk-r]

Originally created by KayodeBakker (https://github.com/VNG-Realisatie/BAG-Gemeentelijke-wensen-tav-BAG-Bevragingen/issues/343):

Het is mij opgevallen dat beide de BRK als BAG API de Accept-Crs header implementeren, maar dat alleen de BAG API deze verplicht. Dit is om meerdere redenen onbegrijpelijk aangezien het niet alleen een probleem van afnemers/gebruikers etc. wordt gemaakt, maar een default zou een kleine moeite zijn geweest. Daarnaast wordt er gebruikt gemaakt van het Linked Data concept. Hierin kan niet worden verwacht dat elke URL die wordt aangeboden in een response vervolgens met de hand een header moet krijgen. Het is juist de bedoeling dat een gebruiker op de URL kan klikken en zo de volgende bevraging kan doen, wat nu dus niet het geval is.

Nu is het zeer goed mogelijk dat de reden hiervoor te maken heeft met de API-strategie van het DSO waar WGS84 wordt gedicteerd als default, maar zelfs dan moet die default daadwerkelijk worden ingesteld en niet verplicht worden gemaakt. Op die manier kan een afnemer de bevraging doen zonder een header mee te geven en dus zoals Linked Data hoort te werken en de response terugkrijgen met WGS84 als crs. Mocht de data niet beschikbaar zijn dan is er geen andere keus dan een default in te stellen die wel bruikbaar is zoals RD_NEW.

Zoals het er nu voor staat worden alle problemen op de afnemer afgeschoven en dat is niet hoe een nette API in elkaar zou steken. Graag hoor ik hier antwoord op voor waarom het nu werkt zoals het werkt en waarom deze problemen nu op de afnemers worden afgeschoven.

[melsk-r]

This comment originally might have been created by someone else.

@MelvLee op dit issue is nog geen antwoord gegeven. Kan jij hierop reageren? of vind je dat we dit in het project moeten bespreken?

[melsk-r]

This comment originally might have been created by someone else.

Volgens mij is voor zowel de BAG als BRK de Accept-Crs header niet verplicht. Ik heb voor de zekerheid de openapi.yaml hierop gecontroleerd. Ook in Haal-Centraal-Common is gedefinieerd dat de Accept-Crs header niet verplicht is

[melsk-r]

This comment originally might have been created by someone else.

@MelvLee de specificatie dwingt dit niet af, maar de implementatie vanuit het Kadaster wel voor de BAG. Bij de BRK is dit inderdaad niet het geval.

[melsk-r]

This comment originally might have been created by someone else.

Maar dan is het een bug of een fout in de specificatie, want implementatie en specificatie komen niet overeen.

Wij (HC team) hebben deze header optioneel gemaakt omdat BRK op dit moment geen geo info volgens WGS84 formaat kan retourneren.

[melsk-r]

This comment originally might have been created by someone else.

@MelvLee Ik dacht dat de specificatie leidend is en niet de implementatie? Als in de specificatie staat dat iets optioneel is dan moet de implementatie dat ook ondersteuning. Anders heb je niks aan een standaard. @fsamwel Wat denk jij?

[melsk-r]

This comment originally might have been created by someone else.

@MelvLee Ik dacht dat de specificatie leidend is en niet de implementatie? Als in de specificatie staat dat iets optioneel is dan moet de implementatie dat ook ondersteuning. Anders heb je niks aan een standaard.

Mee eens dat specs leidend moeten zijn, maar soms worden specs aangepast door restricties in het achterliggende systeem. Maar dit staat naar mijn mening los van een standaard. Volgens mij is dit een bug, omdat ik mij niet kan herinneren dat wij dit hebben veranderd.

[melsk-r]

This comment originally might have been created by someone else.

Hier is uitgebreid over gediscussieerd destijds. Als ik het me goed herinner ging het erom dat de NL API strategie voorschrijft (in de versie die toen actueel was) dat ETRS89 default is. Maar het Kadaster ondersteunt ETRS89 nog niet. Op dit moment wordt alleen epsg:28992 ondersteund. Door nu het sturen van de Crs te verplichten kan op een later moment ondersteuning van ETRS89 worden toegevoegd en kan ETRS89 ook als default worden gehanteerd, zonder dat dit een breaking change veroorzaakt.

Content-Crs kan in de specificaties niet verplicht zijn, want is alleen verplicht wanneer in het request ook geometrie is gestuurd. Dus als je een pand zoekt op locatie (een geometrisch punt), dan is content-Crs verplicht, als je een pand zoekt op adresseerbaarObjectIdentificatie is content-Crs niet verplicht (er wordt immers geen geometrie gestuurd).

N.B. Het lijkt erop dat deze regel in de NL API strategie (extensie) sindsdien is gewijzigd. Bovendien is deze nog in ontwikkeling, zo blijkt uit de waarschuwing die erbij is gezet: "This extension is in development and may be modified at any time." De tekst nu is als volgt:

17.24 API-39: Use ETRS89 as the preferred coordinate reference system (CRS) General usage of the European ETRS89 coordinate reference system (CRS) is preferable, but is not necessarily the default CRS. Hence, the CRS has to be explicitly included in each request.

[melsk-r]

This comment originally might have been created by someone else.

@fsamwel Toch specificeren ze bij de 11.3 kop dat het beter is om beide te ondersteunen zoals hier te lezen.

The API strategy caters for this supporting not only ETRS89 and RD/Amersfoort, but also WGS84 and Web Mercator (EPSG:3857).

Ook staat dit onder het kopje:

The guiding priciples for CRS support:

• Source systems record coordinates as they enter the system (legal context);
• Coordinate reference systems API strategy: request/response in RD; ETRS89; WGS84; Web Mercator;
• Consider no-regret: record both in ETRS89 and RD/Amersfoort instead of on-the-fly transformation;
• Use RDNAPTRANS™ 2018 to transform RD/Amersfoort to ETRS89 (correction grid);
• Presentation depending on context (e.g. user requirements);
• Exchange format (notation) ETRS89 and WGS84 X Y in decimal degrees: DD.ddddddddd (for example: 5.962376256, 52.255023450)
• Exchange format (notation) RD and Web Mercator X Y in meters: 195427.5200 311611.8400

Daar is wel logisch om bij te stellen dat met meerdere CRS'n om te ondersteunen dat een gebruiker idd wel duidelijk moet maken vanaf het begin wat de verwachting is. Er moet daarentegen een keuze worden gemaakt over welk default het meest logisch is voor de gebruikers van de API en tevens moeten alle Haal Centraal API's deze regels dan ook blijven hanteren aangezien de BRK niet "Accept-Crs" verplicht en simpelweg RD_NEW als default hanteert.

[melsk-r]

This comment originally might have been created by someone else.

@KayodeBakker er is hier dus een verschil tussen wat we graag willen (meerdere Crs-en ondersteunen) en wat op redelijke termijn te realiseren is

[melsk-r]

This comment originally might have been created by someone else.

@strijm Deze staat ook open sinds november. Heb jij enig indicatie wanneer hier naar wordt gekeken of op z'n minst op gereageerd?

[melsk-r]

This comment originally might have been created by someone else.

1. is ondersteunen van meerdere Crs-en is wenselijk? @CathyDingemanse is die behoefte er ook echt bij gebruikers en staat dat op de wensenlijst om binnen afzienbare tijd te realiseren? @KayodeBakker zou het voor jou de implementatie makkelijker hebben gemaakt als de API default ETRS89 zou leveren? (ik vermoed dat dit alleen echt voordeel heeft als alle API's die je nodig hebt ETRS89 leveren, dus ook BRK)

2. als het nog lang duurt tot ETRS89 wordt geleverd door de API is het beter om epsg:28992 tot default te bestempelen en gebruikers niet te belasten met de verplichting om Crs te sturen terwijl er op dat punt niks te kiezen valt

3. als we op korte termijn wel de andere Crs-en kunnen leveren, ten minste ETRS89, dan lost dit probleem zich direct op, want kunnen we ETRS89 tot default maken.

4. de "eis" dat ETRS89 default is, is geen verplichte design rule, maar een principe in een extensie. We hebben alle vrijheid hiervan af te wijken (mocht dat nodig zijn omdat het nog lang gaat duren voor ETRS89 geleverd kan worden).

5. het kunnen aanbieden van de 4 Crs-vormen beschreven in de extensie en expliciet zijn over welke Crs je levert is m.i. belangrijker dan welke Crs default is.

6. WMS en WFS services bieden wel al alle Crs vormen, en er is al een transformatie beschikbaar in RDNAPTRANS™2018, dus ik vind het lastig te begrijpen dat de BRK en BAG API's dit niet ook op korte termijn zouden kunnen leveren

[melsk-r]

This comment originally might have been created by someone else.

Mijn vermoeden is dat onze grootste voorkeur zal zijn epsg:28992, maar dat hoort niet de richting te dicteren natuurlijk.

[melsk-r]

This comment originally might have been created by someone else.

@JohanBoer zou jij jouw documentatie van onze voorkeursoplossing oplossing zoals we die hebben besproken hier willen delen? Thnx!

[melsk-r]

This comment originally might have been created by someone else.

Is verwoord bij https://github.com/VNG-Realisatie/Haal-Centraal-BAG-bevragen/issues/371#issuecomment-815804160

[melsk-r]

This comment originally might have been created by someone else.

opgelost