Difference between revisions of "Geonovum4GII"

From Geonovum Wiki
Jump to: navigation, search
(Created page with '= Naar een Nederlandse GII = Binnen Geonovum wordt hard gewerkt aan hulpmiddelen die een GII mogelijk maken. In dit document geven we per activiteit aant GII welke hulpmiddelen G…')
 
Line 1: Line 1:
= Naar een Nederlandse GII =
+
= Naar een Nederlandse GII =
Binnen Geonovum wordt hard gewerkt aan hulpmiddelen die een GII mogelijk maken. In dit document geven we per activiteit aant GII welke hulpmiddelen Geonovum biedt. Uiteindelijk kan het document gepubliceerd wordt op de geonovum wiki onder de naam: ‘Hoe maak ik een informatiemodel’.
 
  
 +
Binnen Geonovum wordt hard gewerkt aan hulpmiddelen die een GII mogelijk maken. In dit document geven we per activiteit aant GII welke hulpmiddelen Geonovum biedt. Uiteindelijk kan het document gepubliceerd wordt op de geonovum wiki onder de naam: 'Hoe maak ik een informatiemodel?'. Uiteindelijk moet dit document verwijzen naar de meest recente versie van alle hulpdocumenten.
  
Idealiter bevat het kookboek voor iedere hieronder genoemde handeling een goede beschrijving en is ieder document te vinden op onze website. Dat is nu nog zeker niet zo. Wat mij betreft gaan we:
 
  
* Ieder genoemd document krijgt een in de wiki (met een verantwoordelijke)
+
== Het maken van een conceptueel informatiemodel  ==
* Missende documenten worden geschreven.
 
  
== Het maken van een conceptueel informatiemodel ==
+
In het conceptueel informatiemodel wordt definities van objecten gegeven die voor belang zijn van de betreffende sector. Plus afbakening van het domein van de sector etc.  
In het conceptueel informatiemodel wordt definities van objecten gegeven die voor belang zijn van de betreffende sector. Plus afbakening van het domein van de sector etc.
 
  
 +
<br> Wat is waar belegd:
  
Wat is waar belegd:
+
*<nowiki>Hoe het conceptuele informatiemodel in UML gespecificeerd wordt is vastgelegd in NEN3610:2010 [Paul beheert hiervan de laatste versie ].</nowiki>
 +
*Daarnaast is er een template informatiemodel (nen3610.eap) <nowiki> dat kan zorgen voor harmonisatie. (Wilko beheert die)
 +
*Een volledig informatiemodel wordt daarna als een document gepubliceerd. Hier moet nog een template voor komen. (PDOK DPS template)(Paul beheert die).
 +
*In die template is een hoofstuk Feature Catalogue waarin een omschrijving van alle objecten en attributen wordt gegeven. We hebben een java programma dat een Feature Catalogue <nowiki>automatisch kan afleiden uit een eap file (FCGeneration gekregen van JRC). Het gebruik van het programma valt niet normatief vast te leggen. Wel kan je de layout die het programma genereerd normatief vastleggen. (Wilko beheert dit programma)
 +
*Verder willen we graag veel vastleggen over het beheer van de standaard (BOMOS) en versienummering etc. (Dit is belegd bij Marcel en Monique). BOMOS heeft ook een paragraaf over gebruiks licenties.
  
* <nowiki>Hoe het conceptuele informatiemodel in UML gespecificeerd wordt is vastgelegd in NEN3610:2010 [Paul beheert hiervan de laatste versie ].</nowiki>
+
== Het maken van een GML-applicatieschema  ==
* Daarnaast is er een template informatiemodel (nen3610.eap)<nowiki> dat kan zorgen voor harmonisatie. [ Wilko beheert die ]</nowiki>
 
* Een volledig informatiemodel wordt daarna als een document gepubliceerd. Hier moet nog een templ<nowiki>ate voor komen. [PDOK DPS template] [Paul beheert die].</nowiki>
 
