search

nl-digigo / NLCS

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

Variant lijnstylen: staat in de standaard vanaf 5.0, maar leveranciers ondersteunen het nog niet #176

Closed NielsNederpel closed 1 month ago

NielsNederpel commented 10 months ago

Zijn de "variant" lijnstylen makkelijk toe te passen via de NLCS tooling? mijn ervaring met InfraCAD is dat deze "handmatig" moeten worden toegekend aan een object. dan wordt deze echter gezien "fout" (zie afbeelding) en daarnaast wordt deze overschreven bij het opnieuw tekenen van eenzelfde object e.e.a. kan/hoort uiteraard te worden opgelost met een projectenbibliotheek, maar als men "niet weet" dat e.e.a. bestaat wordt dit niet gebruikt. alleen een tekstuele uitleg in de Formele beschrijving lijkt niet even goed te landen. Kan hier de tooling iets in betekenen?

Controle variant lijnstyle

ElisabethKloren commented 10 months ago

Vraag aan experts van leveranciers: (1) of dit werkt zoals bedoeld in je applicatie en (2) of er een handiger manier is om deze uitzondering te publiceren als onderdeel van de standaard?

ElisabethKloren commented 10 months ago

De formele specificatie staat hier: https://nl-digigo.github.io/NLCS/code_documentation/#bijlage-1-lijnstijlen-varianten

SanderNijhof commented 10 months ago

Het wijzigen van een lijnstijl die bij een laag hoort is altijd toegestaan (toch?). De melding die de controletooling hierboven geeft is correct en is geen "fout" melding. Dat eigenschappen van een bestaande laag ongevraagd worden gewijzigd is niet erg vriendelijk... Het zou inderdaad wel mooi/luxe zijn als de tooling herkend dat er meerdere varianten van lijnstijlen voor de betreffende laagnaam mogelijk zijn, maar dat is service van de softwareleverancier.

ElisabethKloren commented 10 months ago

Dan zullen we in elk geval moeten verduidelijken wat wel en niet gevraagd wordt van de softwareleveranciers qua checks en hoe variant linestyles aangeboden moeten worden

ElisabethKloren commented 6 months ago

ik vind dit nog steeds een ongelukkige manier van werken, varianten bedenken maar die niet publiceren. Kunnen deze varianten niet gewoon in de database worden opgenomen? Dit werkt toch niet???

MvanderHulst commented 4 months ago

De VARIANTEN lijn bedacht, om van de 100-den lijntypes terug te kunnen naar een aantal varianten. Dit is prima voor gebruik in de praktijk. De varianten worden nu via de NLCS wel aangeboden, maar kunnen niet worden toegepast binnen de applicaties. Het doel van de varianten is om, indien een specifieke tekening erom vraagt, een aangepast lijntype te kunnen toekennen aan een object. Dit is dus niet op databaseniveau, maar op DWG-niveau. Dit staat dus helemaal los van het 'aanpassen van de database' als gebruiker. Verschillende objecten hebben gewoon 2 mogelijke lijntypes beschikbaar.

ElisabethKloren commented 3 months ago

Vraag aan EC is: dit lijkt op een aanpassing die consequenties heeft voor de software, maar is al beschreven in de documentatie 5.0. Toch is het dilemma: kan dit geïmplementeerd worden in 5.1 of moet dit op de langere termijn gepland worden, daar het nog niet in de eisen aan software-implementaties stond.

of is er een betere manier om deze variant lijntypes te publiceren en te kunnen verwerken in de software?

of moet alleen ge-eist worden dat de foutrapportage geen foutmelding geeft?

of is dit een heel ongelukkige manier om de standaard complexer te maken? En moeten we weer terug naar de oude werkwijze?

voorbeeld 12 afmetingen van opsluitbanden. Die hadden een eigen lijntype, nu niet meer. Ze hebben nu hetzelfde lijntype; als je twee soorten hebt in je project, kun je uit deze lijst een tweede type kiezen. Ook voor een nieuw object. Omdat de leveranciers dit niet ondersteunen, hebben de gebruikers nu geen keuze en krijgen alle maten opsluitbanden hetzelfde lijntype.

ElisabethKloren commented 3 months ago

@expertcommissie: als we weer meer kantopsluitingen in NLCS opnemen met eigen lijnstijlen, dan kunnen we deze methode met variant lijnstijlen weer schrappen zonder consequenties, toch? Of is het al wel geïmplementeerd door een deel van de softwareleveranciers?

SanderNijhof commented 3 months ago

