search

nl-digigo / NLCS

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

Ter consultatie: Voorstel extra statussen voor ondergrondse infra en voor overdracht van gegevens naar beheerpakketten #371

Open ElisabethKloren opened 5 months ago

ElisabethKloren commented 5 months ago

Voorstel ter consultatie

Onderstaand voorstel is gedaan om het werkingsgebied van NLCS uit te breiden met twee functionaliteiten: extra statussen voor ondergrondse infra en voor overdracht van gegevens naar beheerpakketten.

Ik zet elk onderdeel in een comment, zodat je kunt "reply-en op dit onderdeel.

Spelregels Expertcommissie

de Expertcommissie beoordeelt het voorstel op (a) haalbaarheid voor automatisering, (b) gebruiksgemak en (c) het invulling geven aan de beoogde werking van de standaard, inclusief de beoogde uitbreiding van het werkingsgebied.

Als aan een van onderstaande niet goed wordt voldaan, mag het label "controversieel" aan dit issue worden gehangen. Voorwaarde daarbij, is dat je een voorstel doet voor een alternatief, dat beter invulling geeft aan de voorwaarden.

Bijgaand het gehele voorstel in een presentatie: 20240402_Voorstel_werkgroep_NLCS_Statusmodel.pdf of download de bewerkbare presentatie

Afweging gekozen oplossing

Scenario Voordelen Nadelen
1. Extra statusletters, alleen voor K&L, OV. Bewerking geeft aan wat er in het project gebeurt met het object • Geschikt voor verschillende visualisaties
• Deze extra statusletters zijn alleen zichtbaar voor de gebruikers die deze nodig hebben
• Laagnaam blijft compacter
• Gebruikt kan een selectie van objecten in één handeling van status wijzigen		 • Statusmodel is complexer (alleen voor de hoofdgroepen KL en OV)
• Wijkt af van methode bij Riolerin -> deze aanpak moet dan ook bij Riolerin worden toegepast.
2. Als subobject. Bewerking geeft aan wat er in het project gebeurt met het object • Statusmodel blijft beperkt
• Geen afkortingen		 • Het aantal objecten in de database (=aantal objecten in de bibliotheek) wordt enorm groot.
• Onderscheid tussen subobject en Bewerking is _ of -, lastig te onderscheiden.
• Laagnaam wordt lang
3. Als attribuutinformatie • Volledig configureerbaar
• Geen impact op de laagnaam		 • Niet te gebruiken voor aangepaste weergave in de tekening
• Buiten scope van huidige NLCS versie
• Extra tooling nodig om zichtbaar te maken in de tekening.

Zie voor de discussie voorafgaand aan dit voorstel: #327

ElisabethKloren commented 5 months ago

In de functionele beschrijving zullen dit als doelen van NLCS moeten worden opgenomen:

  1. Een NLCS model/tekening moet geschikt zijn voor (soorten) tekeningen in verschillende fasen:

    • Beheerfase: Bestaande situatie (situatie voorafgaand aan project: alleen status B)
    • Ontwerpfase: Ontwerptekening (wat moet er gebeuren met details in Bewerking)
    • Overdracht aan beheer, opleveringsfase: As-built tekening (wat is er werkelijk gebeurd met details in Bewerking)

  2. Een NLCS tekening moet (zichtbaar) onderscheid maken tussen onderstaande statussen van het object, om te zorgen dat duidelijk is hoe het werk uitgevoerd moet worden:

    • Bestond reeds voorafgaand aan het project en blijft onveranderd (B)
    • Bestond reeds voorafgaand aan het project en wordt gewijzigd (G) > deze functionaliteit verbetert met dit voorstel
    • Bestond reeds voorafgaand aan het project en wordt verwijderd (V)
    • Wordt in het project toegevoegd/geplaatst (N)
    • Bestaat alleen tijdens het project (T)

  3. Een NLCS model/tekening moet geschikt zijn om met de As-built tekening het bronsysteem bij te werken (Verwijderen, Toevoegen, Aanpassen, Niet aanpassen)

  4. Moet geschikt zijn voor gefaseerde uitvoering (substatus nr) > deze functionaliteit wijzigt niet met dit voorstel

  5. Voor ondergrondse infra, zoals kabels en leidingen maar ook riolering: moet zichtbaar en qua data onderscheid kunnen maken tussen In Bedrijf, Verlaten en Reserve.

ElisabethKloren commented 5 months ago

Voorstel nieuwe statussen en betekenissen

Hierbij wordt aangetekend: in de database worden de statussen voor reserve en verlaten kabels alleen opgenomen bij ondergrondse netinfrastructuur; NLCS applicaties kunnen daarmee automatisch een beperkt aantal statussen aanbieden voor gebruik bij andere NLCS objecten. Dit beperkt de complexiteit van het statusmodel voor andere gebruikers.

