Publicatie van bedrijfstoestand in NLCS publicatie / objectentabellen; onderdeel van veld BEWERKING

[ElisabethKloren]

Conform het besluit in issue #371 in deze issue de voorgestelde uitwerking in de NLCS Database ter review door de developers van de softwareleveranciers.

Uitgangspunten

1. Voor in Reserve en Verlaten hebben alle ELEMENTEN dezelfde kleur, linetype en lineweight. Er komen daarmee drie attributen bij voor elke combinatie van een status en een bedrijfstoestand

Eisen aan applicaties
3. De gebruiker moet voor objecten waar deze attributen zijn ingevuld twee picklisten krijgen bij het tekenen van een object of bij het wijzigen van de laagnaam: de status en de bedrijfstoestanden, waarbij als default "in gebruik" geselecteerd is (NB: eventueel kan als service naar de gebruikers de BEWERKING ook worden aangeboden als picklist; ook al staat dat in de database als onderliggende) laagnaam;
4. de gebruiker moet bij een status alleen de keuze krijgen om een bedrijfstoestand in te voeren, als deze attributen bij dit object staan ingevuld. Bijvoorbeeld: bij T en X komt geen bedrijfstoestand voor in de tabellen van netbeheer.
5. De gebruiker moet bij het tekenen van andere objecten maar één picklist krijgen, voor de huidige NLCS gebruikers die de buitenruimte tekent veranderd er in principe niks.
6. Na het selecteren van de status en bedrijfstoestand moeten deze op de juiste plek in de laagnaam worden gezet:

• Er komen twee soorten dingen in het veld bewerking te staan: [bedrijfstoestand] en BEWERKING;
• Scheidingsteken: onderliggend streepje = underscore alleen gebruiken als er zowel een bedrijfstoestand als een BEWERKING is
• bedrijfstoestand altijd tussen blokhaken plaatsen (wat: OP DE KOP = bewerking met spaties)
• De bedrijfstoestand wordt voluit geschreven, voorbeeld: N-**-KL-BRANDSTOF_TRANSPORTLEIDING_STAAL-[RESERVE]_VOLSCHUIMEN-G

In de publicatie kun je dus deze extra attributen verwachten.
De standaard attributen

Status	Bedrijfstoestand: In Gebruik	Bedrijfstoestand: Reserve	Bedrijfstoestand: Verlaten
B	lw_b,kl_b,kl_b_a,kl_b_gd,kl_b_gn,kl_b_v,lt_b	lw_b_[RESERVE],kl_b_[RESERVE],lt_b_[RESERVE]	lw_b_[VERLATEN],kl_b_[VERLATEN],lt_b_[VERLATEN]
N	lw_n,kl_n,kl_n_a,kl_n_gd,kl_n_gn,kl_n_v,lt_n	lw_n_[RESERVE],kl_n_[RESERVE],lt_n_[RESERVE]	lw_n_[VERLATEN],kl_n_[VERLATEN],lt_n_[VERLATEN]
V	lw_v,kl_v,kl_v_a,kl_v_gd,kl_v_gn,kl_v_v,lt_v	lw_v_[RESERVE],kl_v_[RESERVE],lt_v_[RESERVE]	lw_v_[VERLATEN],kl_v_[VERLATEN],lt_v_[VERLATEN]
T	lw_t,kl_t,kl_t_a,kl_t_gd,kl_t_gn,kl_t_v,lt_t	niet van toepassing	niet van toepassing
X	niet van toepassing	niet van toepassing	niet van toepassing
R	Lagen met de STATUS “R” moeten dezelfde eigenschappen krijgen als lagen met de STATUS “N”.	Lagen met de STATUS “R” moeten dezelfde eigenschappen krijgen als lagen met de STATUS “N”.	Lagen met de STATUS “R” moeten dezelfde eigenschappen krijgen als lagen met de STATUS “N”.

[ElisabethKloren]

Gestuurd aan de experts van leveranciers,

Zoals beloofd een voorstel van mijn kant hoe we de bedrijfstoestanden van de netbeheerder kunnen opnemen in de NLCS database, zodat jullie bij je developers kunnen checken of dit inderdaad geprogrammeerd kan worden. Het voorstel staat in deze issue: #461

Ik ben zo dit mogelijk bij de originele vorm van de NLCS database gebleven, waarbij alleen extra kolommen zijn toegevoegd in de database. Graag jullie feedback over de voorgestelde oplossing.

[FrankvdHeijden]

Opname bedrijfstoestand in NLCS database

“Voor in Reserve en Verlaten hebben alle ELEMENTEN dezelfde kleur, linetype en lineweight. Er komen daarmee drie attributen bij voor elke combinatie van een status en een bedrijfstoestand”

• Wenselijk is om hier meer database velden beschikbaar te hebben vergelijkbaar met overige NLCS kenmerken;
  Onderbouwing: Kleur kan afhankelijk zijn van netvlak/spanningsniveau; zou ook kunnen gelden voor lijntype (onderscheid in ieder geval voor RESERVE en VERLATEN en mogelijk ook LS MS HS)

Gebruikersfunctionaliteit in software voor “bedrijfstoestand”

3. De gebruiker moet voor objecten waar deze attributen zijn ingevuld twee picklisten krijgen bij het tekenen van een object of bij het wijzigen van de laagnaam: de status en de bedrijfstoestanden, waarbij als default "in gebruik" geselecteerd is
(NB: eventueel kan als service naar de gebruikers de BEWERKING ook worden aangeboden als picklist; ook al staat dat in de database als onderliggende) laagnaam;

• Voor de toepassing van de “bedrijfstoestand” moet de gebruiker in staat zijn om op basis van een voor gedefinieerde lijst (=picklist) de bedrijfstoestand kunnen selecteren voor objecten. Daarnaast moet de bedrijfstoestand per object of over selecties van meerdere objecten gewijzigd kunnen worden.

Voor status geldt dat deze functionaliteit reeds bestaat en uiteraard moet blijven bestaan

Toepassing van “bedrijfstoestand” voor specifieke NLCS statussen

4. de gebruiker moet bij een status alleen de keuze krijgen om een bedrijfstoestand in te voeren, als deze attributen bij dit object staan ingevuld. Bijvoorbeeld: bij T en X komt geen bedrijfstoestand voor in de tabellen van netbeheer.

• “TIJDELIJK” kan voorkomen voor netbeheer, X kan uberhaupt door een gebruiker niet worden gekozen. Daarmee vervalt bovenstaande regel.

Toepassing van “bedrijfstoestand” voor specifieke hoofdgroepen

5. De gebruiker moet bij het tekenen van andere objecten maar één picklist krijgen, voor de huidige NLCS gebruikers die de buitenruimte tekent veranderd er in principe niks.

• Voorgestelde aanscherping; Regel zegt hier eigenlijk: “De toepassing voor een bedrijfstoestand wordt enkel toegepast op objecten waarvoor dit is ingeregeld (voor nu zal dit neerkomen op enkel objecten uit de hoofdgroep KL)”

Opmerking over blokhaken:

6. Na het selecteren van de status en bedrijfstoestand moeten deze op de juiste plek in de laagnaam worden gezet:
Er komen twee soorten dingen in het veld bewerking te staan: [bedrijfstoestand] en BEWERKING;
Scheidingsteken: onderliggend streepje = underscore alleen gebruiken als er zowel een bedrijfstoestand als een BEWERKING is
bedrijfstoestand altijd tussen blokhaken plaatsen (wat: OP DE KOP = bewerking met spaties)
De bedrijfstoestand wordt voluit geschreven, voorbeeld: N-**-KL-BRANDSTOF_TRANSPORTLEIDING_STAAL-[RESERVE]_VOLSCHUIMEN-G

Probleembeschrijving
Gebruik van de tekens “[” en “]” in verband met de herkenbaarheid van de bedrijfstoestand in de laagnaam geeft geen eenduidige resultaten in bijvoorbeeld layer filters binnen AutoCAD.

Beschrijving
De tekens “[” en “]” hebben betekenis in AutoCAD.
Bij het gebruik van layer filters in AutoCAD is het resultaat niet zoals verwacht wanneer letterlijk “[VERPLAATSEN]” wordt toegepast.

Vanuit de documentatie van Autodesk ten aanzien van karakters [ ]:
[...] Matches any one of the characters enclosed
[~...] Matches any single character not enclosed

Voorbeeld: [ABC] geeft laag “A” en “C” als resultaat terug

Voorstel
Deze karakters in verband met de zuiverheid en conflicterende functionaliteit in (in ieder geval) AutoCAD niet te gebruiken en “bedrijfstoestanden” volgens voorstel Sander met vaste lijst te beschrijven.

Onderbouwing:
Met de onderbouwing “altijd als eerste object” voor bedrijfstoestand binnen de NLCS bewerkingen wordt het kenmerk altijd voorafgegaan met een “-” en beëindigd met “ ” of “_”
Daarnaast is de lijst beperkt tot bekende waarden en is daarmee te documenteren.
Filtering is dus met bovenstaande sowieso mogelijk.

[ElisabethKloren]

Opname bedrijfstoestand in NLCS database

“Voor in Reserve en Verlaten hebben alle ELEMENTEN dezelfde kleur, linetype en lineweight. Er komen daarmee drie attributen bij voor elke combinatie van een status en een bedrijfstoestand”

• Wenselijk is om hier meer database velden beschikbaar te hebben vergelijkbaar met overige NLCS kenmerken;
  Onderbouwing: Kleur kan afhankelijk zijn van netvlak/spanningsniveau; zou ook kunnen gelden voor lijntype (onderscheid in ieder geval voor RESERVE en VERLATEN en mogelijk ook LS MS HS)

Dit klopt, de kleuren kunnen per NLCS-Object verschillen, er zijn verschillende objecten voor LS MS HS enzovoorts. De zin zegt alleen maar dat de kleuren worden toegepast op alle ELEMENTEN (G/A/S en alle andere). Voorgestelde nieuwe tekst:

Een NLCS Objecten waarop de bedrijfstoestand van toepassing is krijgt per combinatie van een status en een bedrijfstoestand drie extra attributen: kleur, linetype en lineweight. Deze attributen zijn van toepassing op alle ELEMENTEN

[ElisabethKloren]

Gebruikersfunctionaliteit in software voor “bedrijfstoestand”

3. De gebruiker moet voor objecten waar deze attributen zijn ingevuld twee picklisten krijgen bij het tekenen van een object of bij het wijzigen van de laagnaam: de status en de bedrijfstoestanden, waarbij als default "in gebruik" geselecteerd is
(NB: eventueel kan als service naar de gebruikers de BEWERKING ook worden aangeboden als picklist; ook al staat dat in de database als onderliggende) laagnaam;

• Voor de toepassing van de “bedrijfstoestand” moet de gebruiker in staat zijn om op basis van een voor gedefinieerde lijst (=picklist) de bedrijfstoestand kunnen selecteren voor objecten. Daarnaast moet de bedrijfstoestand per object of over selecties van meerdere objecten gewijzigd kunnen worden.

Voor status geldt dat deze functionaliteit reeds bestaat en uiteraard moet blijven bestaan

akkoord, laatste zin komt er bij in de tekst.

[ElisabethKloren]

Toepassing van “bedrijfstoestand” voor specifieke NLCS statussen

4. de gebruiker moet bij een status alleen de keuze krijgen om een bedrijfstoestand in te voeren, als deze attributen bij dit object staan ingevuld. Bijvoorbeeld: bij T en X komt geen bedrijfstoestand voor in de tabellen van netbeheer.

• “TIJDELIJK” kan voorkomen voor netbeheer, X kan uberhaupt door een gebruiker niet worden gekozen. Daarmee vervalt bovenstaande regel.

Akkoord, dat betekent dat de tabel extra attributen krijgt

Status	Bedrijfstoestand: In Gebruik	Bedrijfstoestand: Reserve	Bedrijfstoestand: Verlaten
B	lw_b,kl_b,kl_b_a,kl_b_gd,kl_b_gn,kl_b_v,lt_b	lw_b_RESERVE,kl_b_RESERVE,lt_b_RESERVE	lw_b_VERLATEN,kl_b_VERLATEN,lt_b_VERLATEN
N	lw_n,kl_n,kl_n_a,kl_n_gd,kl_n_gn,kl_n_v,lt_n	lw_n_RESERVE,kl_n_RESERVE,lt_n_RESERVE	lw_n_VERLATEN,kl_n_VERLATEN,lt_n_VERLATEN
V	lw_v,kl_v,kl_v_a,kl_v_gd,kl_v_gn,kl_v_v,lt_v	lw_v_RESERVE,kl_v_RESERVE,lt_v_RESERVE	lw_v_VERLATEN,kl_v_VERLATEN,lt_v_VERLATEN
T	lw_t,kl_t,kl_t_a,kl_t_gd,kl_t_gn,kl_t_v,lt_t	lw_t_RESERVE,kl_t_RESERVE,lt_t_RESERVE	lw_t_VERLATEN,kl_t_VERLATEN,lt_t_VERLATEN
X	niet van toepassing	niet van toepassing	niet van toepassing
R	Lagen met de STATUS “R” moeten dezelfde eigenschappen krijgen als lagen met de STATUS “N”.	Lagen met de STATUS “R” moeten dezelfde eigenschappen krijgen als lagen met de STATUS “N”.	Lagen met de STATUS “R” moeten dezelfde eigenschappen krijgen als lagen met de STATUS “N”.

[ElisabethKloren]

Toepassing van “bedrijfstoestand” voor specifieke hoofdgroepen

5. De gebruiker moet bij het tekenen van andere objecten maar één picklist krijgen, voor de huidige NLCS gebruikers die de buitenruimte tekent veranderd er in principe niks.

• Voorgestelde aanscherping; Regel zegt hier eigenlijk: “De toepassing voor een bedrijfstoestand wordt enkel toegepast op objecten waarvoor dit is ingeregeld (voor nu zal dit neerkomen op enkel objecten uit de hoofdgroep KL)”

Akkoord

[ElisabethKloren]

Opmerking over blokhaken:

6. Na het selecteren van de status en bedrijfstoestand moeten deze op de juiste plek in de laagnaam worden gezet:
Er komen twee soorten dingen in het veld bewerking te staan: [bedrijfstoestand] en BEWERKING;
Scheidingsteken: onderliggend streepje = underscore alleen gebruiken als er zowel een bedrijfstoestand als een BEWERKING is
bedrijfstoestand altijd tussen blokhaken plaatsen (wat: OP DE KOP = bewerking met spaties)
De bedrijfstoestand wordt voluit geschreven, voorbeeld: N-**-KL-BRANDSTOF_TRANSPORTLEIDING_STAAL-[RESERVE]_VOLSCHUIMEN-G

Probleembeschrijving Gebruik van de tekens “[” en “]” in verband met de herkenbaarheid van de bedrijfstoestand in de laagnaam geeft geen eenduidige resultaten in bijvoorbeeld layer filters binnen AutoCAD.

Beschrijving De tekens “[” en “]” hebben betekenis in AutoCAD. Bij het gebruik van layer filters in AutoCAD is het resultaat niet zoals verwacht wanneer letterlijk “[VERPLAATSEN]” wordt toegepast.

Vanuit de documentatie van Autodesk ten aanzien van karakters [ ]: [...] Matches any one of the characters enclosed [~...] Matches any single character not enclosed

Voorbeeld: [ABC] geeft laag “A” en “C” als resultaat terug

Voorstel Deze karakters in verband met de zuiverheid en conflicterende functionaliteit in (in ieder geval) AutoCAD niet te gebruiken en “bedrijfstoestanden” volgens voorstel Sander met vaste lijst te beschrijven.

Onderbouwing: Met de onderbouwing “altijd als eerste object” voor bedrijfstoestand binnen de NLCS bewerkingen wordt het kenmerk altijd voorafgegaan met een “-” en beëindigd met “ ” of “_” Daarnaast is de lijst beperkt tot bekende waarden en is daarmee te documenteren. Filtering is dus met bovenstaande sowieso mogelijk.

Akkoord om blokhaken te laten vervallen. In de database zijn bij sommige objecten extra attributen te vinden met daarin de naam van de bedrijfstoestand; er wordt ook een lijst met bedrijfstoestanden gepubliceerd. Dat moet voldoende zijn voor automatisering.

[SanderNijhof]

Graag jullie feedback over de voorgestelde oplossing.

Gezien de onduidelijke omvang van nog uit te werken bedrijfstoestanden en bewerkingen, zou mijn voorstel zijn om minimale wijzigingen aan de database te doen, totdat er meer duidelijkheid is over wat en hoe e.e.a. het beste te implementeren is.

Mijn voorstel is om vanuit de database per object alleen te verwijzen naar een picklist, zijnde bijvoorbeeld een .txt of een .csv bestand met daarin de regels voor en inhoud van de picklist. De .csv bestanden zijn makkelijker te testen en snel aan te passen als dat nodig blijkt.
Als eenduidig de inhoud van de picklisten en de inhoud van het veld BEWERKING in combinatie met de bijbehorende objecten en status voor iedereen goed werkt, dan kan ook duidelijker gekeken worden of en hoe e.e.a. definitief in de database opgenomen kan worden.

Dit lijkt mij voor de software leveranciers ook het meest praktische, maar dat kan ik ook helemaal verkeerd inschatten 🧐.

[ElisabethKloren]

trouwens gebruiken we beter leesbare attibuutvelden in de linked data publicatie, de extra informatie-attributen worden:
(edit had per ongeluk R ipv V aangemaakt)

a. B color RESERVE
b. B linetype RESERVE
c. B lineweight RESERVE
d. N color RESERVE
e. N linetype RESERVE
f. N lineweight RESERVE
g. T color RESERVE
h. T linetype RESERVE
i. T lineweight RESERVE
j. V color RESERVE
k. V linetype RESERVE
l. V lineweight RESERVE
m. B color VERLATEN
n. B linetype VERLATEN
o. B lineweight VERLATEN
p. N color VERLATEN
q. N linetype VERLATEN
r. N lineweight VERLATEN
s. T color VERLATEN
t. T linetype VERLATEN
u. T lineweight VERLATEN
v. V color VERLATEN
w. V linetype VERLATEN
x. V lineweight VERLATEN

[SanderNijhof]

trouwens gebruiken we beter leesbare attibuutvelden in de linked data publicatie, de extra informatie-attributen worden:

Oh ja?
Dat strookt niet met wat besproken is over variabele terminologie per hoofdgroep. Volgens mij moet er nog een methodiek uitgewerkt worden. Ik begrijp daarom niet hoe bovenstaande al in de linked data kan worden opgenomen. Dat kan helemaal nog niet. Kun je me uitleggen wat de impact hiervan is?

[ElisabethKloren]

trouwens gebruiken we beter leesbare attibuutvelden in de linked data publicatie, de extra informatie-attributen worden:

Oh ja? Dat strookt niet met wat besproken is over variabele terminologie per hoofdgroep. Volgens mij moet er nog een methodiek uitgewerkt worden. Ik begrijp daarom niet hoe bovenstaande al in de linked data kan worden opgenomen. Dat kan helemaal nog niet. Kun je me uitleggen wat de impact hiervan is?

als er andere bedrijfstoestanden bijkomen dan moet hiervoor eigen attribuutvelden worden opgenomen, dit zijn de attribuutvelden voor de bedrijfstoestanden van netbeheer.

[Han-Loermans]

Vanuit onze software ontwikkelaars heb ik de volgende feedback gekregen:

• Blokhaken zijn inderdaad niet wenselijk om toe te passen. Het maakt het wel lastiger of een losse bewerking of bedrijfstoestand wordt bedoeld en alleen te herleiden naar een voorgedefinieerde lijst. Dit maakt de NLCS vervolgens inflexibel en minder geschikt voor andere doelgroepen die ook zoiets willen toepassen.

• Het kunnen instellen van kleuren, lijntypes en diktes per bedrijfstoestand per status en per object, en eventueel sub-object is iets heel complex, mogelijk kan voor een bedrijfstoestand een vast lijntype worden gedefinieerd (zoals nu bij Vervallen ook het geval is?)

• Omdat er vanuit een vaste lijst wordt gewerkt met als start de zaken vanuit de netbeheerders. Wat te doen met personen/bedrijven die zelf toevoegingen aan deze lijst maken (als test of als projectbibliotheek). Wordt dit dan vooralsnog aangemerkt als afwijking?

[ElisabethKloren]

EC 3 okt 2024:

• herkenning van bedrijfstoestand in de laagnaamtekst: er moet een ander symbool benoemd worden (actie Frank)
• generieke oplossing is wel het lijntype publiceren; omdat als er een tekening wordt gemaakt met meerdere soorten netten moet je dit kunnen onderscheiden
• derde inbrengpunt van Han wordt in een vervolgsessie opgepakt.

[SanderNijhof]

• herkenning van bedrijfstoestand in de laagnaamtekst: er moet een ander symbool benoemd worden (actie Frank)

Als we onderscheid maken tussen velden in de NLCS-laagnaam, dan doen we dat met '-' of '_' dus:
STATUS-DISCIPLINE-HOOFDGROEP-OBJECT_SUBOBJ1_SUBOBJ2_SUBOBJ3_SUBOBJ4_SUBOBJ5-BEDRIJFSTOESTAND-BEWERKING-ELEMENT-SCHAAL
of
STATUS-DISCIPLINE-HOOFDGROEP-OBJECT_SUBOBJ1_SUBOBJ2_SUBOBJ3_SUBOBJ4_SUBOBJ5-BEDRIJFSTOESTAND_BEWERKING-ELEMENT-SCHAAL
Dan houdt je het onderscheiden binnen de laagnaamstructuur uniform. De inhoud van BEDRIJFSTOESTAND en BEWERKING moeten sowieso gekoppeld zijn aan lijsten en kunnen dus altijd herkend worden, tenzij het voorkomt dat de inhoud van BEDRIJFSTOESTAND en BEWERKING tekstueel gelijk zijn, maar dat lijkt me heel sterk. Bovendien hebben we dat zelf in de hand.

• generieke oplossing is wel het lijntype publiceren; omdat als er een tekening wordt gemaakt met meerdere soorten netten moet je dit kunnen onderscheiden

1. om hoeveel/welke lijntypes gaat het dan?
   En hoe gaat dat werken? Bijvoorbeeld:
   N-OI-KL-GAS-G
   Die is duidelijk: Hier bepaald het object icm met de status de laag eigenschappen.
   N-OI-KL-GAS-IN RESERVE STELLEN-G
   Hier bepaald 'IN RESERVE STELLEN' de laag eigenschappen? of 'GAS' of de combinatie van 'GAS' + 'IN RESERVE STELLEN'? en 'STATUS' kan alleen 'N' zijn ? of ook 'R' ?
   N-OI-KL-GAS-RESERVE-G
   Zelfde vraag: Hier bepaald 'RESERVE' de laag eigenschappen? of 'GAS' of de combinatie van 'GAS' + 'RESERVE'? en 'STATUS' kan 'B', 'N', 'R', of 'V' zijn?
   B-OI-KL-GAS-RESERVE_IN GEBRUIK STELLEN-G
   Hier nog meer mogelijkheden: Bepaald 'RESERVE' de laag eigenschappen? of 'GAS' of de combinatie van 'GAS' + 'RESERVE'? Of de combinatie van 'GAS' + 'RESERVE' + 'INGEBRUIK STELLEN'?
   Hoe hebben jullie dit bedacht en beschreven?

2. hoe moeten die lijntypes eruit zien? Gaat het dan bijv. om het standaardlijntype van een gasleiding met een symbool/letter daaraan toegevoegd? Of om compleet afwijkende lijntypes? Blijft dit leesbaar op tekeningen waar kabels en leidingen dicht op elkaar liggen.

• Omdat er vanuit een vaste lijst wordt gewerkt met als start de zaken vanuit de netbeheerders. Wat te doen met personen/bedrijven die zelf toevoegingen aan deze lijst maken (als test of als projectbibliotheek). Wordt dit dan vooralsnog aangemerkt als afwijking?

Voor mij heel duidelijk: eigen toevoegingen hierop zijn niet toegestaan en worden daarom aangemerkt als "fout! of ongeldig". Dus niet als afwijking.
Toelichting: Dit valt in dezelfde categorie als zelf STATUSSEN of ELEMENTEN toevoegen. Het is alleen toegestaan OBJECTEN en SUBOBJECTEN toe te voegen. Inhoud van de overige laagnaam onderdelen worden bepaald door de NLCS-standaard. Dit is noodzakelijk voor automatische verwerking en uniforme uitwisseling.

[ElisabethKloren]

Vanuit onze software ontwikkelaars heb ik de volgende feedback gekregen:

• Blokhaken zijn inderdaad niet wenselijk om toe te passen. Het maakt het wel lastiger of een losse bewerking of bedrijfstoestand wordt bedoeld en alleen te herleiden naar een voorgedefinieerde lijst. Dit maakt de NLCS vervolgens inflexibel en minder geschikt voor andere doelgroepen die ook zoiets willen toepassen.
• Het kunnen instellen van kleuren, lijntypes en diktes per bedrijfstoestand per status en per object, en eventueel sub-object is iets heel complex, mogelijk kan voor een bedrijfstoestand een vast lijntype worden gedefinieerd (zoals nu bij Vervallen ook het geval is?)
• Omdat er vanuit een vaste lijst wordt gewerkt met als start de zaken vanuit de netbeheerders. Wat te doen met personen/bedrijven die zelf toevoegingen aan deze lijst maken (als test of als projectbibliotheek). Wordt dit dan vooralsnog aangemerkt als afwijking?

Reply van frank:

1. Beschrijving in de “Formele Beschrijving“ gewenst over de toepassing van “BEDRIJFSTOESTAND” & “BEWERKINGEN”. Expert-commissie is hiervoor verantwoordelijk.
   Functionele eisen:

• Bewerkingen en bedrijfstoestanden mogen nooit dezelfde naamgeving hebben om verwarring te voorkomen. Onderscheid maken in naamgeving voor toekomstige actie (bewerking) en Bedrijfstoestand de actuele toestand. (voorbeeld “TE VERLATEN” & “VERLATEN”)