Nu is het met NLCS 5.0 zo dat de gebruiker zelf aanpassingen moet doen om een variantlijnstijl te gebruiken. De gedachte was wel dat dit via de software gekozen kon worden. Inderdaad goed om hier een eis van te maken. Volgens mij waren de belangrijkste redenen om variantlijnstijlen te gaan toepassen:

  1. het totaal aantal lijnstijlen verminderen
  2. duidelijker onderscheid houden tussen verschillende lijnstijlen. Het verschil tussen een aantal lijnstijlen was zo miniem dat je ze nauwelijks uit elkaar kon houden. Die hebben we laten vervallen, de overige zijn 'varianten' geworden. Met varianten heb je keuze uit minder lijnstijlen in totaal, maar wel keuze uit lijnstijlen die duidelijker leesbaar zijn t.o.v. al toegepaste lijnstijlen in je tekening waardoor je tekening beter leesbaar is.
ElisabethKloren commented 3 months ago

Ik snap dat dit een valide wens is, tegelijkertijd maakt dit de toepassing van de standaard voor een (intredende) softwareleveran cier moeilijker, en blijkbaar speelt dit probleem alleen af bij kantopsluitingen.

Voorgenomen wijziging: de meest voorkomende (combinaties van) opsluitbanden verschillende variant lijnstijlen te geven, en minder voorkomende dubbele lijnstijlen met de meer voorkomende; als je dan in een tekening een keer per ongeluk twee dezelfde hebt, kun je altijd met reden afwijken van de standaard. Dit kunnen we beschrijven in de documentatie op deze manier: "Lijnstijlen zijn in NLCS zo gekozen, dat goed onderscheid gemaakt kan worden tussen objecten. Alleen objecten waarvan veel varianten voorkomen, zoals kantopsluitingen, hebben soms dezelfde lijnstijl. Indien twee objecten dezelfde lijnstijl hebben en daardoor op een tekening moeilijk onderscheiden kunnen worden, is het toegestaan af te wijken van de standaard lijnstijl"

De eis aan softwareleveranciers kan dan zijn dat de foutmelding bij een afwijkende lijnstijl dit ook zegt: Een lijnstijl in laag [naam] wijkt af van de standaard lijnstijlen; [voeg bovenstaande zin toe]

Dan hoeft er geen extra uitzondering te worden geprogrammeerd in de software, en blijft het goed werkbaar voor de ontwerper.

MvanderHulst commented 3 months ago

Heel praktisch:

De keuze is echter destijds gemaakt om de database uit te kunnen en niet al deze lijntypes te willen onderhouden. Zelf was ik hier geen voorstander van, maar toen was het toch doorgegaan.

ElisabethKloren commented 3 months ago

@MvanderHulst het voorstel is hier om niet allemaal extra lijntypes te maken, maar de bekende "variant lijntypes" te gebruiken en te accepteren dat sommige exoten hetzelfde lijntype hebben; wat betekent dat je in een tekening soms bewust kan afwijken van de standaard als je twee banden gebruikt die toevallig hetzelfde lijntype hebben.

NielsNederpel commented 3 months ago

Het wijzigen van een lijnstijl die bij een laag hoort is altijd toegestaan (toch?).

in mijn idee niet...de lijnstylen hoort bij de laag en daar kun je niet van afwijken. in die zin kun je dan ook de controle uitvoeren en herstellen. daar is echter sinds 5.0 dan de verandering bij gekomen door de variantlijnstylen. alleen in de huidige tooling van InfraCAD werkt dit in ieder geval zo dat deze weer wordt overschreven indien je een nieuw entiteit op dezelfde laag tekent. waarschijnlijk is dit niet goed doorgevoerd in de tooling.

ik vind dit nog steeds een ongelukkige manier van werken, varianten bedenken maar die niet publiceren. Kunnen deze varianten niet gewoon in de database worden opgenomen? Dit werkt toch niet???

niet helemaal. ze staan wel in de (oude) database (en daarmee in het LIN bestand) maar zijn niet gekoppeld aan objecten. je kunt ze dus wel handmatig kiezen, maar probleem bij InfraCAD is inieder geval dat deze weer hard wordt overschreven bij het opniuew tekenen van een entiteit op die laag.

@MvanderHulst het voorstel is hier om niet allemaal extra lijntypes te maken, maar de bekende "variant lijntypes" te gebruiken en te accepteren dat sommige exoten hetzelfde lijntype hebben; wat betekent dat je in een tekening soms bewust kan afwijken van de standaard als je twee banden gebruikt die toevallig hetzelfde lijntype hebben.

