search

kadaster / klic-win

https://kadaster.nl/zakelijk/registraties/landelijke-voorzieningen/klic
20 stars 16 forks source link

Relation of Disciplines and Network Elements to Information Polygon only (buffer) #80

Closed adam-ludera-intive closed 3 years ago

adam-ludera-intive commented 4 years ago

Based on the presentation given by Justin Roodenburg, Kadaster will be able to support the client with information on which Disciplines (and thus, presumably, Network Elements) are contained solely in the Information Polygon (i.e. the "buffer" = the area between Graaf boundaries and Information boundaries).

Based on our research on the current data model we find no solid way of producing such information. Therefore, we would like to ask for clarification of whether we shall expect data model change or alternatively how does the Kadaster elicit such information?

One of the possibilities that we consider is that rather than telling the client which of delivered Disciplines are part of the Information Polygon, the Kadaster plans on telling the client which declared Disciplines are part of the Information Polygon.

The latter can be achieved by following geraaktBelangBijInformatiepolygoon and geraaktBelangBijGraafpolygoon links (i.e. taking only those disciplines that are declared in Belangs linked with geraaktBelangBijInformatiepolygoon and not with geraaktBelangBijGraafpolygoon).

However, the former cannot be achieved with the current data model as there is no direct link between UtilityNetwork and Information Polygon.

JustinRoodenburg commented 4 years ago

Hi Adam,

Could you please elaborate a bit on the process you are referring to? Are you referring to the B2B process in which a response is given with the 'KlicB2BBetrokkenBeheerders' in case of a 'calamiteitenmelding'?

Kind regards, Justin

adam-ludera-intive commented 4 years ago

Hi Justin, sorry for late response. I was referring to screenshots of your presentation regarding Information Polygon that presented a list of Utility Companies (Beheerders) and their disciplines (Themas) where, next to each pair, you could see an "i" icon that stated that this specific pair was related solely to the Information Polygon (i.e. the "buffer"). As far as I can remember it was shared that this list is (will be) presented to the Customer after requesting the KLIC via Kadaster Web portal.

My questions there are:

  1. Is this list indeed planned to be shown to the User on successful KLIC Request via Kadaster Web Portal? Or delivered in the later stage, if so when and in what form?
  2. Will this be available as a response from B2B Service (e.g. in "KlicB2BBetrokkenBeheerders") to allow the Service Providers to deliver similar functionality?
  3. If above is true - is it for all types of KLIC (currently, as far as I know this response is there only for Calamity KLICs)?
  4. Regardless of the delivery method of this list - we would like to understand what data is it based on - is it based on the Belanghebbende-Belang declaration or is it based on factual Utility Network information delivered by involved Utility Companies?
  5. If it is based on factual Utility Network information - how this is constructed? With the currently known model, we see no relation between Utility Network (and thus network elements) to the specific polygon in the GML - you can only tell which Belangs are in releation to either Polygon.

Regards, Adam

JustinRoodenburg commented 4 years ago

Hi Adam,

The list you are referring to is shown after doing a ‘calamiteitenmelding’ via the Kadaster website. The information will also be available in the Ontvangstbevestiging.pdf, but then presented as two separate tables. Unfortunately, in the presentation it was not shown that the KlicB2BBetrokkenBeheerders will be adjusted to provide similar information. I can confirm that the KlicB2BBetrokkenBeheerders-message will be adjusted. The GI.xml will mention the intersections between the graafpolygoon and informatiepolygoon with the polygons of the ‘Belangenregistratie’. They are successively referred to as 'geraaktBelangBijGraafpolygoon' and 'geraaktBelangBijInformatiepolygoon'.

All the above is information based on the 'Belangenregistratie', and not on the factual Utility Network information.

In the LI.pdf, it is also shown which Utility Companies (Beheerders) and their disciplines (Themas) are involved and if this specific pair is related (solely) to the Information Polygon (i.e. the "buffer") This information for the LI.pdf is based on the factual Utility Network information. Please note that this information is not included in the GI.xml, since the IMKL is not (yet) suitable for this.

Please let me know if you need more explanation.

Kind regards, Justin

adam-ludera-intive commented 4 years ago

Hi Justin, I would appreciate if you could share more details onto the following:

  1. How this information will be added to the KlicB2BBetrokkenBeheerders model? I don't see any field that would allow delivering such information.
  2. So that we are 100% clear - KlicB2BBetrokkenBeheerders will be still given only for calimiteitenmelding?
  3. Why the new data is going to be added to LI.xml as the current direction is in moving all KLIC data to the GML?
  4. In the Leveringsinformatie-2.1.xsd I cannot find any field that would carry information about the relation to the Information Polygon - could you point me out to where we should expect this information to be provided?

Regards, Adam

JustinRoodenburg commented 4 years ago

Hi Adam,

  1. The XSD fot the KlicB2BBetrokkenBeheerders will change. An additional Boolean will indicate whether a netwerk-thema is solely involved in the information polygon. The new version will be published on Github, probably this week.
  2. The implementation of the Information polygon will not change when you will get the KlicB2BBetrokkenBeheerders-message; to be explicit: after implementation it will indeed still only be given in case of a calimiteitenmelding.

3/4. It will not be in the LI.xml, sorry for the confusion. In the GI.xml you will get ‘geraaktBelangBijGraafpolygoon’ and ‘geraaktBelangBijInformatiepolygoon’. That will be based on the 'Belangenregistratie'.

(FYI: I have corrected that in my above answer to avoid further confusion. Thanks for your accuracy!)

Kind regards, Justin

JustinRoodenburg commented 4 years ago

Hi Adam,

The updated XSD for 'KlicB2BBetrokkenBeheerders' is per yesterday published on github

Please note that this is just the XSD, the optional field will not be returned in the response yet.

Kind regards, Justin

adam-ludera-intive commented 4 years ago

Hi Justin, thank you for the update.

I'd like to go back to the 3&4 item from the previous post, as I find it not fully clear or differently - I see it as a potential risk of data mismatch.

My worries are grounded in the fact that geraaktBelangBijGraafpolygoon and geraaktBelangBijInformatiepolygoon are structures referring to imkl:Belang, and Belang elements are created (as shared on multiple occasions) based on the declaration from the Utility Company, rather than factual Utility Network. On the other hand, you say that you plan to use those structures to share information based on the factual Utility Network location in Information and Dig polygons, which is a contradiction to me.

To help this discussion let's use artificial examples.

The first example comes with a Dig Polygon only, say the size of it is 500x500. Based on the declaration of the Utility Company KL1563 following data is delivered in the KLIC GML:

<gml:featureMember>
    <imkl:Belanghebbende gml:id="nl.imkl-KL1563._Belanghebbende_19G468490-1">
        <imkl:geraaktBelangBijGraafpolygoon xlink:href="nl.imkl-KL1563._Belang_5010699-501"/>
        <imkl:geraaktBelangBijGraafpolygoon xlink:href="nl.imkl-KL1563._Belang_5010699-502"/>
        <imkl:geraaktBelangBijGraafpolygoon xlink:href="nl.imkl-KL1563._Belang_5010699-503"/>
        <imkl:utiliteitsnet xlink:href="nl.imkl-KL1563.datatransport"/> <!-- Network for thema datatransport-->
        <imkl:utiliteitsnet xlink:href="nl.imkl-KL1563.laagspanning"/> <!-- Network for thema laagspanning-->
        <imkl:utiliteitsnet xlink:href="nl.imkl-KL1563.hoogspanning"/> <!-- Network for thema laagspanning-->
        <imkl:utiliteitsnet xlink:href="nl.imkl-KL1563.water"/> <!-- Network for thema water-->
        <imkl:netbeheerder xlink:href="nl.imkl-KL1563._Beheerder"/>
        <!-- Other child elements skipped for clarity sake-->
    </imkl:Belanghebbende>
</gml:featureMember>
<gml:featureMember>
    <imkl:Belang gml:id="nl.imkl-KL1563._Belang_5010699-501">
        <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/datatransport"/>
        <!-- Other child elements skipped for clarity sake-->
    </imkl:Belang>
</gml:featureMember>
<gml:featureMember>
    <imkl:Belang gml:id="nl.imkl-KL1563._Belang_5010699-502">
        <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/water"/>
        <!-- Other child elements skipped for clarity sake-->
    </imkl:Belang>
</gml:featureMember>
<gml:featureMember>
    <imkl:Belang gml:id="nl.imkl-KL1563._Belang_5010699-503">
        <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/laagspanning"/>
        <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/hoogspanning"/>
        <!-- Other child elements skipped for clarity sake-->
    </imkl:Belang>
</gml:featureMember>

Now, let's imagine a situation where the same area is requested as Information Polygon and only a small portion of the area is requested as Dig Polygon. Additionally, imagine that your geospatial analysis says that datatransport, hoogspanning and water networks are in Dig polygon (hence also in Information polygon) but the laagspanning network is present only in the Information Polygon (i.e. not present in Dig Polygon). How do you express it?