* In die template is een hoofstuk Feature Catalogue waarin een omschrijving van alle objecten en attributen wordt gegeven. We hebben een java programma dat een Feature Catalogue <nowiki>automatisch kan afleiden uit een eap file (FCGeneration gekregen van JRC). Het gebruik van het programma valt niet normatief vast te leggen. Wel kan je de layout die het programma genereerd normatief vastleggen. [Wilko beheert dit programma]</nowiki>
 
* Verder wil<nowiki>len we graag veel vastleggen over het beheer van de standaard (BOMOS) en versienummering etc. [Dit is belegd bij Marcel en Monique]. BOMOS heeft ook een paragraaf over </nowiki>gebruiks licenties.
 
  
== Het maken van een GML-applicatieschema ==
+
Voor uitwisseling is het publiceren van een GML-applicatieschema nodig. Dit schema kan (met een aantal extra afspraken vast te leggen in GML4NL) automatisch worden afgeleid uit het UML applicatiemodel. Dit applicatiemodel in UML is gebaseerd op het conceptuele (UML) model voor dit domein.  
Voor uitwisseling is het publiceren van een GML-applicatieschema nodig. Dit schema kan (met een aantal extra afspraken vast te leggen in GML4NL) automatisch worden afgeleid uit het UML applicatiemodel. Dit applicatiemodel in UML is gebaseerd op het conceptuele (UML) model voor dit domein.
 
  
 +
<br> Wat willen we hieraan standaardiseren:
  
Wat willen we hieraan standaardiseren:
+
*We willen goed uitleggen over hoe je een conceptueel model kunt omzetten naar een applicatiemodel. (Dit zal zijn door multiple-inheritance te verwijderen etc,)
 +
*GML biedt duidelijk vertaalregels voor het vertalen van het applicatiemodel naar een GML applicatieschema. We kunnen nog wel het eea vastleggen:
 +
*Wat voor namespace wordt er gebruikt voor een sectoraal model?
 +
*Hoe gaan we om met <<placeholder>> klasses en hoe gaan we om met verwijzingen tussen verschillende sectorale modellen?
 +
*Welke versie van GML gebruiken we 3.2.1
 +
*Welke character encoding raden we aan.(UTF-8)
 +
*Welke geometrie types gaan we toestaan. (simple features + cirkelbogen) Gaan we hier een profiel van maken. (TODO: Linda)
 +
*Gaan we lijsten nog vastleggen in een register
 +
*Gaan we de schema’s zelf ook nog een ID geven of een URN (urn:nen3610:schema:gml4nl:1.0.0)
 +
