kadaster / klic-win Goto Github PK

Voor netbeheerders met thema Buisleiding Gevaarlijke Inhoud (BGI) wordt ook de mogelijkheid geboden om de liggingsinformatie van de betrokken netbeheerders op te vragen. De wijze van opvragen mist in het document KLIC-WIN Netbeheerders API v1.1.

In Appurtenance feature for tag heeftExtraInformatie was decided to send ‘Type’ of feature if it is different from IMKL type. But there is no code list value for the tag. testing facility is gving error.

Please find the doc for discription and the screen shot of the error.

Validation Issue - heeftExtraInformatie.docx

Bij het zoeken naar gebiedsaanvragen kunnen in de parameters waarden vanuit codelijsten meegegeven worden. In de API specificatie staat niet duidelijk beschreven of hier de key of de value vanuit de codelijst meegegeven moet worden.

I have the following xml specifying a KabelBed which validates but doesn't show any kabels on the map. How should KabelBed contents be listed ?

This is the code I'm using :

<?xml version="1.0" encoding="UTF-8"?>
<gml:FeatureCollection xmlns:imkl="http://www.geostandaarden.nl/imkl/2015/wion/1.1" xmlns:us-net-wa="http://inspire.ec.europa.eu/schemas/us-net-wa/4.0" xmlns:us-net-sw="http://inspire.ec.europa.eu/schemas/us-net-sw/4.0" xmlns:us-net-common="http://inspire.ec.europa.eu/schemas/us-net-common/4.0" xmlns:us-net-el="http://inspire.ec.europa.eu/schemas/us-net-el/4.0" xmlns:us-net-ogc="http://inspire.ec.europa.eu/schemas/us-net-ogc/4.0" xmlns:net="http://inspire.ec.europa.eu/schemas/net/4.0" xmlns:base="http://inspire.ec.europa.eu/schemas/base/3.3" xmlns:base2="http://inspire.ec.europa.eu/schemas/base2/1.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" gml:id="ID_1c0c5554-5c4a-467a-a9ef-9f36b5af2bfq" xsi:schemaLocation="http://www.geostandaarden.nl/imkl/2015/wion/1.1 https://register.geostandaarden.nl/gmlapplicatieschema/imkl2015/1.1/IMKL2015-wion.xsd">

 <gml:featureMember>
  <imkl:Utiliteitsnet gml:id="nl.imkl.KL1051.geul">
   <us-net-common:utilityNetworkType xlink:href="http://inspire.ec.europa.eu/codelist/UtilityNetworkTypeValue/telecommunications"/>
   <us-net-common:authorityRole xlink:href="http://inspire.ec.europa.eu/codelist/RelatedPartyRoleValue/owner"/>
   <imkl:identificatie>
    <imkl:NEN3610ID>
     <imkl:namespace>nl.imkl</imkl:namespace>
     <imkl:lokaalID>KL1051.geul</imkl:lokaalID>
    </imkl:NEN3610ID>
   </imkl:identificatie>
   <imkl:beginLifespanVersion>2001-12-17T09:30:47.0Z</imkl:beginLifespanVersion>
   <imkl:thema xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/Thema/datatransport"/>
   <imkl:technischContactpersoon>
    <imkl:TechnischContactpersoon>
     <imkl:naam>KPN</imkl:naam>
     <imkl:telefoon>+0800-0105</imkl:telefoon>
     <imkl:email>[email protected]</imkl:email>
    </imkl:TechnischContactpersoon>
   </imkl:technischContactpersoon>
  </imkl:Utiliteitsnet>
 </gml:featureMember>

 <gml:featureMember>
  <imkl:Kabelbed gml:id="nl.imkl.KL1051.55772887">
   <net:beginLifespanVersion>2016-03-03T13:26:07.0Z</net:beginLifespanVersion>
   <net:inspireId>
    <base:Identifier>
     <base:localId>KL1051.55772887</base:localId>
     <base:namespace>nl.imkl</base:namespace>
    </base:Identifier>
   </net:inspireId>
   <net:inNetwork xlink:href="nl.imkl.KL1051.geul"/>
   <net:link xlink:href="nl.imkl.KL1051.55772887.ulink"/>
   <us-net-common:currentStatus xlink:href="http://inspire.ec.europa.eu/codelist/ConditionOfFacilityValue/functional"/>
   <us-net-common:validFrom>2016-03-03T13:26:07.0Z</us-net-common:validFrom>
   <us-net-common:verticalPosition>underground</us-net-common:verticalPosition>
   <us-net-common:utilityFacilityReference xsi:nil="true"/>
   <us-net-common:utilityDeliveryType xlink:href="http://inspire.ec.europa.eu/codelist/UtilityDeliveryTypeValue/transport"/>   
   <us-net-common:warningType xsi:nil="true"/>
   <us-net-common:ductWidth uom="urn:ogc:def:uom:OGC::cm">40</us-net-common:ductWidth>   
  </imkl:Kabelbed>
 </gml:featureMember>

 <gml:featureMember>
  <us-net-common:UtilityLink gml:id="nl.imkl.KL1051.55772887.ulink">
   <net:beginLifespanVersion>2016-03-03T13:26:07.0Z</net:beginLifespanVersion>
   <net:inspireId>
    <base:Identifier>
     <base:localId>KL1051.55772887.ulink</base:localId>
     <base:namespace>nl.imkl</base:namespace>
    </base:Identifier>
   </net:inspireId>
   <net:inNetwork xlink:href="nl.imkl.KL1051.geul"/>
   <net:centrelineGeometry>
    <gml:Curve srsName="EPSG:28992" gml:id="idm55772887">
     <gml:segments>
      <gml:LineStringSegment>
       <gml:posList srsDimension="2">233880.60 580728.40  233880.96 580729.27  233882.39 580730.75  233884.16 580732.74  233887.80 580736.05  233887.17 580737.37  233881.15 580750.00  233880.84 580750.66  233880.71 580750.63  233878.35 580750.63  233875.83 580751.33  233874.31 580753.04  233872.14 580758.08  233858.71 580792.95  233858.86 580792.22  233858.71 580792.95  233857.97 580796.56  233859.20 580802.44  233860.24 580807.01  233862.20 580815.61  233864.28 580825.95  233864.39 580826.48  233866.24 580837.53  233866.35 580838.21  233866.90 580840.85  233872.05 580865.66  233872.82 580869.40  233871.98 580874.23  233873.38 580881.50  233875.53 580883.11  233877.93 580894.88  233877.28 580895.21  233871.74 580897.48  233866.91 580901.43  233847.22 580950.53  233841.73 580959.01  233841.61 580959.15  233832.75 580969.06  233831.77 580970.20  233850.29 580985.81  233865.65 580999.41  233866.05 580999.87  233866.06 581000.16  233878.45 581010.52  233883.51 581014.85  233884.61 581015.37  233885.44 581015.62  233885.70 581016.57</gml:posList>
      </gml:LineStringSegment>
     </gml:segments>
    </gml:Curve>
   </net:centrelineGeometry>
   <net:fictitious>false</net:fictitious>
   <us-net-common:currentStatus xlink:href="http://inspire.ec.europa.eu/codelist/ConditionOfFacilityValue/functional"/>
   <us-net-common:validFrom>2016-03-03T13:26:07.0Z</us-net-common:validFrom>
   <us-net-common:verticalPosition>underground</us-net-common:verticalPosition>
  </us-net-common:UtilityLink>
 </gml:featureMember>

