input stedelijk spoor, hoofdgroep AL

[ElisabethDeVries]

Toelichting: De hoofdgroep AL is primair bedoeld voor de algemene aankleding van een tekening in de ‘layout’ omgeving en algemene aankleding van details.

input werkgroep: https://github.com/nl-digigo/NLCS/blob/main/ontwikkeling/stedelijk%20spoor/2024-10-28/HBA_AL-Algemeen.20241004.xls

Vraag aan werkgroep:
Kan worden toegelicht wat de toepassing is van object: assetbeschrijving, assetgrens, assetkader en assetnummer?

Vraag aan werkgroep en productmanager:
Object Tabel is toegevoegd, welke ontbreekt in de NLCS.
Aanvullend zijn diverse soorten tabellen als ‘subobjecten’ toegevoegd. Dit zijn zéér specifieke tabellen. Zodoende een tweetal vragen:

• Is het noodzakelijke om elke soort tabel op een eigen layer te zetten?
• Is het gewenst dat voor alle soorten tabellen een subobject wordt opgenomen? Als we GWW-breed beschouwen wordt dat een enorme lijst aan mogelijkheden.
  Voorstel is om de subobjecten voor tabellen achterwege te laten. Als dit wel gewenst is stel ik voor om onder ‘SB’ een eigen object Tabellen aan te maken met de sub-soorten erin en dan in AL achterwege te laten.

Vraag aan werkgroep:
Kan worden toegelicht wat wordt bedoeld met objecten ‘tekenblad_werkzaamheden’ en alle varianten hierop?

Ter info:
VERWIJZIGING_DOORSNEDE is reeds onderdeel van de NLCS. Hiervoor is in versie 5.1 al een aangepast lijntype AL-DOORSNEDE-SO

[ElisabethDeVries]

We gaan alleen het object "tabel" aanmaken; het is dan altijd mogelijk om individuele laagnamen te maken in aanvulling op NLCS. Om grote hoeveelheden laagnamen voor elke discipline te voorkomen.

[ElisabethDeVries]

11-11-2024 werkgroep stedelijk spoor

Vraag aan werkgroep: Kan worden toegelicht wat de toepassing is van object: assetbeschrijving, assetgrens, assetkader en assetnummer?
Op de DO/bestekstekeningen krijgen de assets een nummer en van de assets staan de belangrijkste gegevens op tekening
Vanuit NLCS logica is hoofdgroep algemeen bedoeld voor de plotomgeving, zoals kaders et cetera, is dat als onderdeel van het model, of voor op de plotomgeving?
antwoord; dit wordt op de plotomgeving gezet
dan hebben we uitleg nodig voor in de documentatie
actie @ehensing en marco om voorbeeld tekening te delen

• Is het noodzakelijke om elke soort tabel op een eigen layer te zetten?
  Het is niet nodig om de tabellen op verschillende lagen te zetten, dit is meegekomen vanuit de historie. Dit mag dus wat mij betreft zonder subobjecten
  Variaties qua tabellen, blokken, et cetera kan in één laag worden samengevat
  actie @ElisabethKloren geen subobjecten opnemen

Vraag aan werkgroep: Kan worden toegelicht wat wordt bedoeld met objecten ‘tekenblad_werkzaamheden’ en alle varianten hierop?
Dit is de laag waarop wij op de bestekstekeningen de werkzaamheden beschrijven en nummeren. Mag niet weg
Zijn onderdelen in de model, maar bedoeld om te kunnen kiezen om dit wel of niet te visualiseren op de tekeningen.
Opnemen als AL-WERKZAAMHEDEN los van tekenblad? @MvanderHulst checkt dit met Marco

Ter info: VERWIJZIGING_DOORSNEDE is reeds onderdeel van de NLCS. Hiervoor is in versie 5.1 al een aangepast lijntype AL-DOORSNEDE-SO
S is toegevoegd om de doorsnede pijlen als symbool te kunnen plaatsen
@michel checkt of dit foutje in de database is

