Is dit niet iets dat een keer op de dev-mailinglijst besproken zou kunnen worden? Dit probleem wordt er met de loop der jaren niet kleiner op. Je wilt natuurlijk ook niet ieder jaar alle data 2,5 cm opschuiven.
Heb je nog iemand nodig om dit te testen? Ik had in de oude plugin problemen met een aantal nieuwe huizen die ik niet geïmporteerd kreeg, terwijl de status op pand in gebruik staat.
Bedankt voor je aanbod. Ik ben nu met 3 mensen versie 0.6.4. aan het testen, wat op niet al te lange termijn tot een versie 0.6.5 moet leiden. Voor mij is het het handigst als je bij die versie instapt.
Waar stonden de huizen die je niet geimporteerd kreeg? Dan kan ik alvast even kijken of ze nu mee komen. Het echte importeren laat ik aan jou over.
Het gaat om de Stakenberg 65 t/m 83, Ede. De huisnummers t/m 63 importeerden wel goed.
De nieuwe verlsie importeert deze panden en adressen zonder problemen.
Hoe gaan we om met hergebruik van historische gebouwen ? Houden we voor het gemak de door de gemeente aangehouden (foutieve) verbouw datum aan of de originele stichtingsdatum en eventueel de ontwerper (architect), etc ?
Ik kreeg van een Gemeente dit antwoord terug
“Wij hebben geconstateerd dat het pand wel een kleine ronding op de begane grond heeft (draaideur) maar dat de verdiepingen oversteken, en alles wat hoger is dan 1,50 op verdiepingsniveau dient ook in BAG te worden ingetekend, het pand is dus iets groter geworden.”
Ik ging er steeds vanuit dat wat wij zien en intekenen op funderingsniveau is.
edit: van een hierop volgende mail
“In BAG wordt gekeken naar het bovenaanzicht (in tegenstelling tot de GBKN waarbij gekeken werd naar maaiveldniveau), met dien verstande dat de overbouw alleen word meegenomen als deze substantieel is, dus niet als het alleen om een overstekende dakconstructie gaat.”
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 