</gml:FeatureCollection>

Als enige opmerking heb ik dat de parameters die verplicht, optioneel of conditioneel zijn soms best verwarrend overkomen. Wat ik wel een klein puntje vind is dat het telefoonnummer of mobile nummer van de aanvrager optioneel zijn. Ik zou ze ieder geval conditioneel op elkaar maken. Of zelfs verplicht zoals nu ook is. (blz. 12 en 22)

Verder akkoord vanuit mijn rol als grondroerder / aannemer.

For BMKL messages, we need to have the examples for:

• /gebiedsInformatieAanvragen/netbeheerder: This will return the list of map requests. We require an example of the exact format what this URI will return.
• /gebiedsInformatieAanvragen/{id}/netbeheerder: This will return the map request with specific ID. We require an example of the exact format what this URI will return when we specify the KLIC ID.
• /gebiedsInformatieAanvragen/{id}/netbeheerder/gezien: This will be used for posting the acknowledgement / confirmation of specific KLIC Id. We require the format of what to be posted as acknowledgement.

• we need to know how the ZIP file containing the XML, PDFs etc needs to be sent. Will it be in JSON or SOAP format. We need to know the way of communication and an example of the exact format to be used.

Martin van Vaalen

Paragraaf 2.3.1.1 bevat een typo (Huisaansluistchets Adres) en in de omschrijvingen wordt ten onrechte gerefereerd aan het bezoekAdres van de gebiedsinformatieaanvrager i.p.v. huisaansluitschetsadres.