Code Verklaring Bestaand Ontwerp as-built Toelichting Is de status relevant voor het bijwerken van de beheerdata
B Bestaand object, in gebruik X X X Object is een bestaand object dat tijdens de werkzaamheden ongewijzigd is. Bij ondergrondse infra is dit een object dat in gebruik is Nee
BRS Bestaand object, in reserve X X X Object is een bestaand object dat tijdens de werkzaamheden ongewijzigd is. Bij ondergrondse infra is dit een object dat in reserve is Nee
BVL Bestaand object, verlaten X X X Object is een bestaand object dat tijdens de werkzaamheden ongewijzigd is, , bij ondergrondse infra is dit een object dat verlaten is Nee
G Te wijzigen / gewijzigd object X Optionele status om aan te kunnen geven of een object een bestaand object betreft dat is gewijzigd of verplaatst. Nieuwe status G toegevoegd om onderscheid te maken tussen bestaande objecten die aangepast worden en object die nieuw worden toegevoegd. Nieuw toegevoegde objecten altijd op een laag met status N plaatsen. Bij ondergrondse infra is dit een object dat in gebruik is Ja
GRS Te wijzigen / gewijzigd object, in reserve X Zie verklaring bij G. Bij ondergrondse infra is dit een object dat in reserve is Ja
GVL Te wijzigen / gewijzigd object, verlaten X Zie verklaring bij G. Bij ondergrondse infra is dit een object dat verlaten is Ja
N Nieuw of gewijzigd object X Objecten die bestaan en tijdens de werkzaamheden worden gewijzigd of nieuw worden toegevoegd. Indien status G in de tekening wordt gebruikt dan krijgen alleen objecten die nog niet bestaan en nieuw in het ontwerp zijn toegevoegd de status N. Bij ondergrondse infra is dit een object dat in gebruik is Ja
NRS Nieuw of gewijzigd object, in reserve X Zie verklaring bij N. Bij ondergrondse infra is dit een object dat in reserve is Ja
V Te verwijderen / is verwijderd object X Object is een bestaand object dat na gereedkomen van de werkzaamheden niet meer aanwezig is. Dus wordt (ontwerp) of is (asbuilt) verwijderd Ja
T Tijdelijk object X Object is alleen tijdens de werkzaamheden aanwezig. Dus bij start van het werk is het object niet aanwezig en na gereed komen van het werk is het object ook niet meer aanwezig. Voorbeelden zijn tijdelijke markeringen, rijplaten, bemaling Nee
R Revisie X X Deze STATUS komt te vervallen. Status R wordt vervangen door status N op type tekening Revise/as-built Nee

Huidige statussen en betekenis staat hier beschreven: #239

ElisabethKloren commented 5 months ago

Verplaatsen van objecten

Voor uitvoering is oude én nieuwe ligging noodzakelijk Object komt dus twee keer in de tekening voor:

KristiaanH commented 5 months ago

Voorstel ter consultatie

Onderstaand voorstel is gedaan om het werkingsgebied van NLCS uit te breiden met twee functionaliteiten: extra statussen voor ondergrondse infra en voor overdracht van gegevens naar beheerpakketten.

Ik zet elk onderdeel in een comment, zodat je kunt "reply-en op dit onderdeel.

Spelregels Expertcommissie

de Expertcommissie beoordeelt het voorstel op (a) haalbaarheid voor automatisering, (b) gebruiksgemak en (c) het invulling geven aan de beoogde werking van de standaard, inclusief de beoogde uitbreiding van het werkingsgebied.

Als aan een van onderstaande niet goed wordt voldaan, mag het label "controversieel" aan dit issue worden gehangen. Voorwaarde daarbij, is dat je een voorstel doet voor een alternatief, dat beter invulling geeft aan de voorwaarden.

Bijgaand het gehele voorstel in een presentatie: 20240402_Voorstel_werkgroep_NLCS_Statusmodel.pdf of download de bewerkbare presentatie

  • [ ] Frank/Dimitry: voorbeeld uitwerken statusmodel, toegepast binnen Netbeheer.
  • [ ] Elisabeth biedt deze uitwerking aan als nieuw issue tbv interne review door expertcommissie
  • [ ] Aansluitend voor openbare consultatie aanbieden op GitHub & via kanalen DigiGO verspreiden

Afweging gekozen oplossing

Scenario Voordelen Nadelen 1. Extra statusletters, alleen voor K&L, OV. Bewerking geeft aan wat er in het project gebeurt met het object • Geschikt voor verschillende visualisaties • Deze extra statusletters zijn alleen zichtbaar voor de gebruikers die deze nodig hebben • Laagnaam blijft compacter • Gebruikt kan een selectie van objecten in één handeling van status wijzigen • Statusmodel is complexer (alleen voor de hoofdgroepen KL en OV) • Wijkt af van methode bij Riolerin -> deze aanpak moet dan ook bij Riolerin worden toegepast. 2. Als subobject. Bewerking geeft aan wat er in het project gebeurt met het object • Statusmodel blijft beperkt • Geen afkortingen • Het aantal objecten in de database (=aantal objecten in de bibliotheek) wordt enorm groot. • Onderscheid tussen subobject en Bewerking is _ of -, lastig te onderscheiden. • Laagnaam wordt lang 3. Als attribuutinformatie • Volledig configureerbaar • Geen impact op de laagnaam • Niet te gebruiken voor aangepaste weergave in de tekening • Buiten scope van huidige NLCS versie • Extra tooling nodig om zichtbaar te maken in de tekening. Zie voor de discussie voorafgaand aan dit voorstel: #327

Graag zou ik nog een vierde alternatief zien waarin de exacte betekenis van de status afhankelijk is van projectfase (ontwerp/oplevering/beheer) waarin het object verkeert. Dit kan binnen de bestaande NLCS-structuur opgelost worden door bijvoorbeeld projectfase aan discipline te hangen (mijn voorstel van vorige week), maar projectfase kan ook op een andere wijze toegevoegd worden aan de NLCS-structuur, wat m.i. een duidelijkere omgang met status bewerkstelligt, dan de toch enigszins onduidelijke definitie van bewerking, die voor netbeheer wel resulteert in een statustoevoeging, en voor andere bewerkingen (op hoogte stellen?) als ik het goed begrijp weer niet.

SanderNijhof commented 5 months ago

Hierbij wordt aangetekend: in de database worden de statussen voor reserve en verlaten kabels alleen opgenomen bij ondergrondse netinfrastructuur;

