Dit is nagenoeg 100% zeker data die oorspronkelijk uit ArcGIS en gemeentelijke GIS systemen komt. De velden OBJECTID, Shape_Area en Shape_Length wijzen hierop, want dat zijn systeemvelden uit GIS bestanden van ESRI. Ik ken ArcGIS binnenstebuiten, want werk er zelf al jaren mee.
Op zich is er niets mis mee als mensen vanuit deze hoek bijdragen willen leveren, maar als er geen enkele moeite wordt gedaan om Nederlandstalige gegevensvelden uit een GIS, naar zinvolle en betekenisvolle OSM keys om te zetten, en erger nog, zoals hier elk attribuutveld zomaar mee wordt genomen bij de conversie, dan lijkt mij maar 1 oplossing de juiste: reverten!
Dit levert namelijk niets op dat waarde voor mede-osmers heeft. We willen echt niet de hele databank vol met alleen maar taalgebonden tags, dat is de doodsteek voor een internationale community project, je kan dan niets meer zinvol renderen, zoeken of analyseren.
Edit:
In aanvulling op Commodoortje: ik denk dat het inderdaad vooral onwetendheid is, maar dat neemt niet weg dat je toch mag hopen, dat de meeste mensen uit de geo-hoek iets meer moeite zullen doen om zich in te lezen en bekend te worden met OSM, voordat zij tot edits overgaan. Ik heb mijzelf in ieder geval te pletter gelezen voordat ik actief werd…
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.
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.
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.
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 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