Omdat we nu wat nieuwe servers hebben hangen, kunnen we daar ook wat leuke hippe dingen mee doen. Een van die dingen is een dagelijkse BAG update. We hebben inmiddels de dagelijkse mutaties van het Kadaster. Dus we zouden daar ook triggers op kunnen zetten voor gebruikers. Uiteraard gaan de mutatiebestanden zelf richting de mirror.
Mocht je zelf nog ideeën hebben wat we hiermee kunnen doen ben ik benieuwd.
Stefan, kun je wat meer uitleg geven over de werking van een (mogelijke) dagelijkse BAG update?
Je hebt in de BAG een aantal varianten. De “INSPIRE” levering, de maandelijkse levencyclus, de dagelijkse mutaties, en ik meen ook een soort van API. Daarnaast zijn er verschillende service provider leveringen die door het Kadaster worden gemaakt denk hierbij aan afgeleide een adressenbestand. Op basis van de huidige INSPIRE bestanden (gratis) of de maandelijkse bestanden (betaald) moet je voor iedere levering alle data opnieuw inladen. Met de software die we daarvoor hebben gemaakt: NLextract ben je daar wel even mee zoet.
Een mutatie bestand geeft je de mogelijkheid om op een bepaalde datum in te stappen, en vervolgens alleen de wijzigingen op de database toe te passen. Ook krijg je alle wijzigingen die op die dag door gemeentes zijn doorgegeven mee. Je kunt dus eigenlijk “real-time” editen, als je uit gaat van gemeentes die hun geodata snel bewerken.
Hoe zit het dan als er aanvullende data op de gebouwen of adresnodes zijn gezet?
Dat is geheel aan de persoon die BAG updates gaat mergen. Ik voel totaal niet de behoefte om iets uit de BAG te gaan importeren 
Ik ga de BAG zelf als leidende kaartlaag gebruiken
Stefan,
In aanvulling op Commodoortje: zoals je waarschijnlijk inmiddels weet, ben ik hard bezig om een geheel nieuwe “renderer” voor OSM data op te zetten op basis van ArcGIS. Daarbij laat ik ook nadrukkelijk gebouwen zien, die een tourism=* en historic=* tag hebben. Dat zijn er best veel in Nederland, en ook in het buitenland worden deze tags goed gebruikt. Ik denk dat deze rendering zeer waardevol is, gezien de render resultaten tot nu toe. Als deze gegevens bij een BAG update verloren gaan, dan ben ik daar zeker geen voorstander van.
Maar dat was waarschijnlijk ook niet de insteek van je voorstel, desondanks toch maar weer even onder de aandacht gebracht…
Vervanging van de geometrie met behoud van de bestaande OSM tags (voorzover niet al uit BAG), is natuurlijk geen probleem, mits met zorg uitgevoerd.
Mvg,
Marco
Marc, correct ‘ik’ ben al genoeg kwijt geraakt, waar ik de import toch ook aardig en wijs vond. maar import met nieuwe tags zonder de oude te behouden nee.
Als het goed is zijn bij de inmiddels afgeronde BAG import de relevante bestaande tags behouden
Ik vermoed dat Stefan het niet heeft over het bijwerken van de OSM data. Interessant project trouwens die rendering. Dat kan er zeker aan bijdragen om de bomen in het OSM bos weer beter te gaan onderscheiden, wat weer een flinke bijdrage kan bieden aan het verbeteren van OSM. Uiteraard -te zijner tijd- heb ik daar ook nog wel wat wensen voor die hopelijk d.m.v. flexibele rendering op te lossen zijn (bijvoorbeeld: alle benzinestations weergeven)
Its so Funny,
goed gesproken, maar bij het woordje als struikelt de zin, geeft niet tis gebeurd klaar, maar een schip op t strand is een baken in zee. Maar ook over ‘relevante’ kan verschillend gedacht worden en daar heb ik geen woord over gelezen noch gehoord.
Wat relevant is staat hier beschreven http://wiki.openstreetmap.org/wiki/BAGimport_via_ODS_plugin onder stap 2D (gebouwen) en stap 2E (adressen)
Dank je. Ik ben er nu al bijna een jaar mee bezig, en jullie willen niet weten hoeveel tijd er in is gaan zitten… Over flexibele rendering en benzinestations: in principe render ik al alle benzinestations (amenity=fuel), zowel als simpele node getagged, en als multipolygon met of zonder building=yes. Dat zou bijna alle stations moeten omvatten. Wel is het zo, dat ik benzinestations pas vanaf schaal 1:25000 en groter laat zien, want ik kwam er achter dat in bijvoorbeeld Rome, op bepaalde plekken bijna elke straathoek een pomp heeft. Dat lijkt veel op de goede oude tijd in Nederland, toen ook nog elke autogarage zijn eigen benzine stationnetje had, voor milieunormen die onrendabel en onmogelijk maakten. Ook ga ik ze niet labelen voor 1:5000, want ik wil mijn “topografische kaarten” niet overbelasten met in mijn (persoonlijke) ogen onzinnige labeling info. Op een topografische kaart zie je ook geen merken en “brands”…, als je de stations überhaupt al ziet!
Maar over flexibiliteit: ja, de renderer is zo opgezet, dat je zelf aanpassingen kan doen, daarvoor is alleen basiskennis van ModelBuilder in ArcGIS nodig. Een beetje bedreven ArcGISser, zou daar geen moeite mee moeten hebben. Dit is ook mijn streven met deze renderer: hoewel ik groot respect heb voor al het werk aan de Open Source oplossingen rond OpenStreetMap, is de benodigde programmeer- en database-kennis voor het opzetten van een eigen, persoonlijke, rendering iets wat veel mensen ver “boven-de-pet” gaat. Mijn oplossing maakt (hopelijk) aan deze situatie een eind, en kan een flexibele, persoonlijke, rendering binnen het handbereik van veel meer mensen brengen, in ieder geval diegenen, die al basiskennis GIS hebben, en dat zijn er nogal wat binnen b.v. overheidsdiensten, onderzoeksinstituten en universiteiten, en bedrijfsleven…
Ik denk zelf dat dit gebrek aan flexibiliteit (beter gezegd: niet aan flexibiliteit maar aan gebruiksvriendelijkheid), 1 van de grootste redenen voor de lange lijst aan “issues” en “wishes” is, die op de OpenStreetMap CartoCSS Github worden geplaatst.
Overigens wordt “het bos” er niet minder klein op, als alle bomen zoals in een arboretum, netjes “gelabeld” en op naam gebracht zijn… Mijn renderer rendert de kaarten momenteel in meer dan 200(!) ArcGIS layers, om het gewenste effect te krijgen en “multi-scale” opties mogelijk te maken (waarbij sommige lagen op bepaalde zoomniveau’s anders worden weergegeven).
Dus ik wil je even uit je droom halen, als je dacht dat ik de magische oplossing voor alle problemen had (maar zo naïef schat ik je niet in op grond van wat je schrijft ;))
Maar het helpt natuurlijk wel om “die bomen” hun correcte naam te geven…
Mvg,
Marco
Marco,
Complimenten. keep up the good work. En past dat dan op de gehele OSM databank ?
Ja, in principe wel, omdat ESRI (de fabrikant / software ontwikkelaar van ArcGIS) een mogelijkheid in de door hun gebouwde, en door mij gebruikte, ArcGIS Editor for OpenStreetMap heeft ingebakken, om ook de volledige tagging info van elk object op te slaan in de (File) Geodatabase die hun tool genereert op basis van standaard *.osm database extracts, zoals die van b.v. Geofabrik. Dit betekent, dat je dus zelfs tot exotische, zelf bedachte, taggings toegang hebt.
Voor de datatabase technici onder ons: dit is vergelijkbaar met PostGreSQL hstore…, de grote implementatiewens voor de rebuild van de renderer database van CartoCSS, zoals ik het nu begrepen heb.