2. De bedrijfstoestand “VERLATEN” (in PMKL “Buiten Gebruik”) heeft voor wat betreft NLCS Netbeheer een vaste presentatie in de vorm van een lijnstijl (idem voor Bedrijfstoestand “RESERVE”). Voor NLCS netbeheer lijkt hierdoor de presentatie in de vorm van een vaste lijnstijl / kleur afdoende.
   Actie: Inschatting maken over de impact voor andere toepassingen / disciplines.

Functionele eisen:

• Visueel onderscheid voor de toepassing van BEDRIJFSTOESTAND op basis van lijntype overeenkomstig met presentatie zoals beschreven in PMKL
• Kleurgebruik volgens PMKL voor onderscheid netvlak

3. Betreft hier eigenlijk een software vraag. Voorstel is hier om dit vast te leggen in de standaard waarbij BEDRIJFSTOESTANDEN per hoofdgroep worden vastgelegd. Daarmee wordt geborgd dat definities eenduidig worden toegepast.

Functioneel is benodigd voor NLCS Netbeheer:

• Uitbreiding gewenst in “Formele Beschrijving” voor vaste bedrijfstoestanden per hoofdgroep. Controle functionaliteit moet hier rekening mee houden.
• Software oplossing: Functionaliteit gewenst waarbij onderscheid wordt gemaakt waarbij controle wordt uitgevoerd op aanwezigheid in bepaalde bibliotheken (NLCS en/of Project-bibliotheek bijvoorbeeld)

[SanderNijhof]

2. De bedrijfstoestand “VERLATEN” (in PMKL “Buiten Gebruik”) heeft voor wat betreft NLCS Netbeheer een vaste presentatie in de vorm van een lijnstijl (idem voor Bedrijfstoestand “RESERVE”). Voor NLCS netbeheer lijkt hierdoor de presentatie in de vorm van een vaste lijnstijl / kleur afdoende.

1. Bij de ingelast EC werd genoemd dat er ook zichtbaar onderscheid moet zijn in bijvoorbeeld een reserve-waterleiding en een reserve-gasleiding. Maar niet per sé via een eigen lijnstijl?
2. Nu in NLCS 5.0 worden alle kabels & leidingen zwart afgedrukt. Gaat dat met 5.1 veranderen? (ik ben daar niet op tegen).

• Uitbreiding gewenst in “Formele Beschrijving” voor vaste bedrijfstoestanden per hoofdgroep.

Hebben we dan al vastgesteld dat per hoofdgroep voor alle objecten de bedrijfstoestanden identiek zijn? Wel dat we nu alleen voor de hoofdgroep KL bedrijfstoestanden gaan definiëren.
Gaat het nu alleen om de toestanden 'RESERVE' en 'VERLATEN'?

[ElisabethKloren]

Wat mij betreft gaan we werken met een vaste lijst bedrijfstoestanden; we hebben er nu twee. Dit kán worden uitgebreid. Dit zorgt voor flexibiliteit naar de toekomst. Deze bedrijfstoestanden kunnen in alle hoofdgroepen voorkomen, maar dat ik nu niet zo:

bij een bedrijfstoestand horen bepaalde attributen ("kolommen in de objectentabellen"), als deze attributen zijn ingevuld is de bedrijfstoestand van toepassing op het object (dus niet per sé op alle objecten in een hoofdgroep waar dat niet logisch is). Dat betekent dat uitbreiding van bedrijfstoestanden leidt tot extra attributen. Dat is noodzakelijk, maar is een flinke aanpassing van de softwareleveranciers. Dat betekent wat mij betreft ook, dat we niet "alternatieve namen" gaan gebruiken als bij bijvoorbeeld rioleringen andere termen gelden voor reserve en verlaten, maar we in NLCS standaard termen hebben voor bedrijfstoestanden.

[SanderNijhof]

Dit kán worden uitgebreid. Dit zorgt voor flexibiliteit naar de toekomst. Deze bedrijfstoestanden kunnen in alle hoofdgroepen voorkomen

Bij de voorgestelde 2 bedrijfstoestanden zijn dit al 24 extra kolommen die aan alle objecten worden toegevoegd maar die slechts voor een groep objecten van toepassing zijn. Met 2 bedrijfstoestanden is dat al een redelijke ballast bij objecten waarvoor de kolommen niet gelden. Als we meer statussen gaan toevoegen en ook bewerkingen op een vergelijkbare manier gaan toevoegen, hebben we het over honderden extra kolommen die niet op alle objecten van toepassing zijn, maar wel beheerd moeten worden, ook al zijn ze 'leeg'. Voor alle objecten moeten al die kolommen door de software gelezen en gecontroleerd worden.
Of zie ik dit helemaal verkeerd?

Dat betekent wat mij betreft ook, dat we niet "alternatieve namen" gaan gebruiken als bij bijvoorbeeld rioleringen andere termen gelden voor reserve en verlaten

Dit past niet bij de stelling dat je per hoofdgroep de voor die hoofdgroep gebruikelijke termen moet kunnen gebruiken. We kunnen niet gaan voorschrijven met welke (technische) termen disciplines moeten gaan werken. Voor de database wel, maar voor degenen die ontwerpen en met de tekening moeten werken niet.

Dat is noodzakelijk,

Weten we al wat noodzakelijk is? Is al vastgesteld wat de bedrijfstoestanden en bewerkingen betekenen voor de presentatie van objecten:
Nu wordt de presentatie van een object bepaald door:

1. het object zelf
2. de status van het object
   Per object zijn kleur, lijndikte, lijnstijl gedefinieerd en die kunnen per STATUS verschillen.

Er is gezegd dat een object herkenbaar moet zijn aan een presentatie zowel specifiek voor dat object (bijv. kleur+lijnstijl/symbool) als ook aan de bedrijfstoestand (en later mogelijk ook aan de bewerking). Maar hoe is mij nog niet duidelijk.
Krijgt elk object per bedrijfstoestand en per status een aparte lijnstijl, lijndikte en kleur? Dan kom ik bij toevoegen van RESERVE en VERLATEN op minimaal 4, maar waarschijnlijk 6 nieuwe lijnstijlen per object. Is dat nodig?
Moeten we niet eerst duidelijke afspraken over de keuzes voor de presentatie van deze objecten maken?
Zodat we niet onnodig extra kolommen toevoegen.

De wens komt vanuit NETBEHEER. Kunnen zij ook laten zien wat zij nu gebruiken of wensen qua kleuren en lijnstijlen? Voorbeelden? Is er al wat beschikbaar wat we in de NLCS kunnen implementeren? Of wordt van ons verwacht dat we in een paar weken een compleet systeem met nieuwe kleuren en lijnstijlen ontwikkelen? Het is mij niet duidelijk.

