De description van het component 'LocatieType' bevat de volgende waarde:

Is dit een definitie?

Is dit een definitie?

Verwijder deze.

We hebben destijds besproken dat elke leverancier de API minimaal ondersteunt in de vorm van bestandsuitwisseling (kunnen leveren dan wel verwerken van een bestand met gegevens volgens de structuur van de API). Is het voldoende duidelijk hoe de API-specificatie toegepast moet worden als je de gegevens in een bestand wil uitwisselen? Welke additionele afspraken, richtlijnen of requirements zijn hiervoor nog nodig? Bijv. characterset?

In diverse componenten (op diverse niveau's) is dezelfde nietszeggende omschrijving

Een inhoudelijke toelichting op de toepassing van het informatie-element.

opgenomen. Verwijder deze.

In het overleg op 1-10-2020 is ingebracht dat ook een procedurenummer of -aanduiding meegegeven moet kunnen worden (optioneel) op het niveau van de gegevenslevering d.w.z. niet per activiteit e.d. Er moet ook op proceduregeselecteerd cq. opgevraagd kunnen worden. Dit zit m.i. nog niet in de API. Waar en hoe zou dit verwerkt moeten worden?
Ook is ingebracht dat er sprake zou moeten zijn van een "status-gegeven dat overeenkomt met een herkenbare status in de plansoftware", waarop ook geselecteerd kan worden. Zit er m.i. ook nog niet in. Is dit hetzelfde als die procedure-aanduiding? Zo nee, toevoegen, en waar dan?

Er wordt aangegeven dat men het attribute ‘origineel coördinatensysteem’ in de resource ‘locatie’ opgenomen wil hebben. Op dit moment hebben we dat nog niet opgenomen omdat het de praktijk is om dit als 'acceptCRS' en ‘contentCRS’ in de header van de berichten op te nemen. De vraag is echter of er redenen zijn waarom je dit juist toch in de content zou willen opnemen?

Op diverse properties is geen omschrijving gedefinieerd.

Het attribuut 'type' in de groep 'Omgevingsdocument' is als niet verplicht gedefinieerd. Het is echter wel een verplicht attribuut

In het SIM zit in de omschrijving van de 'gerelateerd' relatie die loopt van 'activiteit' naar 'activiteit' een karakter dat een fout veroorzaakt in de GitHub:

Hetzelfde geldt voor de omschrijving van de relatie 'is' die eveneens van 'activiteit' naar 'activiteit' loopt:

Verwijder resp. vervang deze karakters.

Een deel van de toelichting van het attribuut 'werkppakketCode' in 'regeltekst' is verloren gegaan. Het bevat nu alleen de volgende tekst:

Een unieke aanduiding van de verzameling samenhangende activiteiten gericht op het publiceren van een nieuwe versie van een omgevingsdocument.

Er kunnen tegelijkertijd meerdere trajecten gaande zijn waarin bijvoorbeeld een omgevingsplan gewijzigd wordt, die elk leiden tot een apart te publiceren nieuwe versie van het omgevingsplan. De werkpakketcode biedt de mogelijkheid om de regelteksten te m

De ‘title’ property van het attribuut 'type' in de groep 'Omgevingsdocument' heeft de waarde ‘documentType’, dit moet ‘type’ zijn.

Indien in een regeltekst een norm gesteld is dan kunnen de daarvoor geldende normwaarden verschillen binnen het werkingsgebied van de regeltekst. Denk bijvoorbeeld aan maximale bouwhoogten die binnen het ambtsgebied kunnen verschillen. Dergelijke normwaarden hoeven niet in de regeltekst vermeld te worden. Ze staan dan 'in de kaart' en worden in een GIO aangeleverd (in het STOP/TPOD-bestand). Een norm met dergelijke normwaarden en bijbehorende locaties zit nu niet in het informatiemodel en dus niet in de API. Toch lijkt me de locatie van een dergelijke normwaarde relevant voor toepasbare regels. Je wilt toch iets kunnen vragen als 'Bouwt u niet hoger dan 15 meter?' Die '15' is de normwaarde en geldt voor bepaalde plekken in het ambtsgebied. Op andere plekken is het 10, 20 of meer meter. Dus wil je die plekken cq. locaties weten, lijkt me.
Overigens komt dit in het CimTR niet voor. Vreemd? Of is dit meer iets voor toepasbare regelbeheer dus voor die applicatie?

In de resource 'locatie' is het attribuut ‘hoogte’ opgenomen. De hoogte is in een aantal coördinatensystemen echter al onderdeel van dat systeem (bijv. EPSG 7415). De vraag is dus of dit attribute echt opgenomen moet worden.

...zodat [vul aan].

Acceptatiecriteria

• [ ]
• [ ]

Definition of done

• functionele specificatie
• Open API specificatie
• gegenereerde code
• testgevallen
• referentie-implementatie

Het CimOW en de API kennen locaties bij meerdere objecttypen: Regeltekst en Juridische regel en bij Activiteitlocatieaanduiding van Regel voor iedereen. Het CimTR kent alleen de locatie bij een activiteit. Het laatste is per activiteit de verzameling van locaties van de Activiteitlocatieaanduidingen bij de Activiteit. Laatstgenoemde locatie-relatie lijkt dus i.i.g. noodzakelijk. Zijn de andere twee locatie-relaties ook noodzakelijk in de API? Of willen we de API generiek houden: alles er in wat in het Cim staat. En wordt per uitvoering bepaald wat daadwerkelijk opgevraagd wordt?

De url waarden van de server beschrijving bovenin de specificatie (zie hieronder) komt niet overeen met de naam van de API.

servers:
  - description: "SwaggerHub API Auto Mocking"
    url: https://virtserver.swaggerhub.com/VNGRealisatie/api/plan_sw___toepasbare_regel_sw/v0
  - description: "Referentie-implementatie"
    url: https://www.voorbeeldgemeente.nl/api/plan_sw___toepasbare_regel_sw/v0

De properties:

• 'gerelateerdeActiviteitIdentificaties' ('Activiteit');
• 'omvattendeLocatieIdentificaties' ('Locatie');
• 'normeertActiviteiten' ('JuridischeRegelVoorIedereen');
• 'themas' ('JuridischeRegelVoorIedereen');
• 'gerelateerdeRegeltekstIdentificaties' ('Regeltekst')

mogen leeg zijn. Ze bevatten de construct 'minItems' met de waarde 0 of ontberen deze construct.
Aangezien 0 de default waarde is zijn beide situaties aan elkaar gelijk.

Deze situatie is echter incorrect. Ik zie nl. geen redenen waarom een van deze properties aanwezig zou mogen zijn zonder een waarde te hebben.

In de omschrijving van de relatiesoort 'is' die in het CIM loopt vanuit 'Activiteit' naar 'Activiteit' staat de volgende tekst:

'Met “is (een)” wordt ...'.

Dit vertaalt zich in de yaml naar:

'Met “is (een)‿ wordt ...'.

wat een probleem oplevert bij het genereren van de genereervariant.

Impediment

Door locatiegroepen niet te ondersteunen moeten in plaats daarvan gebruik gemaakt worden van de multi-variant van geometriën. Bij locaties die uit veel geometriën bestaan en een groot gebied beslaan leidt dit tot performance problemen. Bijvoorbeeld het Natuurnetwerk Nederland van een provincie bestaat uit gedetailleerde geometrie die de hele provincie beslaat die een omvang kan hebben in de orde van 100MB. Als zo'n locatie als multipolygon wordt geleverd dan zorgt deze grote geometrie voor performance problemem bij het tekenen en zoeken omdat deze geometrie bij iedere zoek- en tekenactie verwerkt moet worden, maakt niet uit hoever je bent ingezoomd. Door deze locatie als groep van multipolygonen aan te leveren
raak je alleen de multi-polygonen die "in beeld zijn", namelijk als je op een bepaald gebied bent ingezoomd zoals meestal het geval is.

Hier en daar zijn door platslaan attributes elders terecht gekomen waardoor er een noodzaak was de namen te wijzigen. Ook is in de OAS3 specificatie bij relaties tussen resources niet de namen van die relaties gebruikt maar van de daaraan gekoppelde resources, echter bij meerdere relaties naar dezelfde andere resource zijn de namen gedifferentieerd. Verzoek is om de gekozen naamgeving kritisch tegen het daglicht te houden.

De ‘title’ property in het info deel van de specificatie (zie hieronder) komt niet overeen met de naam van de API.

info:
  title: Plan SW - Toepasbare regel SW

Deze is nu 'platgeslagen' (zie derde ontwerpbeslissing) in drie 'elementen': activiteitregelkwalificatie [0..n], gekwalificeerdelocaties [1--n?] en, tsja, waar zijn de activiteiten gebleven? Ik zie ze niet in Swagger. Wel in het UGM maar dan als relatie van JuridischeRegel. Dit is onjuist. De Activiteitlocatieaanduiding is een gegevensgroep die nul tot n keer voor komt en telkens bestaat uit één regelkwalificatie, één activiteit en één of meer locaties. Die drie horen telkens bij elkaar, in elke instantie van de gegevensgroep. Dit is nu uit elkaar getrokken waardoor bijvoorbeeld niet meer bekend is welke regelkwalificatie voor welke activiteit voor welke locaties geldt. Ook in het UGM moet dit aangepast worden.

De resource 'locatie' bevat een attribuut 'werkpaketcode'. Dit is niet correct, dit attribuut hoort alleen op de resource 'regeltekst' voor te komen.

Te overwegen is om de resource JuridischeRegelsVoorIedereen als aparte resource te laten vervallen en de inhoud daarvan als embedded op te nemen in de resource Regelteksten (i.t.t. de 2e overweging in het document Ontwerpbeslissingen). De Juridische regel is dan (in de API) als het ware een gegevensgroep met een kardinalieit 1-n van de Regeltekst. In de praktijk zal een juridische regel altijd opgevraagd worden in combinatie met de bijbehorende regeltekst (een juridische regel sec verschaft onvoldoende informatie). En bijna elke regeltekst zal bestaan uit precies één juridische regel. Het onderscheiden van twee resources met eigen endpoints (operations) lijkt dan weinig efficient. Deze structuur van de API is een manier van uitdrukken van de semantiek van het conceptueel informatiemodel en legt daaraan geen beperkingen op.

... zodat ik daarmee kan testen of mijn applicatie dit goed kan verwerken of exporteren.

Deze vraag is gesteld in het koppelvlak-leveranciersoverleg van 27 januari jl. Bij voorkeur een voorbeeldbestand (van de bestandsuitwisseling o.b.v. de API) voor Gemeentestad, de STOP/TPOD-voorbeeld-gemeente van Geonovum.

Acceptatiecriteria

• [ ]
• [ ]

Definition of done

• functionele specificatie
• Open API specificatie
• gegenereerde code
• testgevallen
• referentie-implementatie

... zodat leveranciers van (plan- en vooral) toepasbare regel-software dergelijke opvraagfunctionaliteit maar één keer hoeven te ontwikkelen.
Deze vraag is door één van de stelselarchitecten gesteld in het Interbestuurlijk Architectuuroverleg (van het DSO) op 22 februari jl.

In OZON zijn de omgevingsdocumenten (waaronder omgevingsplannen) met annotaties 'opgeslagen'. Met de API “Omgevingsdocument opvragen” kan een omgevingsdocument daaruit opgevraagd worden. Qua mogelijkheden lijkt dat op de voorliggende API, waarbij de laatstgenoemde beperkt is tot een deel van de gegevens van het omgevingsdocument. Daar waar het over dezelfde gegevens gaat, zou de API-specificatie ook hetzelfde moeten zijn, tenzij er goede redenen zijn om daarvan af te wijken. Voor software-ontwikkelaars heeft dat genoemde voordelen.

Acceptatiecriteria

• [ ]
• [ ]

Definition of done

• functionele specificatie
• Open API specificatie
• gegenereerde code
• testgevallen
• referentie-implementatie