search

nl-digigo / NLCS

Technische documentatie en issues NLCS
Creative Commons Attribution 4.0 International
2 stars 0 forks source link

[NLCS NBH] 6. Bewerkingen #328

Closed theokolman closed 2 months ago

theokolman commented 6 months ago

In de huidige NLCS Formele Beschrijving zijn Bewerkingen enkel toegestaan voor de Status NIEUW en TIJDELIJK. Voor NLCS Netbeheer is het noodzakelijk dit ook toe te kunnen passen op de status “Bestaand”.

Binnen netbeheer wordt gebruik gemaakt van verschillende termen voor het aangeven van bepaalde acties die uitgevoerd moeten worden op objecten in het net.

Voor de NLCS Netbeheer bewerkingen geldt dat deze zijn vastgelegd hierdoor kan de presentatie hiervan eenduidig worden vastgelegd. De bewerkingen zijn samengesteld op basis van de input vanuit de verschillende netbeheerders.

OPVULLEN RELINEN VERPLAATSEN BB STELLEN IB STELLEN

Consequenties ACTIE | DIGIGO

Consequenties Software ontwikkelaars

“Aan ieder OBJECT of SUBOBJECT kan optioneel een BEWERKING worden toegevoegd. Voorbeeld: N-WE-VH-KANTOPSLUITING_OPSLUITBAND-OPNIEUW STELLEN-G. Alle BEWERKINGEN krijgen de STATUS ‘NIEUW’ of ‘TIJDELIJK’.”

Gewenste functionaliteit in software tooling Het gebruik van bewerkingen zal naast de statussen Nieuw en Tijdelijk beschikbaar moeten worden gemaakt voor de status Bestaand. Gewenst is het hier dit eenvoudig op basis van een keuzelijst toe te kunnen passen waardoor gebruikers eenvoudig en efficiënt kunnen selecteren en daarmee toepassen.

MvanderHulst commented 6 months ago

Eerder heb ik een voorstel gedaan om dit NOG éénduidiger aan te pakken: alleen iets dat bestaand is, kan je tenslotte bewerken. Introductie van de status 'M' voor 'MUTATIE'. B = bestaand (ongewijzigd) M = mutatie van het bestaande object V = vervallen.

waterdicht.

De 'bewerking' als T of N beschouwen heb ik nooit begrepen.

@theokolman VERPLAATSEN vindt ik wel en spannende.... Hoe geef je aan waar de nieuwe kabel heen gaat? Dit kan je nergens in de statussen kwijt. T of N zou niet terecht zijn...

DimitryDekker commented 6 months ago

Vandaag hebben we deze bewerkingen nog een stukje aangescherpt met de materiedeskundigen van de netbeheerders Stedin, Alliander en Enexis. De term "Buiten Bedrijf" heeft niet voor alle netbeheerders dezelfde betekenis, dus we hebben deze vervangen door "VERLATEN". Daarnaast is IB STELLEN (=in bedrijf stellen) vervangen door IG NEMEN (In gebruik nemen).

Met deze aanscherpingen worden de waarden voor Bewerking als volgt: image

NielsNederpel commented 6 months ago
MvanderHulst commented 6 months ago

VERPLAATSEN zal inderdaad altijd in combinatie met VERPLAATST aangemerkt moeten worden (lijkt mij)? Doen wij nu trouwens ook voor kabelwerk, dus ja, het is een herkenbaar secnario. ;-)

ElisabethKloren commented 6 months ago

EC 2024-03-14 “Bewerking” moet nu altijd nieuw of tijdelijk zijn Voorstel om dit ook toe te staan voor bestaand. Ook voor riolering wordt nu bewerking toegestaan voor bestaand

Moet je het wel beperken in de beschrijving? Vervallen zou bijvoorbeeld bewerking “vervoeren naar depot” kunnen krijgen? > is geen bewerking van het object

Discussie; over de betekenis van status: status nieuw; een bestaand object dat gewijzigd is, krijgt status nieuw omdat de situatie gewijzigd is Bestaand betekent “handhaven”. Moet er geen status mutatie worden toegevoegd?

Status 1: was het object er al (ontwerpperspectief) Status 2: is het object gewijzigd (beheerperspectief) We willen deze perspectieven in de keten allebei kunnen

Tegenvoorstel EC: voeg een status Mutatie toe; wijzigen objecten met status bestaand en een bewerking bij riolering

afbeelding

SanderNijhof commented 6 months ago

VERPLAATSEN

Bijna alle objecten in de NLCS kunnen verplaatst worden. We gebruiken ook niet LICHTMAST_VERPLAATSEN of TROTTOIRKOLK_VERPLAATSEN en vul de 'tig' mogelijkheden maar aan. Dan zou ik liever opten voor 'LICHTMAST_HERGEBRUIKT' of inderdaad 'LICHTMAST_VERPLAATST'.

SanderNijhof commented 6 months ago
  • 5.1 verplaatsen? hoe gaat dit dan getekend worden? heb je een 1 object "verplaatsen" 2 lagen? 1 voor Vervallen/Verwijderde locatie en 1 voor Nieuwe locatie?

Dit is afhankelijk van hoe het werk wordt uitgevoerd denk ik. Als je het object eerst fysiek verwijdert en later weer terugplaatst of dat je het object in één handeling 'opschuift'. Uiteindelijk op de revisietekening staat het object op een N- of R- laag.

SanderNijhof commented 6 months ago

Ter overweging… Ik denk dat we duidelijk moeten zijn in het onderscheid tussen de benaming van CAD-lagen en gebruik van (Asset)Data:

Interpretatie: Bij de laagnamen ligt de focus op de CAD functionaliteit, op functionaliteit voor de CAD-tekenaar en uitlezen door externe applicaties: B = Het object is niet gewijzigd (geen mutatie in de beheerdata) R = N = Het object is gewijzigd t.o.v. de bestaande situatie (!mutatie in de beheerdata) V = Het object is verwijderd uit de bestaande situatie (!mutatie in de beheerdata) T = Het object is tijdelijk aanwezig (geen mutatie in de beheerdata) X = Geen fysiek of beheerbaar object, betreft opmaak van de tekening (geen mutatie in de beheerdata).

De STATUS geeft dus o.a. aan (externe) applicaties door of een object gemuteerd moet worden of niet. De tekenaar kan makkelijk filteren op wat wordt gewijzigd en wat wordt verwijderd. Onderscheid tussen een verplaatst object of een nieuw geplaatst object middels een status ‘M’ maakt het tekenwerk en uitlezen van de tekening complexer. Ik ben nog niet overtuigd dat die extra status nodig is. Ik zie wel het belang voor de tekening of een object nieuw geleverd is of hergebruikt, maar behoort die eigenschap niet tot de assetdata? Een object op een N-laag met een bekend asset-ID is een gewijzigd bestaand object. Een object op een N-laag zonder asset-ID of met een onbekend asset-ID is een nieuw object. Een status ‘M’ in de laagnaam zou dit wel vereenvoudigen, maar past dat wel in de STATUS-systematiek?

Of een object bijvoorbeeld ‘verlaten’ of ‘buiten werking’ is past niet in deze uitleg van de STATUS. Dit betreft informatie over het object zelf en is dus assetdata. Onderscheid tussen verplaatste en nieuwe geleverde objecten hoort eigenlijk niet in de STATUS thuis maar elders in de laagnaam. Hiervoor kent de NLCS (nog) geen veld in de laagnaamopbouw. Naar mijn mening zou dit als SUBOBJECT of BEWERKING ingevuld moeten worden, zoals bijvoorbeeld de lagen bij riolering met 'VOLGESCHUIMD'. Of desgewenst (liever niet) apart toegevoegd moeten worden aan de laagnaamopbouw, los van de BNVTX-statussen. Misschien de 2 letters van het betwiste veld DISCIPLINE hiervoor gebruiken? De opbouw wordt dan STATUS-OBJECTSTATUS-HOOFDGROEP-OBJECT_5xSUBOBJECT_BEWERKING-ELEMENT[-SCHAAL]. Is de impact daarvan te overzien? (Pollen bij gebruikers?). Letters toevoegen aan het huidige SUBSTATUS-veld vind ik geen beter idee. Bij werken in fasen krijg je dan een 5 letterig veld, bijvoorbeeld ‘BBB01’ of ‘NRS01’.

Of is het handig om de betekenis van STATUS formeel te wijzigen zodat deze de eigenschappen van het object aangeven? Kan dan nog herkend worden of een object wel of niet gemuteerd moet worden? Dan moeten dus ook alle objecten in de tekening gecontroleerd worden ipv alleen de N- (R-) en V- objecten. Dat kost meer inspanning en vergroot dat ook niet de complexiteit van de verwerking en de kans op verschillende interpretaties en op fouten?

MvanderHulst commented 6 months ago

@SanderNijhof bovenstaande uitleg kan ik mij ook deels in vinden. Ik denk, ook naar aanleiding van bovenstaande uitleg, dat het vooral zeer belangrijk is om af te kaderen: WAT staat in WELKE tekening en hoe ga je om met dubbelingen.

Ik zou het gewenst vinden als ALLE bestaande en vervallen objecten in 1 DWG staan, zodat ik één 'SINGLE POINT OF TRUTH' heb, zowel voor mijn 'databeheer' als het kunnen opstellen van de technische tekeningen. hiervoor zou ook de omgang (presentatie) van V aangepast moeten worden... Als de 'single point of truth' geen noodzaak is, moet duidelijk aangemerkt worden in WELKE tekening de mutaties opgenomen worden. Na alle discussie ben ik er ondertussen wel achter dat de omgang van DWG bestanden en 'wat doe je in welke' tekeningen enorme consequenties heeft voor de noodzaak van de aanvullende statussen of niet.

Ander voorbeeld: het vol te schuimen riool. De buis staat als B in de 'bestaande situatie'. In zou deze in de bron als 'M' met bewerking 'volschuimen' willen aanmerken. Dan heb ik de leiding 1x in mijn model staan, met alle data én presentabel op de bestaande situatie én werktekeningen.

Je kan ook in een 'ontwerp' tekening de leiding overtrekken en aanmerken als 'volschuimen' met de status nieuw. Dan staat de betreffende leiding dus 1x in mijn model....

Als na een inmeting de locatie van de leiding iets anders blijkt te liggen, moet in dat óf in 1 model aanpassen, of in 2 modellen...

Tekening opbouw, en afspraken over de import/export liggen ter grondslag van de te maken keuzes.

Hier sluit ook mijn presentatie op aan, maar dan voor de omgang van 'vervallen'.

SanderNijhof commented 6 months ago

Je kan ook in een 'ontwerp' tekening de leiding overtrekken en aanmerken als 'volschuimen' met de status nieuw. Dan staat de betreffende leiding dus 1x in mijn model....

Dit is hoe wij het conform NLCS geleerd hebben. Je hebt een model met de bestaande situatie en die leg je onder je model met je ontwerp. De te wijzigen objecten kopieer je naar je ontwerp en pas je aan. Je moet daarbij dus wel opletten dat de assetdata meekomt naar je ontwerp. Maar we doen nog niets met assetdata in CAD-ontwerpen dus dat probleem kennen we nog niet. Bij ons wijkt de 'digitale bestaande situatie' vaak af van de werkelijke situatie buiten, vooral wat riolering betreft. Dan passen we het model met de bestaande situatie aan en blijven die bestaande objecten op B-lagen staan. Die worden dus niet gecorrigeerd in het beheersysteem. Die zouden we eigenlijk moeten opnemen in het onwerpmodel op N-lagen, ook al hebben we die buiten niet gewijzigd. Allemaal theoretisch, we hebben nog geen ervaring met automatisch muteren van CAD-tekeningen in de beheerdata :-/

MvanderHulst commented 6 months ago

@SanderNijhof daar zit dus al het 'gedachten' verschil. Heel bestaand moeten vervallen onder het ontwerp, vind ik altijd al een rare situatie. Ik wil de 'vervallen' situatie uit kunnen zetten door alle 'V' lagen uit te zetten. Bestaand en vervallen zitten bij ons dan ook altijd in 1 model, waarbij de B en V laten dezelfde presentatie hebben, alleen vervallen een andere kleur krijgt. Hiermee behoud dus dus 1 model, kan je 'bestaand' en 'vervallen apart schakelen en de vervallen situatie wel, of niet, tonen onder je ontwerp. NLCS dwingt je er nu toe dat je één model met bestaande situatie hebt en een ander model met de 'te vervallen' situatie. Hierdoor komt een bestaande boom dus eigenlijk 2x in mijn projectomgeving voor. Als er aanvullende metingen van de ondergrond worden gedaan, moet ik dit dus ook op 2 plekken verwerken en onder verdelen. Dit heb ik altijd al een hele rare, onlogische gedachtengang gevonden, wat resulteert in dubbelwerk en dubbele data. Ik snap volledig wat je zegt, dat de NLCS je wel dwingt om met deze methodiek te werken.

Zelf gebruiken wij de V-status dan ook niet, maar zetten alles op B, B01, B02 etc. Hiermee kunnen wij borgen dat alle informatie maar 1x voorkomt, er geen dubbele data is, wijzigingen maar 1x verwerkt moeten worden EN we gefaseeerde tekeningen kunnen opstellen. Allemaal voordelen die door de visuele presentatie van de status V niet mogelijk zijn. omdat je dan de verkeerde 'Vervallen' informatie voor latere faseringen al op tekening te zien krijgt.

Wij werkten 'vroeger' bij HB altijd object georiënteerd. door NLCS is dit 'situatie' georienteerd geworden. Ik zie nu de gang naar 'objectgericht' weer ingezet worden. Ik ben daar blij mee, maar vraagt wel een hele andere (maar m.i. logischere) manier van tekenen.

SanderNijhof commented 6 months ago

Kan in Netbeheer voor objectstatus en bewerking niet ook dezelfde systematiek als bij riolering toegepast worden? voorbeelden riolering: V-WE-RI-DWA_LOZELEIDING _VOLGESCHUIMD-G en N-WE-RI-DWA_RIOOLLEIDING -VOLSCHUIMEN-G B-WE-RI-DWA_LOZELEIDING _VOLGEZAND-G en N-WE-RI-DWA_RIOOLLEIDING -VOLZANDEN-G

Hier wordt dus in de NLS 5.0 al afgeweken van de Formele Beschrijving waarin staat dat alle BEWERKINGEN de STATUS 'NIEUW' of 'TIJDELIJK' krijgen. zie ook #327

ElisabethKloren commented 6 months ago

even check vraag, werkwijze met model van bestaande situatie als ondergrond gebruiken, werkt dat ook zo in microstation of alleen in autocad? (even vergeten)

SanderNijhof commented 6 months ago

even check vraag, werkwijze met model van bestaande situatie als ondergrond gebruiken, werkt dat ook zo in microstation of alleen in autocad? (even vergeten)

Dat werkt ook zo in Microstation.

MvanderHulst commented 6 months ago

Kan in Netbeheer voor objectstatus en bewerking niet ook dezelfde systematiek als bij riolering toegepast worden? voorbeelden riolering: V-WE-RI-DWA_LOZELEIDING _VOLGESCHUIMD-G en N-WE-RI-DWA_RIOOLLEIDING -VOLSCHUIMEN-G B-WE-RI-DWA_LOZELEIDING _VOLGEZAND-G en N-WE-RI-DWA_RIOOLLEIDING -VOLZANDEN-G

Hier wordt dus in de NLS 5.0 al afgeweken van de Formele Beschrijving waarin staat dat alle BEWERKINGEN de STATUS 'NIEUW' of 'TIJDELIJK' krijgen. zie ook #327