Dit kan volgens mij niet. Als je een status toevoegt dan doe je dat bij ALLE objecten. Je kunt het wel zo inrichten dat bepaalde statussen alleen in bepaalde hoofdgroepen beschikbaar zijn voor de gebruiker door de laageigenschappen bij een status leeg te laten, zodat de NLCS-tooling herkent dat die status niet voor dat object toegepast kan worden.

SanderNijhof commented 5 months ago

@ElisabethKloren In de tabel met 'Voorstel nieuwe statussen en betekenissen': Als Status 'R' vervalt dan moeten statussen N en NRS wel toegepast mogen worden in de as-built tekening. Die kruisjes ontbreken in de tabel. Dat geld ook voor de statussen G, GRS en GVL: Die wil je ook in je as-built tekening. Anders mis je alsnog de mogelijkheid in je as-built om onderscheid te maken tussen gewijzigde en nieuw toegevoegde objecten. En status 'V' is ook wel handig in de ontwerptekening, zodat je weet dat je wat moet weghalen.

SanderNijhof commented 5 months ago

5. Voor ondergrondse infra, zoals kabels en leidingen maar ook riolering: moet zichtbaar en qua data onderscheid kunnen maken tussen In Bedrijf, Verlaten en Reserve.

Om dat mogelijk te maken ontbreken er nog een aantal statussen in het voorstel. Ik mis: VRS te verwijderen object, in reserve VVL te verwijderen object, verlaten NVL Nieuw of gewijzigd object, verlaten

ElisabethKloren commented 5 months ago

Ja, sorry, ik zie dat er nog wat fout is gegaan bij het overtAIpen. Als ik de voorbeeldteksten krijg pas ik alles aan en dan mail ik de expertcommissie

SanderNijhof commented 5 months ago

Over ‘Afweging gekozen oplossing’ Ik lees bij scenario 1. : ‘Bewerking geeft aan wat er in het project gebeurt met het object’ Dat betekent toch evengoed dat het aantal objecten in de NLCS-database enorm wordt uitgebreid?

SanderNijhof commented 5 months ago

Graag zou ik nog een vierde alternatief zien waarin de exacte betekenis van de status afhankelijk is van projectfase (ontwerp/oplevering/beheer) waarin het object verkeert.

@KristiaanH Dat lijkt mij verwarrend en onhandig. Waarom zou je per projectfase een andere betekenis willen hebben? Dat wil je om het duidelijk te houden toch juist niet?

dan de toch enigszins onduidelijke definitie van bewerking, die voor netbeheer wel resulteert in een statustoevoeging, en voor andere bewerkingen (op hoogte stellen?) als ik het goed begrijp weer niet.

@KristiaanH In een eerder voorstel werd BEWERKING wel in de STATUS voorgesteld, maar volgens het laatste voorstel hierboven worden ook voor de hoofdgroep KL de bewerkingen in de daarvoor opgenomen positie voor BEWERKING in de laagnaam toegevoegd, als ik het nog goed begrijp.

SanderNijhof commented 5 months ago

Verplaatsen van objecten

Voor uitvoering is oude én nieuwe ligging noodzakelijk Object komt dus twee keer in de tekening voor:

De oude ligging van het object zal niet in alle tekeningen voorkomen (voorkomen te drukke tekening).

Dat is niet hoe het in de FB terecht moet komen, daar willen we juist tegenstrijdigheden eruit halen. Tussen de regels door: Bij het verplaatsen van objecten mag de oude ligging van het object achterwege gelaten worden, als dat de leesbaarheid van de tekening ten goede komt. En volgens mij als je helemaal niets hierover opneemt in de FB komt het ook goed, als het verplaatste object op de as-built maar op een G- of N- laag staat en dat is al opgenomen in de tabel met statussen.

SanderNijhof commented 5 months ago

Omdat issue #327 gesloten is en de argumenten voor voorstel #1 en #2 niet sluitend zijn:

Mijn tegenvoorstel blijft: houdt STATUS en SUBOBJECT gescheiden op de plekken die daarvoor in de NLCS-laagnaam zijn ingericht. Met andere woorden: STATUS blijft 1 letter met evt. 2 nummers voor de FASE en objecteigenschappen blijven staan in het veld voor SUBOBJECT. De NLCS-gebruiker merkt dan alleen een wijziging in de tooling en niet in de laagnaam. Dat software leveranciers te veel moeten aanpassen in de tooling betwijfel ik en is ook geen argument zolang we niet het grenzend aan het onmogelijke van ze verlangen: De NLCS is er primair voor de gebruikers.

Ik zie gevaren in scenario 1.:

  1. Het veld STATUS wordt oneigenlijk gebruikt door subobjecteigenschappen erin op te nemen en krijgt een andere betekenis en functie.
  2. Meer keuze betekent ook meer mogelijkheden en meer verschillende uitleggen/interpretaties/verschillende wijzen van gebruik.
  3. Het is niet onaannemelijk dat er meer 3 letterige STATUSsen (moeten) worden toegevoegd waardoor het gebruik van STATUS onoverzichtelijker wordt.
  4. Het is een niet noodzakelijke grote wijziging van de laagnaam-opbouw en de consequenties daarvan zijn nog niet te overzien.

De STATUS wordt nu door gebruikers niet eenduidig toegepast. Ik zie gebeuren dat met de wijziging naar 3 letters de STATUS in plaatst van beter juist verkeerd gebruikt wordt en uiteindelijk geen waarde meer heeft voor het muteren van objectgegevens.

