Plan-plan validatieportaal

Het Plan-Plan validatieportaal is een portaal dat wordt gebruikt door stedenbouwkundige en andere bureaus of organisaties voor het valideren van omgevingsdocumenten tegen de PRE-ETO-omgeving.

Gebruik

U kunt een account aanvragen bij IPLO. Vul dit contactformulier in en zet bij de vraag ‘Aanvraag account DSO plan-planvalidatie’. U krijgt dan een persoonlijke landingspagina voor het gebruik van dit validatieportaal, met een bijbehorende gebruikersnaam en wachtwoord.

Deze validatieservice is speciaal ontwikkeld voor de zogenoemde plan-plan keten. Deze service valideert alleen initiële omgevingsdocumenten tegen de PRE-ETO-omgeving van het DSO. Het valideren van mutaties wordt NIET ondersteund.

Deze validatieservice wijzigt volgens een speciaal algoritme de ID's van het omgevingsdocument, zodat er geen conflicten kunnen plaatsvinden met bestaande content in de PRE-ETO omgeving. In de validatierapporten worden de gewijzigde ID's weer teruggerekend naar de oorspronkelijke ID's.

Uitleg

Inleiding

Het algoritme doet zo min mogelijk aannamen over de opbouw van de levering en conformiteit aan de standaarden. Het kan namelijk niet zo zijn dat alleen correcte en valide content door dit portaal kan worden gevalideerd. Zo ondersteunen de standaarden momenteel maar 1 doel, maar ons omnummer algoritme ondersteunt ook meerdere doelen.

Uiteraard zijn er grenzen. Alle xml dient ten minste well-formed te zijn. Als de content niet schema-valide is, kunnen we een foutloze werking van het algoritme niet garanderen. Bij ernstige schemafouten kan het voorkomen dat het omnummeren in het geheel niet lukt.

ID's worden ’omgenummerd'. Hierdoor worden de ID's in de aanlevering NIET gevalideerd door de validaties die plaatsvinden op het LVBB-bronhouderkoppelvlak. In plaats daarvan valideren wij het deel van het oorspronkelijk Id dat door ons wordt omgenummerd. Doordat de rest van het oorspronkelijke ID wordt gevalideerd door het LVBB-bronhouderkoppelvlak vindt zo toch een sluitende validatie plaats.

Een levering dient te voldoen aan de limieten, ook bij de bestandsformaten. Een bestand opnemen dat hieraan niet voldoet, leidt tot een afgewezen levering.

Stap 1: Controle limieten

De levering wordt uitgepakt en vergeleken met de limieten mbt omvang en extensies van de bestanden. Als hieraan wordt voldaan, volgt stap 2.

Stap 2: Omnummering volgens het omnummer algoritme

Het omnummer algoritme valt uiteen in 4 delen:

  • ow-ids van alle objecten die ontstaan in deze levering.
    • xpath expressie: //*:identificatie
    • voorbeeld: imow-gm0363.regeltekst.<omnummeren>
  • doelen van de regeling:
    • xpath expressie: //*:doel
    • voorbeeld: /join/id/proces/gm0363/2021/<omnummeren>
  • akn-ids:
    • xpath expressie: //*:FRBRWork[starts-with(text(),'/akn/nl')]
      • NB: uiteraard worden de FRBRExpression-id's afgeleid van deze FRBRWork id's ook omgenummerd.
    • voorbeeld: /akn/nl/act/gm0363/2021/<omnummeren>
  • join-ids:
    • xpath expressie: //*:FRBRWork[starts-with(text(),'/join/id')]
      • NB: uiteraard worden de FRBRExpression-id's afgeleid van deze FRBRWork id's ook omgenummerd.
    • voorbeeld: /join/id/regdata/gm0363/2021/<omnummeren>

De met <omnummeren> gemarkeerde delen worden omgenummerd naar een uniek id met de volgende opbouw:

  • start met: dsX
  • aangevuld met 29 karakters, willekeurig gekozen uit de karakters at/m Z en de cijfers 0 t/m 9 .

Stap 3: Klaarzetten voor validatie

De levering wordt als volgt klaargezet voor de validatie:

  1. Alle bestanden uit de oorspronkelijke levering worden klaargezet voor de validatie.
  2. De om te nummeren bestanden worden omgenummerd. Dit gebeurt met behulp van tekstvervanging.
  3. Alle gml-bestanden genoemd in manifest.xml worden opnieuw gehashed, en de hash verwerkt in de GIO-xml.
  4. Een nieuwe opdracht.xml wordt in de levering gezet:
    • root element validatieOpdracht
    • idLevering met daarin:
      • een herkenbaar begin gelijk voor alle leveringen: PP__VALIDATIE
      • de accountnaam, voorafgegaan door __
      • een timestamp in het formaat "ddmmjjjjuummss", voorafgegaan door __.
    • idAanleveraar: onze digikoppeling leverancier
    • Overige element volgens de oorspronkelijke levering

Stap 4: Aanbieden voor validatie

Alle bestanden uit stap 3 worden gezipt en via onze digikoppeling aangeboden aan LVBB.

De omnummer tabel wordt bewaard om de validatierapporten terug te kunnen nummeren.

Validatieresultaten

Bij het ophalen van de validatieresultaten worden de validatiemeldingen met behulp van tekstvervanging teruggenummerd zodat de oorspronkelijke ID's in het rapport worden getoond.

In het validatierapport wordt zowel de oorspronkelijke idLevering genoemd, als de idLevering die is gebruikt bij de validatie.