Bestandsformaat: wat is NLCS++ precies?

Uitgangspunten voor attributen in NLCS++

Voor het uitwisselen van attribuutgegevens binnen de sector is de bestaande NLCS-standaard niet volledig dekkend. Naast netbeheerders en aannemers hebben ook andere partijen, zoals gemeenten (IMBOR) en stedelijk spoor, behoefte aan het kunnen meegeven en uitwisselen van attribuutdata. Een belangrijk uitgangspunt is dat NLCS onafhankelijk is van het gebruikte CAD-pakket. De oplossing voor attribuutdata moet daarom toepasbaar zijn binnen verschillende systemen, zoals AutoCAD, MicroStation en BricsCAD. Daarnaast moet de oplossing laagdrempelig zijn voor de deelnemende partijen. Met name aannemers zijn terughoudend in grote investeringen of ingrijpende technische veranderingen, waardoor eenvoud en toegankelijkheid essentieel zijn voor brede adoptie. De oplossing voor attribuutdata moet ook voorzien in het uitwisselen van keuzelijsten. Tegelijkertijd is het van belang dat de implementatie voor softwareleveranciers relatief eenvoudig blijft, zodat de uitbreiding op NLCS snel kan worden gerealiseerd en toegepast. Vrijwel alle netbeheerders en aannemers beschikken al over een DSP-oplossing voor aansluitingen, gebaseerd op XML.

De keuze voor het formaat van attribuutdata is gebaseerd op een vergelijking van verschillende criteria. In Tabel 1 worden de belangrijkste formaten met elkaar vergeleken.

Tabel 1: Vergelijking van mogelijke formaten voor attribuutdata binnen NLCS++ op basis van relevante criteria.

*AVRO is een framework dat onder andere schemadefinities voor JSON specificeert. Ondersteuning hiervoor is echter nog niet in alle veelgebruikte ontwikkelomgevingen standaard beschikbaar.

NLCS++ nader uitgelegd

Wat is de “++” in NLCS++?

NLCS++ is de benaming voor de uitbreiding op NLCS waarbij attribuutinformatie wordt toegevoegd aan de objecten in een NLCS-tekening. Waar in de traditionele NLCS veel informatie in de laagnaam wordt vastgelegd (zoals status, stelseltype, materiaal en diameter), maakt NLCS++ het mogelijk om deze informatie als gestructureerde attribuutdata op te slaan. Hierdoor groeit NLCS uit tot een standaard waarmee objecten zonder informatieverlies kunnen worden uitgewisseld. Dit verlengt de toepasbaarheid en toekomstbestendigheid van NLCS aanzienlijk. Daarnaast zorgt het gebruik van XML-attribuutinformatie ervoor dat laagnamen overzichtelijk blijven, omdat niet langer alle eigenschappen daarin hoeven te worden opgenomen. Een belangrijk voordeel is dat XML onafhankelijk is van het gebruikte CAD-pakket. Alternatieven zoals AutoCAD Xdata zijn daarom niet geschikt, omdat deze software-specifiek zijn. NLCS++ is ontwikkeld vanuit de behoefte van netbeheerders om volledige assetinformatie uit te wisselen, maar is ook toepasbaar voor andere domeinen, zoals gemeentelijk beheer (IMBOR) en riolering (GWSW).

Het verschil tussen traditionele NLCS en NLCS++ wordt geïllustreerd in Figuur 1 en Figuur 2. Dit verschil laat zien hoe NLCS++ (Figuur 2) zorgt voor een duidelijkere scheiding tussen geometrie en attribuutdata en daarmee de uitwisselbaarheid en kwaliteit van gegevens verbetert.

Open

Figuur 1: Weergave van traditionele NLCS waarbij attributen zoals status, stelseltype, materiaal en diameter zijn opgenomen in de laagnaam.

Open

Figuur 2: Weergave van NLCS++ waarbij attribuutinformatie, inclusief keuzelijsten, gestructureerd wordt opgeslagen buiten de laagnaam, waardoor informatieverlies wordt voorkomen.

Uitgangspunten

Het gebruik van XML-attribuutdata binnen NLCS++ is optioneel en wordt bepaald door de samenwerkende partijen. Dit betekent dat NLCS++ geen verplichting oplegt, maar een uitbreidingsmogelijkheid biedt. Partijen maken onderling afspraken over toepassing en invulling. De structuur van de attribuutdata wordt vastgelegd in een XSD (XML Schema Definition). Deze beschrijft de attributen en bijbehorende keuzelijsten. XSD’s kunnen door partijen zelf worden opgesteld, maar bij voorkeur worden branchegerichte standaarden gebruikt, zoals:

• IMBOR (gemeenten)

• GWSW (riolering)

• NLCS Netbeheer (ondergrondse infrastructuur)

Binnen de XSD zijn naam en versienummer vastgelegd, waardoor versiebeheer mogelijk is. Elke asset in de tekening correspondeert met één record in het XML-bestand. De structuur is bewust eenvoudig gehouden, zodat implementatie in software laagdrempelig blijft.

Praktische invulling van XML/XSD

Open

Figuur 3: Voorbeeld van de bestandsstructuur binnen NLCS++, waarbij een CAD-tekening (.dwg) wordt gecombineerd met een XML-bestand (.xml) en bijbehorende XSD-definitie voor attribuutdata.

In de praktijk wordt attribuutinformatie als volgt gekoppeld aan een NLCS-tekening:

• Het XML-bestand heeft dezelfde naam als het CAD-bestand, maar met de extensie .xml (zie Figuur 3)

• Bijschriften en maatvoering worden niet als assets beschouwd en krijgen dus geen XML-data

• Elke asset wordt gekoppeld aan een XML-record via de handle (unieke sleutel binnen de CAD-tekening)

• De handle is daarom een verplicht attribuut in het XML-bestand

Optioneel kan ook de geometrie in XML worden opgenomen. Dit maakt het verwerken van revisies in GIS-systemen eenvoudiger. Voor bestaande objecten wordt aanbevolen om een unieke identificatie (bij voorkeur een AssetID) mee te geven. Hierdoor kunnen objecten bij revisieverwerking betrouwbaar worden herkend.

Hoewel sommige CAD-systemen (zoals AutoCAD) attribuutdata in blocks kunnen opslaan, wordt deze aanpak niet gebruikt. NLCS++ kiest bewust voor een CAD-onafhankelijke oplossing.

Benodigde functionaliteit in NLCS-software ten behoeve van NLCS++

Om NLCS++ effectief te kunnen ondersteunen, moet CAD-software beschikken over aanvullende functionaliteit voor het verwerken, bewerken en uitwisselen van attribuutdata. Deze functionaliteit kan worden onderverdeeld in kernfunctionaliteit en optionele uitbreidingen.

Kernfunctionaliteit

Gegevensuitwisseling en koppeling

• Lezen en schrijven van XML- en XSD-bestanden

• Gebruik van de handle als verbindende schakel tussen CAD-object en XML-record

• Ondersteuning voor het opnemen van geometrie in het XML-bestand en XSD

Attribuutbeheer

• Weergeven en bewerken van attribuutinformatie

• Ondersteuning voor keuzelijsten zoals gedefinieerd in de XSD

• Consistent houden van attributen en laagnaam (status, bedrijfstoestand, bewerking en subgroepen) tijdens het editen

NLCS-specifieke ondersteuning

• Ondersteuning voor status, bedrijfstoestand en bewerking (zowel in laagnaam als in attributen)

• Gebruik van hoofd- en kleine letters in laagnamen toestaan

• Ondersteuning voor bijschriften bij tracés (zoals AmantelbuisInhoud)

• Ondersteuning voor incourante materialen

Bewerking van objecten

• Bij splitsen van objecten: behoud van attribuutdata voor beide delen

• Bij samenvoegen van objecten: mogelijkheid voor gebruiker om te kiezen welke attributen behouden blijven

• Bij (gedeeltelijk) verplaatsen van objecten: correcte verwerking van geometrie en bijbehorende attributen

Configuratie

• Vastleggen van de relatie tussen NLCS-laagnaam en object in het informatiemodel

• Mogelijkheid om deze relatie voor een volledige subboom in één keer in te stellen

• Vastleggen van de relatie tussen attributen en onderdelen van de laagnaam (subgroepen)