Waar scenario 2 op afgebrand wordt is de enorme toename van het aantal NLCS-objecten. Maar volgens scenario 1. Neemt het aantal NLCS-objecten evengoed fors toe. Ik vind dan ook het voorstel van ‘waardelijsten’ in issue #370 een zeer goed idee ongeacht de keuze van de voorgestelde 3 scenario’s in deze issue.

Als veilig alternatief voor de 3 letterige status wil ik een waardelijst voor TOESTANDen voorstellen: TOESTANDen zijn kenmerken van een object die een resultaat (kunnen) zijn van een in de NLCS opgenomen BEWERKING. Bijv. GERELINED als resultaat van RELINEN; RESERVE als resultaat van IR_STELLEN, VOLGEZAND als resultaat van VOLZANDEN. De toe te voegen TOESTANDen zijn alleen toegestaan bij de statussen B en V en worden aan de laagnaam toegevoegd zodat die ook in combinatie met een BEWERKING mogelijk zijn. Voorbeeld: G-OI-KL-GAS_HD_AANSLUITLEIDING_1 BAR_PE32VERLATEN -G G-OI-KL-GAS_HD_AANSLUITLEIDING_1 BAR_PE32RESERVE-IB_STELLEN-G N-WE-RI-DWATRANSPORTLEIDINGVOLGESCHUIMD-G

Waarbij ‘_RESERVE’ als (in dit geval als 6e formeel niet toegestane) SUBOBJECT is toegevoegd en ‘-IB_STELLEN’ als BEWERKING. Om te voorkomen dat TOESTAND als 6e subobject wordt toegevoegd kan TOESTAND wellicht beter in het veld BEWERKING opgenomen worden: Voorbeeld: G-OI-KL-GAS_HD_AANSLUITLEIDING_1 BAR_PE_32-VERLATEN-G G-OI-KL-GAS_HD_AANSLUITLEIDING_1 BAR_PE_32-RESERVE_IB_STELLEN-G N-WE-RI-DWA_TRANSPORTLEIDING-VOLGESCHUIMD-G

(ik kan nog niet inschatten hoe vaak het voor gaat komen dat TOESTAND met BEWERKING gecombineerd moet worden, is dat alleen bij RESERVE?). Wat mij betreft is dit de enige juiste oplossing. Laten we a.u.b. niet gaan knoeien met het belangrijke veld STATUS.

ElisabethKloren commented 5 months ago

Over ‘Afweging gekozen oplossing’ Ik lees bij scenario 1. : ‘Bewerking geeft aan wat er in het project gebeurt met het object’ Dat betekent toch evengoed dat het aantal objecten in de NLCS-database enorm wordt uitgebreid?

De bewerkingen zijn nu een vrij in te vullen veld, dus leidt niet tot meer objecten in de _NLCS-_database . Ook als bewerkingen een waardelijst worden, neemt het aantal objecten niet toe. Er kunnen door het gebruik van bewerkingen wel meer laagnamen voorkomen. Dat is iets anders.

Dirkjan-CADAC commented 5 months ago

Het voorstel om de revisie status er uit te halen is vanuit onder aanneming niet altijd gewenst. Voorbeeld van een klant: Wij gebruiken de status revisie veelvuldig bij het opleveren van revisie(metingen) aan onze opdrachtgevers. Het is voor de beheerder van onze opdrachtgever in één oogopslag duidelijk welke objecten in zijn beheeromgeving (GIS) gemuteerd moeten worden.

De afweging om de revisie/mutaties niet op de status bestaand of nieuw aan te leveren heb ik in onderstaande voorbeeld omschreven.

Aannemer X heeft het woonrijp maken van een nieuwbouwwijk aangenomen. Aan de ene kant wordt aangesloten op een bestaande weg welke voor de realisatie van het project is ingemeten. Deze data staat op de laag B-ME-###, hierop is zowel het ontwerp als de revisie aangesloten. De status B-ME-## is dus voor de revisie niet te gebruiken, immers is dan geen onderscheid meer te zien. Aan de andere kant van het werk wordt aangesloten op het (nog te realiseren of in realisatie zijnde) werk van aannemer Y. Hier zijn bij aannemer X enkel de ontwerptekeningen van bekend, deze zijn getekend op N-WE-###, de status N-WE/ME is dus ook niet te gebruiken omdat dan het onderscheid ook lastiger te zien is.

SanderNijhof commented 5 months ago

De status B-ME-## is dus voor de revisie niet te gebruiken

Waarom niet? B_ wil in elk geval zeggen dat de objecten niet in het beheersysteem gemuteerd moeten worden. Moet de bestaande ingemeten situatie wel verwerkt worden in het beheersysteem dan moet je die lagen op status N- zetten (of straks kan dat ook optioneel op G-lagen). Door de objecten nieuw in te meten, maak je voor die bestaande objecten gebruik van nieuweobject gegevens in plaatst van de bestaande objectgegevens uit het beheersysteem, vandaar de status N-.

Hier zijn bij aannemer X enkel de ontwerptekeningen van bekend, deze zijn getekend op N-WE-###, de status N-WE/ME is dus o

De N- lagen die nog niet gerealiseerd zijn zouden op een ontwerptekening moeten staan en de N- lagen die wel gerealiseerd zijn op de as-built tekening. Dus 2 verschillende tekeningen. Visueel zijn de N- en R- lagen identiek dus dat onderscheid is er standaard niet.

KristiaanH commented 5 months ago

Dirk jan, die laatste logica volg ik niet helemaal. De nog aan te leggen weg kan / moet nog niet gemeten worden en zal dus op de as-built niet aanwezig zijn. Het onderscheid tussen N-WE (nog niet gerealiseerd) en N-ME (wel gerealiseerd) lijkt mij een duidelijke, zodra iedereen hiermee bekend is / alert op is. Met een substatus B, O, M (bestaand, ontwerp, gemeten) zou je daar wel meer helderheid in kunnen scheppen, maar het voorstel was erop gericht het binnen de bestaande NLCS-structuren op te lossen.

ElisabethKloren commented 3 months ago

EC 6-6-2024: Het probleem is voor de expertcommissie helder: op tekening moet je een andere visualisatie hebben voor kabels die in reserve of verlaten zijn.

Er blijkt wel spraakverwarring te zijn: Dit is iets anders dan de bewerking, de bewerking geeft aan wat er tijdens het werk moet gebeuren aan het object; maar niet dat een object al verlaten of reserve is bij aanvang van het werk.

Er wordt fundamenteel bezwaar gemaakt tegen het gebruik van het veld status, omdat dat een onderdeel is van de “ordening” van NLCS, en "reserve" en "in verlaten" objectinformatie zijn

Zoektocht is naar een oplossing die (a) werkt voor cad-tekeningen (b) goed te automatiseren valt en (c) de eindgebruikers die aan het tekenen is niet te veel werk opleveren.

Het huidige voorstel levert te veel bezwaren op om tot een voorstel te komen.

Afspraak: er komt een datumprikker vanuit Elisabeth, de dag dat de meeste mensen kunnen gaan we live in een hok zitten tot we een goede oplossing hebben gevonden.

PHaffmans commented 3 months ago

Ter voorbereiding op onze bijeenkomst op 03-07-2024:

Zoals jullie al wel gemerkt hebben ben ik principieel en faliekant tegen het toevoegen van de extra fysieke statussen voor ondergrondse infra aan de bestaande tekenstatussen in de huidige NLCS structuur en wel om twee redenen:

  1. De huidige status is een tekenstatus en wordt gebruikt voor ordening van elementen (zie ook het commentaar van Elisabeth op 3 april eerder in dit issue en uiteraard de FB). Daar hoort een status die de fysieke toestand van een object buiten betreft niet bij.
  2. Als we dit nu toestaan voor Netbeheerders, wat dan te doen als er straks ook andere disciplines komen die dit willen, bv Spoor. Die hebben ook een 'buiten gebruik'. Hoe ga je dan het onderscheid maken tussen de ene en de andere status en hoe ga je de bijbehorende representatie regelen (maw: hoe zorgen we ervoor dat een buitengebruik zijnde spoor niet dezelfde representatie krijgt als een verlaten leiding).

De mooiste oplossing is volgens mij de beoogde status in een attribuut onder te brengen, maar zo ver zijn we nog niet met de NLCS en ik begrijp het dat de netbeheerders daar niet op kunnen/willen wachten.

In mijn optiek is dan het veld 'bewerking' het meest geschikt om, naast de huidige bewerkingen, ook statussen van fysieke objecten te beschrijven. Het beste kan dit dan door middel van domeinlijsten (picklisten) die gekoppeld kunnen worden aan een of meerdere specifieke (sub)objecten en waarin aanvullend een afwijkende presentatie meegegeven kan worden. De software kan deze domeinlijsten als optie aan de gebruiker presenteren zodra een specifiek (sub)object geplaatst of bewerkt gaat worden. De huidige CAD paketten zijn prima in staat lagen te filteren op deze 'bewerking' of 'status', ook al staat die achteraan in de levelnaam, zodat een constructeur in een oogopslag bv alleen de 'verlaten' leidingen kan selecteren. Voorwaarde is uiteraard wel een uniforme benaming van de statussen en of bewerkingen. Domeinlijsten zouden door Digigo aangeleverd en beheerd kunnen worden en de huidige Linked Data database leent zich hier uitstekend voor. Voor software leveranciers betekent dit uiteraard wel een aanpassing in hun software, maar weinig meer dan de aanpassing die gedaan zou moeten worden als de fysieke status aan de tekenstatus zou worden toegevoegd, maar is wel veel makkelijker onderhoudbaar en beheersbaar omdat de domeinlijsten voor ieder object in een fysieke status een eigen representatie kunnen geven, hetgeen bij het toevoegen van de fysieke status aan de tekenstatus niet lukt.

Bovenstaand voorstel houdt de huidige NLCS Ordening en Codering volledig in stand, is uitbreidbaar voor andere objecten dan alleen ondergrondse infra, geeft de mogelijkheid van aangepaste weergave per object met een bepaalde fysieke status en voorkomt het dupliceren van objecten naar separate objecten-met-een-fysieke-status.

MvanderHulst commented 2 months ago

@ElisabethKloren en @PHaffmans. Ik snap zeker de zorgen en kan mij er deels ook in vinden. Het 'punt 2' wat je aandraagt ben ik echter niet bang voor. Als het aanvullende statussen worden, zijn het aanvullende kolommen in de database, dit is een invuloefening, wat niet anders is dan de bestaande situatie, maar slecht met behoorlijke uitbreidingen.

Passend in het huidige model ben ik het 100% met je eens dat de BEWERKING de perfecte positie hiervoor is. Om het werkbaar te maken voor de eindgebruiker MOET dicht dan echter als een pick-list ontsloten worden, net als nu snel tussen statussen gekozen kan worden. Op het moment dat de BEWERKING bij het maken van de lagen eigenlijk als een SUBOBJECT wordt behandeld, wordt dit een onwerkbaar scenario.

Vanuit 'ordening' in het CAD-model is het aanvullen van de statussen wel de meest overzichtelijke werkmethodiek voor de eindgebruikers.