In de verschillende JSON responses worden er @-elementen gebruikt om waarschijnlijk de vertaalslag te maken van XML attributen naar JSON elementen. Echter vermindert hierdoor de semantiek van het document. Ook wordt het geautomatiseerd verwerken met een API-client implementatie van deze JSON elementen lastiger. Tevens kunnen in zowat alle gevallen de geneste elementen direct als waarde van de bovenliggende key worden gebruikt. Voorbeeld:

Huidige situatie:

"aanvraagSoort": {"@href": "https://api.kadaster.nl/klic/v1/cl/aanvraagSoorten/orientatiemelding"}

Voorgestelde situatie:

"aanvraagSoort": "https://api.kadaster.nl/klic/v1/cl/aanvraagSoorten/orientatiemelding"

In hoofdstuk 4 is niet opgenomen een attribuutbeschrijving van de opgeleverde netinformatie van de geïdentificeerde netbeheerder. Graag deze opnemen voor compleetheid (gelijk aan de attribuutbeschrijving van de gebiedsinformatie [paragraaf 3.4.2]).

In het voorbeeld XML wordt er 'coordinate' en 'coordinates' gebruikt voor het beschrijven van geografie, echter zijn deze elementen zijn sinds GML 3.1 deprecated. Dit staat beschreven in OpenGIS® Geography Markup Language (GML) Implementation Specification version 3.1.1:

9.1.3.5 gml:CoordinatesType, gml:coordinates

This type is deprecated with GML version 3.1.0 for tuples with ordinate values that are numbers.

CoordinatesType is a text string, intended to be used to record an array of tuples or coordinates.

While it is not possible to enforce the internal structure of the string through schema validation, some optional attributes have been provided in previous versions of GML to support a description of the internal structure. These attributes are deprecated with GML version 3.1.0. [...]

[...] The "coordinates" element is deprecated with GML version 3.1.0. [...]

Wij zouden graag zien dat de elementen gml:pos en gml:posList gebruikt worden, aangezien deze elementen door het OGC aanbevolen worden.

In de voorbeeld geometrie staat het SRS beschreven met een naam, zoals EPSG:28992, echter heeft het OGC in 2007 de OGC® Best Practices Paper uitgegeven, waar in het subdocument Definition identifier URNs in OGC namespace staat beschreven dat het een best practice is om SRS'en in URN definities uit te drukken. Ook in de GeoJSON specificatie van het IETF wordt er met deze URN's gewerkt.

Wij zouden daarom graag zien dat de SRS volgens de URN specificatie van het OGC wordt opgebouwd. Tevens vereenvoudigd dit de automatische verwerking en ondubbelzinnigheid van de gegeven SRS.

Regarding the BMKL request validations (2.3.1 Parameters map request), for the 'aanvrager', both 'bezoekAdres' and 'postbusAdres' are conditional and the attributes inside those are also conditional. But for 'opdrachtgever', 'bezoekAdres' is required and 'postbusAdres' is conditional, but the attributes inside both 'bezoekAdres' and 'postbusAdres' are either conditional or optional and condition depends on each other attributes. We feel that 'bezoekAdres' should be conditional.
Same applicable for the 'bezoekAdres' and 'postbusAdres' under 'opdrachtgever'.

In de API specificatie onder hoofdstuk 3.2.2 staat een voorbeeld XML response. Wij denken dat er in deze XML response het element <element> onnodig voorkomt. Daarom zouden wij voorstellen deze te laten vervallen en het volgende aan te houden:

<?xml version="1.0" encoding="UTF-8"?>
<gebiedsInformatieAanvragen> 
      <gebiedsInformatieAanvraag href="https://api.kadaster.nl/klic/v1/ws/gebiedsInformatieAanvraag/2a3fe3ef-b606-4f6a-b5dd-d19d6f3e3ce6/Netbeheerder" />
      <gebiedsInformatieAanvraag href="https://api.kadaster.nl/klic/v1/ws/gebiedsInformatieAanvraag/995b3a08-de6a-44f1-8547-98273f1139bb/Netbeheerder" />
</gebiedsInformatieAanvragen>

Naar onze mening wordt tevens de semantiek van het response verbeterd, waarnaast de implementeerbaarheid vereenvoudigd wordt.

Via het KLIC-WIN contactformulier heb ik de volgende vraag gesteld:

Netbeheerders van telecom (datatransport) moeten in de huidige versie van het IMKL het aantal kabels in een HDPE buis aangeven. Een manier die toegestaan is, is om dat via annotatie duidelijk te maken. Blijft deze mogelijkheid binnen IMKL2015 toegestaan?
De achtergrond is dat bij veel klein(er)e telecom-netbeheerders gegevens alleen in de vorm van CAD-tekeningen beschikbaar zijn, waarbij het aantal kabels alleen uit de annotatie blijkt. Conformeren aan IMKL2015 is dus potentieel een grote inspanning/kostenpost.

Het antwoord van het Kadaster luidde:

Dit is meer een sectorvraag. In het model is hier namelijk een speciaal attribuut voor opgenomen ‘buismateriaalType’. U kunt een issue aanmaken op GitHub https://github.com/Kadaster/KLIC-WIN Dit kan dan door één van de Werkgroepen beantwoord worden.
Ons advies zal ook zijn dat als er een attribuut is voor de informatie die u wilt communiceren, dat u ook dat attribuut daarvoor moet gebruiken en dat u de informatie niet in een andere vorm communiceert.

Bij deze leg ik dus de vraag hier als issue voor.

Sebastiaan Baars schrijft:

In de KLIC-WIN Netbeheerder API v1.1 documentatie zit een typo. Bij header 5.15 staat klic/v1/ci/validatieStapMeldingLeves en dit moet volgens mij klic/v1/ci/validatieStapMeldingLevels zijn 😄

Hieronder de reviewopmerkingen op de BMKL 0.9 van Wil en mij. Het zijn geen grote bevindingen, maar opmerkingen over typo’s, leesbaarheid en consistentie.

1, 3, 4, 9 en 10 zijn typo’s
Tav 2 en 8 kan de leesbaarheid verbeterd worden
5,6 en 7. Hier wordt een max aantal van 100 en ook van 50 genoemd. Wat is nu het max en waarom zou het van 50 naar 100 meten gaan?

1. Par 2 Typo
2. Par 2.1 In de figuur 1 is de GebiedsinformatieAanvraag een bericht tussen Aanvrager en KLIC en niet tussen KLIC en Netbeheerder. Dit stemt niet overeen met de tekst bij de figuur.
3. Par 2.3.1.1 Typo in de titel
4. Par 2.4 Typo
5. Par 3.2.1 Tabel “Request Parameters”. In regel “Offset” is sprake van een max van 100. Klopt 100 wel? Bij punt 7 wordt een max van 50 genoemd. Waarom nu 100?
6. Par 3.2.1 Tabel “Request Parameters”. In regel “Limiet” is sprake van een max van 100. Klopt 100 wel? Bij punt 7 wordt een max van 50 genoemd. Waarom nu 100?
7. Par 3.2.2 Tabel “Response Parameters”. In regel “GebiedInformatieAanvragen” is sprake van een max van 50. Bij punten 5 en 6 wordt een max van 50 genoemd?
8. Par 4.2 en 4.3 De paragraafindeling is onduidelijk. Voor 4.2 “Opvragen Status beheerdersinformatie” en 4.3 “Opvragen Beheerders Informatie” zou je dezelfde subpararaaf indeling en vergelijkbare info in de subparagrafen verwachten
9. Par 5.1.1 Typo. Is het orientatiemelding of oriëntatiemelding. (dus e of ë). Dit is niet door het hele document op dezelfde wijze geschreven in de voorbeelden
10. Bijlage 1 Typo

2.3.1

1. Relatienummer netbeheerder ontbreekt
2. Klicnummer ontbreekt
3. Aanvrager Huisnummer tekst “indien van toepassing” kan weg
4. Aanvrager telefoon verplicht als geen mobiel nummer is opgegeven
5. Aanvrager mobiel verplicht als geen telefoon is opgegeven
6. Opdrachtgever Huisnummer tekst “indien van toepassing” kan weg
7. Opdrachtgever telefoon verplicht als geen mobiel nummer is opgegeven
8. Opdrachtgever mobiel verplicht als geen telefoon is opgegeven
9. Aanvraagdatum tekst “Alleen verplicht in antwoordbericht” kan weg.
10. Datumverzending ontbreekt
11. locatieWerkzaamheden (Bijvoorbeeld het dichtstbijzijnd adres) doorgestreept, voorstel “Dichtstbijzijnde adres binnen de gemeente waar gegraven wordt ten opzichte van het midden van de graafpolygoon. met minimaal plaatsnaam en straat) Bij afwezigheid straatnaam betere locatie toevoegen.
12. Stardatum en Einddatum . (* Alleen verplicht in geval van een graafmelding)

2.3.1.1

1. Tekst bij alle attributen klopt niet

2.3.2

1. Klicnummer ontbreekt

3.2.1

1. Relatienummernetbeheerder ontbreekt bij zoekcriteria.

3.3.2

1. Zie eerder opmerkingen bij gebeidsinformatieaanvraag.

4.2.3

1. Klicnummer ontbreekt

4.3

1. Zou wel > 1 mogen zijn mijns inziens. Mogelijk is 100 teveel maar 1 is erg weinig

In de waardenlijsten worden alle waardes (values) gelimiteerd op 50 tekens. Echter zijn er al voorbeelden in de API specificatie die over de specifieke 50 tekens heen gaan. Ons voorstel zou dan ook zijn om het maximaal aantal tekens niet te hanteren, of om een (veel) hogere waarde te kiezen. Voorbeelden:

• De beheerdersinformatie komt uit de centrale voorziening (57 tekens)
• Nog niet alle beheerdersinformatie is geleverd en goedgekeurd (62 tekens)

In paragraaf 2.1 wordt BMKL2.0 afgebakend. Onderdeel van BMKL2.0 is ook het Netinformatie bericht t.b.v. het aanleveren van informatie aan de centrale voorziening. Hiervoor is echter geen API gepubliceerd. Wanneer komt hiervoor wel een API ter beschikking?

Op dit moment heb ik eigenlijk geen opmerkingen over het document anders dan dat jou visualisaties zoals die gebruikt zijn in onze besprekingen naar mijn idee een toegevoegde waarde hebben in het per onderdeel verhelderen van het proces, waarbij het daarnaast zinvol is om de situatie van centraal en de-centraal duidelijk te onderscheiden.

In de API specificatie staat onder hoofdstuk 3.2.2 dat er een lijst met URI’s wordt teruggegeven vanuit de API. Echter wordt er in het voorbeeld een lijst met (geneste) objecten teruggegeven. Wel hebben deze objecten echter altijd dezelfde key’s. Daarom zouden wij voorstellen om het daadwerkelijk een lijst met URI’s te maken, in de volgende vorm:

[
"https://api.kadaster.nl/klic/v1/ws/gebiedsInformatieAanvraag/995b3a08-de6a-44f1-8547-98273f1139bb/Netbeheerder",
"https://api.kadaster.nl/klic/v1/ws/gebiedsInformatieAanvraag/995b3a08-de6a-44f1-8547-98273f1139bb/Netbeheerder"
]

of eventueel in deze vorm, waarbij er tevens nog wat semantiek wordt bewaard:

[
{"gebiedsInformatieAanvraag": "https://api.kadaster.nl/klic/v1/ws/gebiedsInformatieAanvraag/995b3a08-de6a-44f1-8547-98273f1139bb/Netbeheerder"}, 
{"gebiedsInformatieAanvraag": "https://api.kadaster.nl/klic/v1/ws/gebiedsInformatieAanvraag/995b3a08-de6a-44f1-8547-98273f1139bb/Netbeheerder"}
]

Beide varianten zijn tevens gemakkelijker implementeerbaar in een API-client.

Ik zou de gebiedsInformatieAanvragen-service willen gebruiken om bij het constateren van graafschade te achterhalen of er relevante aanvragen zijn gedaan.

Daarover twee vragen:

• Hoever gaat de gebiedsInformatieAanvragen service terug? Zijn alle ooit ingediende gebiedsInformatieAanvragen via dit endpoint op te vragen, of worden gesloten aanvragen op een gegeven moment gewist?
• Is het mogelijk bbox (bounding box) toe te voegen als parameter aan GET /gebiedsInformatieAanvragen/netbeheerder/, zodat enkel de aanvragen worden teruggegeven waarvan het graafgebied enige overlap met de bbox heeft?

Wij zouden graag bij HTTP POST requests een 'Content-Type' HTTP header meesturen. Wanneer dat gebeurt kan de REST API namelijk een 415 Unsupported Media Type HTTP status code terugsturen, als er een 'verkeerde' payload meegestuurd wordt. Dit verduidelijkt dan de foutmelding voor de implementatie ontwikkelaar. Deze header zou dan tevens verplicht kunnen zijn voor "Sturen melding gebiedsinformatieaanvraag gezien", aangezien het daar mogelijk is om zowel een JSON als XML te versturen.

As per the xls IMKL2015 v 1 1_object-attributen-ExtraRegels.xlsx, 'rotatiehoekSymbool' property is mentioned, but in xsd 'IMKL2015-wion.xsd' its missing.
Please suggest what to do for the issue.
Please find the screen shot of the xlsx attached

Er ontbreekt een formele beschrijving van aansluitschetsAdressen en in het response voorbeeld bij 3.3 Ophalen gebiedsinformatieaanvraag ontbreekt de BAG identificatie.

Loggin in to the 'My Kedaster' Portal is denied. Loggin ID used is 'UdayTechM'. Please reset the password.

Bij het zoeken naar gebiedsaanvragen is het mogelijk om een datum en tijd mee te geven. Dit is in het formaat ISO 8601 volgens de huidige specificatie. Echter is het niet geheel duidelijk in welk formaat van de ISO 8601 formaat gezocht kan en mag worden en worden er in de voorbeelden geen tijdzones gedefinieerd.

Ons voorstel zou dan ook zijn om de mogelijkheid te bieden om te zoeken op datum vanaf 00:00 volgens formaat: 2015-10-21, waarbij er een zero-offset tijdszone wordt gehanteerd, dus eigenlijk 2015-10-21T00:00:00Z. Tevens zou er dan de mogelijkheid geboden kunnen worden om op specifieke datum en tijd te zoeken volgens de volgende formaten: 2015-10-21T15:41:36+01:00 en 2015-10-21T15:41:36Z. Dan is er namelijk geen onduidelijkheid meer over de eventuele tijdszone.

We hebben in de sessie van 23 september begrepen dat er geen API beschikbaar komt om afgehandelde INSPIRE aanvragen te downloaden. dit was wel onze verwachting. Is er een mogelijkheid om deze wens, die veel netbeheerders hebben, opnieuw onder de aandacht te brengen?

The NTD-testfacility contained a button 'Selecteer Bestand' to upload a new zipfile. This button is gone and we cannot test our zipfiles. Attached the situation as I see it now and the situation from the manual

Current:

Manual :

In KlicVoorzorgsmaatregelenBeheer-0.1.xsd staat dat de lengte van bronhoudercode maximaal 5 karakters mag zijn. Dit is niet correct het moet maximaal 6 karakters zijn. In de KlicDocumentenBeheer.xsd staat dit wel goed.

In de datum en tijd van de responses in paragrafen 3.3.2 en 4.3.2 is de precisie aan de onnodig hoge kant. Onze voorkeur zou hebben om dit op de seconde af te handelen.

Tags like ValidFrom, ValidTo, verticalPosition, DuctWidth, WarningType are optional as per IMKL. When we dont give this tags the testing portal gives error. And also when we give no values or NULL value it gives error.
Find the attachement for the errors sreen shots
Validation Issue.docx

In het voorbeeld XML response van het ophalen van een gebiedsaanvraag worden dezelfde elementen gebruikt als in het JSON document. In de XML response zou het echter wenselijker zijn om pure GML te gebruiken, zonder extra elementen eromheen. Voorbeeld:

<informatieGebied>
    <gml:Polygon srsName="EPSG:28992">
        <gml:outerBoundaryIs>
            <gml:LinearRing>
                <gml:coordinates>194137,465803 194136,465921 194314,465923 194315,465804 194137,465803</gml:coordinates>
            </gml:LinearRing>
        </gml:outerBoundaryIs>
    </gml:Polygon>
</informatieGebied>

Dit zou tevens de eenvoudigheid met betrekking tot implementatie verhogen, vanwege de mogelijkheid tot gebruik van standaard bibliotheken. Voorbeelden van zulke standaard bibliotheken voor GML zijn:

• Java GeoTools
• Java JAXB2
• C# (.net)
• JavaScript (OpenLayers)

Marcel Olij (services expert):

1. Ik neem aan, dat het ‘Zoeken naar gebiedsInformatieaanvragen’ zonder parameters default (alle of 1e 100 )aanvragen met status ‘open’ levert??
2. Dan heb ik er moeite mee, dat het autorisatie en authenticatiemechanisme zo dun omschreven is. Of staat dit in een ander document?

Jorrit Hansson:

1. Mijn naam is met 2 s-en (Jorrit Hansson), niet met 1 s
2. Ik mis een stukje overzicht / informatie in de API: het opvragen gebiedsinformatie door netbeheerder
   Als ik het document lees dan mis ik nog iets, namelijk het benoemen van de stroom Gebiedsinformatie van KLLO-Online naar de Netbeheerders.
   Die staat wel in de powerpoint maar ik kon hem niet goed terugvinden in het document

Op pagina 37 staat een json voorbeeld met een foutje tav upper/lowercase, BiNotificatieStatussen moet met een kleine letter beginnen.
{ "key": "https://api.kadaster.nl/klic/v1/cl/BiNotificatieStatussen/open", "value": "Dit is een openstaande gebiedsinformatie-aanvraag" }

Op pagina 41 staat een json voorbeeld met een foutje tav upper/lowercase, GiAanvraagStatussen moet met een kleine letter beginnen.
{ "key": "https://api.kadaster.nl/klic/v1/cl/GiAanvraagStatussen/open", "value": "Er is een nieuwe gebiedsinformatie-aanvraag ingediend" }

Bij lezing van v0.90 heb ik de volgende opmerkingen:

1. Typo: begin pag 7; verwijzing 2.5 moet 2.6 zijn.
2. Pag 9: Vraag: 'gebiedsInformatieAanvragen/{id}/ (GET)' zie ik niet direct terug in figuur daarvoor. Idem mbt 'beheerdersInformatie/gebiedsInformatieAanvraagId/{id} (GET)'.
3. Pag 11: aanvraagID is blijkens voorbeelden iets anders dan KLIC-nummer. Ik mis het KLIC-nummer. Alliander heeft dat ook geconstateerd. In reactie is dit een business-vraag genoemd.
   Mi moet KLIC-nummer er altijd bij staan, dit is het meest éénduidige nummer voor communicatie op gebruikersniveau. Nu is dat nummer er ook en dit zou niet mogen verdwijnen.
4. Pag 17 / par 3.2: Hoe vraag je de aanvragen op die je nog niet hebt ontvangen? Kan dit obv status?
   NB: Eerdere reactie op dit punt is mij nog niet voldoende duidelijk.
5. Pag 26: Voorbeeld met BAG-adres bovenaan bevat geen postcode. Toch verplicht?
6. Pag 30/ par 4.3.: "GET klic/v1/ws/beheerdersInformatie/gebiedsInformatieAanvragen/{id}"
   Waar staat deze in een figuur? Graag verwijzing tbv duidelijkheid.

NB: Misschien zijn punten al eerder opgemerkt, dan zijn ze bij controle van de issues door mij over het hoofd gezien en zijn ze ten overvloede.

In de documentatie wordt niet goed duidelijk uitgelegd dat bij het zoeken met een parameter uit de codelijst een id moet worden gebruikt en dat het id het gedeelte is na de laatste slash van een key (URI). In de response wordt wel de volledige key (URI) wordt geretourneerd. Aan de hand van de voorbeelden is het wel af te leiden maar wellicht is het verstandig de documentatie t.a.v. dit punt iets meer te verduidelijken.

Voorbeeld:
Zoeken naar gebiedsinformatie-aanvragen met request parameter aanvraagSoort bijvoorbeeld aanvraagSoort=orientatiemelding.
In de json response wordt de volledig key geretourneerd: "aanvraagSoort": "https://api.kadaster.nl/klic/v1/cl/aanvraagSoorten/orientatiemelding"

Bij het zoeken naar gebiedsaanvragen kunnen er meerdere parameters meegegeven worden in het request. In hoofdstuk 2 van de voorgestelde API specificatie staat bij alle requests beschreven in hoeverre request parameters optioneel, conditioneel of verplicht zijn. In deze paragraaf mist deze status per parameter, of wanneer ze allemaal dezelfde status hebben, een begeleidende tekst.

In het voorbeeld JSON response van het ophalen van een gebiedsaanvraag, wordt er de suggestie gewekt dat er met GeoJSON wordt gewerkt. Echter is dit niet het geval. Het zou met betrekking tot de open webstandaarden de voorkeur hebben om met de GeoJSON standaard te werken. Tevens verhoogt dit de eenvoudigheid met betrekking tot API implementatie. Het is bij de implementatie dan namelijk mogelijk om een standaard bibliotheek te gebruiken. Voorbeelden van zulke standaard bibliotheken voor GeoJSON zijn:

