Adresseerbaarobject/pand bbox param voldoet niet de definitie van 'OGC API Features specificatie - bbox definitie' zoals aangegeven

[melsk-r]

Originally created by KayodeBakker (lvbag/BAG-Gemeentelijke-wensen-tav-BAG-Bevragingen#544):

Beschrijf de bug
De adresseerbaarobject en pand bevragingsmogelijkheden bieden de optie aan voor bbox waar in de documentatie vervolgens staat: "Voor een definitie van bbox, zie OGC API Features specificatie - bbox definitie". Deze definitie dicteert een standaard voor bbox gebruik en geeft helder aan:

Lower left corner, WGS 84 longitude

Lower left corner, WGS 84 latitude

Upper right corner, WGS 84 longitude

Upper right corner, WGS 84 latitude

Ofwel min-x, min-y, max-x, max-y maar de API dicteert dat er min-x, max-x, min-y, max-y wordt gebruikt en daarmee niet aan de OGC standaard voldoet. Dit is apart aangezien GIS tools ook gebruik maken van de OGC standaard en ik kan me niet voorstellen dat dit een bewuste keuze was.

To Reproduce
Stappen om de bug te reproduceren

1. Ga naar https://api.bag.acceptatie.kadaster.nl/esd/huidigebevragingen/v1/adresseerbareobjecten?bbox=118314,118326,404843,404850
2. Zie error.

{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "Een of meerdere parameters zijn niet correct.",
    "status": 400,
    "detail": "Bad request.",
    "instance": "https://api.bag.acceptatie.kadaster.nl/esd/huidigebevragingen/v1/adresseerbareobjecten?bbox=118314,118326,404843,404850",
    "code": "paramsValidation",
    "invalidParams": [
        {
            "name": "bbox",
            "code": "geometryMismatch",
            "reason": "Waarde is niet conform opgegeven CRS."
        }
    ]
}

3. Ga naar https://api.bag.acceptatie.kadaster.nl/esd/huidigebevragingen/v1/adresseerbareobjecten?bbox=118314,404843,118326,404850
4. Krijg normaal resultaat.

Verwacht gedrag
De bbox param dient te worden geïmplementeerd zoals in de OGC standaard gespecificeerd staat ofwel 'min-x, min-y, max-x, max-y' zoals in de API documentatie ook geschreven staat als ondersteunde standaard.

[melsk-r]

This comment originally might have been created by someone else.

@KayodeBakker
Je schrijft: "de API dicteert dat er min-x, max-x, min-y, max-y wordt gebruikt". Ik zie dat niet in de API specificatie of feature beschrijving staan en volgens mij heb je met jouw test uitstekend aangetoond, dat de API reageert zoals beschreven in de OGC API Features en dat min-x, min-y, max-x, max-y (stap 3) wordt geaccepteerd en min-x, max-x, min-y, max-y (stap 1) niet. Of zie ik iets over het hoofd?

[melsk-r]

This comment originally might have been created by someone else.

De huidige implementatie is verkeerd (min-x, max-x, min-y, max-y) en voldoet niet aan de OGC definitie (min-x, min-y, max-x, max-y. Zie het als twee coördinaten, linksonder (min-x, min-y) en rechtsboven (max-x, max-y).

[melsk-r]

This comment originally might have been created by someone else.

Als het volgende wordt opgegeven:
bbox=118314,404843,118326,404850
dan zijn dat de waarden: min-x, min-y, max-x, max-y
oftewel de coördinaten linksonder en rechtsboven van een bbox.
De coördinaten (118314,404843) en (118326,404850) kun je opzoeken in een (RD) viewer, bv. BAG of PDOK.
Dit is stap 3 in Kayo's test. Dit is correct en conform OGC API Features.

Als het volgende wordt opgegeven:
bbox=118314,118326,404843,404850
dan zijn dat de waarden min-x, max-x, min-y, max-y
oftewel de coördinaten staan niet in de juiste volgorde voor een bbox.
De coördinaten (118314,118326) en (404843,404850) kun je niet opzoeken in een (RD) viewer, bv. BAG of PDOK omdat ze buiten het RD stelsel vallen.
Dit is stap 1 in Kayo's test. Dit is niet correct en niet conform OGC API Features.

M.i. is de werking van de API dus conform OGC API Features.

[melsk-r]

This comment originally might have been created by someone else.

Kayo heeft helaas de requests door elkaar gehaald. Jullie huidige implementatie is min-x, max-x, min-y, max-y en dat is niet correct.

[melsk-r]

This comment originally might have been created by someone else.

@KayodeBakker @Processfive ik begrijp niet zo goed hoe jullie tot de conclusie komen dat de implementatie min-x, max-x, min-y, max-y vereist.
Bijvoorbeeld ik kan /adresseerbareobjecten?bbox=135228,457502,135246,457457 vragen en dan krijg ik objecten terug.
En /adresseerbareobjecten?bbox=135228,135246,457502,457457 geeft een geometryMismatch
Dus zover ik kan zien accepteert de API juist min-x, min-y, max-x, max-y wel en geeft het een fout op min-x, max-x, min-y, max-y.