Idee om wat met BAG te gaan doen

Voor mijn huis klopt dat dan al niet. Mijn huis staat in de BAG met de inspringende voorgevel die op maaiveldniveau is te zien. Op de luchtfoto is dat niet te zien, maar de BAG toont wel degelijk maaiveld niveau.

Ik had een vraag over het taggen van admin_level bij dorp polygonen. Ik zie bij de polygonen source = BAG staan, dus denk dat ik in dit topic het beste mijn vraag kan stellen.

Op deze pagina zie ik dat in Nederland dorpen als admin_level 9 worden gemarkeerd en wijken als admin_level 10. Nu ben ik erachter gekomen dat dorpgrens polygonen in OSM als admin_level 10 gemarkeerd worden (zie Malden, Beers, Urk als voorbeeld). Dit heeft tot gevolg dat wanneer ik bijvoorbeeld Nominatim (geocoder om adres → coordinaat en andersom te rekenen) gebruik, het lijkt alsof deze weg in het dorp Heumen zit met als wijk Malden. Dit terwijl daadwerkelijk Malden het dorp is en Heumen de gemeente.

Mijn vraag is dus eigenlijk: wat is de logica van het taggen van admin_level in Nederland? Is de pagina van OSM outdated? Is dit een fout die meegenomen is uit BAG?

Je word in de war gebracht door de foutieve vertaling op de OpenStreetMap website van de admin_level zoals deze in Nederland worden gebruikt. Het volgende heb ik eerder gepost in het topic: Vervallen gemeentegrenzen:

Toch vind ik het vreemd.
Op 17 november 2015 was Netherlands nog niet opgenomen in de wiki (10 admin_level values for specific countries:).
https://wiki.openstreetmap.org/w/index.php?title=Template:Admin_level_10&oldid=1243416

Deze is pas geupload op 25 november 2015.

En bovenstaande wijkt af van:

Nu zie ik dat er een proposal heeft aangebracht op de wiki Tag:boundary=administrative op 25 november 2015

Nu begrijp ik ook de verwarring die ontstaan is omtrent de adresvlakken

Is het verstandig om een nieuwe topic te openen, om tot overeenstemming te komen in het gebruik in Nederland op de Tag;boundary=administrative site?

Op de wiki Tag:boundary=admistrative staat helemaal onderaan

11 admin_level values for specific countries
Deze is geplaatst op 29 november 2014 dit lijkt juist te zijn.

11_admin_level_values_for_specific_countries

Waarom Netherlands opgenomen is in “10 admin_level values for specific countries” is me nog onduidelijk.
Het lijkt mij dat 10 admin_level geheel mag komen te vervallen.

10 admin_level values for specific countries:

Een gebruiker zonder wiki profiel heeft Nederland aan de admin_level 10 sectie toegevoegd, waarschijnlijk niet wetende dat wij al jaren 11 admin_levels gebruiken net als Duitsland. Ik heb Nederland uit de admin_level 10 sectie verwijderd, voordat we daarbij opgenomen kunnen worden moeten we de tagging van boundaries in Nederland geheel herzien.

Ik kom hier http://www.openstreetmap.org/#map=15/51.9879/5.1202 een grens binnen de gemeente tegen die lijkt op een toekomstig plan Hoef en Haag. Er lopen nu dus twee grenzen, een plus minus met construction (25-11) en naam van het plan en een BAG plan grens zonder iets (10-12). De BAG import neemt ook nieuwe bestemmingsplannen mee en heeft het dan nog zin om die handmatig in te brengen ?

Er lopen geen twee grenzen, er is een landuse=construction (way:382652395) (die jij hebt aangemaakt) en een boundary=administrative (relation:5733202) voor Hoef en Haag (die ik heb aangemaakt). Dit zijn twee verschillende features, die m.i. beide bestaansrecht hebben. Alleen de boundary relatie is in mijn optiek een “grens” en landuse is dat niet.

In de BAG update van december j.l. is de woonplaats Hoef en Haag geïntroduceerd, en die wijziging heb ik zodoende doorgevoerd in OpenStreetMap. Ook heb ik een Wikipedia artikel aangemaakt voor Hoef en Haag omdat elke woonplaats in Nederland een artikel (met kaarten van Jan-Willem van Aalst) en bijbehorend wikidata object verdient (wat uiteraard in twijfel werd getrokken, zie: Te beoordelen pagina’s).

De BAG import neemt geen bestemmingsplannen mee. In de BAG was slechts een nieuwe woonplaats toegevoegd.

