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 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 ontstaan met bestaande content in de PRE-ETO omgeving. In de validatierapporten worden de gewijzigde ID's weer teruggerekend naar de oorspronkelijke ID's.

De validatieservice verwerkt leveringen die geschikt zijn voor het aanbieden aan het LVBB koppelvlak. Daarnaast verwerkt de validatieservice ook uitwisselpakketten, zoals die gebruikt worden in de uitwisseling tussen plansoftware pakketten.

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 het LVBB-bronhouderkoppelvlak de rest van het oorspronkelijke ID valideert is het resultaat toch een sluitende validatie.

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

Stap 0 (optioneel): Ombouwen van een uitwisselpakket

Indien het aangeboden zipbestand een pakbon.xml bestand bevat wordt het beschouwd als een uitwisselpakket. Deze wordt omgebouwd tot een levering. Hiervoor is het belangrijk dat de het uitwisselpakket zich houdt aan alle vereisten die voor zulke pakketten gelden. Wanneer het uitwisselpakket niet voldoet aan deze vereisten wordt het niet omgebouwd tot een levering en ook niet verder gevalideerd.

Bij het ombouwen wordt een dummy besluit aangemaakt, ook als er een besluit is opgenomen in het uitwisselpakket. Daarnaast wordt er een willekeurig leveringsId gemaakt. Hieraan is de levering in uw geschiedenis herkenbaar.

Het ombouwproces ondersteunt niet het ombouwen van besluiten die tijdelijk regelingdelen instellen.

Stap 1: Controle limieten

De levering wordt uitgepakt en vergeleken met de limieten met betrekking tot 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: nl.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') and not (ancestor::*:isTijdelijkDeelVan)]
      • 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 a t/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.