search

nl-digigo / NLCS

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

Verzoek vanuit Netbeheerders: afspreken korte termijn oplossing voor uitwisseling alfanumerieke data bij objecten #403

Open ElisabethKloren opened 2 months ago

ElisabethKloren commented 2 months ago

Achtergrond vraag

  1. De netbeheerders verenigd bij DigiGO hebben in een project een afweging gemaakt hoe NLCS-leveranciers alfanumerieke data kunnen uitwisselen bij CAD-tekeningen. Daarbij is geometrie gescheiden van data, het voorstel is daar om een CAD-formaat (proprietrary, dus dwg of dgn) te combineren met xsd/xml. Dit kan goed in de huidige cad-pakketten en developers omgevingen worden toegevoegd, waar linked data nog niet makkelijk beschikbaar is.

  2. Voor het project NLCS Verkeersborden wil de opdrachtgever ook testen of locatie en attribuutinformatie kan worden geleverd aan George

  3. De beheerders van de openbare ruimte werken bij het CORE-BORius programma (gemeenten, provincies, CROW, St. Rioned) aan data-uitwisseling, het thema is dit jaar de "Ondergrond", gaat uit van linked data met standaarden IMBOR, GWSW en meer; deze partijen betalen de vergelijking IMBOR-NLCS

  4. Trend: Gelderland, Amsterdam, Zuid-Holland vragen de markt om een eenvoudiger formaat voor korte termijn van combinatie van geometrie in GIS en alfanumerieke gegevens, waarbij een korte termijn oplossing is ontwikkeld in Geopackage

Adviesvraag aan de Expertcommissie,

Met name de experts van softwareleveranciers: welke tussenstap is het meest haalbaar en wat voor implementatietermijn zit hier aan vast?

Optie 1: XML als tussenstap:

Voordelen van deze oplossing:

  1. Door uitwisseling van attributen los te trekken van een uitwisselformaat voor CAD / geometrie, hoeven we daar nog geen besluit over te nemen.
  2. Door geen GIS-uitwisselformaat te kiezen beperkt je niet wat je in de tekening kan opnemen, we werken immers vanuit CAD
  3. Check: Kunnen alle NLCS leveranciers vanuit huidige tooling / developers stacks xsd / xml gebruiken?
  4. Eventueel kan punt, lijn en vlakgeometrie voor GIS ook als attribuut worden meegeleverd Nadelen van deze oplossing
  5. Het model wordt in een proprietary bestandsformaat gedeeld

Optie 2: Geopackage als tussenstap:

Voordelen van deze oplossing:

  1. De beheerders werken vaak in GIS-pakketten, en hebben ook geometrie nodig
  2. Check: Kunnen alle NLCS leveranciers vanuit huidige tooling / developers stacks Geopackage leveren? Nadelen van deze oplossing
    • De CAD-informatie in een tekening gaat verloren bij vertaling naar GIS
    • Beperkt Geopackage formaat het doorwerken met elkaars modellen omdat ze in CAD meer kunnen opslaan dan alleen geometrie, of zou dit voor hen ook kunnen werken?

Optie 3: Direct overstappen naar attribuutdata delen als linked data

Voordelen van deze oplossing:

  1. Niemand kan dit nog, geen leverancier heeft voorsprong
  2. Dit is een grotere stap naar de stip op de horizon
  3. IMBOR en GWSW werken al op basis van linked data, er kan beter worden aangesloten op de ontwikkelingen bij CORE-BORius
  4. Eventueel kan punt, lijn en vlakgeometrie voor GIS ook als attribuut worden meegeleverd Nadelen van deze oplossing
  5. De netbeheerders moeten (weer) investeren in tooling, vlak na hun pilot
  6. Check: Kunnen alle NLCS leveranciers vanuit huidige tooling / developers stacks inderdaad nog geen linked data leveren?