Feedback: Samenstelling Locatieserver-ID’s

Toepassingen LocatieServer
#1

Beste Locatieserver gebruiker(s),

PDOK is voornemens om in het Locatieserver-ID niet meer de ID’s uit de achterliggende databronnen voor te laten komen. Dit om verwarring te voorkomen en aan te blijven haken bij het ontwerp en doel van de Locatieserver. Hieronder meer informatie. We waarderen uw input dus willen de gelegenheid geven voor opmerkingen of aanvullingen. We willen het voorstel graag op donderdag 30 maart aanstaande bekrachtigen dus horen graag voor die tijd van u. Alvast bedankt!

Huidige situatie
Veel gebruikers implementeren de suggestservice in combinatie met de lookupservice van de Locatieserver. Zo is het ontwerp van de Locatieserver ook ingericht. Een teruggeven suggestie kent weinig relevante informatie omwille van de performance, maar wel een uniek ID waarmee een koppeling gelegd kan worden naar het gesuggereerde object in de lookupservice. Het object in de lookupservice bevat alle relevante informatie van het object, waaronder de geometrie die nodig is om naar de locatie op de kaart te gaan.

In de huidige versie van de Locatieserver is het Locatieserver-ID afgeleid van ID’s uit de achterliggende databronnen, zoals BAG. Dit is niet handig gebleken, omdat er straks ook andere datasets toegevoegd kunnen worden die geen eigen ID kennen of waarvan het eigen ID kan wijzigingen. Dit soort situaties zijn niet beheer(s)baar en is daarom niet gewenst. Qua ontwerp zou het Locatieserver-ID dan ook mogen wijzigen.

Nieuwe situatie
PDOK is voornemens om in het Locatieserver-ID niet meer de ID’s uit de achterliggende databronnen voor te laten komen om verwarring te voorkomen. Kenmerkend aan het Locatieserver-ID zal zijn dat het een willekeurig ID is, dat geldig blijft totdat er een volgende update van de data is geweest. Het ID is daarmee wel uniek, maar niet persistent. Momenteel zal de achterliggende data niet vaker dan dagelijks worden geupdate. Omdat in de huidige situatie de ID’s uit de achterliggende databronnen nog worden gebruikt als basis voor het Locatieserver-ID, zal PDOK dit aanpassen naar willekeurig genereerde ID’s. Dit zal ook voor toekomstige datasets generiek toegepast gaan worden. Deze ontwerpkeuze draagt bij aan het op een beheersbare manier toevoegen van nieuwe datasets aan Locatieserver en past binnen het doel en ontwerp van de Locatieserver van PDOK om niet als combinatieservice, maar als zoekservice te dienen.

#2

Ha Jeroen, ik moet eerlijk bekennen dat ik dit besluit zou betreuren. Het gaat echt een beetje tegen de tijdsgeest in, om data zonder haar persistent identifier te publiceren. Ik begrijp ook niet zo goed de motivatie om hiervan af te zien.

Handreikingen zoals INSPIRE raden organisaties ten zeerste aan om data op te slaan vergezeld van een persisitent identifier, in toenemende maten als URI. Als locatie server hoef je deze identifier alleen maar over te nemen. Als de achterliggende dataset geen persistent identifier bevat, dan is het een ander verhaal, maar mijn vermoeden is dat dit in steeds minder situaties voor zal komen.

Overigens zou ik persoonlijk de identifier van het object los trekken van een eventuele identifier die locatieserver aan het object toekent, dus beide opslaan. Mogelijk lost dit voor jullie een organisatorisch aspect op.

#3

Wij sluiten ons aan bij de bezwaren en redenering van Paul. In aanvulling hierop: je introduceert hier mee het potentiele (weliswaar kleine) risico dat tussen de aanroep van suggest en lookup de identifier wijzigt, en dat daarmee gegevens van een verkeerd of niet meer bestaand object worden opgehaald.

#4

Ik vraag me sterk af of Jeroen niet hetzelfde bedoelt als Paul. In de database wereld noem je dit verschil “natuurlijke sleutels” en “niet-natuurlijke sleutels”. De suggest-service moet niet-natuurlijke sleutels gebruiken die doorgegeven moeten worden aan de lookup-service om meer info op te halen. De lookup-service geeft vervolgens o.a. eventuele natuurlijke-sleutel terug als die er is (en dat blijkt dus niet altijd zo te zijn volgens Jeroen).

Dat is volgens mij precies wat het voorstel van Jeroen beoogt.

#5
#6

@pvgenuchten @rli @nico.plat Het voorstel betreft inderdaad het los trekken van Locatieserver ID’s en de ID’s van het object. Op dit moment zijn beide hetzelfde en we willen voor de Locatieserver ID’s eigen ID’s gaan genereren. Daarnaast was het oorspronkelijke idee om dan na iedere update deze ID’s te laten wijzigen. Dit vanuit beheeraspecten. Maar zoals ik lees in jullie reacties hebben jullie goede argumenten om dit niet te doen. We gaan dit als alternatief onderzoeken. Bedankt voor jullie feedback!

#7

De volgende vraag is hoe het “lostrekken” (d.w.z. geen natuurlijke sleutels gebruiken) moet gebeuren. Dit kan via hashing, sequences of UUID’s. Als iemand een andere mogelijkheid weet, laat het ons weten.

We hebben het een keer over hashing gehad. Dit werd afgewezen i.v.m. de kans op collisions. De kans op een collision is +/- 50% wanneer het aantal keys dat je hebt gegenereerd de wortel is van het totaal aantal mogelijkheden. Dus bij een 128-bits hash (bijv. MD5) gebeurt dit als je ca. 2^64 hashes hebt berekend. Zie Birthday Attack op Wikipedia. Deze cijfers gelden alleen wanneer het hashing algoritme voor een goede distributie van de resultaten zorgt, dus een goede “balance” heeft.

Nu zitten we op ca. 10 miljoen objecten in Locatieserver. Door met name kadastrale percelen zal dit toenemen (+/- 7 miljoen) en in de toekomst worden waarschijnlijk andere datasets toegevoegd. Het is gissen, maar stel dat we onder 1 miljard objecten blijven. De kans op een collision van slechts 10^-18 bij 128 bits treedt pas op bij ca. 26 miljard objecten, dus wat dat betreft zou hashing “veilig” zijn. Zeker als we een algoritme zouden kiezen dat gebruik maakt van veel meer bits.

Het voordeel van hashing is dat we de hash direct kunnen afleiden uit de brondata. Als van een record uit de brondata de attributen zodanig wijzigen dat de hash anders wordt, dan moet het in principe als een ander object beschouwd worden. Voor brondata met een duidelijke eigen ID spreekt het voor zich dat we dit als hash zouden gebruiken. Voor brondata waar dit niet het geval is, bijv. NWB hectopunten, zouden we een aantal attributen moeten selecteren, desnoods de locatie (hash over de WKT of de WKB van de geometrie). In beide gevallen zou ook het type in de hash moeten worden meegenomen, net zoals op dit moment unieke ID’s worden gegarandeerd.

Bij het gebruik van een sequence of UUID’s moet de relatie tussen het bronobject en de ID worden vastgelegd. Dit maakt het verwerkingsproces complexer en PDOK moet ervoor zorgen dat deze data wordt gebackupt, omdat het als brondata gezien moet worden. Verder speelt bij UUID’s, ook als deze volledig random zijn, nog steeds de kans op collisions. Bij sequences natuurlijk niet.

Bij het gebruik van hashing moeten we de snelheid van het berekenen in ogenschouw nemen en ook de ruimte die het in de index opneemt. I.t.t. hashing van wachtwoorden, zou een door Locatieserver gebruikt algoritme best snel mogen zijn, maar niet als dat er voor kan zorgen dat de kans op collisions significant groter wordt, zoals bijv. bij MD5. ID’s worden als tekst opgeslagen en kunnen nu al heel lang zijn. ID’s van adressen zijn nu 37 karakters. Als we hashes hexadecimaal zouden opslaan, zou dit 32 karakters betekenen voor een 128 bit hash.

Wat zijn jullie gedachten hierover?

#8

Ha Frank, fijn dat jullie stabiele ID’s overwegen. Ik zou me geen zorgen maken over hash collision. MD5 is prima, tenzij je een theoretische aanval van een malefide bronhouder wil overwegen die een collision wil forceren. SHA-512 ook redelijk snel, en daar kun je dan zoveel bits van gebruiken als je wilt.

Zie ook https://en.wikipedia.org/wiki/SHA-1#Comparison_of_SHA_functions en Birthday attack - Wikipedia.

De hash baseren op de ID van de bron, of op de waardes van essentiële attributen, lijkt me voor de hand liggen.

#9

