Adresvlakken?

@Commodoortje: al respons gehad op je vriendelijke mail?

Nee nog geen reactie

Is dit de verklaring omtrent het taggen van adresafbakeningen?

Inmiddels is de gemeente Ommen aan de beurt?
https://www.openstreetmap.org/#map=17/52.53523/6.43260&layers=N

Yep, zelfde auteur, zoals verwacht. Een half uur geleden. Dus geen reden dat hij zijn berichten niet kan lezen.

Hij gebruikt admin_level=7.

In de Engelstalige wiki staat Nederland niet apart genoemd, maar door de oogharen kijkend zie ik dat admin_level=7 in andere landen niet gebruikt wordt, dan wel voor niveaus als gemeenten of districten en zeker niet voor erfafscheidingen.

Het rendert wellicht wel mooi.

Inmiddels is deze dubbele en verkeerde informatie op de wiki pagina verwijdert.

De juiste info stond al op de wiki, Nederland heeft 11 admin levels

Je zou in de 10-levels-tabel een verwijzing naar de 11-levels-tabel kunnen maken zoals voor Duitsland ook is gedaan.

Opgesloten in het woord ‘level’ (‘niveau’) zit een rangorde. Een level met een hoger getal betekent in het algemeen een lagere orde.

Het afbakenen van een (woon)perceel zou dan eerder level 12 moeten zijn (en van de kamers in het huis level 13 voor de mierenmappers onder ons).
Level 7 lijkt me dan sowieso volkomen misplaatst.

Martin

Goed idee, ik heb een poging gedaan maar op één of andere manier zie ik het resultaat alleen in de preview en niet in de opgeslagen versie.

Inmiddels heeft gerrit_dankelman via mail gereageerd. Zijn intentie is goed, en hij is bereid over de oplossing mee te denken.
Zijn mail heb ik inmiddels beantwoord en heb hem uitgenodigd om aan te haken op dit draadje.

Da’s mooi; ik denk ook dat niemand getwijfeld had aan zijn goede intenties.

Alleen je aanpassen aan de (andere) conventies kost wellicht even moeite.

We gaan er vanuit dat het allemaal goed komt.
Mijn persoonlijke voorkeur is overigens, voor wat het waard is, dat we niet perceelsgrenzen in al hun omvang gaan taggen.

Want als we Staphorst en Ommen gedaan hebben, wie doet dan de rest?

Adresvlakken kunnen in dichte bebouwing, (woonplaatskernen) meer duidelijkheid verschaffen waarbinnen een adres manifest is.
Ik heb admin_level 7 gebruikt omdat deze in de kaart zichtbaar is als een dun stippellijntje. http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative Met beperkte niet officiele invullen in betekenis.
Deze lijnen zouden op de zoomlevel zichtbaar moeten worden als ook de huisnummers in de kaart zichtbaar worden.

Gerrit, welkom op het forum!

Maar dit is toch taggen voor de rendering?

Op http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#11_admin_level_values_for_specific_countries staat immers voor level 7: “Collaboration of municipalities, but not an official plusregio” en daar lijkt een kavelgrens imho verre van aan te voldoen.

Inmiddels heeft het een aardige olievlek werking.
Zo te zien de gemeentes Zwartewaterland, Staphorst en Ommen.
Dus de plaatsen: Genemuiden, Zwartsluis, Rouveen, Hasselt, Staphorst, IJhorst, Ommen, Lemele

Van uitbreiding zal geen sprake meer zijn, eerder optimalisatie of verwijdering van deze gegevens.
Als we Stedelijke gebieden kunnen verrijken met adresvlakken kan dat meerwaarde betekenenen voor gebruikers.
Ook in het kader van rampenbestrijding is snel inzichtelijk binnen welk adresgebied zaken relevant kunnen zijn.

Welkom in deze discussie Gerrit.
Waar komt de term adresvlak vandaan? De enige betekenis van dit woord dat ik kan vinden is het vlak op een envelop waarin je de adresgegevens zet.
Wat je nu op de kaart gezet heb in de regio Staphort lijken mij meer kadastrale percelen. De belangrijkste reden waarom de OpenStreetmap gemeenschap internationaal erg terughoudend is met het opnemen van percelen, is de onderhoudbaarheid. Zodra je deze in de OSM database zet, suggereer je dat de data actueel is. Dat kunnen we als OSM gemeenschap in Nederland natuurlijk nooit hard maken. Dit geldt voor de OSM data in het algemeen, maar het verschil met kadastrale percelen is, dat ze vooral ook een belangrijke juridische functie hebben.

Ik ben daarom niet voor het opnemen van kadastrale data in OSM, en zeker niet buiten de import procedures om. Zie: http://wiki.openstreetmap.org/wiki/Import/Guidelines

Ik ben het hier geheel mee eens; dit los van OSM onbekende tags als:
BenoembareNaam
HUISNUMMER
Postcodenaam
Woonplaatsnaam

Dit tevens los van het feit van van de verkeerde bewoording dat dit doublures betekenen, want vanuit de BAG import zijn deze datavelden al - correct - geïmporteerd.

Het verkeerde gebruik van adminlevel 7 is al eerder genoemd. Rendering van adminlevel 7 “ziet er leuk uit” interpreteer ik dan maar even vrij.

Het argument van rampenbestrijding lijkt me niet zo valide: als we op adres/postcode uit BAG zoeken vinden we de ‘ramp’ snel genoeg denk ik.

Als Gerrit zich hier in kan vinden en we geen edit-war gaat starten (en ik denk dat vanuit democratische principes zeer aan te bevelen is) kan iemand hem misschien helpen alle changesets terug te draaien om te voorkomen dat Gerrit moeizaam alles stuk voor stuk gaat verwijderen?

Adresvlakken zijn geen kadastrale percelen, ze zijn er vaak wel van afgeleid. Adresvlakken hebben de mogelijkheid nieuwe objecten te bergen denk aan schuurtjes en bijgebouwen. Adrespunten bestaan niet. Alle objecten in de werkelijkheid zijn vlakken die een domeinwaarde vertegenwoordigen. Zo is een ook tuin onderdeel van het adres. Betekenis verlenen door intersectie van elementaire objecten geeft betekenis aan de representatie van deze werkelijkheid.
Punten en lijnen bestaan niet in de werkelijkheid. Punt is een identifier en een lijn richtinggevend.
Als punt wordt gebruikt gaat deze vergezeld met een symbool en een lijn met een buffer om de lijn wat altijd een vlak oplevert wat betekenis geeft.
Onderhoud en actualisatie geld voor alle opgevoerde objecten in openstreetmap.
Door objectvergelijking bij de bron laat snel zien welke objecten zijn gewijzigd, en deze kunnen dan in de kaart worden bijgewerkt.
Veel objecten in openstreetmap zijn niet actueel en zullen de nodige aandacht moeten krijgen.
Level 7 heb ik gebruikt voor adresvlakken omdat dit nog een zichtbaar resultaat opleverd, hogere levels leveren geen zicht baar resultaat.
Zelfs onze Oosterburen gaan er flexibel mee om http://www.openstreetmap.de/karte.html?zoom=17&lat=52.61541&lon=6.18167&layers=B000TT
groet
gerrit

Gerrit,
Dit is een misverstand die je hier suggereert.
De link die je plaatst is een kaart die gebruik maakt gebruik van OSM data, de renderer (de maker van de kaart) laat op haar manier deze de tags visueel op de kaart verschijnen. Zo zijn er veel afgeleide kaarten die gebruik maken van OSM data.

Het is niet zo dat “de Oosterburen” er flexibel mee om gaan.
Al eerder is tagging voor de renderer aan de orde gekomen, er mag niet voor de renderer getagd worden zodat het mooier op de kaart verschijnt!

Er dient een oplossing gezocht te worden voor de “vervuiling” die op de kaart is gezet.

Graag wil ik een oproep doen aan ervaren OSM’ers om mee te denken in oplossingen.

In een eerdere post is al diverse keren aan de orde gekomen dat er door Gerrit gebruik gemaakt is van “een databron” en het lijkt erop dat deze tags 1 op 1 naar OSM gezet zijn.

Zonder dat Gerrit er vermoedelijk erg in heeft gehad, heeft hij bij uploaden van zijn changesets hoogstwaarschijnlijk alle validatorwaarschuwingen genegeerd.

In onderstaand voorbeeld heb ik alleen de objecten die gekoppeld zijn aan gerrit geselecteerd.
Met deze selectie heb ik de JOSM validator gedraaid, en schrok behoorlijk van de fouten en waarschuwingen die (alleen al in Ootmarsum) door de validator worden gevonden.