Optionele functionaliteit

• Gelijktijdig bewerken van attribuutdata van meerdere objecten van hetzelfde type

• Controle op logische combinaties van attribuutwaarden

• Visualisatie van mantelbuizen als brede lijn

Bijlagen

Aanvullende documentatie bij dit model omvat:

• Vergelijking van overwogen standaarden

• Achtergrond en totstandkoming van het model

• Onderbouwing van keuzes voor incourante materialen en typen

• Overzicht van deliverables

Vergelijking beschikbare standaarden

In Tabel 2 is een vergelijking opgenomen van verschillende standaarden voor het vastleggen en uitwisselen van kabel- en leidinggegevens, waaronder NLCS, IMKL en NLCS++. Hierbij is gekeken naar bruikbaarheid in ontwerpomgevingen, ondersteuning van attribuutdata en geschiktheid voor uitwisseling van ontwerp- en revisiegegevens.

Tabel 2: Vergelijking van standaarden voor uitwisseling van kabel- en leidinggegevens (NLCS, IMKL en NLCS++)

*NLCS++: NLCS aangevuld met XML voor attribuutgegevens. Voor kabels en leidingen kunnen de attribuutgegevens worden gebaseerd op IMKL, eventueel met aanvullingen.

**Wens Alliander: doorgroei naar een XML-only oplossing.

Hoe gaan we om met incourante types?

Voor het omgaan met incourante types binnen NLCS++ zijn verschillende oplossingsrichtingen onderzocht. Deze verschillen in de wijze waarop type-informatie wordt vastgelegd in de laagnaam en/of attribuutdata, en in de mate waarin flexibiliteit en beheersbaarheid worden ondersteund. In Tabel 4 zijn de belangrijkste oplossingsrichtingen met hun voor- en nadelen weergegeven. Scenario 1 is op basis van deze afweging als voorkeursscenario geselecteerd en is als zodanig in het informatiemodel verwerkt.

Tabel 4: Vergelijking van oplossingsrichtingen voor het omgaan met incourante types binnen NLCS++.

Deliverables

• InformatiemodelNetbeheerV12.xlsx: mapping van de datamodellen (van Alliander, Stedin en Enexis) en IMKL op het Netbeheer-informatiemodel op attribuutniveau

• Domains_InformatiemodelNetbeheerV12.xls: bevat alle keuzelijsten (Elektra, Gas, Telecom) van Alliander, Stedin en Enexis, inclusief de relatie tussen keuzelijsten en attributen

• NLCS_NetbeheerAllianderV11Import.xsd: XSD die het informatiemodel beschrijft voor Alliander

• NLCS_NetbeheerAllianderV11Import_Keuzelijst.xsd: XSD met keuzelijsten voor Alliander

• NLCS_NetbeheerStedinV11Import.xsd: XSD die het informatiemodel beschrijft voor Stedin

• NLCS_NetbeheerStedinV11Import_Keuzelijst.xsd: XSD met keuzelijsten voor Stedin

• NLCS_NetbeheerEnexisV11Import.xsd: XSD die het informatiemodel beschrijft voor Enexis

• NLCS_NetbeheerEnexisV11Import_Keuzelijst.xsd: XSD met keuzelijsten voor Enexis

• Informatiemodel_NetbeheerE_G_Oplevering_V12.pptx: presentatie met achtergronden, ontwerpkeuzes, toelichting op NLCS++ en een overzicht van openstaande punten

Overzicht restpunten

De volgende keuzelijsten zijn nog niet compleet of vertonen inconsistenties in opbouw:

• UitvoeringMSmof: Stedin-waarden ontbreken

• MateriaalMantelbuis: Stedin-waarden opschonen, bevat nog incourante types

• UitvoeringAftakzadel: Stedin-waarden opschonen, bevat ook T-stukken e.d.

• UitvoeringOvergangsstukGas: Stedin-waarden ontbreken

• UitvoeringHSKabel en OpbouwHSKabel: Stedin-types ontbreken

• UitvoeringHSMof: Stedin-waarden ontbreken

• Aardingssysteem: Stedin-waarden ontbreken

• TypeLSMof: Stedin-waarden ontbreken