Een theoretische aanvaller van een bronhouder om een hash collision in Locatieserver te veroorzaken, dat zou mooi zijn :joy:

Ik ben van plan om SHA-512 te gebruiken, omzetten naar base64 (met hex worden de ID’s een stuk langer) en dan de eerste 32 karakters nemen. ID’s zijn case sensitive. Het plus-teken zet ik om naar een min-teken, omdat het anders problemen in URL’s veroorzaakt. De slash zet ik om naar een underscore. De is-gelijk tekens die kunnen ontstaan, komen alleen aan het eind voor.

Het aantal mogelijke ID’s wordt hiermee 2^192 (6 bits per karakter). Met hex wordt het “slechts” 2^128 (4 bits per karakter). Mochten er bedenkingen zijn tegen base64, dan kan ik de encoding makkelijk omzetten naar hex.

Voor het ID blijf ik de prefix plakken zoals we die nu ook gebruiken, dus gem, wpl, weg, pcd en adr. Hierdoor kun je gelijk aan het ID zien om wat voor object het gaat. Bij het bepalen van de ID zet ik ook deze prefix voor de identificatie-string. Dat is eigenlijk niet nodig, omdat door de prefix achteraf voor het ID te plakken ook uniciteit wordt gegenereerd, maar mochten we besluiten om de prefix ooit te wijzigen of te verwijderen, dan hebben we niet opeens te maken met collisions. We weten nu al zeker dat dezelfde ID’s in verschillende bronsystemen worden gebruikt, bijv. gemeente- en woonplaatscodes.

Wanneer we objecten gaan toevoegen uit bronnen zonder eigen identificatie, maken we gebruik van essentiële attributen. Deze zetten we in een string, bijv. :;etc. voorafgegaan door type:. Dit laatste ook weer om ervoor te zorgen dat de hashes zonder prefix zelf ook uniek zijn.

#10

Ik heb ook naar de spreiding van de hashes gekeken. Dit heb ik met de ID’s van de BAG openbare ruimtes getest (zonder ‘weg’-prefix). Het viel me op dat de spreiding van de met MD5 gegenereerde hashes minder goed was dan van SHA-256 en SHA-512. Met name als ik naar de eerste 2 karakters kijk van de met hex geëncodeerde string.

Een voordeel van hashing + encoding is ook dat het makkelijk is om een kleine subset op te vragen van de gegevens in Locatieserver. Als je zoekt op id:adr-X* zul je 1/64 deel van de adressen terugkrijgen, id:adr-XX* levert 1/4096 deel op, etc.

Dit is vergelijkbaar met hoe je nu alle objecten van een bepaald type uit een bepaald gemeente zou kunnen opvragen, door te querien op ID: http://geodata.nationaalgeoregister.nl/locatieserver/free?q=id:weg-0200* geeft alle wegen in gemeente Apeldoorn terug. Echter, voor de leesbaarheid kun je beter het volgende request doen: http://geodata.nationaalgeoregister.nl/locatieserver/free?q=type:weg%20and%20gemeentenaam:Apeldoorn

#11

Die hebben we zelf, vanwege de mogelijkheid dat er “schunnige” woorden voor kunnen komen binnen een ID-string. Dat geldt in theorie ook voor hex encoding. Maar aangezien het aantal mogelijke combinaties veel kleiner is en hex encoding op veel meer toegepast wordt, is dat acceptabel.

#12

Aanpassingen n.a.v. bovenstaande zijn doorgevoerd (aanpassing samenstelling ID’s). Wij verwachten dat dit geen impact heeft maar willen het voor de zekerheid wel eerst voorleggen. Om die reden willen wij verzoeken om dit te testen op http://test.geodata.nationaalgeoregister.nl/locatieserver/… Wij horen graag voor 28 april of er bevindingen zijn. Mocht dat niet haalbaar zijn of als er vragen zijn dan horen wij dat graag. Alvast bedankt!

#13

Bij het indexeren is er helaas iets misgegaan, waardoor slechts een deel van de adressen beschikbaar zijn en geen andere data. Ik zal dit zsm fixen.

#14

De index is nu weer compleet. Excuses voor het eventuele ongemak.

#15

Hierbij een reminder dat wij bovenstaande wijziging (aanpassen van Locatieserver-ID’s) op korte termijn zullen doorvoeren in de huidige services. Dit hebben wij destijds (zie bovenstaande discussie) met gebruikers besproken en feedback is daarin meegenomen.