BGT BRT, akkoord beschikbaarheid voor Openstreetmap.

Naast de bovenstaande layers (BGT en Hillshade) gebruik ik de Strava layer, wel oppassen als paden zijn afgesloten. Vermoedelijk bewaard Strava alle gedeelde tracks. Ooit zal ik voorstellen om tracks ouder dan een jaar eruit te filteren.

Dit is absoluut niet zo.

Zoals Allroads al aangeeft, is de BRT/TOP10NL gebaseerd op een uniforme luchtfoto-analyse voor heel Nederland, met als streefnauwkeurigheid 1:10.000 voor de meest nauwkeurige topografische kaart van 1:10k. 1:50k/1:100k en 1:250k waren dan historische bezien handmatig sterk gegeneraliseerde kaarten, die in aparte productielijnen werden bijgehouden. De uitgaven van de verschillende series liepen dan ook niet synchroon, en b.v. de 1:50k kaart was niet een directe afgeleide van de 1:10k kaart. Tegenwoordig is het Kadaster er in geslaagd, om de 1:50k kaart direct - en met volautomatische tools - uit de 1:10k af te leiden via computermodel gestuurde generalisatie in ArcGIS (zie https://www.kadaster.com/nl/automatic-generalisation)). Vroeger waren deze kaarten een exclusief militair product van de Topografische Dienst van Defensie.

De BGT daarentegen, is een opvolger van de GBKN (Grootschalige Basiskaart Nederland), en wordt samengesteld uit een veelheid van bronnen (gemeenten, provincies, Rijkswaterstaat data), die op even zovele manieren is ingewonnen (b.v. ge-orthorectificeerde luchtfoto’s zonder omvalling, stereoscopische luchtfoto meting zoals Allroads illustreerde, terristrische inmetingen met een total station door een landmeter, of laserscanning). Het is eigenlijk een groot “patchwork” van verschillend ingewonnen en bijgehouden data. De streefnauwkeurigheid is hoger dan van BRT/TOP10NL en veelal ergens tussen de 1:5k en 1:1k, tot misschien wel 1:100, met uitzondering van de over het algemeen als minder nauwkeurig ingewonnen Agrarisch Ariaal Nederland perceel gegevens, die meer richting de 1:10k-1:25k gaan.

Groot verschil tussen de BGT en voorloper GBKN is dat de BGT unieke objectcodes heeft en ook vlakgericht is. De GBKN was slechts lijnen “spaghetti”… leuk voor de achtergrond, maar verder kon je er niet veel mee.

Bedankt voor de toelichting mboeringa en Allroads, erg leerzaam!

Gesproken over bladloze luchtfoto’s, hebben wij daar ook toegang toe? Voor zo ver ik weet zitten bij alle luchtfoto’s die OSM mag gebruiken de bladeren aan de bomen.

Ik ben trouwens benieuwd of TOP10 in de toekomst (deels) BGT-data gaat gebruiken? Zou logisch zijn.

Voor de zekerheid: AHN zelf is niet compatible met OSM, toch?

Bing is toch ook (kaart)bladloos…? :smiley:

Alle gekheid op een stokje, maar bladloos betekent wel dat de foto’s in de herfst of winter zijn gemaakt. Dat betekent tevens dat de zon vaak laag staat, en je dus veel last van slagschaduwen kunt hebben in de beelden. Het is dus een beetje kiezen tussen twee kwaden…

Persoonlijk had ik liever gezien dat de nieuwste Nederlandse luchtfoto’s, op hogere resolutie (5cm), en volledig “ge-orthorectificeerd” afgeleverd waren op basis van koppeling met het AHN. Bij orthorectificatie staan alle gebouwen recht, en kijk je dus loodrecht van boven voor je gevoel. De nieuwste luchtfotobeelden doen pijn aan mijn ogen op dit vlak… op veel plekken is de omvalling in Bing en de nieuwe PDOK foto’s nauwelijks met elkaar te rijmen, en blijf je je afvragen waar het in te tekenen object nu werkelijk ligt… En dit is nog los van de extreme beeldcompressie met artefacten die lijkt te zijn toegepast (ik heb zelf een drietal jaartjes bij de toenmalige Meetkundige Dienst van Rijkswaterstaat gedetacheerd gezeten, en daar maakten ze van de rijkswegen prachtige orthofoto’s op hoge resolutie, onvergelijkbaar qua kwaliteit).

Al minstens twintig jaar speelt er een discussie tussen de verschillende overheidsinstanties over de aanbesteding van landelijke luchtfoto’s: sommige partijen vinden dit goed genoeg, en dus wordt het helaas pindakaas de laagste - eigenlijk niet - gemene deler, i.p.v. een echt goed product. Ondertussen moeten dan de partijen die er niet mee kunnen werken, alsnog weer hun eigen foto’s laten schieten…

AHN zelf is cc0; de beperkingen gelden alleen voor de door esri bedreven server die daar een aantal mooie visualisaties van maakt. Het dient ook als achtergrond voor de mooie opentopo kaarten. Op de ftp server waar je die kunt downloaden staan ook schade rdelief kaarten alleen weet ik niet of je die ook in josm kunt laden.

Melding op ideawall:

De BGT komt, in overleg met IenM, ook beschikbaar als WFS en WMS.

Submitted by BeheerPDOK on 9/4/2017 7:49 AM

De bgtomtrekgericht kaart is erg handig in combinatie met de PDOK luchtfoto’s. De laatste zijn wel recent, maar vrij laag van resolutie en genomen in de zomer (bladeren); samen met de BGT-lijnen en boots-on-the-ground controle levert dat data voor een erg nauwkeurige kaart.

Misschien een idee om naar een handleiding voor JOSM te linken in een sticky? Het lijkt me goed dat zoveel mogelijk Nederlandse mappers de weg ernaar weten te vinden.

Helemaal mee eens! :slight_smile:
Persoonlijk vind ik lijngericht en achtergrond ook erg handig om in combinatie met omtrekgericht te gebruiken.

Misschien een beter idee om deze laag toe te voegen aan de lijst met lagen die standaard in JOSM aanwezig zijn? Gelijk hoe de PDOK luchtfoto daar laatst ook aan toegevoegd is.

Ik had het gebruik / uitproberen van de BGT even voor me uitgeschoven. Zojuist heb ik er eens beter naar gekeken naar aanleiding van een opmerking van Allroads in een ander topic.

Wat me opvalt aan waterwegen is dat de omtrek (BGT omtrekgericht) nogal eens beduidend ruimer is dan ik in OSM heb aangegeven op basis van de combo eigen waarneming en PDOK luchtfoto. De BGT lijkt uit te gaan van de bovenrand van een talud, terwijl ik meer rekening houd met de daadwerkelijke breedte en watermassa van een waterweg.
In de BGT kan een bijna droogstaande sloot met aan beide zijden een riant talud even breed zijn als een twee meter flink stromende waterweg met steile kaden.

Vanuit het oogpunt van landuse zou je een aanliggend weiland tot de bovenrand van het talud kunnen tekenen. Mijn voorkeur gaat ernaar uit om meer vanuit de waterweg te redeneren, waarvan de breedte op een kaart een groter stempel drukt.

EDIT: Ik zie nu dat BGT soms een binnen- en buitenlijn weergeeft voor verschil tussen water en talud.

p.s. Hoe doe je zo’n conversie met copy paste?

De BGT watergangen kan je ook vergelijken met Actueel Hoogtebestand Nederland, Esri AHN hillshade maaiveld, wat de talud rand aan geeft. Landbouwgrond loopt tot aan de taludrand, zoals AAN aangeeft, Agrarisch Areaal Nederland.
Zou inhouden, dat er voor het talud een tag (combinatie) moet kunnen komen.
topic over talud
Vanuit agrarisch perspectief en ook voor mij, landbouwgrond loopt tot aan het talud, schouw is ook onderhoud van het talud.
De sloten staan wel vaker tot aan de rand van het talud vol.

Conversie:
Daar moet nog een discussie over komen, hoe de individuele mappers met de BGT database kunnen omgaan.

Welke de beste methode is?
Van .gml bestanden naar…

Zie BGT forum, waar zaken al eens te sprake zijn gekomen.

Zou mooi zijn als we een tot een gebruiksvriendelijke, makkelijk uit te leggen procedure kunnen komen.

Bespreking welke data tags behouden, overtollig verwijden (liefst systematisch/automatisch) en welke osmtags bij welke onderdelen horen.

Voor mij is het wel handwerk, waarbij kennis van omgeving noodzakelijk is. Vandaar opmerking, copy/paste.
Ook bedoelt om de BGT discussie onder de aandacht te brengen, want veel beter kunnen wij het niet tekenen. Eerder slechter. Dus waarom geen BGT gebruiken.
Met de BAG hebben we enige ervaring, vooral de update methode, behoud geschiedenisdata en mergen vlakken.

Aansluitend werken, dat houd voor mij in, als je dan toch bezig bent zal de rijbaan en parkeerplekken ook ingevoerd worden.
area:highway is laatst te sprake gekomen en andere onderdelen zal een eigen tagcombinatie moeten krijgen.
Gemeentelijk groen discussie loopt ook al.

Wie zijn dorp er netje in wil leggen, heeft aan BGT een mooie database.

Via Qgis heb ik zaken omgezet.
Maar vindt het niet een methode voor ons allemaal, daarnaast is discussie nodig of dit wel een goede methode is.

Zoals Peewee als eens aan gaf, een bijeenkomst organiseren betreffende het BGT gebruik.

Ik heb nu in dat topic een reactie bijgedragen. Landbouwgrond (farmland) loopt formeel tot aan het talud maar meestal gaat het om weiland of een berm aangegeven met landuse=grass.
Als er een weiland is, dan een afscheiding (geen sloot), dan een grasberm, dan de weg… dan trek ik het weiland als landuse=grass gerust door tot aan de wegkant. Of een smalle sloot teken ik in als lijn binnen het grote landuse=grass.

Het lijkt me inderdaad, wat jij ook lijkt te suggereren, een onderwerp om in de toekomst verder te bespreken als OSM in een verdere fase is. En dan meteen een werkwijze voor meerdere vormen van ‘area detail mapping’ afspreken.
Of eerst eens een lokaal proefproject.
Voorlopig is er ook in Nederland nog genoeg te doen op meer basisniveau mapping.

Ik wil mijn dorp goed gedetailleerd ‘afmappen’ (en daarna bijhouden) en dat moet ook niet al te lang meer duren want ergens schreeuwt de regio om mijn aandacht om meer basale zaken te controleren en toe te voegen. :roll_eyes:

+1

Er valt nog zo veel basaals te mappen wat voor gebruikers van OSM waarde toevoegt (want daar doen we het toch met ons allen grotendeels voor) dat µ-mapping toch zeker niet de grootste prioriteit heeft.

Met name het (meer en meer mogelijk) massa-importeren van publieke data in OSM brengt het risico met zich mee dat iemand dat eens doet voor een deel van NEderland en vervolgens de discipline ontbreekt om het ook (jarenlang) te onderhouden.

Alleen al het bijhouden van de BAG-panden houdt een aantal mappers bezig.

Zoals ik in een ander topic al stelde: kijk naar een topografische kaart 1:10.000 kwa vlakvulling, dan vind ik dat we als we dat bereiken in OSM en daarbovenop nog alle aanvullende data (winkels, bushaltes, stationsnamen etc. etc.) dan hebben we toch met OSM al iets heel moois bereikt?

Als je alle gegevens van de imports AND en 3dShapes die nooit goed gecontroleerd zijn door een mapper zou weghalen dan zou je schrikken hoe kaal de kaart zou zijn. Dus nog voor het risico van gebrek aan onderhoud ligt nog het gebrek aan handmatige controle, met name in bepaalde regio’s. De grote activiteit binnen OSM op sommige terreinen en in sommige steden en regio’s kan ten onrechte de indruk wekken dat bijna alle gegevens en regio’s zijn gebaseerd op menselijke mapactiviteit (door actieve toevoeging danwel controle). Het gaat dus ook om de discipline om controles te doen die weinig direct zichtbare verbetering opleveren maar wel de betrouwbaarheid verhogen.

Ik kom vaak tegen dat een weg is verlegd of een nieuwe woonwijk is gebouwd en er nog oude 3dShapes-landuses verkeerd liggen. Ze liggen dan dwars door huizen of over wegen. De makkelijkste oplossing is gewoon de foute landuses verwijderen, maar dat maakt de kaart erg leeg. Ik probeer dan de nieuwe situatie in te tekenen met de PDOK-luchtfoto.

Hoe gedetailleerder je het intekent, hoe mooier de nieuwe kaart. Het kost dan wel ontzettend veel werk. Dan denk ik vaak: waar doe ik dit nou voor. Vooral aangezien er een BGT-kaart is die veel gedetailleerder en preciezer is dan ik het ooit zal kunnen maken.

Herkenbaar. Achteraf heb ik er altijd meer tijd en energie ingestoken dan de bedoeling was, o.a. door het werkgebied telkens iets te vergroten. En toch vind ik dit soort bijdragen tot het echte OSM-mapping behoren: op basis van eigen waarneming / info / onderzoek de kaartindeling verbeteren.
Zouden we een massa-import van BGT-info krijgen dan wordt het meer OpenAmbtenarenMap.
Als vele van mijn handmatige aanpassingen zouden worden overschreven dan is de kans ook groot dat ik zou afhaken.

Ik denk dat de AND import juist heel goed bij gehouden wordt. Ik navigeer al jaren vrijwel uitsluitend met OSM data en dat klopt gewoon. Natuurlijk niets is perfect, maar ik kom heel weinig wegen tegen die niet of verkeerd op de kaart staan.

Bij fietspaden merk ik dat mijn GPS gewoon niet in de buurt komt van de nauwkeurigheid van BGT. Dus ik gebruik nu mijn GPS data alleen om te controleren of de BGT wel up-to-date is, en teken dan de BGT data na.

Dus het zou veel handiger zijn als die data gewoon te importeren is.

Ik heb nog geen idee wat ik moet met BGT data die niet klopt. Als ik een nieuw fietspad tegen kom dat nog niet in BGT staat, dan teken ik 'm op basis van mijn GPS data. Maar de kans dat ik over een half jaar nog weet dat ik nog een keer in de BGT data moet kijken is klein.

Dan zijn er ook gevallen waarin de BGT niet bijgewerkt lijkt te zijn, misschien omdat het een al jaren durende tijdelijke situatie is.

De AND-import was dacht ik in 2008 en is vooral de basis van het huidige wegennet in OSM. Wegen zijn natuurlijk hoofdzaak in OSM en worden dus relatief vaak aangepast. De grote meerderheid van de info klopt of klopte en dat geldt ook voor de 3dShapes-import. Qua wegen zitten de fouten voornamelijk in dunbevolkte gebieden met geen lokale mappers en in woonwijken en dan vooral in de (afgrenzing van) naamgeving. Ik noem het nog eens omdat ik weet dat het in veel gevallen niet opvalt totdat je nauwkeurig gaat kijken.

Ik had ook liever deze import met wat extra fouten (die er deels na 9 jaar nog in staan) dan geen import en in 2017 heel veel nog ontbrekende wegen.
Het mooie aan OSM vind ik echter ook dat lokale info beter en nauwkeuriger kan zijn dan overheidsdatabases. Daarom vind ik nog steeds jammer dat ik laatst geen bijval kreeg in mijn verzoek om structurele BAG-imports voortaan aan te kondigen zodat je gericht voor- of nacontrole kunt doen.

Middels deze link kun je de laatste BAG imports/updates volgen.