[ElisabethKloren]

Bij de voorgestelde 2 bedrijfstoestanden zijn dit al 24 extra kolommen die aan alle objecten worden toegevoegd maar die slechts voor een groep objecten van toepassing zijn. Met 2 bedrijfstoestanden is dat al een redelijke ballast bij objecten waarvoor de kolommen niet gelden. Als we meer statussen gaan toevoegen en ook bewerkingen op een vergelijkbare manier gaan toevoegen, hebben we het over honderden extra kolommen die niet op alle objecten van toepassing zijn, maar wel beheerd moeten worden, ook al zijn ze 'leeg'. Voor alle objecten moeten al die kolommen door de software gelezen en gecontroleerd worden.
Of zie ik dit helemaal verkeerd?

In de NLCS concept 5.1 versie gaat de database worden uitgebreid met de extra kolommen zoals in het voorstel; het staat leveranciers vrij om dit in hun eigen applicaties te vertalen naar een ander datamodel, als de werking voor de tekenaar maar hetzelfde is.
Hetzelfde geldt voor anderen die zelf in eigen applicaties NLCS toevoegen. Sterker nog, als je zelf geen netten tekent kun je de extra "kolommen" weglaten uit je eigen omgeving en blijft de techniek hetzelfde.
We beheren geen "lege" kolommen in de NLCS publicatie, we hebben nu ook al objecten die alleen waardes hebben voor B daarbij geldt hetzelfde.

[Han-Loermans]

Hierbij een vernieuwd voorstel van ons waarbinnen Bedrijfstoestand en Bewerking goed bruikbaar zijn, men flexibel hiermee kan omgaan en ook binnen de controle en herstel functionaliteit goed getoetst kan worden:

Combinatie van bedrijfstoestand en bewerking kan ook op een andere manier, namelijk op basis van taalkundige beoordeling zoals huidige bewerking. Dit houdt in dat zoals nu iedereen zelf een bewerking kan invoeren, ook een combinatie kan toepassen of alleen een bewerking of alleen een toestand kan invoeren.

De software is al ingericht om kleuren, lijntypes en lijndiktes toe te passen op een bewerking. Hiermee zijn alle gewenste combinaties al in de bibliotheek of project-bibliotheek te combineren en in te voeren.

De feitelijke beoordeling wat voor waarde de bewerking heeft, ligt bij een Bewerking bij de mens, en niet bij de computer. Elk bedrijf of vakgebied kan dan richtlijnen opstellen hoe om te gaan met de waarde van de Bewerking/Toestand combinatie. Bijvoorbeeld het gebruik van een eigen lijstje met toegestane waarden, het koppelwoord EN gebruiken voor combinaties, enz.

Voordelen:

• Software is al gereed, en per bewerking, toestand of combinatie kan een kleur/lijndikte of lijntype worden ingesteld
• Beoordeling is net als bij Bewerking taalkundig gericht
• Bij hanteren richtlijnen kunnen onderaannemers aangesproken worden op afwijkingen (net als nu bij toepassen symbolen en kleuren)
• Leesbaarder voor gebruikers
• Flexibel voor andere vakgebieden
• Geen misbruik en combinaties van verschillende soorten aanduidingen
• De controletool zal toetsen op de aanwezigheid in de bibliotheek, dus afwijkingen worden direct geconstateerd

Voorbeelden:
(Overigens is er al een sub-object Reserve voor Data).
N-OI-KL-DATA-RESERVE-G
N-OI-KL-DATA-VERLATEN-G
N-OI-KL-DATA-VERLATEN EN VOL TE SCHUIMEN-G
N-OI-KL-DATA-VERLATEN EN VOLGESCHUIMD-G

Enzovoort.

Nogmaals, in te vullen en samen te stellen naar eigen inzicht en richtlijnen voor onderaannemers, dit legt geen dwingende beperkingen op aan andere gebruikers en de software is hier al voor ingericht.

Hiervoor zijn twee zaken benodigd:

• Veld Bewerking anders noemen (Conditie, Gesteldheid, Toestand)
• Bewerking toestaan op alle statussen

[MvanderHulst]

@Han-Loermans en @ElisabethKloren
Ik ben het spoor kwijt hoe het idee is om de verschillende combinaties van 'bewerking' en 'bedrijfstoestand' op te gaan nemen in de database, omdat het volgens mij niet gewenst was om voor ALLE soorten kabels subobjecten/bewerkingen te moeten gaan toevoegen, maar dat dit op één of andere manier centraal geregeld moet gaan worden.

Wel kan ik mij vinden in de basis van het voorstel,
omdat werken met haken [ ] of andere rare tekens voor identificatie is gebleken dat het niet gaat werken is het woord ' EN ' juist goed te identificeren en te onderscheiden.
De herkenning zou dan worden EN .

Goed alternatief wat mij betreft. Goed op te filteren én voor de gebruiker ook prima leesbaar.

[ElisabethKloren]

Dit zal ik ook mailen aan betrokkenen:
Graag wil ik jullie aandacht vestigen op het voorstel van Han hierboven. Ik kan me voorstellen dat dit hetzelfde bereikt, het toevoegen van bedrijfstoestanden, zonder het datamodel aan te passen van de standaard en van de NLCS-software. Het lijkt me dan ook redelijk, dat we onszelf tijd geven om dit voorstel te onderzoeken tijdens de reviewperiode van het concept van versie 5.1.

Ik zal een extra expertsessie organiseren in nov / december om dit voorstel te beoordelen.

Dit betekent eventueel wel dat we een tweede concept-publicatie moeten uitvoeren om extra objecten met bedrijfstoestanden/bewerkingen van de netbeheerders toe te voegen, echter dit gebeurt dan zonder aanpassing van het datamodel.

[MvanderHulst]

@ElisabethKloren
Lijkt me goed, gezien we de laatste keer geconcludeerd hebben dat het identificeren met 'haken' en simpelweg niet gaat werken. :-)

[ElisabethKloren]

Ik wil in de expertsessie wel bespreken, hoe we kunnen zorgen dat een gebruiker niet een te grote lijst meekrijgt van mogelijke objecten omdat je én het harmonicamodel wil kunnen gebruiken, én alle bedrijfstoestand/bewerkingen wilt kunnen aanbieden.

[MvanderHulst]

als elke toestand/bewerking een eigen presentatie moet krijgen (per thema) dus een buiten bedrijf DATA moet er weer anders uit zien dan een buiten bedrijf WATER, dan ga je er niet aan ontkomen om het in het harmonicamodel op te nemen.
Wanneer er aan één bedrijfstoestand één presentatie kan hangen, dan zou je het kunnen aanbieden door de bewerkingen als 'keuzelijst' net als de status aan te bieden. Je kan dan per 'bewerking' een lijntype koppelen bijvoorbeeld, maar dan wel de kleureigenschappen van de 'parent' overnemen. DATA 'buiten bedrijf' is dan groen gestippeld, en water is blauw gestippeld bijvoorbeeld.