Belangrijkste vraag is: volgens mij: 'Wat is belangrijker?

Als de aanvullende statussen heel specifiek voor ONDERGRONDSE INFRA worden beschreven verwacht ik echt geen gekke problemen.

Het voorbeeld van Spoor vind ik geen representatief voorbeeld. Met enig gezond verstand is uit te leggen dat de enorme spaghetti van kabels onder de grond andere inzichten nodig hebben dan een spoorlijn die 1 bedrijf zelf in beheer heeft.

Tot slot is de NLCS voor de Infra-sector. Als bij het opstellen van de NLCS de WIBON regelgeving daarin niet is opgenomen... is hier dan door de NLCS niet al JAREN de plank misgeslagen, en moeten we juist dit gemis nu goed faciliteren?

ElisabethKloren commented 2 months ago

De oplossingsrichting van @PHaffmans staat als één van de oplossingen genoemd in de voorbereiding van de expertsessie over dit bijeenkomst van 3 juni:

Objectstatus opnemen bij bewerking, afspreken hoe dit te onderscheiden van bewerking (bestaand / verlaten: in bewerking staat objectstatus; nieuw: in bewerking staat objectstatus + bewerking van het object)

Er komen dan twee soorten dingen in het veld bewerking te staan: [Objectstatus verlaten / in reserve] en [BEWERKING]

De visualisatie van de [Objectstatus verlaten / in reserve] hangt af van de combinatie met de [NLCS status]: B + VL is een andere visualisatie dan N + VL

Qua publicatie in de NLCS database komt het nog steeds neer op 15 extra velden / kolommen, voor elke voorkomende combinatie van status + objectstatatus een kleur, lijnstijl en lijnweigt

PHaffmans commented 2 months ago

Hoi Michel,

Dank voor je reactie, maar zonder al op de hele discussie van morgen vooruit te lopen wil ik al wel twee opmerkingen terug plaatsen:

Belangrijkste vraag is: volgens mij: 'Wat is belangrijker?

Het voorbeeld van Spoor vind ik geen representatief voorbeeld. Met enig gezond verstand is uit te leggen dat de enorme spaghetti van kabels onder de grond andere inzichten nodig hebben dan een spoorlijn die 1 bedrijf zelf in beheer heeft. Ik heb Spoor hier als willekeurig voorbeeld gebruikt, maar dit kan net zo goed voor ieder andere objectsoort gelden, maar dan met andere, eigen statussen. Bv verbanden bij bestratingen om maar eens iets geks te noemen. Er wordt nu te eng alleen naar kabels en leidingen gekeken.

Gr,

Paul ~~

Met vriendelijke groet,

Paul Haffmans Senior consultant,

@.***

Bentley Qualified trainer for MicroStation

@.***http://www.thepeoplegroup.nl/

The People Group | Software & Trainingen Middelweg 2 | 5253 CA, NIEUWKUIJK | Nederland M +31(0)6 55 165 140<tel:+31655165140> | T +31(0)85 22 40 000<tel:+31852240000>

Click for disclaimerhttps://www.thepeoplegroup.nl/e-mail-disclaimer/