• Java, Jackson
• Java, Jackson
• C# (.net)
• JavaScript (Leaflet)
• JavaScript (Google Maps)
• JavaScript (OpenLayers

Wat is the supported ZIP format?

In 2.3.1, 'aanvraagDatum', 'giAanvraagStatus' and 'soortWerkzaamheden' are mentioned as Conditional. But the condition is not mentioned in the Description column like in case of other conditional attributes.

1.1; Met uitzondering van het aanleveren van gegevens voor de centrale voorzienign.Zie 1.2 Scope.
2.2; beheerdersInformatie/gebiedsInformatieAanvraagId/{id} (GET): Deze stap staat niet in figuur 3.
2.3.1; Conditioneel als er geen bezoekadres is maar een postbus dan ook geen postcode voor het bezoekadres.
2.3.1.1; Pand of verblijf ID?
2.4; Mogen of moeten
3.1; Is er dan een bericht? Of alleen een header?
5.1; INSPIRE melding?
5.7; Stuur een lijst?
5.8; Vraag een lijst De tekst bij 5.7 is hetzelfde als bij 5.8
5.9; Stuur een lijst?
5.10; Vraag een lijst?

De beveiliging moet conform Digikoppeling middels tweezijdig TLS.

Voor de identificatie gebruiken we PKIoverheid-certificaat, voorzien van een uniek identificerend nummer voor (OIN).

XSD issue’s
• We have converted the XSD ‘IMKL2015-wion.xsd’ to C# classes using Xsd2Code tool of Visual studio.
• It got converted to C# classes.
• But when we try to serialize the class (for example FeatureCollecton) using.NET API it throws Invalid Operation error. Refer below image.

• When we go into the details of the error it shows ‘Cannot serialize object of type 'IMKL2015_wion.MeasureType'. Consider changing type of XmlText member 'IMKL2015_wion.MeasureType.Value' from System.Double to string or string array’
• From the above description of error, we understand that for serializing or converting to XML the type must be in string , but in the XSD it is double.
• We changed the type(Double to string) of the property, then we noticed that it requires changes in more than one places. Then we changed all the classes that are generated from XSD. Changes was required in around 126 places in the classes.
• After doing the above changes, we got another error. Refer below image

• The error showed ‘Type of choice identifier 'ItemsElementName' is inconsistent with type of 'Items'. Please use array of System.Collections.Generic.List`1[[IMKL2015_wion.ItemsChoiceType3, IMKL2015-wion, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].’
• Above error was because of the itemchoices are in LIST datatypes they must be array.

Het huidige uitgangspunt van de API is dat de "gebruiker" een netbeheerder is waarbij de netbeheerder alleen informatie kan zien of wijzigen die voor hem zelf bedoeld is of die hij zelf aangeleverd heeft.
Een serviceprovider is hierbij een "gebruiker" die namens een netbeheerder opereert. Onder het account waarmee hij voor een netbeheerder iets uitvoert kan hij alleen die informatie zien of wijzigen die voor de betreffende netbeheerder bedoeld zij of die in de context van de betreffende netbeheerder aangeleverd zijn.

Hi Fuat,

TechM (System Integrator from KPN) has a question regarding the interface between the Kadaster site and the KPN site concerning KLIC WIN. As I understood the
proposal is to use JSON technology for the API and we will send gml files across using the API (interface). There will be only one GJSON component in this, the request which
comes from the Kadaster will hold a GJSON component.

Can you please confirm this and if it’s different as I explained above then please let us know how it should be. If the explanation as mentioned above is correct then can you
please explain why we don’t use GJSON for the vector data instead of gml files?
Thanks!

Regards,

John

John van Luijk
Domain Architect OSS GIS
KPN NetCo FO N&S Development
+31 6 537 603 01

Voor de helderheid van de API specificatie zouden wij graag zien dat een HTTP status code 406, Not Acceptable teruggestuurd wordt wanneer er een request wordt gedaan met een niet ondersteunde Accept-header.

In het documetn 'IA Geautomatiseerd actualiseren 2016-07-07.ppt' zijn wensen aangegeven vanuit netbeheerders t.a.v. het geautomatiseerd aanleveren van netinformatie (sheet 4). Hierin is de wens

'dat een serviceprovider aanleveringen namens een netbeheerder volledig kan afhandelen (enkel en alleen als deze daarvoor gemandateerd is de door de betreffende netbeheerder).'

Als prioriteit 2 aangemerkt.

Hoe is tot deze prioriteit gekomen? Wie hebben de prioriteiten bepaald?

Voor Service Providers, en daarmee ook voor alle netbeheerders die via een service provider gaan aansluiten, is deze wens prioriteit 1. Dit is in het belang van alle netbeheerders die via een service provider aansluiten. Deze wens is nodig om de kosten laag te kunnen houden (geen handmatige acties), en dus in het belang van 'de kleinere netbeheerders', die niet de kennis en kunde in huis hebben om de aansluiting zelf te realiseren. Is het mogelijk dat deze wens prioriteit 1 krijgt?

Geachte werkgroepleden,

Ik heb geen op//aanmerkingen op de V0,9