wordt wel een lastig verhaal. denk ik als ik even terugkijk (naar alleen de kantopsluitingen) daar hebben we nu 11 (x2 = 22 ivm vervallen) lijnstylen. in 4.2 waren dit voor deze 5 verschillende kantopsluitingen 42 (x2 ivm vervallen) GAZONBAND (7x) (x2) GELEIDEBAND (7x ) (x2) OPSLUIITBAND (11|x) (x2) SCHEIDINGSBAND (10x) (x2) TROTTOIRBAND (7x) (x2)

andere optie...die ook niet waterdicht is, maar dan komen de variant lijntype wel onder de aandacht... in de datbase het als volgt opnemen de banden zonder afmeting (bv OPSLUITBAND, TROTTOIRBAND etc) de huidige lijntypen te laten houden van dat type band en álle banden met afmeting van dat type (bv. OPSLUITBAND_80X200, TROTOIRBAND_180x200 etc) het variant lijntype van dat type band? dan echter wel in de controle tooling iets regelen dat er geswitched mag worden voor de banden mét afmeting om hier de lijntype "zonder variant" toe te staan. of gaan we dan de lijntypen waar dit van toepassing is ook "variant" noemen zodat je bij banden altijd 2 lijntypen hebt met variant01 en variant 02 en dus geen lijntype meer zónder "variant" in de naam

SanderNijhof commented 3 months ago

Het wijzigen van een lijnstijl die bij een laag hoort is altijd toegestaan (toch?). in mijn idee niet...de lijnstylen hoort bij de laag en daar kun je niet van afwijken.

Naar mijn idee wel. Dit is zelfs 1 van de fundamenten van de NLCS. De laagnaam is verplicht, maar de bylevel/bylayer eigenschappen mag je aanpassen binnen de regels van de formele beschrijving. Met name de lijnstijl en kleur zijn hierdoor aan te passen, de lijndikte ligt veelal vast aan de status van het object. Door de kleur en lijnstijl enigzins vrij te houden geef je de tekenaar de mogelijkheid de tekening beter leesbaar te maken. Daarom mag de controletooling wel een melding geven als een lijnstijl niet ‘klopt’ maar geen foutmelding. Per NLCS 5.0 hebben we regels voor de naamgeving van lijnstijlen geïntroduceerd. Zo kunnen lijnstijlen makkelijker door de software aan objecten worden gekoppeld. Met name nodig voor de variantlijnstijlen. Voorbeeld: Laagnaam: N-WE-VH-KANTOPSLUITING_TROTTOIRBAND-G Lijnstijl: VH-TROTTOIRBAND-SO De software kan dan lijnstijlen: VH-TROTTORBAND_VARIANT01-SO en VH-TROTTORBAND_VARIANT02-SO aanbieden als alternatieve mogelijkheden voor lagen die de lijnstijl : VH-TROTTOIRBAND-SO gebruiken. Kom wel gelijk een probleempje tegen dan met : VH-TROTTOIRBAND_STELLEN-SO en VH-TROTTOIRBANDVARIANT01 STELLEN-SO, dat zou dan VH-TROTTOIRBAND_STELLEN_VARIANT01-SO moeten zijn. Bij symbolen passen we deze systematiek al langer toe: Laagnaam: N-WE-GR-BOOM-S Symbool: SGR-BOOM_001, SGR-BOOM_002, SGR-BOOM_003, SGR-BOOM_004 enz. (maar dan zonder het woord ‘VARIANT’). Laagnaam: N-WE-RI-DRAINAGE_PUT-S Symbolen: SRI-PUT_DRAIN-SO; SRI-PUT_DRAIN_KUNSTSTOF-SO; SRI-PUT_DRAIN_KUNSTSTOF_DOORSPUIT-SO;

Hoe zijn deze symbolen die op dezelfde laagnaam komen in de database opgenomen? Kan dit voor lijnstijlen niet vergelijkbaar?

MvanderHulst commented 3 months ago

@SanderNijhof en @NielsNederpel Leuke discussie, het wel of niet toegestaan zijn van het aanpassen van een lijntype... Als ik op de letter de formele beschrijving lees staat er bij: 3.5.2 Lijndikte, artikel C: 'Alleen indien het de overzichtelijkheid of duidelijkheid van een tekening ten goede komt, mag van de standaard lijndikten worden afgeweken' 3.5.4 Lijnkleur, artikel D: 'Uitgangspunt van het kleurenschema is een consequent kleurgebruik. Hiervan kan worden afgeweken, wanneer dat noodzakelijk is voor de overzichtelijkheid en/of duidelijkheid van de tekening.' 3.5.3 Lijntype: Geen artikel die aangeeft dat er van de standaard afgeweken mag worden, alleen een uitleg over de opbouw. Formeel zou het aanpassen van lijntypes, anders dan de objectentabel dus NIET toegestaan zijn.

