Monitoren project "NLCS mee in ISO 19650: OTL+ILS" #138
Comments
ElisabethDeVries
added
Netbeheer
|
Tijdens EC 2023-10-03 besproken: Netbeheerders hebben de behoefte om extra informatie te ontvangen bij tekeningen, meer dan in laagnaam en beschrijvingen kunnen staan. Men wil (dit is een voorstel, zeker niet in beton gegoten, gezien de bredere context en de meerdere opties) een optie toevoegen aan NLCS om attribuutgegevens toe te voegen bij tekeningen in de vorm van XML. Daar is dan een schemadefinitie bij nodig (XSD) waarin je ook attribuutnamen en waardelijsten kan meegeven. Dit voorstel werkt anders dan bijvoorbeeld bij de aansluiting naar IMBOR, waarbij je de attributen en keuzelijsten kan inlezen vanuit een linked data ontologie. |
|
Reactiesa tijdens EC 2023-10-03: Reacties in chat: Bij gebruik van NLCS++ ben je dus wel verplicht om met een commerciële partij in zee te gaan om de techniek te kunnen toepassen. Arkance, CADAC of Cad&Company? > dat is niet per sé zo, partijen die met FME ed werken kunnen wel ook ermee werken Als alles op basis van Handle is gekoppeld met een extern bestand, moeten dus ook álle bewerkingscommando's in AutoCAD ondervangen worden voor juiste verwerking van de data. Uitwisseling tussen verschillende DWG's is hierbij spannend? > ja, dit is zeker spannend, bijvoorbeeld bij het splitsen van objecten waarbij een deel wordt verwijderd en een deel in gebruik gehouden. Dit zal aandacht vragen van degenen die de software inrichten Wat gebeurt er bij een 'Fatal-Error', is de kans op corrupte bestanden dan aanwezig? > dat is altijd een risico Hoe gaat een XML/XSD op met Sharepoint/OneDrive sync? of een Autodesk Construction Cloud? Meerdere bestanden continue bijwerken lijkt voer voor synchronisatieproblemen. > Nu schrijft NLCS geen bestandsformaat voor, maar in dit voorstel is er voor het optionele deel juist wel een voorgeschreven bestandsformaat voor objectdata, maar weer niet voor de geometrie...het optioneel opslaan van die data moet vanuit die optiek misschien juist wel verplicht meegenomen worden om met die xml/xsd een totaalbestand te kunnen leveren die los kan staan van een dwg of dgn? Behoorlijk fundamenteel probleem omdat je de xsd niet los kan zien van de geometrie. |
|
Nog meer tijdens EC 2023-10-03 Het is een utopie om softwareonafhankelijk te zijn, want het is zeer moeilijk om elkaars geometrische bestanden over te nemen, in te lezen. Maar nu moet je twee verschillende bestanden maken. Moet je niet beschrijven hoe die uitwisseling in beide CAD pakketten zou werken in eigen formaten / context?, zodat je niet met twee bestanden hoeft te werken? Je zou alleen het uitwisselen aan het eind van een project wel een bestand kunnen exporteren. Hoe gaan de nutsinstanties er zelf mee om, omdat zij elk hun eigen soorten materiaalkeuzes hebben en dergelijke? > Het informatiemodel is standaard voor alle netbeheerders, alleen de waardelijsten kunnen verschillen. De xsd's kunnen dus gaan verschillen per netbeheerder. |
|
van data gegijzeld in software naar federatief datadelen.... is IFC als uitwisselformaat geen optie? |
|
presentatie van Dimitry in EC 2023-10-03: |
|
Er bestaat een prima werkend (semi) open standaard voor 2d cad data in de vorm van DXF. Drawimg eXchange File. Voordeel is dat het geen 'intelligente' specifieke object definities kent die dwg ontwikkelaars in dwg meegeven. Die zijn dan alleen bruikbaar met hún dwg software plossing. Dat zit veel in Autodesk Civil 3d. DXF is dan opzicht mooi open en in te lezen met een text editor. Dat zou ik zeker even overwegen. De Belgische instantie voor kadaster en klic gebruikt DXF als standaard voor CAD vector data. Enige nadeel is dat DXF 'eigendom' is van Autodesk. Ze willen dit niet niey overdragen. |
ElisabethDeVries
changed the title
|
Besproken 11-3-2024: Actie voor Elisabeth |
ElisabethDeVries
removed
Netbeheer
|
voor dit porject is geen financiering gevonden, deelvragen zijn opgenomen in ontwikkelingsissues op de backlog |
Voor dit project is geen financiering gevonden
Jaarplan 2024
In 2022 is er een verdieping van de NLCS onderzocht om een dataset te vullen conform de informatie standaarden (IMKL, IMBOR, GWSW en OTL Spoor). Aanvullende kenmerken worden als data aan NLCS-objecten gekoppeld, zodat hier vervolgens een dataset uit gegenereerd kan worden welke voldoet aan het informatiemodel. Daarnaast s gekeken naar de overige overkoepelende standaarden zoals ISO19650.
Voor 2024 wordt dit verder uitgewerkt en wordt dit verder geïmplementeerd in de NLCS.
Het ILS vraagstuk valt uiteen in meerdere zaken:
Tekening in ILS
Hoe kan een opdrachtgever aangeven welke objecten op een tekening moeten komen en welke (variant) kleuren en lijnstijlen gewenst zijn?
Data bij de objecten op een tekening
Uitwisseling CAD-tekeningen in open formaat
Vanuit zowel Stedelijk Spoor als vanuit Netbeheer als vanuit gemeentelijke en provinciale opdrachtgevers met IMBOR komen dilemma's rondom ILS en uitwisseling van NLCS modellen en aanvullende informatie.
Dit vraagstuk is relevant voor de hele sector, omdat er een woud aan suboptimale oplossingen ontstaat, waarbij elke (groep) opdrachtgevers een eigen oplossing bedenkt voor uitwisseling van informatie, die gericht is om de informatie in de eigen systemen te importeren. De opdrachtnemers (aannemers, ingenieursbureaus) kunnen met hun digitalisering niet goed aansluiten op zoveel verschillende oplossingen.
Er worden daarbij diverse oplossingen genoemd voor de korte termijn werken om data in eigen systemen te importeren in systemen, daarbij ontstaat een grote diversiteit in data-uitvragen tussen verschillende opdrachtgevers
Lange termijn
Kortere termijn
The text was updated successfully, but these errors were encountered: