Goedemorgen!
Ik download dagelijks de deltas van de BRK Percelen via de API
Nu zie ik dat bijvoorbeeld bij de delta met ID d668fb23-25af-4d0e-a860-99891a0d0f5b van 21-11-2022 overlappende percelen aanwezig zijn die beiden geen eindgeldigheid hebben. Daarmee zouden ze volgens mij gewoon geldig moeten zijn? Een specifiek voorbeeld is lokaalid 21610417870000 icm 21610342570000. Beide percelen zijn vastgesteld, hebben geen eindgeldigheid en hebben statushistorie Geldig. Zover ik weet is er geen andere eigenschap waar ik op zou moeten filteren om de actuele percelen op te halen? Op het screenshot hieronder is te zien dat er twee percelen over elkaar heen liggen op de plek waar het vlak iets donkerblauwer is. Iemand enig idee wat hier fout gaat?
Hallo Terralytics,
Ik heb even specifiek naar deze complexe situatie gekeken en ik zie dat perceel 21610342570000 in deze delta meerdere mutaties ondergaat. Waarbij er ook een mutatie is voordat de eindgeldigheid gezet wordt. Voor een initiële stand werkt het filteren op eindgeldigheid, maar in de delta’s moeten de mutaties achterelkaar doorgevoerd worden en geeft de laatste mutatie de actuele situatie weer.
Dag John, bedankt voor je check en snelle antwoord! Nog wel een vraag: hoe herken ik in dit geval welke mutaties bij elkaar horen? Het lokaalid is immers niet hetzelfde voor de twee objecten. Dus ik kan dan volgens mij ook niet bepalen wat de laatste mutatie is. Of kan ik daar een ander attribuut voor gebruiken?
Ik doe het zo:
Ik stuur request:
{
“deltaId”:“d668fb23-25af-4d0e-a860-99891a0d0f5b”,
“format”: “gml”,
“featuretypes”: [
“perceel”
],
“geofilter”: “POLYGON((101644.9613407744 468298.9016792417,102633.10680464159 468117.15624100924,102182.56134077441 467306.17443681,101305.90685591113 467278.68350907566,100957.68868574512 467695.6289729428,101644.9613407744 468298.9016792417))”
}
In de response horen alle mutaties met <t:lokaalID>21610342570000</t:lokaalID> bij elkaar, waarbij de laatst de actuele situatie weergeeft voor dit perceel.
Nu snap ik 'm! Heel erg bedankt.
Mijn oude workflow:
- alleen objecten met eindgeldigheid = null behouden
- sorteren op tijdstipregistratie
- laatste/nieuwste tijdstipregistratie behouden
→ dit resulteert er dus in dat percelen die helemaal vervallen niet goed werden verwerkt
Nieuwe workflow:
1 sorteren op tijdstipregistratie
2 laatste/nieuwste tijdstipregistratie behouden
3 filteren op eindgeldigheid = null
→ dit resulteert in een kloppende kaart waarbij vervallen percelen zijn verdwenen en alleen de laatste stand van zaken wordt verwerkt.