Het is mij opgevallen dat er in OSM BAG referentie nummers met en zonder voorloop nullen voorkomen. Ik heb tevens gemerkt dat bij zoeken in de BAG Viewer die nullen van belang zijn.
Ik heb een paar recente invoeren bekeken en die hadden de nullen.
Kan ik er van uitgaan dat als ik een edit doe aan een object met een BAG nummer waar de nullen ontbreken het geen probleem is om dan, als ik er toch ben, ook die nullen to te voegen?
Voorloopnullen maken niet echt deel uit van de code. Diverse tools zouden met of zonder moeten werken. Ik zou ze niet wijzigen en dat verder aan de semi-geautomatiseerde tools overlaten die ze importeren.
Als je in JOSM vanuit het contextmenu van de ref:bag-tag op de link naar de BAG website klikt werkt het gewoon, ook zonder voorloopnul:
In JOSM wordt de voorloopnul namelijk automatisch in de URL gestopt. Als mapper zou je er dus geen last van moeten hebben. Dit is trouwens veruit de makkelijkste manier om vanuit een OSM object uit de BAG in JOSM naar de betreffende BAG-registratie te gaan.
Mooi, dat JOSM dat doet. JOSM is echter niet de enige manier waarop het BAG nummer beschikbaar komt. Als een object bekeken wordt in OSM zelf, wordt bewerkt me iD of wordt bekeken in OpenPoiMap bijvoorbeeld dan komt het nummer beschikbaar in ruwe vorm.
Copy paste naar de BAG Viewer levert dan geen resultaat en er moet handmatig een voorloopnul worden toegevoegd.
Het koste mij de eerste keer wat moeite om uit te vogelen waarom het nummer niet gevonden werd. En dat is niet bepaald starter vriendelijk
Even voor alle duidelijkheid, ik was niet van plan om op grote schaal nummers aan te gaan passen maar als ik een object toch aan het editen ben voor een ander datapunt is het een klein moeite om gelijk even die nul aan te brengen.
en even voor de goede orde met dit punt ben ik het niet eens. BAG Viewer heeft die nul nodig om het object te kunnen vinden dus die nul is belangrijk.
Ja heel irritant. Heb je het probleem gemeld bij het Kadaster? Zij beheren de BAG-viewer immers.
Hoeft ook niet.
Er zit verschil tussen notatie en data. In de BAG wordt in de documentatie aangegeven dat het een nummer is, en niet een code die elke vorm kan hebben. Ook al schrijft de een 0010 en de ander 10, het is hetzelfde nummer. De notatie verschilt alleen.
Natuurlijk zou het mooi zijn als die (overbodige) voorloopnullen niet in de OSM-data staan, maar data consumers moeten er gewoon mee om kunnen gaan wanneer ze deze verwerken. Dit zou anders zijn wanneer het een code betrof waarvan de vorm toevallig overeenkomt met een nummer.
Het heeft geen zin om handmatig bag:ref aan te passen op dit vlak, want er zijn duizenden objecten met (en zonder) voorloopnul. Als je mensen wil helpen, laat het Kadaster hun bug dan oplossen.
Het is geen nummer, maar een string en voor de BAG is dat blijkbaar van belang dat die voorloopnullen er wel voor staan. Was me trouwens nog nooit opgevallen dat via de rmk direct naar de BAG viewer te navigeren is.
De oorspronkelijke BAG import was helaas als numeriek ingelezen en daarbij zijn de voorloopnullen dus nooit in OSM gekomen. Bij alle nieuwe BAG imports zijn sinds jaren wel deze voorloopnullen van de partij en bij mutaties van bestaande panden worden deze automatisch erbij gezet bij de BAG updates. Niet aangepaste panden blijven ongemoeid aangezien het vooralsnog gekkenwerk lijkt om dat in bulk te doen zolang niemand er echt iets aan heeft.
Op dit moment zijn blijkbaar de posities 5 en 6 altijd “10” en dat is blijkbaar lastig af te vangen met een 100% numerieke definitie, vandaar dat ze schijnbaar naar een string zijn uitgeweken, of ze wilden nog de mogelijkheid hebben om op een later moment ook nog alfanumerieke tekens te kunnen gebruiken.
Het zou overigens handig zijn als de BAG viewer ook gewoon zou werken zonder de voorloopnullen.
Gemeenten geven in terugmeldingen ook regelmatig aan dat ze pand 12345 hebben aangepast. Hun lokale systemen lijken een nog korter nummer te hanteren. Of ze hebben nog nooit van CTRL-C/V gehoord en willen het zo kort mogelijk houden…
Ze negeren daarbij dan volledig de 1e 6 karakters en de “voorloopnullen” daarna omdat hun eigen systemen schijnbaar de gemeentecode oid die ervoor staat niet interessant is. Na een gemeentelijke herindeling zie je vaak dat de 1e 4 cijfers die vanaf dan uitgegeven worden ineens anders zijn, dus dan leren ze dat wel af om verwarring met de andere voormalige gemeenten te voorkomen.
Een BAG identificatie lijkt dus al een samenstelling van 2 nummers die beide met voorloopnullen en een vaste waarde aan elkaar geplakt wordt. Dus al ziet het eruit als een nummer en noemt men het een nummer is het dat niet echt meer dan volgens mij.
Dat ze dit in de XML-definities zo oplossen verbaast me niet (anders zouden die voorloopnullen ook niet terugkomen in hun systemen), maar dat neemt niet weg dat ze dit in de communicatie en gebruik niet als een opaque string hanteren, maar expliciet als een nummer. Buiten de BAG-wereld (OSM bijvoorbeeld) is het dan niet zo vreemd dat de voorloopnul als notatiekeuze gezien wordt.
Mogelijk, maar dat is niet wat ze nu in hun documentatie schrijven. Ik vermoed dat ze bij het plotseling introduceren van een A in de code gelijk wel een paar pakketten in gebruik bij gemeentes breken.
Als het kwaakt als een eend en er uitziet als een eend, dan is het geen vreemde sprong om het op zijn minst als een vogel uit de Anatidae familie te behandelen.
Dat het nummer intern meer is dan een volgnummer is voor OpenStreetMap verder niet relevant (mogelijk wel voor een data consumer, maar dat valt buiten de scope van de tag).
Het kan natuurlijk dat de BAG zelf fout zit door dit een numerieke waarde te noemen; dat zou nagevraagd kunnen worden.
OK, ik moest even uitwijken naar de Engelse (onder Quantification) wikipedia omdat de Nederlandse (onder Kwantificatie) versie het niet meld maar de reguliere expressie gebruikt om te definiëren hoe het nummer er uitziet ^[0-9]{4}10[0-9]{10)}$ betekent het volgende:
^ - start van de regel
(0-9) - toegestane symbolen. De cijfers 0 tot en met 9
{4} - het aantal malen dat het symbool moet voorkomen
10 - letterlijk
(0-9) - toegestane symbolen. De cijfers 0 tot en met 9
{10} - het aantal malen dat het symbool moet voorkomen
$ - einde van de regel
Dat betekent volgens mij dus dat de referentie altijd exact 16 posities moet zijn en dat de begin nullen niet mogen worden weggelaten.
In het spraakgebruik kunnen de begin nullen mogelijk worden “ingeslikt” maar ze horen er formeel wel bij.
Dit betekend overigens ook dat Sander H’s idee voor mogelijk gebruik van alfanumerieke tekens niet kan, die passen niet binnen de definite. De meer waarschijnlijke reden is dat een number type veld de begin nullen weglaat.
De 10 op positie 5 en 6 geven aan dat het om een pand object gaat. Andere BAG object types zoals ligplaats, standplaats, verblijfsobject en nummeraanduiding hebben een andere 2 cijferige code op positie 5 en 6.
Ha, van tijd tot tijd komt dit weer op! Het BAG id is een string van 16 cijfers. De eerste 4 vormen de CBS gemeente code, die kan 0 tot 3 ‘voorloopnullen’ bevatten. Bijv 0363 is Amsterdam. Hunze en Aa 1680 heeft bijv geen voorloopnullen. Zie lijst.
De eerste BAG imports maakten gebruik van NLExtract om de BAG XML eerst in PostGIS in te lezen. Helaas was toen, mea culpa, plm 2014 net de BAG id als nummer kolom. Efficiency…Dat is later weer de 16 cijfer string geworden, rest is historie. Lees hier de issue met community discussie.
Als dit feit is, is het dan niet een top idee hier een OSM-wiki pagina van te maken die in eerste instantie gemaakt is op: “geïnteresseerde leek”-niveau die daarbinnen verwijst naar expert niveau ?
Als deze discussie dan weer plaatsvindt (alleen maar logisch door steeds nieuwe aanwas hier gelukkig) kan je verwijzen naar die OSM-wiki pagina zonder hele discussie’s op nieuw te hoeven voeren…
Just my 10 cents in deze discussie…
Als ik een en ander samenvat, dan is de BAG referentie
een string van 16 posities waar alleen de tekens 0 tot en met 9 toegestaan zijn
die kan beginnen met 1 tot 3 nullen
Bij invoeren van BAG gegevens
zijn tot tijdstip X die nullen niet meegenomen
bij nieuwe invoeren en updates na tijdstip X worden de nullen wel meegenomen
Er zijn geen plannen om bestaande BAG referenties zonder de startend nullen grootschalig aan te passen.
Dat brengt mij terug naar wat mijn oorspronkelijke vraag was:
Kan ik er van uitgaan dat als ik een edit doe aan een object met een BAG nummer waar de nullen ontbreken het geen probleem is om dan, als ik er toch ben, ook die nullen to te voegen?
Gebaseerd op de conversatie zeg ik dus: geen probleem.
Als ik de discussie volg & de voorbeelden en links in de discussie lees is dat een goede 1ste poging tot opzet tot een mooie OSM pagina hierover inderdaad inderdaad.
Is idd geen probleem om dat dan gelijk mee te nemen, maar voel je geenszins verplicht om het al dan niet te doen.
Overzichtje van de lengte van het ref:bag veld in OSM:
en dan waren er nog ~120 met lengtes van 2-101 karakters waarin men zo te zien een jaartal, een voorloopnul teveel, of meerdere nummers in 1 veld heeft gepropt.
Voor een stel knooppunten relaties met een ref:bag heb ik die er maar af gehaald net.