Idee om wat met BAG te gaan doen

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.

Ik ben het niet met je eens, de gemeentelijke weg valt in de gemeentelijk categorie erftoegangswegen, nu dat deze doodlopend is, stopt bij een erf, maakt niet uit, die wordt bij mij unclassified. Pas als je het erf op rijdt wordt hij highway=service service=driveway. We moeten wel het juiste beeld weergeven.

een =service zal eigenlijk altijd een tweede tag key=value nodig hebben, service=
bij parkeerterreinen geven service=parking_aisle aan.

Het kan zijn dat NWB wegen niet up to date is.
Die andere bij de rotonde is ook zo’n leuke, die erftoegangsweg (gemeentelijk categorie) begint bij de rotonde dat is de Gemeente Hof van Twente en zal waarschijnlijk Holterweg heten, vanaf de Gemeentegrens gaat hij over in Gemeentelijke weg van de Gemeente Ruissen-Holten, Markeloseweg, en loopt tot de bocht waar kadastraal de weg overgaat in prive. (de kadastrale layer in JOSM)
Dit volgens de medewerker van Gemeente Rijssen-Holten, die ook OSM’er is.
Waarbij Bag pand gemeld is.

Edit ik had de verkeerdde situatie.
Heerlijk dat overspringen van google maps, naar een plaats waar een gebouw staat.
Dus als je op een weg drukt bij een brug, verspringt GM maps naar een gebouw. Stuk verderop. Dat was vroeger niet. Lastig.

Ja hoor eens, als je nu ook nog exact de kadastrale grenzen moet gaan raadplegen en ook de wegbeheerder, dan wordt het wel erg lastig en tijdrovend. En er is nog zoveel werk te doen. En voor een hele categorie mappers wordt dan niet meer behapbaar.
Best interessant, maar laten we het nog een beetje simpel houden.
Hoe leg je iemand uit waarom de ene doodlopende weg wel dik getekend wordt en de andere niet?
Die weg bij de rotonde heeft een verwijsbordje naar Markeloseweg, net als aan de andere kant een verwijsbordje staat naar Holterweg.

Om nog even off-topic verder te reageren. Een doodlopende weg naar enkele huizen lijkt mij maximaal als residential te classificeren. Service zonder toevoeging driveway lijkt me ook een goede optie, zeker als er een uitritconstructie is naar een “grotere” residential of unclassified. Bij een “unclassified” verwacht ik toch redelijk wat doorgaand verkeer.

Enige maanden geleden:

Ik ben zelf een hele tijd bezig geweest met een hoop andere dingen en heb me maar spaarzaam met BAG bezig gehouden.
Ik moet nu toch weer (een hoop) achterstallig werk doen en kwam er inderdaad achter dat de plugin niet meer werkt en ik kon ook geen nieuwe vinden.
O.b.v. Gertjan’s github repositories voor de josm-ods-bag en de josm-openservices heb ik die beide jar’s maar zelf gecompileerd, maar er staan ook een aantal issues … En ik dacht er toen pas aan om hier maar eens te kijken.
Ik heb mijn zelf gecompileerde (maar uiteraard 100% Gertjan’s jars) nog niet gebruikt vanwege het “relaties import issue”. Dat issue lijkt opgelost (is dat zo?) en ik zie dat Gertjan al bezig is met versie 0.67.

Kortom: Wat is de status op dit moment?

Edit: die zelf gecompileerde ods-bag.jar is niet goed.