De landuse=construction maakt het duidelijk dat het dorp nog in aanbouw is/nog gebouwd moet worden, dat is een andere feature dan de woonplaats die voornamelijk van belang is voor de adressen die in dat gebied zullen ontstaan n.a.v. de construction activiteiten.

Voor BAG-importjes bij ons in de buurt gebruikte ik nog JOSM 8800 met BAG-ODS 0.5.1.
Sinds enkele dagen meldt JOSM 8800 bij het opstarten:

Maar JOSM werkt niet automatisch bij naar 0.6.6.
Ook als ik JOSM zelf naar de nieuwste versie zet, wordt ODS niet bijgewerkt.
(En toen ik terugging naar 8800, werkten andere plugins niet meer…)

Is de nieuwe versie inderdaad al (bijna?) ergens beschikbaar, of zijn jullie nog verder aan het testen?

Groet,
Kees-Jan

Inderdaad, de oude plugin is vanaf een bepaalde datum niet meer compatible met JOSM.
De nieuwe versie (maar ook de oude) is niet updatebaar in de JOSM plugins.

En de plugin is momenteel in testfase.

Ik had een tijd geleden JOSM, opnieuw er op gezet.

Nu was ik aan het kijken bij imagery preference welke lagen er nog meer in staan, daar staat een laag in JOSM → OSM inspector: addresses

En dan doe je toch weer een aantal constateringen waar nog aan gewerkt moet worden.

NU de BAG plugin nog in ontwikkelingen is, ** activeer de laag **en kijk eens wat je tegenkomt. !!

Zoom ook eens wat dieper in dsan zie je verbindingslijnen, zijn dat lange lijnen dat kan kloppen. Maar ook lange lijnen waarbij een stuk weg vergeten is een naam te geven.

Kijk in de pdok viewer bij NWB wegen waar de straatnaam begint.

Die is handig, daar zocht ik al een tijdje naar, zit ie er al in…

Nu eigenlijk nog een manier om een aantal altijd gebruikte layers tegelijk met JOSM op te starten om het nog gemakkelijker te maken.

edit: Is eigenlijk jammer dat de goede adressen er ook op staan, overschaduwen de issues een beetje. Zouden ze ook nog een WFS hebben met deze data?
Straks eens kijken of ik deze kan hergebruiken: http://tools.geofabrik.de/osmi/views/addresses/wxs?LAYERS=nearest_areas%2Cnearest_roads%2Cconnection_lines%2Cnearest_points%2Cinterpolation%2Cbuildings%2Cbuildings_with_addresses%2Cnodes_with_addresses_interpolated%2Cpostal_code%2Centrances%2Cinterpolation_errors%2Caddrx_on_nonclosed_way%2Cno_addr_street%2Cmisformatted_housenumber%2Cstreet_not_found%2Cplace_not_found&FORMAT=image%2Fpng%3B%20mode%3D24bit&PROJECTION=EPSG%3A900913&DISPLAYPROJECTION=EPSG%3A4326&TRANSPARENT=TRUE&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A900913&BBOX=492281.85202317,6779364.5486755,505639.22271415,6783119.5176895&WIDTH=1398&HEIGHT=393

Kleine aanvulling. Een lange lijn kan ook betekenen dat een weg naar een pand helemaal niet is ingetekend. Ik ben momenteel in Salland bezig en ik zie de nodige (service)roads ontbreken. En inderdaad veel serviceroads zijn naamloos, dat klopt. Die krijgen van mij een naam als ik ze tegen kom.

BTW, Allroads, bedankt voor deze tip. Erg nuttig :slight_smile:

Omgekeerd zoeken van ref:bag nummer naar locatie

Overpass ref:bag nummer zoeken

Fraai voorbeeld waarom het nuttig is, de wegen naar panden ook een naam te geven, is de volgende:

Nr 14 rechtsboven heeft als straat Markeloseweg. OSMInspector tekent nu een lange lijn naar de serviceroad van Markeloseweg 2A. Benoem je de serviceroad vanaf de Borkeldweg met Markeloseweg, dan kan het adres gevonden worden. Bij de Borkeldweg staat ook een bord met verwijzing naar Markeloseweg 14
Dit soort situaties komt vaker voor. Een adres heeft een afwijkende straatnaam van de straat, waar de serviceroad van aftakt. Benoemen van serviceroads is dus belangrijk.
Dat zie ook bij de lijnen van nr 7 en 9 in het midden. Benoem de serviceroad als Borkeldweg en de lijnen worden een stuk korter.

Niet elke lange lijn hoeft opgelost te worden.

Maar is het dan juist, nee.

Het zoeken op adres dan is gebouw / node bepalend.
Een goede routering zorgt er voor dat je zo dicht mogelijk bij de node komt. Alleen het intekenen van de unclassified road is voldoende.

Het bordje, is geen straatnaam bordje maar een verwijzing naar een adresnummer.

highway=service service=driveway is onjuist, het is een openbare gemeentelijke weg.

Heb je gezien hoe het gebouw huis nummer 7 is ingetekend in OSM uit de BAG.
Alleen dat deel van het huis, dat in de Gemeente Hof van Twente ligt.

Zie Gemeente lijnen. En dan is het begrijpelijk hoe het ontstaan is.

@ dick, ik vindt je plaatje flets, heb je bij de layers die je aan hebt staan bij de wms wel gekozen voor image formaat png, want alleen bij png kan je een transparent layer laten zien, in de string staat dan &TRANSPARENT=true

of heb je aan de gamma slider getrokken bij de openstreetmap laag?

De wiki zegt over serviceroads: Wegen naar parkeerplaatsen, tankstations, gebouwen, etc. Voor verzorgingsplaatsen langs autosnelwegen, zie ook highway=motorway_link. Voor het gebied zie highway=services. Rijbanen op een parkeerplaats tussen de parkeerplaatsen. Weg van de openbare weg naar een huis of kantoorgebouw. Veelal zijn deze wegen privéterrein.

Er wordt dus gezegd Veelal zijn ze privé terrein. Maar dat hoeft dus niet. Dus jouw conclusie dat ze niet openbaar zijn, staat nergens. En van de meeste van dit soort wegen valt absoluut niet vast te stellen of ze wel of niet openbaar zijn, wel of niet privé eigendom. Soms staat er een bordje eigen weg, soms ook niet. En het zijn voor het overgrote deel doodlopende wegen.
Voor mij blijven het serviceroads. Ze lopen naar één of meer huizen of boerderijen.
Unclassified is naar mijn mening een beetje teveel het manusje van alles geworden.
Wat meer differentiatie, zeker in het buitengebied is welkom.

Plaatje is zo omdat deze in de browser is gedaan. Dus via de link http://tools.geofabrik.de/osmi/ en dan is het altijd alsof er een laag overheen zit.
Het is dus niet in JOSM gedaan.

Die conclusie heb ik niet getrokken, ik zeg juist dat het Gemeentelijke wegen zijn.
Die zijn nu blauw geselecteerd, maar normaal dus grijs.

Wat betreft het pand heb ik contact gehad met Gemeente Rijssen Holten.
Wordt aan gewerkt.
Volgens gbkn hoorde Hof van Twente, tot aan de Gemeentegrens in te tekenen. Volgens de BGT hoort het hele erf ingetekend te worden door Hof van Twente. Volgens afspraak.
We zullen het zien, wat er binnen 6 maanden gebeurd. Officieel termijn na BAG melding.

Oh wacht, nu zie ik wat je aan het doen bent. Je kijkt naar de wegbeheerder. Duidelijk.
En nu is me ook helder waarom de ene boerderijweg wel en de andere niet in het NWB verschijnt. Als ze particulier eigendom zijn, dan niet, want niet in de wegenlegger.

Maar ik blijf het een service vinden, gemeente of niet. Het is een weg naar een boerderij, meer niet.
En verder wordt het ook ongelooflijk ingewikkeld en moeilijk. Particuliere wegen zouden dan wel service worden, maar toegangswegen beheerd door gemeente of waterschap weer niet. Wordt een mistige boel.

Laten we gewoon een heldere afspraak houden, wegen naar panden toe, worden service.
Per slot wegen op een parkeerplaats zijn vaak ook openbaar en wel service.

En verder als je al die toegangswegen als unclassified gaat zetten, krijg je nul differentiatie in de kaart. De renderer heeft geen mogelijkheid om op bepaalde zoomlevels dit soort wegen uit te filteren.
En ook je kaartbeeld wordt een en dezelfde brei. Door dit soort wegen als service te zetten, worden ze anders weergegeven dan de unclassified en kun je ze minder belangrijk maken.
En nee, dit is geen taggen voor de renderer. Die kan geen onderscheid maken tussen de diverse wegen. De classificatie moet van de mappers komen. Wat een render met die classificatie doet, is dan zijn/haar zaak.