[ehensing]

Voorbeeld tekeningen discipline sporen (hoofdgroep SB), niet alle kleuren en lijnstylen komen overeen met de voorgestelde objecten lijst

P500-538-BO-HTM-IB-SPO-00056 versie 0.pdf
P500-538-BO-HTM-IB-SPO-00057 versie 0.pdf
P500-538-BO-HTM-IB-SPO-00058 versie 0.pdf
P500-538-BO-HTM-IB-SPO-00059 versie 0.pdf
P500-538-BO-HTM-IB-SPO-00060 versie 1.pdf
P500-538-BO-HTM-IB-SPO-00061 versie 1.pdf
P500-538-BO-HTM-IB-SPO-00062 versie 1.pdf
P500-538-BO-HTM-IB-SPO-00063 versie 3.pdf
P500-538-BO-HTM-IB-SPO-00082 versie 0.pdf
P500-538-DO-HTM-IB-SPO-00028 versie 0.pdf
P500-538-DO-HTM-IB-SPO-00029 versie 1.pdf
P500-538-DO-HTM-IB-SPO-00030 versie 1.pdf
P500-538-DO-HTM-IB-SPO-00031 versie 3.pdf
P500-538-DO-HTM-IB-SPO-00032 versie 2.pdf
P500-538-DO-HTM-IB-SPO-00049.pdf
P500-538-DO-HTM-IB-SPO-00037 versie 2.pdf

[ehensing]

Voorbeeldtekeningen van onze discipline WSB (hoofdgroep IS):

P062-096-DO-HTM-IB-WSB-00021 versie 1.pdf
P062-096-DO-HTM-IB-WSB-00037 versie 1.pdf
P062-096-DO-HTM-IB-WSB-00042 versie 5.pdf

[ehensing]

Voorbeeldtekeningen van onze discipline bovenleiding (hoofdgroep ES):

P500-538-DO-HTM-IB-SVZ-00046.pdf
P500-538-DO-HTM-IB-SVZ-00047.pdf
P500-538-DO-HTM-IB-SVZ-00048.pdf

[ehensing]

Voorbeeldtekeningen van onze discipline elektrische tractie (o.a. hoofdgroep KL):

P500-538-BO-HTM-IB-SVZ-00139.pdf
P500-538-BO-HTM-IB-SVZ-00138.pdf

[MvanderHulst]

Toelichting: De hoofdgroep AL is primair bedoeld voor de algemene aankleding van een tekening in de ‘layout’ omgeving en algemene aankleding van details.

Vraag aan werkgroep:
Kan worden toegelicht wat de toepassing is van object: assetbeschrijving, assetgrens, assetkader en assetnummer?
Op de DO/bestekstekeningen krijgen de assets een nummer en van de assets staan de belangrijkste gegevens op tekening

Helder, een aantal objecten zijn nu uitgeschreven, maar kunnen worden ondervangen door gebruik te maken van de elementen van de NLCS.
Voorstel om op te nemen in hoofdgroep ZZ, hiermee kan hij op alle hoofdgroepen geplaatst worden en dus ook op AL, meer generieke flexibliteit.
-	ASSET
o	Kan met element ‘G’ geplaatst worden voor het maken van een ‘kader’.
o	Kan met element ‘T’ worden geplaatst voor tekst / beschrijving
-	ASSET_NUMMER
o	Kan met element ‘T’ worden geplaatst voor nummer
-	ASSET_GRENS
o	Kan met element ‘G’ worden geplaatst voor de grens.
Elisabeth:
	Deze logica zou ik graag voor alle GRENS_ objecten in AL willen toepassen. In de huidige structuur is wel bijvoorbeeld GRENS_FASE aanwezig, maar is er eigenlijk, geen optie om het fasenummer te plaatsen. Eerst filtering op ‘GRENS_ is zodoende onlogisch.

Vraag aan werkgroep en productmanager:
Object Tabel is toegevoegd, welke ontbreekt in de NLCS.
Aanvullend zijn diverse soorten tabellen als ‘subobjecten’ toegevoegd. Dit zijn zéér specifieke tabellen. Zodoende een tweetal vragen:

• Is het noodzakelijke om elke soort tabel op een eigen layer te zetten?
  Het is niet nodig om de tabellen op verschillende lagen te zetten, dit is meegekomen vanuit de historie. Dit mag dus wat mij betreft zonder subobjecten
  Voorstel is om ‘TABEL’ op te nemen in hoofdgroep ZZ. Hiermee wordt generieke toepasbaarheid mogelijk.
• Is het gewenst dat voor alle soorten tabellen een subobject wordt opgenomen? Als we GWW-breed beschouwen wordt dat een enorme lijst aan mogelijkheden.
  Voorstel is om de subobjecten voor tabellen achterwege te laten.

Vraag aan werkgroep:
Kan worden toegelicht wat wordt bedoeld met objecten ‘tekenblad_werkzaamheden’ en alle varianten hierop?
Dit is de laag waarop wij op de bestekstekeningen de werkzaamheden beschrijven en nummeren. Mag niet weg

De wens is om een ‘algemene’ positie te hebben waar in het kader toelichting/opmerkingen geplaatst kan worden. In dit geval gaat het specifiek op werkzaamheden.

Voorstel om hoofdgroep ZZ aan te vullen met object: OMSCHRIJVING en OMSCHRIJVING_NUMMER
Hiermee kan in elke hoofdgroep een ‘algemene’ geometrie en tekstlaag worden aangemaakt, voor aanvullende teksten/notities. Aanvullend op het standaard object ‘VERKLARING’

Ter info:
VERWIJZIGING_DOORSNEDE is reeds onderdeel van de NLCS. Hiervoor is in versie 5.1 al een aangepast lijntype AL-DOORSNEDE-SO
S is toegevoegd om de doorsnede pijlen als symbool te kunnen plaatsen
Akkoord.

Conclusie:
De wensen zijn allemaal generiek en niet ‘Spoorbouw’ afhankelijk. Zodoende is ZZ een prima oplossing om e.e.a. in kwijt te kunnen. Vanuit de NLCS logica wordt iets minder ‘lagen’ toegevoeg en is het gewenst om meer met ‘elementen’ het onderscheid te maken. Dit resulteerd dat geen aanvullingen/wijzigingen in AL noodzakelijkzijn (m.u.v. de wijziging voor 'doorsnede'.

[ehensing]

Vraag aan werkgroep:
Kan worden toegelicht wat de toepassing is van object: assetbeschrijving, assetgrens, assetkader en assetnummer?
Op de DO/bestekstekeningen krijgen de assets een nummer en van de assets staan de belangrijkste gegevens op tekening

In onze testdatabase gebruiken wij nu één laag voor alle asset informatie, nu: *-**-AL-ASSETNUMMER-G/S/T.
Mag van mij ook een andere laagnaam worden, bv: ASSETNFORMATIE of ASSETBESCHRIJVING

[MvanderHulst]

@ehensing Goed te horen dat er al samengevoegd wordt.
Ik kan mij voorstellen dat je met bijvoorbeeld ASSETINFORMATIE het element G S en T kan gebruiken voor alle losse objecten welke nu in het voorstel zitten. Is het gewenst dat een assetbeschijving en een nummer los van elkaar 'aan en uit' gezet worden?
Zoniet, zou je alles op ASSETINFORMATIE-T** kwijt kunnen, anders is een los SUBOBJECT voor het nummer wel praktijk.

[ehensing]

Het volgende zip-bestand bevat symbolen voor van trams:
20241202 - Aankleding trams symbolen SAL.zip