[OSM-talk-nl] NLExtract project

[Frank Steggink]

On 23-1-2012 21:27, Michiel Faber wrote:
> Just van den Broecke schreef op ma 23-01-2012 om 10:33 [+0100]:
>
>> Dit zijn o.a. de "gotchas" waar ik in een eerdere mail op doelde. En
>> mogelijk zijn er die ik nog niet ken.
>>
>> groeten,
>>
>> Just
> Hallo,
>
> Ik spui hier zomaar wat vragen die in mij opkomen omtrent de top10.
> Dit zijn zo maar dingen die in mij opkomen. Wellicht al bij jullie
> opgekomen, niet relevant of al in overleg met het kadaster.
>
> Weet het Kadaster van deze "gotchas"?
> Zijn ze bewust er in gebracht?
> Hoe gaan zij er mee om?
> Wellicht een idee om er met hun over te praten om de brondata al in een
> beter formaat (aangeleverd) te krijgen of hun manier van werken te
> bekijken?
>
> Succes,
> Michiel
>
Michiel,

De meeste gotcha's zijn inherent aan het datamodel van Top10NL, dus ze 
zijn "bewust" ingebracht. Dit is gebaseerd op GML (geography markup 
language). Op basis hiervan is door Geonovum NEN3610 ontwikkeld en 
geïmplementeerd in GML (via een XML Schema-definitie). Dit heeft als 
doel uitwisseling van ruimtelijke data in Nederland. Dit model is 
behoorlijk complex. Top10NL is weer op basis van NEN3610 ontwikkeld. 
Volgens mij is dit alleen door het Kadaster gedaan. NEN3610 biedt al de 
mogelijkheid om meerdere geometrieën aan een object te koppelen (bijv. 
oppervlakte en hartlijn van een weg), of om meerdere attributen met 
dezelfde naam toe te voegen (bijv. wegnummers: een weg kan meerdere 
wegnummers hebben). Het doel is om de informatie zo compleet mogelijk op 
te slaan en uit te wisselen. Het is aan de gebruikers hiervan om te 
bepalen welke data wel of niet getoond wordt.

Dit heeft als consequentie dat de tooling aan behoorlijke eisen moet 
voldoen. ogr2ogr komt een heel eind, maar niet overal is een oplossing 
voor. Bijv. de meerdere geometrieen per object: hiervoor is dus de 
splitsings-stap nodig. Uitlevering in een ander formaat lost het 
probleem niet 1-2-3 op. Bijv. Shape is te beperkt om alle informatie 
ongeschonden door te laten. De data zoals die door het Kadaster wordt 
uitgeleverd is ook geen eindproduct waar een willekeurige gebruiker iets 
mee kan. Daarvoor moet er nog een bewerkingsslag overheen. De reden dat 
het NLExtract project is opgestart is juist om deze bewerkingsslag te 
maken en afgeleide producten te genereren, bijv. database-dumps voor 
PostgreSQL/PostGIS en Oracle. Dit is geen verantwoordelijkheid van het 
Kadaster. De "markt" kan het prima oplossen. (Het Kadaster levert wel de 
data in FGDB uit, maar waarschijnlijk komt dat omdat dit een 
tussenproduct van hun eigen werkproces is.) O.a. op LinkedIn in de NL 
OpenData groep is hierover discussie gevoerd.

Andere gotcha's zijn niet bewust:
* Afkappen van velden: dit is iets wat ogr2ogr blijkt te doen. Hier is 
omheen te werken, door bijv. de GFS-bestanden te editen.
* Niet-validerende GML: ik heb begrepen dat het Kadaster hier 
ondertussen van op de hoogte is. In april zou een goede versie moeten 
komen. (Kan geen linkje vinden.)
* Sommige objecten zijn dubbel als je alles importeert. Dit komt omdat 
ze over de bladgrenzen heen liggen. Dat zullen we met de hand moeten 
oplossen, tenzij het Kadaster een set landsdekkende GML's gaat maken 
waar geen dubbelingen in voorkomen.
Voor de rest moeten we zien waar het schip strandt ;)

Groeten,

Frank