*Publicatie van het GML schema kunnen we centraal doen op bijvoorbeeld: [http://schemas.geostandaarden.nl/ http://schemas.geostandaarden.nl]
  
* We willen goed uitleggen over hoe je een conceptueel model kunt omzetten naar een applicatiemodel. (Dit zal zijn door multiple-inheritance te verwijderen etc,)
+
== Extra afspraken over hoe het GML eruitziet  ==
* GML biedt duidelijk vertaalregels voor het vertalen van het applicatiemodel naar een GML applicatieschema. We kunnen nog wel het eea vastleggen:
 
* Wat voor namespace wordt er gebruikt voor een sectoraal model?
 
* <nowiki>Hoe gaan we om met <<placeholder>> klasses en hoe gaan we om met verwijzingen tussen verschillende sectorale modellen?</nowiki>
 
* Welke versie van GML gebruiken we 3.2.1
 
* Welke character encoding raden we aan.(UTF-8)
 
* Welke geometrie types gaan we toestaan. (simple features + cirkelbogen) Gaan we hier een profiel van maken. (TODO: Linda)
 
* Gaan we lijsten nog vastleggen in een register
 
* Gaan we de schema’s zelf ook nog een ID geven of een URN (urn:nen3610:schema:gml4nl:1.0.0)
 
* Publicatie van het GML schema kunnen we centraal doen op bijvoorbeeld: [http://schemas.geostandaarden.nl/ http://schemas.geostandaarden.nl]
 
  
== Extra afspraken over hoe het GML eruitziet ==
+
Niet alles wat je wilt afspreken over hoe het GML eruitziet ligt vast in een applicatieschema. Vooral over het coderen van unieke identifiers en verwijzingen kan nogal wat worden vastgelegd.  
Niet alles wat je wilt afspreken over hoe het GML eruitziet ligt vast in een applicatieschema. Vooral over het coderen van unieke identifiers en verwijzingen kan nogal wat worden vastgelegd.
 
  
 +
<br> Wat willen we nog meer standaardiseren:
  
Wat willen we nog meer standaardiseren:
+
*Hoe ziet een unieke identifer eruit als URN. (TODO: URN aanvragen)
 +
*Hoe coderen we de unieke identifiers in een GML document als: gml:id, gml:identifcatie en NEN3610id
 +
*Hoe verwijzen we naar een object: Locatie en over de grenzen
  
* Hoe ziet een unieke identifer eruit als URN. (TODO: URN aanvragen)
+
<br>
* Hoe coderen we de unieke identifiers in een GML document als: gml:id, gml:identifcatie en NEN3610id
 
* Hoe verwijzen we naar een object: Locatie en over de grenzen
 
  
 +
== Het publiceren van dit informatiemodel  ==
  
== Het publiceren van dit informatiemodel ==
 
 
Een informatiemodel kan als Feature Catalogue (ISO19110) worden gepubliceerd.  
 
Een informatiemodel kan als Feature Catalogue (ISO19110) worden gepubliceerd.  
  
 +
<br> Wat willen we hieraan standaardizeren:
  
Wat willen we hieraan standaardizeren:
+
*Een pdf van het informatiemodel kan centraal gepubliceerd worden op bijvoorbeeld: [http://www.geostandaarden.nl/ http://www.geostandaarden.nl]<nowiki>. [Willen we dit?]</nowiki>
 +
*Publicatie van de Feature Catalogue kunnen we centraal doen op bijvoorbeeld: [http://fc.geostandaarden.nl/ http://fc.geostandaarden.nl] <nowiki>[TODO].</nowiki>
  
* Een pdf van het informatiemodel kan centraal gepubliceerd worden op bijvoorbeeld: [http://www.geostandaarden.nl/ http://www.geostandaarden.nl]<nowiki>. [Willen we dit?]</nowiki>
+
== Het publiceren van de metadata van de gegevens  ==
* Publicatie van de Feature Catalogue kunnen we centraal doen op bijvoorbeeld: [http://fc.geostandaarden.nl/ http://fc.geostandaarden.nl] <nowiki>[TODO].</nowiki>
 
  
== Het publiceren van de metadata van de gegevens ==
+
Hier een verwijzing naar het NGR: Dit kan op [http://www.nationaalgeoregister.nl/ www.nationaalgeoregister.nl]  
Hier een verwijzing naar het NGR: Dit kan op [http://www.nationaalgeoregister.nl/ www.nationaalgeoregister.nl]
 
  
Onder het tabje publiceren wordt je momenteel verwezen naar Geonovum.
+
Onder het tabje publiceren wordt je momenteel verwezen naar Geonovum.  
  
== Het publiceren van visualisatieregels ==
+
== Het publiceren van visualisatieregels ==
Hier wacht ik de workshop resultaten af.
 
  
== Het bouwen van services die wat met de gegevens doen ==
+
Hier wacht ik de workshop resultaten af.  
Wanneer een sectoraal model geheel gedocumenteerd is zoals hierboven beschreven kunnen er services gebouwd worden die deze gegevens leveren. Dit kan bijvoorbeeld in de PDOK context zijn. Hier valt flink wat aan te standaardiseren, ik laat dit graag over aan PDOK. Services waaran gedacht kan worden zijn:
 
  
* WMS (de gegevens als een plaatje)
+
== Het bouwen van services die wat met de gegevens doen  ==
* WFS (de gegevens als GML)
 
* URN resolver. Server die als je de unieke identificatie van een object weet het bijbehorende object oplevert. Hier heb ik pas een paragraafje over geschreven.
 
  
 +
Wanneer een sectoraal model geheel gedocumenteerd is zoals hierboven beschreven kunnen er services gebouwd worden die deze gegevens leveren. Dit kan bijvoorbeeld in de PDOK context zijn. Hier valt flink wat aan te standaardiseren, ik laat dit graag over aan PDOK. Services waaran gedacht kan worden zijn:
  
== Het valideren van gegevens binnen de GII ==
+
*WMS (de gegevens als een plaatje)
Voor het valideren hebben we een fraai product: De validator. Maar wie weet willen we meer:
+
*WFS (de gegevens als GML)
 +
*URN resolver. Server die als je de unieke identificatie van een object weet het bijbehorende object oplevert. Hier heb ik pas een paragraafje over geschreven.
  
* Het valideren van geometriën: Valt een geometrie binnen GML4NL?
+
<br>
* Het valideren van externe verwijzingen: Momenteel checkt de validator alleen of er op de plek van een verwijzing een correct gestructureerde xlink staat. Dit houdt niet veel in. Als je een URN resolver hebt kunnen ook de volgende dingen gevalideerd worden: Bestaat het object wel waarnaar ik verwijs? Is het object wel van het juiste type? Dus geen bag-pand op een plek waar ik een kadastraal perceel verwacht.
+
 
 +
== Het valideren van gegevens binnen de GII  ==
 +
 
 +
Voor het valideren hebben we een fraai product: De validator. Maar wie weet willen we meer:
 +
 
 +
*Het valideren van geometriën: Valt een geometrie binnen GML4NL?  
 +
*Het valideren van externe verwijzingen: Momenteel checkt de validator alleen of er op de plek van een verwijzing een correct gestructureerde xlink staat. Dit houdt niet veel in. Als je een URN resolver hebt kunnen ook de volgende dingen gevalideerd worden: Bestaat het object wel waarnaar ik verwijs? Is het object wel van het juiste type? Dus geen bag-pand op een plek waar ik een kadastraal perceel verwacht.

Revision as of 11:38, 15 April 2010

Naar een Nederlandse GII

Binnen Geonovum wordt hard gewerkt aan hulpmiddelen die een GII mogelijk maken. In dit document geven we per activiteit aant GII welke hulpmiddelen Geonovum biedt. Uiteindelijk kan het document gepubliceerd wordt op de geonovum wiki onder de naam: 'Hoe maak ik een informatiemodel?'. Uiteindelijk moet dit document verwijzen naar de meest recente versie van alle hulpdocumenten.


Het maken van een conceptueel informatiemodel

In het conceptueel informatiemodel wordt definities van objecten gegeven die voor belang zijn van de betreffende sector. Plus afbakening van het domein van de sector etc.


Wat is waar belegd:

  • Hoe het conceptuele informatiemodel in UML gespecificeerd wordt is vastgelegd in NEN3610:2010 [Paul beheert hiervan de laatste versie ].
  • Daarnaast is er een template informatiemodel (nen3610.eap) dat kan zorgen voor harmonisatie. (Wilko beheert die) *Een volledig informatiemodel wordt daarna als een document gepubliceerd. Hier moet nog een template voor komen. (PDOK DPS template)(Paul beheert die). *In die template is een hoofstuk Feature Catalogue waarin een omschrijving van alle objecten en attributen wordt gegeven. We hebben een java programma dat een Feature Catalogue <nowiki>automatisch kan afleiden uit een eap file (FCGeneration gekregen van JRC). Het gebruik van het programma valt niet normatief vast te leggen. Wel kan je de layout die het programma genereerd normatief vastleggen. (Wilko beheert dit programma) *Verder willen we graag veel vastleggen over het beheer van de standaard (BOMOS) en versienummering etc. (Dit is belegd bij Marcel en Monique). BOMOS heeft ook een paragraaf over gebruiks licenties. == Het maken van een GML-applicatieschema == Voor uitwisseling is het publiceren van een GML-applicatieschema nodig. Dit schema kan (met een aantal extra afspraken vast te leggen in GML4NL) automatisch worden afgeleid uit het UML applicatiemodel. Dit applicatiemodel in UML is gebaseerd op het conceptuele (UML) model voor dit domein. <br> Wat willen we hieraan standaardiseren: *We willen goed uitleggen over hoe je een conceptueel model kunt omzetten naar een applicatiemodel. (Dit zal zijn door multiple-inheritance te verwijderen etc,) *GML biedt duidelijk vertaalregels voor het vertalen van het applicatiemodel naar een GML applicatieschema. We kunnen nog wel het eea vastleggen: *Wat voor namespace wordt er gebruikt voor een sectoraal model? *Hoe gaan we om met <<placeholder>> klasses en hoe gaan we om met verwijzingen tussen verschillende sectorale modellen? *Welke versie van GML gebruiken we 3.2.1 *Welke character encoding raden we aan.(UTF-8) *Welke geometrie types gaan we toestaan. (simple features + cirkelbogen) Gaan we hier een profiel van maken. (TODO: Linda) *Gaan we lijsten nog vastleggen in een register *Gaan we de schema’s zelf ook nog een ID geven of een URN (urn:nen3610:schema:gml4nl:1.0.0) *Publicatie van het GML schema kunnen we centraal doen op bijvoorbeeld: [http://schemas.geostandaarden.nl/ http://schemas.geostandaarden.nl] == Extra afspraken over hoe het GML eruitziet == Niet alles wat je wilt afspreken over hoe het GML eruitziet ligt vast in een applicatieschema. Vooral over het coderen van unieke identifiers en verwijzingen kan nogal wat worden vastgelegd. <br> Wat willen we nog meer standaardiseren: *Hoe ziet een unieke identifer eruit als URN. (TODO: URN aanvragen) *Hoe coderen we de unieke identifiers in een GML document als: gml:id, gml:identifcatie en NEN3610id *Hoe verwijzen we naar een object: Locatie en over de grenzen <br> == Het publiceren van dit informatiemodel == Een informatiemodel kan als Feature Catalogue (ISO19110) worden gepubliceerd. <br> Wat willen we hieraan standaardizeren: *Een pdf van het informatiemodel kan centraal gepubliceerd worden op bijvoorbeeld: [http://www.geostandaarden.nl/ http://www.geostandaarden.nl]<nowiki>. [Willen we dit?]
  • Publicatie van de Feature Catalogue kunnen we centraal doen op bijvoorbeeld: http://fc.geostandaarden.nl [TODO].

Het publiceren van de metadata van de gegevens

Hier een verwijzing naar het NGR: Dit kan op www.nationaalgeoregister.nl

Onder het tabje publiceren wordt je momenteel verwezen naar Geonovum.

Het publiceren van visualisatieregels

Hier wacht ik de workshop resultaten af.

Het bouwen van services die wat met de gegevens doen

Wanneer een sectoraal model geheel gedocumenteerd is zoals hierboven beschreven kunnen er services gebouwd worden die deze gegevens leveren. Dit kan bijvoorbeeld in de PDOK context zijn. Hier valt flink wat aan te standaardiseren, ik laat dit graag over aan PDOK. Services waaran gedacht kan worden zijn:

  • WMS (de gegevens als een plaatje)
  • WFS (de gegevens als GML)
  • URN resolver. Server die als je de unieke identificatie van een object weet het bijbehorende object oplevert. Hier heb ik pas een paragraafje over geschreven.


Het valideren van gegevens binnen de GII

Voor het valideren hebben we een fraai product: De validator. Maar wie weet willen we meer:

  • Het valideren van geometriën: Valt een geometrie binnen GML4NL?
  • Het valideren van externe verwijzingen: Momenteel checkt de validator alleen of er op de plek van een verwijzing een correct gestructureerde xlink staat. Dit houdt niet veel in. Als je een URN resolver hebt kunnen ook de volgende dingen gevalideerd worden: Bestaat het object wel waarnaar ik verwijs? Is het object wel van het juiste type? Dus geen bag-pand op een plek waar ik een kadastraal perceel verwacht.