<gml:featureMember>
    <imkl:Belanghebbende gml:id="nl.imkl-KL1563._Belanghebbende_19G468490-1">
        <imkl:geraaktBelangBijGraafpolygoon xlink:href="nl.imkl-KL1563._Belang_5010699-501"/>
        <imkl:geraaktBelangBijInformatiepolygoon xlink:href="nl.imkl-KL1563._Belang_5010699-501"/> <!-- datatransport is in both polygons, OK -->
        <imkl:geraaktBelangBijGraafpolygoon xlink:href="nl.imkl-KL1563._Belang_5010699-502"/>
        <imkl:geraaktBelangBijInformatiepolygoon xlink:href="nl.imkl-KL1563._Belang_5010699-502"/> <!-- water is in both polygons, OK -->
        <imkl:geraaktBelangBijGraafpolygoon xlink:href="nl.imkl-KL1563._Belang_5010699-503"/>
<!-- **ISSUE: there's one Belang for two disciplines: hoogspanning and laagspanning but only one of them is in Dig polygon - how to express this?** -->
        <imkl:utiliteitsnet xlink:href="nl.imkl-KL1563.datatransport"/> <!-- Network for thema datatransport-->
        <imkl:utiliteitsnet xlink:href="nl.imkl-KL1563.laagspanning"/> <!-- Network for thema laagspanning-->
        <imkl:utiliteitsnet xlink:href="nl.imkl-KL1563.hoogspanning"/> <!-- Network for thema laagspanning-->
        <imkl:utiliteitsnet xlink:href="nl.imkl-KL1563.water"/> <!-- Network for thema water-->
        <imkl:netbeheerder xlink:href="nl.imkl-KL1563._Beheerder"/>
        <!-- Other child elements skipped for clarity sake-->
    </imkl:Belanghebbende>
</gml:featureMember>
<gml:featureMember>
    <imkl:Belang gml:id="nl.imkl-KL1563._Belang_5010699-501">
        <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/datatransport"/>
        <!-- Other child elements skipped for clarity sake-->
    </imkl:Belang>
</gml:featureMember>
<gml:featureMember>
    <imkl:Belang gml:id="nl.imkl-KL1563._Belang_5010699-502">
        <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/water"/>
        <!-- Other child elements skipped for clarity sake-->
    </imkl:Belang>
</gml:featureMember>
<gml:featureMember>
    <imkl:Belang gml:id="nl.imkl-KL1563._Belang_5010699-503">
        <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/laagspanning"/>
        <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/hoogspanning"/>
        <!-- Other child elements skipped for clarity sake-->
    </imkl:Belang>
</gml:featureMember>

The imkl:Belang elements, based on the data model, are allowed to be defined for multiple disciplines but UtilityNetworks are single discipline only. Therefore, using former to attribute the latter will result in inevitable problems.

Furthermore, I cannot find in any documentation a constraint ensuring that if there is a UtilityNetwork of discipline "A" there must be corresponding Belang present with the same discipline A. Can you point me to such constraint? If such constraint is not enforced, the data consistency is not assured. With the proposed solution (i.e. using imkl:geraaktBelangBijGraafpolygoon and imkl:geraaktBelangBijInformatiepolygoon) in case when this condition is not met, we wouldn't be able to tell if the specific network is in Dig or Information polygon.

Next, should there be two Belangs, both declaring discipline "A" but one linked to Dig and Information polygon but the other to only Information Polygon - should we treat the discipline "A" as included in Information Polygon only or in both Polygons?

Including the Information Polygon and Dig Polygon relation in the UtilityNetwork element would be much more precise and less error-prone.

JustinRoodenburg commented 4 years ago

Adam,

I have to apologize, since I have mixed things up.

The 'geraaktBelangBijGraafpolygoon' and 'geraaktBelangBijInformatiepolygoon' in the GI.xml is based on the 'Belangenregistratie'. For completeness: the indication in the LI.pdf will be based on factual Utility Network information, that is presented on thema level.

No, there is no constraint ensuring that if there is a UtilityNetwork of discipline "A" there must be corresponding Belang present with the same discipline A. It is up to the NetworkOperator to assure that data is consistent. The only way to be able to tell if the specific network is in Dig or Information polygon, would be to do geometrical analysis on the user side. Including the Information Polygon and Dig Polygon relation in the UtilityNetwork elements/disciplines would be much more precise, however this is not supported in the current version of IMKL.

(FYI: I have corrected my above answers to avoid further confusion. Thanks for your accuracy!)

Kind regards, Justin