Technisch zou dat wel kunnen. Ik denk (en begrijp volledig) dat ze voor netbeheer dit voorin de laagnaam willen, zodat je in de layermanager op volgorde alle soorten bij elkaar heb staan. B BBB BRS

Anders staan alle objecten op volgorde en staat de 'bewerking' overal en nergens in het overzicht. Daar waar voor 'regulier' infa de bewerking vaak de uitzondering is, is dit in de kabelwereld veeeel meer van toepassing.

Dus ja.... ik snap de wens volledig, vanuit de huidige NLCS filosofie zou het ook met bewerking opgelost kunnen worden. Voor het gebruikersgemak is de aanpassing nodig.... voor de standaard, kan het al toegepast worden met de huidige regels.

Je zou natuurlijk in de layermanager 'LAYER FILTERS' kunnen toepassen, zodat je evengoed alle varianten bij elkaar ziet staan, echter is dan weer tooling nodig om zaken overzichtelijk te maken. Door de gewenste aanvullingen voorin de laagnaam op te nemen, is deze filtering 'van nature' aanwezig en blijft het geheel veel overzichtelijker....

Vanuit 'civiel' belang zeg ik... niet nodig. Vanuit Netbeheer belang... volledig begrijpbare wens.

ElisabethKloren commented 6 months ago

een verlaten leiding in je bestaande data, die bewerk je niet, maar je wilt wel weten dat hij niet in gebruik is. Dat is technisch gezien geen bewerking, maar echt een status van het object, waarbij de situatie van het object niet wijzigt.

MvanderHulst commented 6 months ago

@ElisabethKloren Zoals Sander aangeeft. Voor de status B en V zou de 'bewerking' dan de 'toestand' kunnen zijn. Voor de status N zou het de bewerking zijn. VOLGESCHUIMD is dan de tegenhanger van VOLSCHUIMEN. Met de status V, ga je deze 'bewerkte' volgeschuimde leiding dan verwijderen.

klinkt opzich logisch

SanderNijhof commented 6 months ago

Technisch zou dat wel kunnen. Ik denk (en begrijp volledig) dat ze voor netbeheer dit voorin de laagnaam willen, zodat je in de layermanager op volgorde alle soorten bij elkaar heb staan. B BBB BRS

Volgens de NLCS-systematiek zou de 1e letter dan STATUS/Situatie in de CAD-tekening zijn en aangeven of het object wel/niet gemuteerd moet worden en de 2e en 3e letter hebben betrekking op eigenschappen van het object zelf (assetdata). Moet je die 2 verschillende betekenissen wel willen combineren in één veld? Ik denk dan ook aan de verschillende interpretaties die er (nu nog) zijn over de betekenis van STATUS. Hoe maken we het eenvoudig en duidelijk.

ElisabethKloren commented 6 months ago

Niet logisch maar wel een " truuk" waarmee het aantal statussen niet wijzigt. Ik ga een overzicht maken van de voorkomende varianten qua statussen en hoe dat kan werken in planfase, ontwerp, revisie, dan kunnen we daarna kijken wat wenselijk is én begrijpelijk blijft voor cad-gebruikers en wat visueel verschillend moet zijn op tekeningen

SanderNijhof commented 6 months ago

Niet logisch maar wel een " truuk" waarmee het aantal statussen niet wijzigt.

Toch wordt deze methode nu al toegepast in de groep RI. Voor Netbeheer wordt nu een andere methode voorgesteld. Ik vind wel dat we zoveel mogelijk in alle hoofdgroepen dezelfde methodiek moeten toepassen. Als het voorstel van Netbeheer wordt doorgevoerd moeten we ook de lagen in de andere hoofdgroepen controleren en in ieder geval de betreffende lagen in de groep RI aanpassen.

ElisabethKloren commented 2 months ago

Issue #371 geeft weer welke oplossing gekozen is voor release 5.1 van NLCS.