Via de mail bereikte ons de volgende vraag:
------------------------
Informatie over Voertuigen kunnen (nog) niet worden verzonden via zaakberichten. Is er mogelijk een optie om dit via een overig zaakobject door te geven?
Dan nog een vraag omtrent het doorgeven van een lokatie van een overtreding (foutparkeren). Via een zaakobject kan op dit moment wel een straat worden doorgegeven (openbare ruimte), maar is er volgens mij geen mogelijkheid om de exacte X-Y locatie op te slaan. Of is hier anderZaakObject (zaakobjectGrp) voor bedoeld?
-----------------------
Het antwoord hierop is:
(Andere) objecten (overtreding, voertuig, etc.) die geen subtype van OBJ zijn moeten in de groep ‘anderZaakObject’ van het zaakbericht opgenomen worden.
Deze groep bevat o.a. het element ‘lokatie’ waarmee de locatie van het object kan worden aangegeven.
Dit element heeft als type ‘GeometrieIMGeo-e’.
Als je goed kijkt naar de definitie van dit type dan zie je dat het niet veel meer om het lijf heeft dan een string.
Liever zouden wij hier een GML type zoals PointPropertyType of SurfacePropertyType gebruiken zodat je de x en y coördinaten of de geometrische markering van het object op een nette manier kunt opgeven.
Wij stellen dan ook voor om dit als zodanig te wijzigen.
De bedoeling van deze post is een beetje ondergesneeuwd.
De reden voor deze post was nl. het melden van een bug.
Akkoord. Dit is inderdaad een bug. Zie ERR253. Eigenlijk wil je hier de mogelijkheid een punt, lijn, vlak of combinatie daarvan te specificeren. Dat zou er voor pleiten GeometrieIMGeo-e te definiëren als een unbounded choice van deze drie.
Met de verwerking van ERR253 in patch 14 is deze bug (ERR250) ook opgelost. Alleen jouw laatste verzoek om GeometrieIMGeo-e te definiëren als een unbounded choice van punt, lijn en vlak lijkt mij meer een RFC. Dit moet dan ook in samenspraak gebeuren met de architecten van het RSGB.
Het verzoek om GeometrieIMGeo-e te definiëren als een unbounded choice van punt, lijn en vlak is als RFC0143 opgevoerd in de onderhoudsverzoeken.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
M.b.t. RFC0143 is tijdens de StUF Expertgroep van 18 februari 2015 geconcludeerd dat het issue wel met StUF-ZKN te maken heeft maar dat de oplossing op een hoger niveau gezocht moet worden. Ook is de opmerking gemaakt dat dit issue geen laaghangend fruit is. Het is dus niet zo 1,2,3 door te voeren.
In het RGBZ heeft deze attribuutsoort het formaat GML: "aanduiding van het type geometrie (Punt, Lijn., Vlak, MultiVlak), gevolgd door coördinatenparen binnen de in Nederland gelegen waarden van het RD-stelsel." Het is dus nadrukkelijk de bedoeling dat StUF-ZKN de mogelijkheid biedt om met het overeenkomstige element de geometrie vast te leggen van een punt, lijn, vlak en multivlak conform de internationale GML-standaard.
Eens met Arjan. Het fragment uit het verslag van de Expertgroep is verwarrend. Bovendien is het verslag nog in concept en niet goedgekeurd. We waren in de StUF Expertgroep de RFC's op de stuf0301-onderlaag aan het behandelen. Per abuis stond RFC0143 daar ook tussen. Vandaar de verwarring! Immers dat is helemaal geen RFC op de onderlaag, maar een RFC op het RSGB 2.0 en StUF-BG 3.10. Ik neem aan dat Ellen deze RFC in het RSGB heeft doorgevoerd. Dan komt ie automatisch mee in StUF-BG 3.20 en als het goed is ook in StUF-ZKN 3.20.
Tijdens de StUF Expertgroep van 20 juli 2016 is besloten dit RFC af te voeren. In het RSGB wordt hier immers niets over gezegd en dus kunnen we er in StUF niets mee.
De expertgroep Informatie modellen wordt gevraagd te besluiten of het object ”voertuig” moet worden opgenomen en zo ja het dan ook nader te specificeren.