| WAAR | WAT | OPLOSSINGSRICHTING |
|---|---|---|
| Algemeen | Verwijzingen naar standaarden en andere documenten zijn niet netjes en consequent opgenomen. Verwijzingen naar documenten kunnen met ReSpec heel netjes worden opgenomen in een bibliografie. ReSpec heeft zelf al een hele bibliografische database voor standaarden, SpecRef, die je kunt vinden via de ReSpec knop rechtsboven in het document. | Verwijs naar entries uit SpecRef tussen dubbele blokhaken bv [[iso-19107-2003]] en neem voor wat ontbreekt in SpecRef een bibliografie op in config.js. Verwijs naar entries in SpecRef / de eigen bibliografie ipv links in de tekst te zetten. ReSpec neemt automatisch de bibliografie op van alle documenten waarnaar verwezen is, achterin het document. Verschillende mensen bij Geonovum kunnen hierbij helpen. |
| Algemeen | Termen worden op verschillende manieren gebruikt in de tekst. Bij 'objecten' gaat het soms om werkelijke instanties (bomen, spoorlijnen, etc), soms om informatieobject(typen), of om begrippen. Soms worden deze ideeën ook door elkaar gebruikt, bijvoorbeeld (uit Hoofdstuk 4): "In enkele gevallen betekent dit dat de SOR-begrippen hetzelfde zijn als objecttypen uit het vernieuwde basismodel geo-informatie". | Dit is een aandachtspunt, het kan worden aangepakt door eenduidige 'basis' begrippen te hanteren. |
| Algemeen | Ontbreken van uitgangspunt: het moet mogelijk zijn om topologische relaties administratief vast te leggen. Om het gebruik van de informatie in de SOR en verbonden resgistraties verder te verbreden is het van belang om de samenhang die geoinformatie biedt ook middels administratieve relaties uit te drukken. Bijv. Gebouw 1 overlaptMet Perceel 2 en 3, Of gemeentegebied A ligtIn Provinciegebied B. Dit zal het voor gebruikers nog veel laagdrempeliger maken om deze informatie te benutten, omdat men geen GIS systeem nodig heeft om bepaalde vragen te beantwoorden. Het opnemen van deze administratieve relaties kan uiteindelijk gefaciliteerd worden voor de bronhouders. |
Uitwerken en opnemen van dit uitgangspunt. |
| Algemeen | Het moet voor andere registraties duidelijk zijn hoe ze relaties kunnen leggen naar SOR objecten. Er zou in kaart moeten worden gebracht hoe er vanuit een andere registratie op een standaard manier gerelateerd kan worden aan de SOR. Het belangijke hier is dat dit tot op bepaalde hoogte gestandaardiseerd is en dat de semantiek van samenhangsrelaties gedefinieerd is. Dit maakt het gemakkelijker om samenhang vanuit verschillende registraties te kunnen interpreteren en hergebruiken. NOOT: dit was een resultaat uit DisGeo Demo II Lessons Learned |
Definieer hoe er vanuit een andere registratie naar een SOR object verwezen kan worden. |
| 1.3 conceptueel model | We hebben eerder met de werkgroep inhoud besproken dat dit document geen conceptueel model te noemen is; de werkgroep inhoud maakt geen conceptueel model maar geeft de kaders en inhoudelijke input voor met maken hiervan. Het is verwarrend dat in 1.3 en elders in het document dan toch van "het conceptueel model" gesproken wordt. | Term overal in het doc vooraf laten gaan door "aanzet tot". |
| 2 Uitgangspunten | We verwachten dat MIM en NEN 3610 worden genoemd als uitgangspunt. Verderop in het document worden deze kaderstellende standaarden wel genoemd, maar ze horen dan ook in hfd 2 genoemd te worden. Ook NTA 8035 zou genoemd moeten worden als standaard waaraan we zoveel als mogelijk willen voldoen. | Voeg toe een paragraaf over kaderstellende standaarden MIM, NEN 3610 en NTA 8035. |
| 2.2.1 Standaardisatie | Kwaliteit wordt gedefinieerd als volledigheid en actualiteit. In ISO 19113 wordt meer genoemd: ook nog logische consistentie, positionele nauwkeurigheid, temporele nauwkeurigheid en thematische nauwkeurigheid. De BGT catalogus 1.1 definieert critera voor al deze aspecten behalve thematische nauwkeurigheid. Conform Spatial Data on the Web best practice 14 zou in ieder geval de positionele nauwkeurigheid van geometrische representaties van objecten beschreven moeten worden. | Bepaal welke kwaliteitsaspecten belangrijk zijn voor de SOR en voeg deze toe. Voorstel: Volledigheid, logische consistentie, positionele nauwkeurigheid, temporele nauwkeurigheid (= actualiteit). |
| 2.2.2 Definiëring | Niet duidelijk wat hier bedoeld is met 'verzamelclassificaties'. Een klasse van dingen is toch een verzameling? Misschien wordt een verzameling van eigenschappen bedoeld die verschillende klassen van dingen delen en voor het gemak maar in een abstracte klasse worden gestopt waar alle klassen van erven? | Verduidelijken. |
| 2.4.2 Onderscheid fysiek en functioneel | 'overlap van verschillende objecttypen': Hier worden objecttypen, objecten en hun geometrische representatie door elkaar gehaald. | Vervangen door 'overlap van de geometrische representatie van verschillende objecttypen'. |
| 2.4.2 Onderscheid fysiek en functioneel | Gaat het niet eerder over een onderscheid tussen fysiek en virtueel (waaronder functioneel)? | Verduidelijken, mogelijk aanpassen |
| 2.4.3 Kleinste semantische eenheden | Onduidelijke zin 'wat er wordt voorgeschreven voor verplicht gebruik bij geaggregeerde objecten (het algoritme of een vastlegging van de uitkomst van dit algoritme).' | Verduidelijken. Wat wordt hier bedoeld met een algoritme? Overweegt men om in plaats van BRT gebouwen te gaan vastleggen wat de regels zijn op basis waarvan gebouwen worden afgebakend? |
| 2.4.4 Volledige levensloop | Verduidelijken: het gaat hier (vermoeden we) om de levensloop van de objecten in de werkelijkheid. | De tekst zou in deze paragraaf kunnen worden verduidelijkt door het onderscheid tussen object in de werkelijkheid en informatieobject in de registratie te hanteren. Bv. 'of een object als zodanig nog bestaat' gaat over het object in de werkelijkheid; 'objecten worden niet afgevoerd' gaat over informatieobjecten in de registratie. |
| 2.5.2 Typering | Of een typering als objecttype wordt gemodelleerd of als eigenschap, is een keuze die in het informatiemodel pas definitief gemaakt kan worden. Hier spelen niet alleen inhoudelijke maar ook modelleertechnische conventies en (on)mogelijkheden rondom hard- vs soft typing. Het is bv voor andere sectoren wellicht eenvoudiger om aan te sluiten op typeringen die als objecttype zijn gemodelleerd. De consequenties zijn nog niet helemaal duidelijk. | Een noot opnemen die aangeeft dat definitieve keuzen pas in het informatiemodel gemaakt kunnen worden. |
| 2.5.3 Geometrie | 'Met geometrie wordt daarbij expliciet bedoeld een geo-gerefereerde vastlegging van de begrenzing van een object.' Uit de volgende zinnen blijkt dat het niet altijd om een begrenzing gaat, maar soms om een enkel punt (of een lijn? Dit wordt niet genoemd, maar zou ook een mogelijkheid kunnen zijn). | Beter is om in de definitie te spreken van een 'vastlegging van de geometrische representatie van een object'. NB ook in 3.2 komt dit voor. |
| 2.5.3 Geometrie | geen impliciete geometrie: in 3D standaarden zoals CityGML komt het wel voor dat objecten een impliciete, geparameteriseerde geometrie hebben als ze veel voorkomen en de geometrie vnl voor visualisatie van belang is. Denk bv aan bomen of straatmeubilair. Deze zouden dan niet in de SOR zijn toegestaan. | Overwegen om dit wel toe te staan. |
| 2.5.4 Meta-informatie | In deze paragraaf is het belangrijk om object (in de werkelijkheid) en informatie-object goed te scheiden. | 'Van elk object in de SOR' > Over de registratie van elk object in de SOR; 'het object' > het informatieobject |
| 3.1.1 Opbouw objectidentificatie | De term 'informatie-object' wordt hier geintroduceerd, maar niet gedefinieerd. Gezien het in 3.1 gaat over identificatie van objecten lijkt dat hier ook hetgeen bedoeld wordt. | De term 'informatie-object' hier vervangen door een gedefinieerde passende term. |
| 3.1.1 Opbouw objectidentificatie | Onduidelijk wat 'Van belang is dat de objectidentificatie niet betekenisvol geïnterpreteerd mag worden.' betekent. | Helder definieren en wellicht duiden met een voorbeeld. |
| 3.1.2 Identiteit | 'Een functionele objectidentificatie kan een of meer technische identificaties hebben' | Ik zou dit iets anders formuleren: 'kan een of meer technische verschijningsvormen hebben'. |
| 3.1.2 Identiteit | 'Een functionele objectidentificatie kan een of meer technische identificaties hebben' | Technische identificaties zijn niet van belang. Het gaat erom dat je functioneel een antwoord op de vraag 'Geef mij de informatie over het object X' moet kunnen krijgen. Hoe beschrijvingen van object X technisch geidentificeerd worden is ondergeschikt. |
| 3.1.3 Tijd | De levensloop van een object laten beginnen en eindigen in de registratie: dit gaat over het registratieobject, niet over het object in de werkelijkheid. Het onderscheid moet in de tekst duidelijk en consequent worden aangegeven. | Verduidelijken mbv inzichten uit het modelleerteam. |
| 3.1.4 Uitgifte | Ik zou nog niet uitsluiten dat objecten hun identificatie al in een sectorregistratie krijgen. Dit in afwachting van de resultaten van het UOI project. Er zijn voorbeelden van succesvolle informatieuitwisseling over objecten waarbij het object bij de eerste registratie door de bronhouder een persistent, uniek ID ontvangt en dit in de hele keten behoudt (bv SIKB0101). | Overweeg om dit ontwerpprincipe voorlopig niet op te nemen, of erbij te vermelden dat het naar aanleiding van de UOI inzichten nog kan wijzigen, net als bij het eerdere ontwerpprincipe over aanvang levensloop. |
| 3.2 Geometrie | De tekst vóór 3.2.1 is dubbelop met 2.5.3. | Op een van de twee plekken verwijderen. |
| 3.2.1 Coordinaatreferentiesystemen | Het is gangbaar in een standaard om een CRS voor te schrijven of een beperkt aantal toe te staan, meestal alleen RD en ETRS89. Ik ben een groot voorstander van het gebruik van WGS84 (als default CRS, niet als de enige aangeboden optie) aan de publicatiekant, maar voor de bijhouding en aanlevering lijkt het me geen goede keuze ivm de eisen aan nauwkeurigheid van grootschalige data. | Perk de toegestane CRS in tot RD en ETRS89 (2D en 3D) met de opmerking dat dit moet worden uitgebreid indien ook bv de overzeese gebieden gaan meespelen. Voor objecten op zee (bv windturbines) is wellicht ook een ander stelsen nodig. |
| 3.2.3 3D | 'Het gaat hierbij dus om de coordinate dimension (ISO19107) en niet om de dimensie van de geometric primitive (ISO19107) die wordt gebruikt om de geometrie te representeren.' Onduidelijk voor de lezer wat hier wordt bedoeld. De paywall bij ISO helpt hier niet bij. Beter om het even kort uit te leggen naast verwijzen naar de iSO standaard. | Coordinate dimension: het aantal assen dat nodig is om een positie in een coordinaatsysteem te beschrijven. |
| 3.2.5 Topologie | De objecten zelf (ie object in de werkelijkheid) en geometrische representaties van het object worden in deze tekst gelijk gesteld terwijl ze dit niet zijn. Neem bv een waterobject, de begrenzing hiervan in het terrein zal doorgaans varieren omdat de waterstand onderhevig is aan allerlei invloeden. De geometrische representatie van dit object in de SOR zal echter - neem ik aan - niet variabel zijn maar een statische begrenzing op basis van afbakeningsregels. | Maak duidelijk in de tekst dat het gaat om de geometrieën van objecten die op elkaar aan moeten sluiten. |
| 3.2.5 Topologie | Als er een referentielaag is die het hele Nederlandse Grondgebied dekt, betekent dat dan niet dat er ten opzichte van huidige basisregistraties nieuwe objecten moeten worden ingewonnen, namelijk in de territoriale wateren? | Maak dit duidelijk in de tekst. |
| 3.2.5 Topologie | Vernieuwde topologieregels lijken relevant, aangezien uit de definities van de begrippen niet altijd blijkt dat bepaalde objecttypes (en dus de objecten op dataniveau) elkaar niet mogen overlappen (zie de Github issue over de definitiescherpte van begrippen) | - |
| 3.2.5 Topologie | "In geval van functionele objecttypen NIET volledig bedekt " - is dit ook niet het geval voor andere virtuele objecten? | Verduidelijken |
| 3.2.7 Lineair referencing | Bronvermelding ontbreekt bij INSPIRE vermelding. | Neem een bibliografische verwijzing op naar het desbetreffende INSPIRE document. |
| 3.2.7 Lineair referencing | "als iets in de werkelijkheid zowel een reel voorkomen heeft als een functie, dan moet de geometrie van het functionele object afgeleid worden van het reële" - wat wordt hier bedoeld met 'iets'? In de registratie wordt gesproken over reële en virtuele object(typen), niet voorkomen. | Verduidelijken |
| 3.4.1 Generaliseren | Waarom cartografische objecten een tijdelijke identificatie geven? Wat is de gebruikersbehoefte? Het lijkt zinloos als deze niet wordt bewaard. Als een technisch ID verplicht is zoals bv in GML (overigens is dit vanaf GML 3.2.2 niet meer het geval) dan is dat niet iets dat je in een conceptueel model zou moeten vastleggen. | Geen tijdelijke identificatie voor cartografische objecten opnemen. |
| 3.4.1 Generaliseren | "Gegeneraliseerde dataobjecttypen worden niet opgenomen" - gaat generalisatie (zoals in 3.4 werd uitgelegd) niet over geometrieën op dataniveau? | Ontwerpprincipe herzien |
| 3.4.2 Kwalteit | Welk kwaliteitsaspect wordt hier bedoeld? Omdat het om mate van detail gaat, is dit waarschijnlijk de positionele nauwkeurigheid? | Maak expliciet welk kwaliteitsaspect hier wordt bedoeld. |
| 3.4.2 Kwalteit | Wat wordt bedoeld met 'basisniveau'? Is dat wat elders (3.2.5) de referentielaag wordt genoemd? | Spreken van referentielaag (of uitleggen wat basisniveau is als iets anders bedoeld wordt) |
| 3.4.2 Kwalteit | 'dataobjecten' is onduidelijk. Het gaat hier om de geometrische representatie van objecten. | Verduidelijken |
| 3.4.2 Kwaliteit | 'Terugmeldingen op gegeneraliseerde objecten' - dit is een andachtspunt, niet een ontwerpprincipe | Opmaak herzien |
| 3.5.1 Relevante aspecten meta-informatie | In deze tekst kan beter onderscheid gemaakt worden tussen gegevens over objecten in de werkelijkheid en gegevens over de registratie van het object. Bv historie gaat over registratie, levensfase over objecten in de werkelijkheid; bronverwijzing gaat soms over registratie maar soms ook over observaties in de werkelijkheid, etc. Dit loopt nu door elkaar heen, terwijl het voor het kunnen gebruiken van objecten in samenhang van groot belang is dat dit in het informatiemodel goed gescheiden wordt. | Het modelleerteam kan helpen om de tekst op dit punt aan te scherpen. |
| 3.5.1 Relevante aspecten meta-informatie | Autorisatie tot op attribuutniveau heeft naast consequenties voor de informatiemodellering ook consequenties op de architectuur, is dit met het architectuurteam afgestemd? Het lijkt ambitieus. | Nagaan wat de mogelijkheden zijn. |
| 3.5.1 Relevante aspecten meta-informatie | Verschillende soorten statussen worden door elkaar gehaald. 'inOnderzoek' zegt iets over een specifiek gegeven; 'optioneel' zegt iets over een klasse van gegevens. Het lijkt me niet nodig om bij elke instantie van een Bak te gaan aangeven dat deze optioneel is. | Onderscheid maken tussen statussen van individuele object enerzijds en hun eigenschappen en van objecttypen en hun gegevens anderszijds. |
| 3.5.2 Specificeren meta-informatie in informatiemodel | In het informatiemodel vastleggen wie de bronhouder is voor een objecttype lijkt me vreemd. Dit zou in de wet moeten worden vastgelegd. Bij een individueel object kan natuurlijk wel worden vastgelegd wat daar de bronhouder van is, maar dat wordt hier waarschijnlijk niet bedoeld. | Informatie over de bronhouder van objecttypen niet in het informatiemodel vastleggen. |
| 3.5.2 Specificeren meta-informatie in informatiemodel | aspecten zoals autorisatie, verplichtheid en wie de bronhouder moet zijn van een objecttype of attribuut in de SOR worden nu vermengd met het informatiemodel. Dit kan leiden to problemen in breder gebruik van het informatiemodel. | Scheidt eisen aan het informatiemodel en de toepassing daarvan in een registratie-architectuur. Mbt autorisatie is het wel van belang om in het informatiemodel voldoende meta-eigenschappen op te nemen op basis waarvan autorisatieprofielen op objecten of gegegevens opgesteld kunnen worden. |
| 3.5.3 Registeren metagegevens per object | Of de bronverwijzing wordt vastgelegd aan de hand van een waardelijst of op een andere manier wordt in het informatiemodel bepaald. Een waardelijst biedt bijvoorbeeld geen aanknopingspunt voor gestandaardiseerde gedetailleerde herkomstbeschrijvingen. | 'aan de hand van een waardelijst' en 'op deze waardelijst' verwijderen. |
| 3.5.3 Registreren metagegevens per object | Of het relevant is om de bronhouder te registreren en of er gebruiksautorisaties nodig zijn, moet uit de werkgroep inhoud komen. De informatiemodelleurs kunnen dit niet zelf bepalen. | Vervangen door 'wordt later gespecificeerd'. |
| 3.5.4 Registeren metagegevens per attribuut | Grotendeels is deze informatie een herhaling van tekst eerder in dit hoofdstuk. | Verwijderen wat dubbel voorkomt. |
| 3.5.4 Registeren metagegevens per attribuut | Ik kan inhoudelijk niet beoordelen of al deze metagegevens nodig zijn; maar wil wel de kanttekening plaatsen dat dit erg veel lijkt. Voor elk attribuut al deze gegevens opnemen en bijhouden zorgt voor heel veel overhead. Is er goed gekeken naar de noodzaak? Overweging is ook dat in de BGT altijd alleen op objectniveau metadata werd opgenomen. | Neem alleen het hoognoodzakelijke op. |
| 3.5.5 Plaatsbepalingspunten | 'omdat van elk basisobject nagespeurd moet kunnen worden wat de bron is en hoe de inwinning tot stand is gekomen'. Is dit werkelijk nodig? De use case van PBP's was m.i. altijd al discutabel en in de praktijk zorgden ze ook nog eens voor extra complexiteit en problemen. Door het toevoegen van de administratieve relatie maak je de PBPs misschien (in theorie) beter beheersbaar, maar aan de andere kant maak je het volume aan gegevens heel veel groter. | Plaatsbepalingspunten niet opnemen, of alleen bij die objecttypen waar duidelijk is dat ze werkelijk nodig zijn. |
| 3.5 Meta-informatie en bronverwijzing | Een inconsistentie in het document: in verschillende onderdelen van 3.5 wordt gezegd dat als de geometrie van een object muteert, dit niet direct moet leiden tot mutatie van de aangrenzende geometrieën om weer tot een topologisch correct geheel te komen. Dit zou in producten moeten worden opgelost. Dit is, of lijkt in ieder geval, in tegenspraak met 3.2.5 Topologie. | Verduidelijken hoe deze uitspraken zich tot elkaar verhouden, de inconsistentie oplossen. |
| 3.6.2 Tijdlijn geldigheid en tijdlijn registratie | Het object zelf en gegevens over de registratie ervan dienen goed gescheiden te worden. De tijdlijn Geldigheid gaat over het object zelf en is dus een gegeven van het object. De tijdlijn Registratie gaat over de registratie van het object en is dus metainformatie. | Dit expliciet aangeven in de tekst. |
| 3.6.2 Tijdlijn geldigheid en tijdlijn registratie | Geometrie-objecten als beginGeldigheid de datum van een luchtfoto geven is onzuiver. Dit is het tijdstip waarop een waarneming (in termen van de internationale standaard Observations & measurements, waar het IMMetingen en een deel van de BRO informatiemodellen oa op gebaseerd is) is gedaan. Het opnemen van een tijdstip van waarneming als tijdstip geldigheid is vermenging van semantiek en heeft een negatief effect op het kunnen gebruiken van gegevens in samenhang. De realiteit is dat je in veel gevallen de datum van ontstaan of wijziging in de werkelijkheid van topografische objecten gewoon niet weet. Daarom is dit ook niet in de BGT opgenomen. | Geen geldigheidsdata voor geometrie opnemen. Je kunt wel eventueel de bronwaarneming voor de geometrie modelleren. |
| 3.6.4 Levensduur | Levensduur zoals gepresenteerd met een inggangsdatumObject en einddatumObject is een lastig fenomeen en in de NEN3610:2011 al aangeduid als afleidbaar gegeven. Allereerst gaat geldgigheid, en dus ook levensduur, over een informatieobject(de gegevens over bijv. een fysiek object als gebouw). Daarnaast is het "raar" om van een informatieobject een eigenschap op te nemen wat eigenlijk gaat over de geldigheid van het eerste geldige informatieobject in een reeks. |
Modelleer levensduur op een andere manier, door het leggen van opvolgingsrelaties tussen informatieobjecten. Hiervoor kan ook weer PROV-DM toegepast worden (https://www.w3.org/TR/prov-dm/#dfn-revision). |
| 3.6.6 Levensfasen | Bij de genoemde levensfasen zijn fasen die horen bij werkelijke objecten en de registratie daarvan niet goed gescheiden. 'ten onrechte opgevoerd' gaat over registratie. Ook vergunde en fysieke werkelijkheid lopen door elkaar. Wat voor problemen dit oplevert zie je in het voorbeeld van de school die verbouwd wordt tot woning. | 'ten onrechte' verwijderen uit de lijst van levensfasen. Dit kan als een apart metagegeven gemodelleerd worden. Nader afwegen of vergunde en fysieke werkelijkheid apart gemodelleerd moeten worden. |
| 3.6.6 Levensfasen | Taxonomische structuur van statussen is niet expliciet gespecificeerd. In de statussen lijkt een taxonomische structuur te bestaan, maar deze is niet expcliciet gedefinieerd. Het expliciet definieren en bruikbaar maken van deze taxonomie zal het gebruik van de SOR bevorderen. Een mogelijkheid die onstaat bij ontsluiting van informatie is het filteren van objectinformatie op basis van een taxonomisch hoger gelegen status (faceted search). Bijvoorbeeld het zoeken naar alleen "aanwezige" fysieke objecten. Wanneer dit niet mogelijk is bij ontsluiting, moet ik alle specifieke statussen in de vergunning en niet vergunningplichte aanwezigheidsfase kennen in opnemen in mijn filter. Dit komt de bruikbaarheid van de informatie niet ten goede. |
Neem een taxonomie van statussen op en maak deze functioneel. |
| 3.6.6 Levensfasen | Statussen met dezelfde term hebben een andere betekenis Momenteel zijn er statussen opgenomen waarvoor dezelfde term een andere definitie heeft. Dit is zeer onwenselijk voor begrip en voor juist gebruik. |
Indien mogelijk definities harmoniseren, of een andere term gebruiken. Ook hier zou gebruik gemaakt kunnen worden van een taxonomie van statussen, welke op verschillende niveaus bruikbaar zijn. |
| 4.2 Nieuwe versie van NEN 3610 als kader | De afbeelding van het NEN 3610 semantisch model komt niet overeen met de begrippen in de tabel daaronder. Bijvoorbeeld 'Hydrologie' staat wel in het diagram maar niet in de tabel. | Consistent maken. |
| 4.5 Beschrijving SOR-begrippen | Wat wordt bedoeld met 'verzamelbegrippen'? | Verduidelijken. |
| 4.5 Beschrijving SOR-begrippen | Onduidelijk scheiding tussen 'begrippen' en 'objecttypen': "Een aantal eigenschappen keren bij alle beschreven SOR-begrippen terug (zoals identificatie, geometrie, status en overige metagegevens)." | Maak onderscheid tussen begrippen, objecttypen en verschillende soorten metadata. |
| Hoofdstuk 5 en 6 (5.1 waterloop - watervlakte; 5.1.1 meer - plas - vijver; 5.2 bos - gras/kruidachtigen; 5.5.1 brug/aquaduct/viaduct - overkluizing;...) | Consistent gebruik van termen in de definities (van typeringen die onder dezelfde SOR-objecttypes vallen). Voorbeeld: waterloop is een ''verlaging in het terrein" en watervlakte een "verlaging in het aardoppervlak" - zijn terrein en aardoppervlak synoniemen hier? | Wanneer blijkt dat verschillende termen als synoniemen worden gebruikt in de tekst van de definities, een keuze maken. |
| Bij verschillende lijsten 'waarde status' | Wordt de term 'status' wel op dezelfde manier gebruikt? Verwijst dit naar de status van het object in de registratie (dit lijkt het geval te zijn voor functionele objecten), of gaat het om een soort fysieke status (zoals 'gesloopt' bij gebouwen)? | Verduidelijken |
| 5.2 Begroeiing | BGT gras type versimpelen lijkt een goed idee ('overig', 'agrarisch' komen meer functioneel over) | - |
| 5.2.1 Bos; 5.2.7 Moeras/Rietland/Heide | Vage definities - wat betekent "min of meer gesloten geheel", "merkbare toe- of afvloeiing"? | Dit is een aandachtspunt (zou beter onderzocht kunnen worden in de transitiefase) |
| 5.2.4 Onbegroeide grond | Verwarrend: onbegroeide grond lijkt gerelateerd te zijn van het NEN2610-2020 objecttype 'Bodem' (waarvan het ook de definitie heeft overgenomen), maar wordt in het document gevonden onder 5.2, de sectie over Begroeiing. | Geef het objecttype een eigen sectie, 5.X |
| 5.2.5 Gewas | "in gebruik als akker [..] kan tijdelijk braak liggen" klinkt niet reëel, dus het zou inderdaad als functioneel gezien kunnen worden | - |
| 5.2.6 Fruit- of kweekbomen | "in gebruik voor" klinkt functioneel, niet reël | Het begrip 'fruit of kweekbomen' herzien, of de definitie aanpassen |
| 5.2.7 Natuurlijk groen | Mist definitie | Definitie toevoegen |
| 5.3.5 Toegangsdeur | (Mogelijk) onjuiste koppeling tussen het begrip en het informatieobject "... toegang geeft tot een object." - geeft een deur echt toegang tot een object? | Definitie aanpassen |
| 5.5.4 Kerende kunstwerken | "Kunstwerk met mogelijk een kerende functie." lijkt te verwijzen naar een functioneel object | Begrip herzien, of de definitie aanpassen |
| 5.5.4 Kerende kunstwerken | Dijk opnemen als functioneel object om het principe te blijven volgen | - |
| 5.6.2 Hek | Het zou als één objecttype gezien kunnen worden: de definitie van 'hek' impliceert niet dat het geen raster kan zijn (de definities lijken elkaar niet uit te sluiten) | - |
| 5.6 Overige constructies (5.6.6 Putdeksel; 5.6.7 Depot; 5.6.8 Geleider…) | De definities lijken functioneel, Voorbeeld: "Putdeksel die toegang geeft tot…" | Begrippen hierzien, of definitie aanpassen |
| 5.6.5 Bak; 5.6.7 Depot; 5.6.14 Kast | Overlap in de definities | Begrippen hierzien, of definitie aanpassen |
| Bij ''waarde status" lijsten | Missende definities | Definities toevoegen |
| In hoofdstuk 5 en 6 | Inconsistente structuur van definities. Vaak worden directe definities gegeven (bv: "is een..."), maar soms worden de termen van de begripppen in de definities herhaald (bv: "een gracht is een...") | Definities aanpassen |
| 6.1.1 Weg, 6.1.2 Spoorweg, 6.1.3 Vaarweg, 6.1.4 Watersysteem | Mist definitie | Definitie toevoegen |
| 6.1.1 Weg (onder lijst "waarde type wegverbinding") | Betekent het begrip 'Weg' hier hetzelfde als in 6.1.1 Weg? | Begrippen herzien, of definitie aanpassen |
| 6.2.1 Verblijfsobject | Zinsopbouw van de definitie van 'verblijfsobject' klopt volgens mij niet | Definitie aanpassen |
| 6.2.1 Verblijfsobject (onder lijst "waarde feitelijk gebruik") | Is het wel de bedoeling om termen zoals hoekwoning, portiekflat, maisonnette (gebouwtyperingen) te groeperen met detailhandel, kantoor, horeca (functies)? | Verduidelijken |
| 6.3.1 Verkeerskundig functionele zone | Definitiescherpte en mogelijke overlap van definities: wat is de relatie tussen de begrippen parkeervlak, perkeerplaats en de term 'parkeergelegenheid'? | Verduidelijken |
| 6.4.1 Kering (onder lijsten ''waarde type'') | Mogelijk incomplete termen. Voorbeeld: "grond" als het over "grondkering" gaat | Termen (waarde namen) aanpassen |
| 6.4.3 Valbescherming | issue vergt meer aandacht, later weer bekijken | - |
| 7 Registratieve objecttypen | Het gaat bij bijna alle objecttypen die in dit hoofdstuk beschreven worden, met name om de begrenzing van de gebieden. Echter in de naamgeving van de objecttypen komt dit niet terug. Bijvoorbeeld 'Gemeente': gaat het om het bestuursorgaan, politieke bestuursapparaat, of het gebied dat bestuurd wordt? De definitie wijst op het laatste: 'afgebakend gedeelte van het grondgebied van Nederland'. | In de namen laten terugkomen dat het gaat om gebieden, bv 'Gemeentegrondgebied'. Dit laat ruimte voor andere registraties die met name het bestuursorgaan registreren. |
| 7.1.2 Provincie | Waarom geen relatie ligtIn met Rijk? | Toevoegen of argumenteren waarom niet. |
| 7.1.4 t/m 7.1.7 | De eigenschap 'landcode' hoort niet bij deze objecttypen, deze eigenschap is te vinden bij het Rijk. | vervangen door relatie 'ligtIn' Rijk, bij gemeenten kan dit indirect via de provincie. |
| 7.3 t/m 7.4 | Kan een wijk of buurt geen alternatieve naam hebben? | Zo ja deze toevoegen. |
| 7.6 Nummeraanduiding | Dit objecttype heeft geen geometrie eigenschap. Hoe kan het dan een registratief gebied zijn. Wordt een nummeraanduiding gezien als een afgebakend stukje Nederland, ook al wordt deze afbakening (geometrie) niet expliciet opgenomen in de registratie? Op basis van de definitie klinkt het meer als een eigenschap of een setje gegevens bij een verblijfsobject of benoemde plaats. Als het een geometrische representatie zou zijn, is dit misschien eerder een puntgeometrie dan een vlak, zoals je bij een registratief gebied zou verwachten. | Heroverwegen of dit wel een registratief gebied is. |
| 7.6 Nummeraanduiding | de ligt aan relatie: kan de openbare ruimte een weg of waterelement zijn, of kan dit alleen een weg zijn? | Zo mogelijk specifiek maken. |
| 8 Geografische gebieden | De toegestane waarden van Status bij geografische gebieden zijn inconsistent en onjuist geformuleerd. Bij bebouwde kom zijn maar twee waarden voor status opgenomen: aangewezen en ingetrokken. Bij Streek zijn het er veel meer. Het lijkt me niet dat geografische gebieden worden 'aangewezen', 'ingetrokken', 'verwijderd', 'gepland' en 'niet gerealiseerd'. Alleen 'bestaand' en wellicht 'historisch' lijken me zinnig. | Statussen van geografische gebieden herzien. |