Directie Geo Product- en Procesbeheer Post/retouradres Postbus 9046, 7300 GH Apeldoorn Datum Behandeld door Daniël te Winkel, Peter Lentjes Contactgegevens T +31 (0)88 183 22 00 kcc@kadaster.nl 1 van 6 Bezoekadres Hofstraat 110, 7311 KZ Apeldoorn
2 van 6 1 Wat is objecthistorie In BRT: TOP10NL 1.2 wordt van ieder object historie afgeleid door middel van de attributen objectbegintijd, objecteindtijd, tijdstipregistratie en eindregistratie. Op het moment dat er een nieuw geo-object wordt gevormd, dan krijgt het een objectbegintijd. Een geo-object dat niet meer actueel is en vervangen wordt, krijgt een objecteindtijd. Het oude geo-object blijft in de database aanwezig. De tijdstipregistratie en eindregistratie zorgen ervoor dat iedere mutatie van een geo-object wordt bijgehouden. Als er bijvoorbeeld een attribuutwaarde van een geo-object verandert, dan kan er een nieuwe versie van het geo-object ontstaan. Voor het volgen van geo-objecten in de tijd heeft elk geoobject een relatie met zijn voorganger en opvolger. Een geo-object kan ontstaan uit één of meer geo-objecten en kan overgaan in één of meer geo-objecten. Het mutatieprotocol van BRT: TOP10NL bepaalt of een object verdwijnt en er een nieuw object ontstaat en wanneer een object een nieuwe versiedatum krijgt. De leveringen van BRT: TOP10NL bevatten alleen de objecten die op het levermoment actueel zijn. De oude objecten en versies van objecten, die een gevulde objecteindtijd en/of eindregistratie hebben, worden niet geleverd. Deze vervallen objecten en versies van objecten worden in het product BRT: TOP10NL Objecthistorie beschikbaar gesteld aan gebruikers van BRT: TOP10NL. Objecthistorie wordt geleverd als aanvulling op de GML bestanden en geeft de klant de mogelijkheid om de eigen TOP10NL database bij te werken en eventueel historie op te bouwen in de eigen TOP10NL database. In de XML-bestanden van objecthistorie staan alle objecten en versies van objecten die vervallen zijn sinds de vorige levering met de identificatie en de verschillende datums. Per levering wordt een XML bestand met objecthistorie geleverd, geldend voor geheel TOP10NL, voor zowel de filechunk als de geocunk dataset. In figuur 1 is een voorbeeld van objecthistorie te zien. In deze figuur zijn de gegevens van twee gebouwen te zien. Het eerste gebouw met identificatie = NL.TOP10NL.102302157 is gemuteerd en de oude versie van het gebouw heeft een eindregistratie gekregen. Dit betekent dat het gebouw een kleine mutatie ondergaan heeft, bijvoorbeeld een attribuutwijziging of een kleine geometriewijziging. Het tweede gebouw met identificatie = NL.TOP10NL.102302035 heeft een objecteindtijd gekregen, dit geo-object is dus komen te vervallen, of de geometrie is zodanig veranderd dat het als nieuw object is vastgelegd.
3 van 6 Figuur 1: Voorbeeld van objecthistorie 2 Gebruik van objecthistorie BRT: TOP10NL Objecthistorie kan in combinatie met de GML bestanden gebruikt worden om de database van de gebruiker bij te werken. Afhankelijk van het bijhouden van historie in de database van de gebruiker zijn er nu twee scenario s die achtereenvolgend beschreven worden: Scenario 1: Geen historie in de database 1. Converteer de BRT: TOP10NL Objecthistorie XML s naar een databasetabel. 2. Maak een koppeling tussen de Objecthistorie tabel en de BRT: TOP10NL tabellen via het attribuut identificatie. 3. Verwijder de vervallen objecten uit de database. Deze objecten zijn te herkennen aan de ingevulde objecteindtijd en de ingevulde eindregistratie in de BRT:TOP10NL Objecthistorie tabel. 4. Verwijder de vervallen versies van gemuteerde objecten uit de database. Deze objecten zijn te herkennen aan de ingevulde eindregistratie in combinatie met de niet ingevulde objecteindtijd in de BRT:TOP10NL Objecthistorie tabel. 5. Lees de GML-bestanden in en voeg alleen de nieuwe versies van de gemuteerde objecten en de nieuwe objecten toe aan de BRT: TOP10NL database. Deze objecten zijn in de GML-bestanden te herkennen aan een tijdstipregistratie die gelijk is aan het levertijdstip.
4 van 6 Scenario 2: Historie in de database 1. Converteer de BRT: TOP10NL Objecthistorie XML s naar een databasetabel. 2. Maak een koppeling tussen de Objecthistorie tabel en de BRT: TOP10NL tabellen via het attribuut identificatie. 3. Geef de vervallen objecten een objecteindtijd en een eindregistratie in de BRT: TOP10NL database. Deze objecten zijn te herkennen aan de ingevulde objecteindtijd en de ingevulde eindregistratie in de BRT:TOP10NL Objecthistorie tabel. 4. Geef de vervallen versies van objecten een eindregistratie in de BRT: TOP10NL database. Deze objecten zijn te herkennen aan de ingevulde eindregistratie in combinatie met de niet ingevulde objecteindtijd in de BRT:TOP10NL Objecthistorie tabel. 5. Lees de GML-bestanden in en voeg alleen de nieuwe versies van de gemuteerde objecten en de nieuwe objecten toe aan de BRT: TOP10NL database. Deze objecten zijn in de GML-bestanden te herkennen aan een tijdstipregistratie die gelijk is aan het levertijdstip. 3 Voorbeeld van objecthistorie In dit hoofdstuk wordt objecthistorie aan de hand van een voorbeeld nader toegelicht. Hierbij wordt gebruik gemaakt van onderstaande figuur waarin enkele topografische objecten op 2 verschillende levermomenten (t1 en t2) in kaart zijn gebracht. 01 04 P weg Tijdstip t1 Tijdstip t2 05 07 02 03 01 08 09 08 04 sloot 06 10 bouwland 06 bos bos P weg overig 11 03 12 10 05 13 bouwland sloot 14 Figuur 2: Voorbeeld op de tijdstippen t1 en t2. Tussen de tijdstippen t1 en t2 zijn enkele mutaties in de database aangebracht. Door toepassing van het mutatieprotocol van BRT: TOP10NL zijn de volgende objectmutaties ontstaan: Objecten 01 (parkeren), 08 (weg) en 10 (boom) zijn onveranderd. Objecten 03 (bouwland), 04 (), 05 (bos) zijn gemuteerd, hiervan is dus een nieuwe versie ontstaan. Objecten 02 (), 06 (sloot), 07 (weg) en 09 (boom) zijn vervallen. Objecten 11 (), 12 (overig), 13 (weg) en 14 (sloot) zijn nieuw.
5 van 6 Bij de eerste levering zijn alle objecten geleverd die op tijdstip t1 actueel waren. Bij de tweede levering zijn alle objecten geleverd die op tijdstip t2 actueel waren. Bij de tweede levering kan er objecthistorie aangemaakt worden, dit is in tabel 1 ingevuld. Identificatie objectbegintijd tijdstipregistratie versieeindtijd eindregistratie 02 t1 t1 t2 t2 03 t1 t1 t2 <leeg> 04 t1 t1 t2 <leeg> 05 t1 t1 t2 <leeg> 06 t1 t1 t2 t2 07 t1 t1 t2 t2 09 t1 t1 t2 t2 Tabel 1: Objecthistorie voor het voorbeeldgebied op tijdstip t2. In tabel 1 zijn alleen de gemuteerde en vervallen objecten opgenomen. Vervallen objecten hebben een ingevulde eindregistratie én een ingevulde objecteindtijd, waarvan de tijden aan elkaar gelijk zijn. Gemuteerde objecten hebben alleen een ingevulde eindregistratie, de objecteindtijd is in dit geval niet ingevuld. Identificatie Attributen ObjectBeginTijd tijdstipregistratie 01 t1 t1 03 t1 t2 04 t1 t2 05 t1 t2 08 t1 t1 10 t1 t1 11 t2 t2 12 t2 t2 13 t2 t2 14 t2 t2 Tabel 2: Inhoud GML op tijdstip t2 In tabel 2 is een uittreksel van de GML-levering op tijdstip t2 te zien, bestaande uit de Identificatie, de objectbegintijd en de tijdstipregistratie. Omdat in de GML alleen actuele objecten geleverd worden, zijn de objecteindtijd en de eindregistratie niet gevuld. De TOP10NL database van de gebruiker kan met behulp van de gegevens uit de GML en Objecthistorie bijgewerkt worden. Er zijn nu twee scenario s te beschrijven afhankelijk van het feit of de gebruiker historie in de eigen database wil bewaren of niet.
6 van 6 Scenario 1: Geen historie in de database 1. Verwijder de vervallen objecten 02, 06, 07 en 09 uit de database. 2. Verwijder de vervallen versies van objecten 03, 04 en 05 uit de database. 3. Voeg uit de GML bestanden alleen de nieuwe versies van de gemuteerde objecten en de nieuwe objecten toe aan de database. Deze objecten zijn te herkennen aan een tijdstipregistratie die gelijk is aan het levertijdstip (in dit geval t2). In dit voorbeeld gaat het om de objecten 03, 04, 05, 11, 12, 13 en 14. Scenario 2: Historie in de database 1. Geef de vervallen objecten 02, 06, 07 en 09 een objecteindtijd en een versieeindtijd in de database. De objecteindtijd en de eindregistratie komen voor in de Objecthistorie tabel. 2. Geef de vervallen versies van objecten 03, 04 en 05 een versieeindtijd in de database. De eindregistratie komt voor in de Objecthistorie tabel. 3. Voeg uit de GML bestanden alleen de nieuwe versies van de gemuteerde objecten en de nieuwe objecten toe aan de database. Deze objecten zijn te herkennen aan een tijdstipregistratie die gelijk is aan het levertijdstip (in dit geval t2). In dit voorbeeld gaat het om de objecten 03, 04, 05, 11, 12, 13 en 14. 4 Opvragingen uit een database met historische objecten Een GIS analyse of het maken van een kaart, gebeurt meestal met de actuele objecten of met objecten die op een datum in het verleden actueel waren. Als zowel de actuele als de historische objecten in de database zitten, moeten daarom de objecten geselecteerd worden op basis van de begin- en eindtijd van het object of de versie. Afhankelijk van het gewenste tijdstip zijn de volgende selecties dan noodzakelijk: Alleen de actuele objecten selecteren uit de tabel WEGDEEL_VLAK Selecteer de objecten waarvoor geldt: eindregistratie is <niet ingevuld> Als SQL query voorbeeld: SELECT * from WEGDEEL_VLAK where eindregistratie is null Objecten die op tijdstip t1 actueel waren uit de tabel WEGDEEL_VLAK Selecteer de objecten waarvoor geldt: (eindregistratie > <tijdtip t1> of <niet ingevuld> ) en tijdstipregistratie <= <tijdstip t1> Als SQL query voorbeeld waarbij t1 = 2011-09-01 : SELECT * from WEGDEEL_VLAK where nvl(eindregistratie, sysdate) > 2011-09-01 and tijdstipregistratie <= 2011-09-01