wijzigen mogelijk onjuist feature voor geometrie woonplaats in onderzoek

[fsamwel]

Wanneer geometrie van een woonplaats in onderzoek staat, dan moet dit hetzelfde worden behandeld als Ligt in gerelateerde woonplaats is in onderzoek.

Dus:
Gegeven woonplaats 1234 heeft geometrie in onderzoek
En nummeraanduiding 1234200000123456 heeft als woonplaats 1234
Als ik vraag /adressen/1234200000123456
Dan bevat het antwoord

    "mogelijkOnjuist": {
        "woonplaats": true,
        "woonplaatsIdentificatie": true,
        "toelichting": [
            "Geometrie of woonplaatsgrens is mogelijk onjuist, waardoor gaten of overlappingen ontstaan in de registratie van woonplaatsen. Gevolg kan zijn dat een object in een verkeerde woonplaats, in twee woonplaatsen, of in geen enkele woonplaats ligt.",
        ]
    },

Gegeven woonplaats 1234 heeft geometrie in onderzoek
En nummeraanduiding 1234200000123456 heeft als woonplaats 1234
Als ik vraag /adressen/1234200000123456?fields=straat,huisnummer,woonplaats
Dan bevat het antwoord

    "mogelijkOnjuist": {
        "woonplaats": true,
        "toelichting": [
            "Geometrie of woonplaatsgrens is mogelijk onjuist, waardoor gaten of overlappingen ontstaan in de registratie van woonplaatsen. Gevolg kan zijn dat een object in een verkeerde woonplaats, in twee woonplaatsen, of in geen enkele woonplaats ligt.",
        ]
    },

Gegeven woonplaats 1234 heeft geometrie in onderzoek
En nummeraanduiding 1234200000123456 heeft als woonplaats 1234
Als ik vraag /adressen/1234200000123456?expand=woonplaats.documentnummer&fields=straat,huisnummer
Dan bevat het antwoord

    "mogelijkOnjuist": {
        "woonplaats": true,
        "woonplaatsIdentificatie": true,
        "toelichting": [
            "Geometrie of woonplaatsgrens is mogelijk onjuist, waardoor gaten of overlappingen ontstaan in de registratie van woonplaatsen. Gevolg kan zijn dat een object in een verkeerde woonplaats, in twee woonplaatsen, of in geen enkele woonplaats ligt.",
        ]
    },

N.B. tabel op regel 45 noemt in bepaalde gevallen (zoals adressen) 2 velden die dan mogelijkOnjuist worden. Scenario op regel 299 noemt er maar 1, namelijk de identificatie. Daar ook uitbreiden of corrigeren?
In de implementatie worden dan beide geleverd in mogelijkOnjuist, zowel woonplaats als woonplaatsIdentificatie.

[NicoleKortoomsBAG]

@fsamwel
Waarom is de mogelijk onjuist response in het 2e en 3e voorbeeld anders? In het 2e voorbeeld zou ik verwachten dat regel 49 van de featureomschrijving wordt gevolgd en dus ook woonplaatsidentificatie wordt genoemd.

Ik ben het met je eens dat het wel vreemd is dat eenzelfde attribuut in onderzoek kan staan en dat dit dan in verschillende, maar vergelijkbare, scenario's verschillend wordt weergegeven bij mogelijk onjuist.

[fsamwel]

Waarom is de mogelijk onjuist response in het 2e en 3e voorbeeld anders? In het 2e voorbeeld zou ik verwachten dat regel 49 van de featureomschrijving wordt gevolgd en dus ook woonplaatsidentificatie wordt genoemd.

voorbeeld	situatie	geleverde mogelijkOnjuist	reden
1	geen fields en geen expand	woonplaats + woonplaatsIdentificatie	woonplaats wordt getoond in geleverde velden woonplaats én woonplaatsIdentificatie
2	fields=woonplaats	woonplaats	alleen woonplaats gevraagd en geleverd, niet woonplaatsIdentificatie
3	expand=woonplaats, fields geen woonplaats	woonplaats + woonplaatsIdentificatie	velden geleverd a.g.v. expand=woonplaats

De oplossing is wat vreemd en lijkt inconsistent, omdat we in de mogelijkOnjuist geen velden hebben opgenomen die kunnen verwijzen naar de relatie in _links of de expanded relatie in _embedded. We hebben destijds gekozen voor het in plaats daarvan opnemen van de identificatie-property. Volgens scenario op regel 299 zou in voorbeeld 3 alleen woonplaatsIdentificatie moeten worden geleverd.
Ik vind het zelf wel vreemd dat als gevolg van het leveren van _embedded.woonplaats het veld mogelijkOnjuist. woonplaatsIdentificatie wordt geleverd en niet mogelijkOnjuist.woonplaats. Hier zou m.i. alleen woonplaats logischer zijn geweest. Maar dat zou een breaking change zijn. Ik stel voor om in dat geval (dus tabel op regel 299, werking bij expand) beide velden op te nemen.

@NicoleKortoomsBAG @CathyDingemanse @JohanBoer @MelvLee wat vinden jullie hiervan?

[NicoleKortoomsBAG]

@fsamwel
Ik zou bij eenzelfde trigger, een in onderzoek bij een bepaald attribuut van een BAG object, van de trigger laten afhangen welke mogelijk onjuist informatie er wordt getoond.
Met de toepassing van fields filter je de attributen en daarmee de mogelijk onjuist informatie die wordt gegeven. (welke, conform featurebeschrijving, niet 1 op 1 met de attributen overeenkomt, maar altijd is gericht op de afnemer voldoende informatie geven en foutief gebruik te voorkomen)
Met het toepassen van expand (object of _link) kan er (na de filter) mogelijk weer mogelijk onjuist informatie 'terugkomen' (of bij het woonplaatsenpoint met expand geometrie, erbij komen).
De mogelijk onjuist informatie de 'terugkomt' zou wat mij betreft dezelfde moeten zijn als dat wordt gegeven als er geen fields was toegepast.

Op basis van de huidige basisregels op grond van het scenario op regel 49, zou dan bij de scenario's op regel 299 en 318 en het voorbeeld voor de aanvulling van woonplaatsgeometrie de mogelijk onjuist informatie zowel woonplaats als woonplaatsidentificatie moeten worden genoemd.

Dit mooier maken, lijkt mij geen breaking change waard. Omdat mogelijk onjuist in onderzoek niet precies volgt, moest er een keus worden gemaakt. Deze keus lijkt me niet fout.

[strijm]

In het kader van het maken van release 1.2, moet hetgeen hier beschreven nog verwerkt worden in de mogelijkOnjuist.feature beschrijving.