On 23-1-2012 21:58, Frank Steggink wrote:
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 ;)
Een andere gotcha waar ik bang voor was, nl. meertaligheid, zit ook in
Top10NL. Zie bestand 06west.gml.
<top10nl:GeografischGebied gml:id="nl.top10nl.103078931" >
<nen3610:identificatie>NL.TOP10NL.103078931</nen3610:identificatie>
<nen3610:objectBeginTijd>2008-11-24T00:00:00</nen3610:objectBeginTijd><nen3610:versieBeginTijd>2008-11-24T00:00:00</nen3610:versieBeginTijd>
<top10nl:naam xml:lang="nl">Leeuwarden</top10nl:naam>
<top10nl:naam xml:lang="fy">Ljouwert</top10nl:naam>
<top10nl:typeGeografischGebied >plaats, bewoond
oord</top10nl:typeGeografischGebied>
<top10nl:labelPunt><gml:Point
srsName='urn:opengis:def:crs:EPSG::28992'><gml:pos
srsDimension="2">182596.785
579147.489</gml:pos></gml:Point></top10nl:labelPunt>
<top10nl:brontype>top10vector</top10nl:brontype>
<top10nl:bronbeschrijving>TOP10vector 2004</top10nl:bronbeschrijving>
<top10nl:bronactualiteit>2004-01-01</top10nl:bronactualiteit>
<top10nl:bronnauwkeurigheid>2</top10nl:bronnauwkeurigheid>
<top10nl:dimensie>2D</top10nl:dimensie>
</top10nl:GeografischGebied>
De naam "Leeuwarden" komt ook in het Fries voor, Ljouwert (met
xml:lang="fy").
Frank
_______________________________________________
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
