BGT BRT, akkoord beschikbaarheid voor Openstreetmap.

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.

Dank je wel. Het zijn dan wel geen vooraankondigingen maar het geeft wel meer inzicht achteraf.

Melding BGT kan hier gedaan worden.
Evenals melding BRT. Top 10 NL etc.
Bij BGT moet je inzoomen tot de laatste laag. En dan je punt maken.
https://www.verbeterdekaart.nl/

Na maak nieuwe wegsituatie moet de Gemeente wel de tijd hebben om het zelf in te meten.
Daarna komt het in de BGT.
Ik heb zelfs een rotonde gezien die na klaar binnen een maand in de BGT stond. Dan kon ik heel mooi het fietspad binnen de lijnen, middenas weg uitlijnen.

In gesprek met Gemeente zijn juist die kleine verschillen ook van belang, want die zijn juist moeilijk op het netvlies te krijgen.

source BAG

dan datum invullen
laatste maand, zelf invullen bij later gebruik.
http://overpass-turbo.eu/s/sHr uitvoeren drukken

Inmiddels ben ik om en maak ik volop gebruik van de BGT omtrekgericht. Het is echt wel een handig hulpmiddel en veelal angstaanjagend nauwkeurig. Samen met de lokale kennis en inspecties maakt het een zeer gedetailleerde kaart mogelijk.

Medemappers: ervaren jullie ook problemen met de beschikbaarheid van BGT in JOSM?

Bij omtrekgericht krijg ik langzaam delen binnen maar veel tiles zijn niet beschikbaar…
Dit zeker sinds gisteren.

Ja, ik ook. Ik dacht dat het aan mij lag. Misschien wordt er nu teveel gebruik van gemaakt en is de server overbelast?

Altijd ‘fijn’ te horen dat het probleem niet lokaal is :confused:

Mogelijk hebben ze kerstreces en in ieder geval geen medewerker beschikbaar om de boel te resetten…

Het kerstreces lijkt voorbij…:smiley: