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
_______________________________________________
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