Dit lijkt dan tegenstrijdig met 3.5.3.b bullet 3 en 5.2.4.b bullet 3 te zijn...

NielsNederpel commented 3 months ago

hmmm denk dat we hier dan toch een controversiële te pakken hebben?

MvanderHulst commented 3 months ago

@NielsNederpel Dat denk ik zeker wel. Al ben ik van mening:

ElisabethKloren commented 3 months ago

Eens met stelling je mag de lijnstijl aanpassen als dit nodig is voor duidelijkheid tekening > voorstel om dat op te nemen in de documentatie.

Verder: nu kun je 1 lijnstijl gegeven bij een object, geen varianten. Dus voorstel blijft staan om dat te doen voor alle trottoirbanden, waarbij sommige banden helaas hetzelfde lijntype krijgen in de standaard. Voor versie 5.1

Ik wil liever geen "extra complicaties" hebben voor de softewareleveranciers, behalve misschien op lange termijn waarbij je afwijkingen beter kunt registreren / bij een tekening een "eigen bibliotheek" kunt meegegeven om de gebruikte variatie ook echt expliciet te maken.

MvanderHulst commented 3 months ago

@ElisabethKloren Dan moeten we toch gewoon het hele VARIANTEN verhaal over boord gooien? Alles hetzelfde = niet gewenst voor de eindgebruiker, zodoende waren de varianten in het leven geroepen. Dan moeten we de beslissing terug draaien en dat alle kantopsluitigen weer een eigen lijntype krijgen. Deze lijken dan veel op elkaar, maar zijn wel onderscheidbaar en kan je met een eigen LIN aanpassen naar wens. Daarmee blijft de controle tooling volledig overeind en heeft de tekenaar de vrijheid weer terug.

De keuze voor VARIANTEN was gemaakt om het voor de NLCS-beheerder makkelijker te maken, maar voor de eindgebruiker is nu een vervelend scenario ontstaan. Als de daarvoor bedachten VARIANTEN niet werken, moeten we het terug draaien ten gunste van de eindgebruiker. Dan maar iets meer lijntypes in het beheer opnemen. Ze stonden mij niet in de weg.

SanderNijhof commented 3 months ago

Eens met stelling je mag de lijnstijl aanpassen als dit nodig is voor duidelijkheid tekening > voorstel om dat op te nemen in de documentatie.

Zover mij bijstaat is altijd de insteek geweest dat de NLCS 'in principe' de presentatie van objecten aangeeft, maar dat hiervan afgeweken mag worden als dat de leesbaarheid van de tekening ten goede komt. Het is niet de bedoeling dat iedereen standaard zijn eigen lijnstijlen, symbolen en kleurvarianten gaat toepassen. Kunnen we dat niet in z'n algemeenheid noemen dan is dat voor eens en altijd duidelijk.

De keuze voor VARIANTEN was gemaakt om het voor de NLCS-beheerder makkelijker te maken,

Ik was ook geen voorstander van varianten, maar bijkomend voordeel is ook dat je nu zelf een duidelijk leesbare lijnstijl kunt kiezen.

Ik wil liever geen "extra complicaties" hebben voor de softewareleveranciers,

Dan hadden ze geen softwareleverancier moeten worden. Software is er vnl. om complexe handelingen voor de gebruiker te vereenvoudigen. Anders hebben we ook geen software nodig. :-)

MvanderHulst commented 3 months ago

Op basis van AI een zeer inhoudelijke analyse laten uitvoeren. De conclusie:

Conclusie Het aanpassen van bestaande lijntypen wordt niet expliciet vermeld in de NLCS-documentatie als zijnde toegestaan of verboden. Echter, de NLCS legt nadruk op consistentie en uniformiteit, vooral bij de uitwisseling van tekeningen tussen verschillende partijen en softwarepakketten.

ElisabethKloren commented 3 months ago

EC 6-6-2024: de beschrijving van de werkwijze met variant lijnstijlen uit 5.0 is niet of nauwelijks overgenomen in de software; het maakt de implementatie van de standaard in de software moeilijker; besproken is: terug naar de basis, in de database staat één type lijnstijl per object, that’s it. Daarbij wel de formele beschrijving aanpassen, duidelijk maken dat het is toegestaan om op een tekening van lijnstijl te wisselen als dit nodig is voor een beter leesbare tekening.