Zie bijvoorbeeld pand 1894100000338588 (x,y=201580.45, 367260.073, reeks 1-3 ontbreekt) of pand 1894100000278717 (x,y=196383.706, 371200.872, reeks 2-7 ontbreekt). Dit zijn panden met 4 nummeraanduidingreeksen, in de GML-Light download zitten er maar 3. Ik zie nergens gedocumenteerd staan dat er een beperking zit op het aantal nummeraanduidingreeksen in de GML-Light download, dus ik neem aan dat dit een bug is.
In de verte wat gerelateerd aan deze topic in die zin: volgens mij zijn de koppelingen met BAG-data in de BGT meer bedoeld voor visualisatie dan formeel/volledig. Vandaar ook hoek en plaatsingspunt elementen. Bijv een flatgebouw met 100-en huisnummers zou ook ondoenlijk zijn.
In het XML schema van GML light staan alle mogelijke attributen genoemd. Deze gaan van “nummeraanduidingreeks_1.tekst” tot en met “nummeraanduidingreeks_3.tekst”. Het is dus qua schema niet mogelijk meer nummeraanduidingreeksen op te nemen, “nummeraanduidingreeks_4.tekst” of hoger kunnen nooit voorkomen. Ook per nummeraanduidingreeks zijn er maar maximaal 3 plaatsingspunten.
Ik neem aan dat GML light ooit eens is verzonnen om het originele GML model dat geen restricties heeft op het aantal nummeraanduidingsreeksen en plaatsingspunten per pand te versimpelen zodat het GML light formaat in meer softwarepakketten direct gebruikt kon worden en is er toen een maximum van 3 gekozen. Een GML formaat dat alleen enkelvoudige attributen per object zoals een pand toestaat (en niet een collectie van nummeraanduidingreeksen) staat ook wel bekend als een GML ‘simple features’ profiel van een bepaald level. Het is veel eenvoudiger voor softwarepaketten om daar mee om te gaan dan de grote vrijheidsgraden qua datamodel die bij XML mogelijk zijn.
Echter leidt dit wel tot gegevensverlies, aangezien niet meer aan de Zero-One-Infinity regel voldaan wordt. Als je alle gegevens wil hebben kan je het best het originele GML / CityGML formaat gebruiken. Het is eigenlijk net als met ‘light’ boter of zuivel, beter gebruik je het origineel 
In de BRMO BGT-loader die het originele GML / CityGML formaat inleest worden nummeraanduidingreeksen van panden genormaliseerd opgeslagen in databasetabellen, dus zonder gegevensverlies. Wel worden van nummeraanduidingreeksen met meerdere plaatsingspunten de tekst in meerdere rijen opgeslagen (je kan ook te ver doorslaan in het normaliseren…).
Met wat queries levert dat wel ‘leuke’ resultaten op, zoals bijvoorbeeld pand 0400100000029810 dat overduidelijk verkeerde nummeraanduidingsreeksen heeft, namelijk 22 keer ‘1-24A’:
Het pand met de meeste nummeraanduidingreeksen x plaatsingspunten is 0303100000588593 met 147:
Dus als je het zou willen ‘denormaliseren’ (dus het aantal beperken tot een ‘arbitrair’ aantal in plaats van geen restrictie) zonder gegevensverlies, moet je alle mogelijke combinaties in het schema opnoemen: van “nummeraanduidingreeks_1.tekst” tot en met “nummeraanduidingreeks_147.tekst” en dat nog vermenigvuldigd met 22 voor de plaatsingspunten. Dat is natuurlijk ondoenlijk!
Dank voor de reacties. De keuze voor een maximum aantal nummeraanduidingreeksen in GML-Light is begrijpelijk. Maar ik had gehoopt die keuze ergens in de product beschrijving terug te vinden en niet daarvoor het XML-schema te hoeven uitpluizen.
Verrassend dat er panden zijn met meer dan 100 nummeraanduidingreeksen, Volgens de BGT richtlijnen neem je maar 1 reeks per openbare ruimte op. Baserend op wat verouderde BAG-data kom ik dan op maximaal 13 nummeraanduidingreeksen bij pand 0344100000142425. Maar in de praktijk wordt (terecht) regelmatig afgeweken van die BGT richtlijnen en worden de reeksen ‘gesplitst’ in kleinere reeksen.
@Just: er is een pand met meer dan 1000 adressen (0344100000068675). Maar in de BGT kunnen die 1000 adressen in 1 nummeraanduidingreeks worden opgenomen (en dat is bij dit pand ook zo gedaan).