Van: Michel van der Hulst @.> Verzonden: Tuesday, 2 July 2024 09:22 Aan: nl-digigo/NLCS @.> CC: Paul Haffmans | The People Group @.>; Mention @.> Onderwerp: Re: [nl-digigo/NLCS] Ter consultatie: Voorstel extra statussen voor ondergrondse infra en voor overdracht van gegevens naar beheerpakketten (Issue #371)

@ElisabethKlorenhttps://github.com/ElisabethKloren en @PHaffmanshttps://github.com/PHaffmans. Ik snap zeker de zorgen en kan mij er deels ook in vinden. Het 'punt 2' wat je aandraagt ben ik echter niet bang voor. Als het aanvullende statussen worden, zijn het aanvullende kolommen in de database, dit is een invuloefening, wat niet anders is dan de bestaande situatie, maar slecht met behoorlijke uitbreidingen.

Passend in het huidige model ben ik het 100% met je eens dat de BEWERKING de perfecte positie hiervoor is. Om het werkbaar te maken voor de eindgebruiker MOET dicht dan echter als een pick-list ontsloten worden, net als nu snel tussen statussen gekozen kan worden. Op het moment dat de BEWERKING bij het maken van de lagen eigenlijk als een SUBOBJECT wordt behandeld, wordt dit een onwerkbaar scenario.

Vanuit 'ordening' in het CAD-model is het aanvullen van de statussen wel de meest overzichtelijke werkmethodiek voor de eindgebruikers.

Belangrijkste vraag is: volgens mij: 'Wat is belangrijker?

Als de aanvullende statussen heel specifiek voor ONDERGRONDSE INFRA worden beschreven verwacht ik echt geen gekke problemen.

Het voorbeeld van Spoor vind ik geen representatief voorbeeld. Met enig gezond verstand is uit te leggen dat de enorme spaghetti van kabels onder de grond andere inzichten nodig hebben dan een spoorlijn die 1 bedrijf zelf in beheer heeft.

Tot slot is de NLCS voor de Infra-sector. Als bij het opstellen van de NLCS de WIBON regelgeving daarin niet is opgenomen... is hier dan door de NLCS niet al JAREN de plank misgeslagen, en moeten we juist dit gemis nu goed faciliteren?

— Reply to this email directly, view it on GitHubhttps://github.com/nl-digigo/NLCS/issues/371#issuecomment-2202150290, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCNET7LBHGEHPWPP24MDKVTZKJIHXAVCNFSM6AAAAABFU6H5NCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBSGE2TAMRZGA. You are receiving this because you were mentioned.Message ID: @.**@.>>

ElisabethKloren commented 2 months ago

In werksessie op 3 juli 2024 heeft de expertcommissie het volgende vastgesteld:

Probleemdefinitie

image

8 extra combinaties = 24 “kolommen” erbij in de database

Criteria

image

image

image

image

image

image

image

Oplossingsrichtingen

Gekozen oplossing: veld bewerking splitsen

Er komen twee soorten dingen in het veld bewerking te staan: [bedrijfstoestand] en BEWERKING;

  1. Scheidingsteken: onderliggend streepje = underscore alleen gebruiken als er twee staan
  2. bedrijfstoestand altijd tussen blokhaken plaatsen (wat: OP DE KOP = bewerking met spaties)
  3. De bedrijfstoestand wordt voluit geschreven > keuze voor direct begrijpen ook door gebruikers van de tekening die niet bekend zijn met netten / dit weegt op tegen kortere laagnaam
  4. Check database: max 255 tekens

N-**-KL-BRANDSTOF_TRANSPORTLEIDING_STAAL-[RESERVE]_VOLSCHUIMEN-G

De visualisatie van de bewerking hangt af van de combinatie met de [tekenstatus]: B + VL is een andere visualisatie dan N + VL

Qua publicatie in de NLCS database komt het nog steeds neer op 24 extra velden / kolommen, voor elke voorkomende combinatie van status + objectstatatus een kleur, lijnstijl en lijnweight

Eisen aan software moeten worden uitgewerkt op basis van de criteria

ElisabethKloren commented 2 months ago

Toegevoegde eisen aan applicaties:

  • De applicatie dient bij het tekenen van een object het invullen van de STATUS en de OBJECTTOESTAND als keuzelijst aan te bieden, en daarbij te zorgen dat de gebruiker alleen de toegestane combinaties kan selecteren.
  • De applicatie moet mogelijk maken een reeds getekend object van STATUS en OBJECTTOESTAND te laten wisselen, en daarbij te zorgen dat de gebruiker alleen de toegestane combinaties kan selecteren. Bestaande eis aangevuld met objecttoestand
  • De objecten die op een in de standaard gedefinieerde laag getekend worden, moeten per STATUS en per OBJECTTOESTAND de presentatie (kleuren, lijnstijlen en lijndiktes) krijgen die NLCS voorschrijft. Daarbij geldt dat Lagen met de STATUS “R” dezelfde eigenschappen moeten krijgen als lagen met de STATUS “N”.
    • SanderNijhof commented 2 months ago

    N-**-KL-BRANDSTOF_TRANSPORTLEIDING_STAAL-[RESERVE]_VOLSCHUIMEN-G

    De visualisatie van de bewerking hangt af van de combinatie met de [tekenstatus]: B + VL is een andere visualisatie dan N + VL

    Wat bedoel je met 'VL'?

    Een laag kan maar 1 presentatie hebben, dus of

    Qua publicatie in de NLCS database komt het nog steeds neer op 24 extra velden / kolommen, voor elke voorkomende combinatie van status + objectstattus een kleur, lijnstijl en lijnweight

    Nee toch? Dit zou toch opgenomen worden in de 'picklisten'? 0 extra kolommen in de database.

    ElisabethKloren commented 2 months ago

    N-**-KL-BRANDSTOF_TRANSPORTLEIDING_STAAL-[RESERVE]_VOLSCHUIMEN-G De visualisatie van de bewerking hangt af van de combinatie met de [tekenstatus]: B + VL is een andere visualisatie dan N + VL

    Wat bedoel je met 'VL'?

    Het gaat om de combinatie van B (tekenstatus bestaand) met objecttoestand Verlaten > deze combinatie geeft een andere presentatie van de combinatie van N (tekenstatus Nieuw) met objecttoestand Verlaten

    De bewerking, in dit geval volschuimen, wordt gepubliceerd als eigen laagnaam / subobject, er bestaan dus deze twee: KL-BRANDSTOF_TRANSPORTLEIDING_STAAL KL-BRANDSTOF_TRANSPORTLEIDING_STAAL-VOLSCHUIMEN

    Bij beide lagen wordt gedefinieerd wat de representatie is van alle combinaties van STATUS en OBJECTTOESTAND

    ElisabethKloren commented 2 months ago

    Qua publicatie in de NLCS database komt het nog steeds neer op 24 extra velden / kolommen, voor elke voorkomende combinatie van status + objectstattus een kleur, lijnstijl en lijnweight

    Nee toch? Dit zou toch opgenomen worden in de 'picklisten'? 0 extra kolommen in de database.

    Er is een verschil tussen hoe het moet werken in de applicatie en hoe we dit gaan publiceren in de NLCS database:

    Er komen nog geen keuzelijsten voor bewerkingen, dit blijft als gebruikerswens op de backlog staan (> maar kan al wel worden ingebouwd in de software, omdat in de NLCS database herkenbaar is als er bewerkingen zijn toegevoegd aan objecten).

    SanderNijhof commented 2 months ago
    • In de NLCS database wordt dit waarschijnlijk geregeld door extra attributen ("24 extra kolommen") aan het object toe te voegen > de exacte technische uitwerking zal ik nog met de softwareleveranciers toetsen.

    Nee dat hoop ik toch niet!! In de database neem je bij het object op welke picklist (met objecttoestanden en bewerkingen) bij het object hoort en in de (een) database neem je de inhoud van elke picklist op. Dat is het voordeel van de picklisten. Dan is implementatie, controle en uitbreiding van objecttoestand/bewerking per object eenvoudig en overzichtelijk.

    Er komen nog geen keuzelijsten voor bewerkingen, dit blijft als gebruikerswens op de backlog staan (> maar kan al wel worden ingebouwd in de software, omdat in de NLCS database herkenbaar is als er bewerkingen zijn toegevoegd aan objecten).

    Dat is energieverspilling: Keuzelijst voor OBJECTTOESTAND=keuzelijst voor BEWERKING. Dat is de enige mogelijkheid, dezelfde systematiek en dezelfde manier van opnemen in de database.

    PHaffmans commented 2 months ago

    Dit klopt Elisabeth en Sander,

    Het maakt niet uit hoe het in de database wordt opgeslagen als we maar:

    1. aan het object gerelateerde piklisten kunnen maken
    2. per status-bedrijfstoestand afwijkende representatie kunnen gegeven.

    Ik denk idd niet dat we dat gaan redden met de extra kolommetjes in de objectentabel maar mogelijk ook wel. Daarom gaf ik al aan dat het handig is hier de programmeurs van de leveranciers en de databasebeheerder bij te betrekken, die hebben daar een veel betere kijk op dan ik.

    Gr,

    Paul ~~

    Met vriendelijke groet,

    Paul Haffmans Senior consultant,

    @.***

    Bentley Qualified trainer for MicroStation

    @.***http://www.thepeoplegroup.nl/

    The People Group | Software & Trainingen Middelweg 2 | 5253 CA, NIEUWKUIJK | Nederland M +31(0)6 55 165 140<tel:+31655165140> | T +31(0)85 22 40 000<tel:+31852240000>

    Click for disclaimerhttps://www.thepeoplegroup.nl/e-mail-disclaimer/

    Van: Elisabeth de Vries @.> Verzonden: Thursday, 4 July 2024 14:37 Aan: nl-digigo/NLCS @.> CC: Paul Haffmans | The People Group @.>; Mention @.> Onderwerp: Re: [nl-digigo/NLCS] Ter consultatie: Voorstel extra statussen voor ondergrondse infra en voor overdracht van gegevens naar beheerpakketten (Issue #371)

    Qua publicatie in de NLCS database komt het nog steeds neer op 24 extra velden / kolommen, voor elke voorkomende combinatie van status + objectstattus een kleur, lijnstijl en lijnweight

    Nee toch? Dit zou toch opgenomen worden in de 'picklisten'? 0 extra kolommen in de database.

    Er is een verschil tussen hoe het moet werken in de applicatie en hoe we dit gaan publiceren in de NLCS database:

    Er komen nog geen keuzelijsten voor bewerkingen, dit blijft als gebruikerswens op de backlog staan (> maar kan al wel worden ingebouwd in de software, omdat in de NLCS database herkenbaar is als er bewerkingen zijn toegevoegd aan objecten).

    — Reply to this email directly, view it on GitHubhttps://github.com/nl-digigo/NLCS/issues/371#issuecomment-2208874053, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCNET7IJYZJV6QDTICY7WSDZKU6X7AVCNFSM6AAAAABFU6H5NCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBYHA3TIMBVGM. You are receiving this because you were mentioned.Message ID: @.**@.>>

    SanderNijhof commented 2 months ago

    Er komen nog geen keuzelijsten voor bewerkingen

    Realiseerde me ineens dat je wellicht bedoeld: Er komen aparte picklisten voor OBJECTTOESTAND en picklisten voor BEWERKING. Dat gaat volgens mij niet werken en wordt te complex. Ik denk dat de beste mogelijkheid is picklisten waarin per (teken)STATUS alle mogelijkheden voor de inhoud van het veld BEWERKING zijn opgenomen. Bijv. een picklist voor (teken)status 'B' [RESERVE], lijnkleur,lijndikte,lijnstijl [VERLATEN], lijnkleur,lijndikte,lijnstijl

    en een picklist voor (teken)status 'N': [RESERVE], lijnkleur,lijndikte,lijnstijl [VERLATEN], lijnkleur,lijndikte,lijnstijl [RESERVE]_IN GEBRUIK STELLEN, lijnkleur,lijndikte,lijnstijl

    Of je geeft in de picklist aan voor welke (teken)STATUS de regel van toepassing is: B;N;R;T, [RESERVE], lijnkleur,lijndikte,lijnstijl (als presentatie voor deze statussen gelijk zijn) V, [RESERVE], lijnkleur,lijndikte,lijnstijl B, [VERLATEN], lijnkleur,lijndikte,lijnstijl V, [VERLATEN], lijnkleur,lijndikte,lijnstijl (als V-VERLATEN een andere lijnstijl heeft dan B-VERLATEN) N;R, [RESERVE]_IN GEBRUIK STELLEN, lijnkleur,lijndikte,lijnstijl

    (even niet lettend of bovenstaande picklisten compleet zijn en de juiste benamingen gebruiken, gaat om het principe) Dan houd je de regie over de combinaties van OBJECTTOESTAND en BEWERKING, en is de bijbehorende presentatie en controle éénduidig: Voor de gebruiker en de implementatie in de software eenvoudiger.

    Dat bedoelde ik met "Keuzelijst voor OBJECTTOESTAND=keuzelijst voor BEWERKING". Je doet maar 1 keer een aanpassing in de software voor de inhoud van het veld 'BEWERKING' in de laagnaam en pakt daarmee gelijk beide oplossingen.

    Hoe en of de picklisten opgenomen worden in de database weet ik niet.

    ElisabethKloren commented 1 month ago

    issue is gesplitsts naar #461 voor release 5.1; dit issue vraagt ook om aanpassing status voor mutaties in beheersystemen, dat plaats ik daarom weer op de backlog, dat gaat niet mee in 5.1