De bewerkingen moet je dan wel weer dichttimmeren in de standaard en gaan omschrijven hoe dit geregeld dient t worden in de software.
Een 'snelle 5.1 oplosing' is naar mijn mening alleen haalbaar door een enorme lijst aan objecten toe te voegen.

Hopelijk kan iemand het tegendeel aantonen, dat zou veel data schelen.

[ElisabethKloren]

deze oplossing leidt tot veel extra laagnamen in de standaard (maar niet veel extra data, want de kleuren en lijnen moesten sowieso gepubliceerd), maar dat zou inderdaad in de software anders gepresenteerd kunnen worden om de eindgebruiker te helpen. Alleen al bewerkingen als keuzelijst aanbieden naar analogie van de statussen kan wel echt helpen.

We moeten wel echt met het mechanisme gaan werken, dat als er geen kleuren zijn ingevuld voor een bepaalde status, dat dan die keuze ook niet in de software komt, maar volgens mij is dat al (impliciet) geregeld, bijvoorbeeld bij algemeen?

[SanderNijhof]

De software is al ingericht om kleuren, lijntypes en lijndiktes toe te passen op een bewerking. Hiermee zijn alle gewenste combinaties al in de bibliotheek of project-bibliotheek te combineren en in te voeren.

Ik weet niet of ik dit goed begrijp. Dus de waarde van 'bewerking' bepaald dan de presentatie van een object? Dus een VERLATEN gasleiding krijgt dezelfde presentatie als een VERLATEN waterleiding?

Elk bedrijf of vakgebied kan dan richtlijnen opstellen hoe om te gaan met de waarde van de Bewerking/Toestand combinatie. Bijvoorbeeld het gebruik van een eigen lijstje met toegestane waarden, het koppelwoord EN gebruiken voor combinaties, enz

Het lijkt mij erg onwenselijk en in ieder geval onbeheersbaar om de invulling van bewerkingen en toestanden vrij te geven. Als toestanden en bewerkingen door software herkend moeten worden moeten die uniform vastgesteld zijn. Voor de presentatie van objecten is het minder relevant maar voor verwerking in je beheersoftware is de betekenis wel van belang.

Ik vind 'VERLATEN EN VOLGESCHUIMD' wel een byzonder voorbeeld: dat zijn 2 toestanden? Is dat iets wat mogelijk moet zijn?

Nogmaals, volgens mij moet er nog veel uitgewerkt worden en is het niet verantwoord dit zo in 5.1 op te nemen.
Als we dat toch doen dan zou ik in ieder geval voorstellen te vermelden dat dit een 'pilot' of 'technology preview' betreft die zich nog moet bewijzen en volledig kan wijzigen.

[SanderNijhof]

We moeten wel echt met het mechanisme gaan werken, dat als er geen kleuren zijn ingevuld voor een bepaalde status, dat dan die keuze ook niet in de software komt, maar volgens mij is dat al (impliciet) geregeld, bijvoorbeeld bij algemeen?

Dat staat haaks op wat eerder is afgesproken dat elk object in elke status gepresenteerd moet kunnen worden, hoe onlogisch dit soms ook is.
Dit kan wel, maar dan moeten we alle NLCS objecten op statussen beoordelen en nakijken, want daar was discussie over.

[SanderNijhof]

Een 'snelle 5.1 oplosing' is naar mijn mening alleen haalbaar door een enorme lijst aan objecten toe te voegen.

Ik heb er vooral moeite mee erachter te komen wat de wens en voorgestelde oplossing is. H̷e̷b̷ ̷w̷e̷l̷ ̷v̷r̷a̷g̷e̷n̷ ̷g̷e̷s̷t̷e̷l̷d̷ ̷m̷a̷a̷r̷ ̷k̷r̷i̷j̷g̷ ̷g̷e̷e̷n̷ ̷a̷n̷t̷w̷o̷o̷r̷d̷e̷n̷.̷
Het is een grote warboel, althans voor mij.

1. gaan we alleen toestanden toevoegen?
2. welke en hoeveel toestand gaan we toevoegen?
3. welke eigenschappen van het object bepalen de presentatie van het object? type? status? toestand? bewerking? of welke combinaties daarvan? hoe: kleur? lijntype? lijndikte?
4. beperken we toestanden tot vaste waarden of mogen toestanden vrij ingevuld worden?
5. zijn toestanden beperkt tot bepaalde objecten, of alle objecten in een hoofdgroep? en hoe regel je die beperking?

en als je naast toestand ook bewerking gaat toevoegen krijg je op bovenstaande vragen dan mogelijkheden in het kwadraat?

[MvanderHulst]

@SanderNijhof dit is mij inderdaad allemaal ook nog niet duidelijk.
Volgens mij is het voorstel nu:
De positie 'bewerking' gebruiken voor zowel de bedrijfstoestand als de bewerking. Hiervoor was eerst een voorstel om de toestand tussen haken [ ] te tonen, om te identificeren of het alleen een bewerking betrof of alleen een bedrijfstoestand.
In plaats van de haken, kan het woord 'EN' toegepast worden:
bijvoorbeeld: VERVALEN EN IN BEDRIJF STELLEN, zou dus betekenen dat een verlaten leiding weer in gebruik wordt genomen.
Omdat ze per situatie de presentatie willen regelen, ontkom je er dus niet aan om voor elke object-subobject combinatie in de database regels toe te voegen, wat resulteerd in 100-en danwel 1000-en regels toe te voegen.

De vraag van Elisabeth is vervolgens of deze combinaties dan ook in de harmonica terug moeten komen, of dat het met software geregeld dan worden, zodat de presentatie vastgelegd zijn in 'een' database, maar met tooling dit eenvoudig toegepast kan worden.

Met de boodschap dat we snel naar een 5.1 release moeten zonder aanpassingen van de softwareleveranciers, zie ik ook geen andere optie van de enorme lijst aan het harmonicamodel toe te voegen.

Maar dan nog moet er een ei gelegd worden over jouw puntje 3. Dit is sterk van invloed op de impact van de database en de nodige tooling...

Gevoelsmatig is er HEEL goed over het datamodel 'nagedacht', maar heel slecht over de visuele presentatie wensen op papier. Zal helaas niet de eerste keer zijn dat 'presentatie' ondergeschikt is gemaakt aan het datamodel..

[ElisabethKloren]

Nogmaals, volgens mij moet er nog veel uitgewerkt worden en is het niet verantwoord dit zo in 5.1 op te nemen.
Als we dat toch doen dan zou ik in ieder geval voorstellen te vermelden dat dit een 'pilot' of 'technology preview' betreft die zich nog moet bewijzen en volledig kan wijzigen.

Het laatste voorstel is; intact houden van het huidige datamodel. Extra laagnamen toevoegen voor alle combinaties van bedrijfstoestand en bewerking die men bij een object wil kunnen toevoegen. Technologisch is er geen verandering, te onderzoeken is of dit leidt tot zo'n grote hoeveelheid extra objecten dat het voor de tekenaar moeilijker wordt om een object te selecteren, en of de software dit kan oplossen voor de tekenaar. Dit geeft tijd om voor versie 6.0 na te denken over eventueel gewenste technologische oplossingen

[SanderNijhof]

Het laatste voorstel is; intact houden van het huidige datamodel.

Dat stelt mij enigszins gerust. Ik had dat nog niet zo begrepen. 😏

💡Idee, voor later, ter overweging:

Als we aanhouden dat de kleur en lijndikte worden bepaald door het object en status, dan kunnen we de lijnstijl voor
TOESTAND EN BEWERKING laten bepalen door de naam van de lijnstijl.

Bijv.:

	Laagnaam:	Lijnstijl1	Lijnstijl2	Lijnstijl3
1	B-WE-KL-DATA-G	B-KL-DATA	CONTINUOUS
2	B-WE-KL-DATA-RESERVE-G	B-KL-DATA-RESERVE	B-KL-RESERVE	B-KL-DATA
3	N-WE-KL-DATA-RESERVE EN IN GEBRUIK STELLEN-G	KL-DATA-RESERVE EN IN GEBRUIK STELLEN	KL-DATA-RESERVE	KL-RESERVE

Alleen regel 1 is opgenomen als object in de database, met lijnstijlen per status, zoals nu ook het geval is.
Regel 2 en 3 kunnen dan door de software worden bepaald a.d.h.v. de aan de laagnaam toegevoegde BEWERKING. Voorstel: Als lijnstijl1 niet bestaat dan wordt door de software lijnstijl2 toegepast, bestaat lijnstijl2 ook niet dan lijnstijl3, bestaat lijnstijl3 ook niet dan de lijnstijl1 van het hoofdobject uit regel 1.

(maar is dus slechts een idee dat nog uitgewerkt en getoetst moet worden of dit voor alle objecten zo kan. Je zou bijv. ook nog een lijnstijl KL-DATA-IN GEBRUIK STELLEN kunnen toevoegen of KL-DATA voorkeur kunnen geven boven KL-RESERVE).

We moeten daarnaast nog wel bedenken hoe we de inhoud van 'BEWERKING', in dit geval 'RESERVE' en 'RESERVE EN IN GEBRUIK STELLEN', kunnen opnemen zonder deze als extra objecten aan de objectendatabase toe te voegen.

Mijn idee daarvoor was/is:
Bijv. door keuzelijsten te koppelen aan het object in regel 1 via de positie voor 'BEWERKING'. Je zou dan zelfs nog de kleur en lijndikte van specifieke objecten kunnen overrulen door die objecten wél met een BEWERKING ipv keuzelijstverwijzing in de objectendatabase op te nemen. Dus bijv.:
x-xx-KL-DATA-#KEUZELIJST1# = verwijzing naar keuzelijst: gebruiker mag bewerking kiezen uit keuzelijst en krijgt lijnstijl1, 2, of 3 volgens bovenstaande principe.
x-xx-KL-DATA-RESERVE = geen verwijzing naar keuzelijst: object krijgt eigenschappen die voor dit object incl BEWERKING in de database zijn opgenomen.

Deze methode kan worden gebruikt door de CADteken-tooling en door de controle-tooling.

Het huidige datamodel blijft dan in tact, maar wel met extra toegevoegde functionaliteit die de software moet herkennen en verwerken. Dit kan zo werken voor lijnstijlen, symbolen en arceringen.

[SanderNijhof]

• Bewerking toestaan op alle statussen

Nog te overwegen om 'BEWERKING' niet toe te staan bij status 'X' en status 'T' ?
Kan het kwaad om bij deze statussen ook 'BEWERKING' toe te staan of kan/mag bij die statussen nooit een toestand of bewerking voorkomen?

[MvanderHulst]

@SanderNijhof
Voor status T zou ik graag ook bewerkingen willen toepassen.
Is omdat Tijdelijk (in ieder geval) bij ons wordt toegepast voor 'bouwwegen' e.d.
Nieuw, niet definitief, zoals ik het graag uitleg.
Vanuit layers schakelen tussen bouw-rijp en woonrijp, plaats ik regelmatig freesvakken in de T-lagen, omdat pas bij woonrijp maken de definitieve vakken te maken bijvorobeeld.

Status X zou geen bewerking hoeven hebben, gezien dit enkel 'aankledings' elementen zijn voor de opmaak en geen relatie met werkzaamheden zou moetne hebben.

[SanderNijhof]

Functionele eisen:

• Visueel onderscheid voor de toepassing van BEDRIJFSTOESTAND op basis van lijntype overeenkomstig met presentatie zoals beschreven in PMKL
• Kleurgebruik volgens PMKL voor onderscheid netvlak

Dit is heel duidelijk 👍 Dus onderscheid alleen via lijnstijl (of symbool, arcering) en het kleurgebruik van de NLCS afstemmen op het kleurgebruik van PMKL.

Functioneel is benodigd voor NLCS Netbeheer:

• Uitbreiding gewenst in “Formele Beschrijving” voor vaste bedrijfstoestanden per hoofdgroep. Controle functionaliteit moet hier rekening mee houden.
• Software oplossing: Functionaliteit gewenst waarbij onderscheid wordt gemaakt waarbij controle wordt uitgevoerd op aanwezigheid in bepaalde bibliotheken (NLCS en/of Project-bibliotheek bijvoorbeeld)

Volgens mij kan dit dus ook op objectniveau en hoofdgroep overschrijdend. Bijv. ervoor kunnen kiezen om een data-kabel vol te schuimen zal niet logisch gekozen worden, maar als dat volgens NLCS wel mogelijk is en door controle-tooling goed wordt gekeurd oogt dat wel apart. Dus indien mogelijk graag een oplossing op objectniveau.

[SanderNijhof]

@MvanderHulst

Voor status T zou ik graag ook bewerkingen willen toepassen.

Ja mee eens!
Bij status 'X' toepassen van BEWERKING uitsluiten en bij alle andere statussen toestaan vind ik veilig en logisch.