Adresvlakken?

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.

De rode gebieden die de validator laat zien zijn grasland objecten die ik heb vervangen door bgt grasland agrarisch.Hierin is het land en sloten in de kaart zichtbaar en sluit beter aan op de erven langs de streek. Dsta is wel door de validator geacceoteerd. Strenge regels kunnen wel een belemmering worden mutaties. Stimuleerd niet om de map te verbeteren.

Gerrit,

Ik begrijp best je gevoelens, en het is ook zeker allemaal zeer goed bedoeld. Maar er zijn spelregels die nageleefd moeten worden, anders is de kaart binnen de korste keren volledige chaos.

Waarom gebruik je dan ongebruikelijke tags?

landuse=grass
user=Ministerie van EZ
version=1
visible=true

Beste Gerrit,
Je staat er kennelijk niet bij stil dat de osm.org kaart niet de enigste kaart is die gebruik maakt van OSM database.
Wat jij mooi vindt renderen als dun stippellijntje komt op een andere kaart totaal niet goed over, omdat Level 7 qua hierarchie tussen een Staats/Provinciegrens en Gemeentegrens in ligt. Kijk maar eens op de garminkaarten wat het resultaat is van jouw tagging, een enorme brei aan grenzen die op lager zoomniveau nog zichtbaar is en tot verstoring van het kaartbeeld leidt (wegen worden overschaduwd door jouw percelen). Deze level 7 gebruik jij voor je eigen doeleinden. Dit heet tagging for the renderer, is onacceptabel en dient zo snel mogelijk te worden teruggedraaid. Desnoods maak je er admin_level=12 van, een niveau lager dan wijkgrens (11). Wordt niet gerenderd/noch ondersteund maar is beter dan de verkeerde tags gebruiken.

Zoom eens uit. Vind jij dat nog acceptabel dat die perceelsgrenzen ook op dit niveau worden gerenderd?
http://www.openstreetmap.de/karte.html?zoom=12&lat=52.64236&lon=6.22073&layers=B000TT

http://www.openstreetmap.org/way/386304763
http://www.openstreetmap.org/way/386312482

Je hebt veel van deze vlakken dubbel op de kaart gezet. Dat is een van de zaken waar de validator je voor waarschuwde.

Inmiddels lijkt het erop dat Gerrit de adresvelden weer aan het verwijderen is.

Ik kan niet nagaan of hij dat handmatig doet of de JOSM reverter-plugin gebruikt, waarmee het een heel stuk sneller gaat!

@Gerrit: geef aub aan of:

• je de democratische beginselen van OSM accepteert en de door diverse forumleden geplaatste bezwaren tegen jouw handelswijze begrijpt en accepteert
• je hulp wilt bij het verwijderen van alle adresvelden.

Ik trek de voorzichtige conclusie uit Linkedin dat jij Vastgoedcoördinator bij de Gemeente Staphorst bent en je dus, blijkbaar, met GIS-systemen overweg kan.

OSM heeft andere regels dan jouw lokale GIS systeem; wil je op OSM data aanvullen (vermeld dan tevens de bron, dat is ook een goede gewoonte), dan zul je de formats van OSM dienen te respecteren, ook al zijn, die wellicht in jouw expert-ogen minder volledig of functioneel dan wat je in je dagelijks werk gebruikt. Toch houden we ons op OSM aan de OSM-regels.

Tevens: heb je, als beginner een vraag of een voorstel: post die in dit forum en veel vrijwilligers geven je snel antwoord!

Groet,
Martin

Dit is geen juiste veronderstelling, gisteren was hij er wel voorzichtig mee begonnen. Ik heb inmiddels mailcontact met hem gehad waarop hij inmiddels heeft geantwoord.

Het is nu wel zaak om te gaan kijken hoe de situatie wordt hersteld/aangepast cq teruggedraaid moet gaan worden.
Nu Gerrit (tijdelijk) geen uploads meer zal doen, mag hij natuurlijk altijd meedenken in de oplossing. En wat misschien belangrijker is, de beweegredenen dat op deze manier is geïmporteerd.

Eenieder kan van mening zijn dat er iets belangrijks mist in OSM. De eerste vraag moet dan zijn: is het vooral belangrijk voor mijzelf of mijn organisatie (a), dan wel is het iets is dat nationaal of liefst internationaal node gemist wordt (b).

(a) Maak (bv. in JOSM) een eigen layer en bewaar/gebruik dit lokaal (.osm bestand), en/of zet het op een server en maak het toegankelijk middels bv. OpenLayers.

(b) Doe een beargumenteerd voorstel, eerstens op dit Nederlandstalig forumdeel, en verder internationaal via een ‘Proposal’ op de Wiki.

Persoonlijk heb ik al enkele zaken in mijn gedachten laten voorbijgaan, die volgens mij NIET in OSM hoeven, doch voor sommigen interessant zouden kunnen zijn: per adres bewonersnaam, telefoonnummer, aantal bewoners, aantal zonnepanelen, JA/NEE-sticker voor reclame; ondergrondse leidingen voor gas, water, elektriciteit, telefoon, kabel (ik heb er kaarten van voor mijn buurt); nestkastjes; routers met naam en beveiligingsniveau.
Oftewel: er is van alles mogelijk. Maar is het zinnig, en voor wie?

Adresvlak, verschillende poi binnen een adresvlak, het kunnen uitwisselen/renderen van gegevens van node of gebouw.
Een mini midgetgolfbaan, bij een popup wil je gelijk alle gegevens .
Dat hoeft niet zichtbaar te zijn in de kaart. Is een gedachte waar ik aan denk.
Is dat landelijk aanwezig en hoe staat het met de licentie betreffende deze gegevens.

Willen werelsdwijde apps dit toepassen, dan hoort het in de OSM. Nieuwe key/value.
Maar zou een op zich staande layer kunnen zijn. Ik zie geen noodzaak om enig andere tag aan dat adresvlak te plakken.

Ik denk ook wel eens waar kunnen wij het verschil maken t.o.v. GM, Wat maakt OSM interessanter dan.

@Allroads en HenkL: de discussie of iemand de spullen op zijn keukentafel gemapt wil hebben, hoe relevant ook, is een geheel andere.

Wat hier speelt is dat Gerrit zaken tagt in strijd met bestaande algemeen overeengekomen taggingregels binnen OSM en daarmee niet alleen de standaardrendering zwaar verstoort, maar ook de onderliggende data (key/value) beschadigt.

Persoonlijk, voor wat het waard is: OSM zal nooit bedoeld zijn voor bepaalde professionele gebruikers als rioolbeheerders, gasleidingmaatschappijen, KPN, kabelmaatschappijen, reclamebezorgers etc. etc. Als zo’n maatschappij de schop in de grond steekt gebaseerd op OSM informatie die zonet door een newbie vermöbeld is…

In aanvulling op alle goede opmerkingen hierboven, wil ik ook nogmaals voor Gerrit benadrukken dat het toevoegen van willekeurige Nederlandstalige gegevensvelden vanuit een GIS systeem aan OSM ongewenst is.

Alleen als alle gegevensvelden naar een zinvolle engelstalige “key” worden omgezet, heeft invoer in OSM nut en zin. OSM is niet een lokale database waaraan door iedereen willekeurig lokale gegevens worden toegevoed, het is een wereldwijd ingezette database, met toepassingen die wereldwijd moeten kunnen functioneren. Denk aan b.v. routeringssystemen die “over de grenzen” gaan, die hebben niets aan data ingevoerd in een lokale taal.

OpenStreetMap is zeer zeker ook niet een vervanging voor een eigen organisatiebrede ‘WebGIS’…

Het streven moet bij een OSM import, waar dit toch zeer sterk op lijkt, nooit zijn om de maximale hoeveelheid gegevens mee te nemen, maar juist de absoluut minimale die nut heeft en aansluit bij de bestaande data / keys, en tagging conventies vastgelegd in de Wiki van OpenStreetMap. Alleen op die manier wordt een breed inzetbare database gegarandeerd.

“Strenge regels kunnen wel een belemmering worden mutaties. Stimuleerd niet om de map te verbeteren.”

Om toch nog de impact van deze import te illustreren: stel je zelf de volgende vraag:

Wat zou jij persoonlijk er van vinden als wij toegang hadden tot de zorgvuldig beheerde gemeentelijke CAD/GIS systemen, en daar van alles naar onze eigen hand en voorkeur in gaan stellen, b.v. de line en entity types van de CAD bestanden, of gegevensvelden hernoemen zodat geen enkele kaart meer het juiste weergeeft?

Hoor ik daar een binnensmondse vloek als je 's ochtends op je werk komend ontdekt wat er gebeurd is??

Dat is dus de impact van een dergelijke import… OSM is met zijn vrije tagging systeem misschien meer wild-west dan we soms willen, maar dat betekent niet dat er het duidelijke streven is om tot tagging conventies en standaarden te komen, en dat er al veel is vastgelegd in de Wiki.

Zoals anderen al hebben aangegeven: indien de bestaande tags niet passen voor bepaalde attributen, dan heb je twee keuzes: 1) weglaten en alleen datgene toevoegen dat wel past, dit is de meest voor de hand liggende optie, en 2) een voorstel doen om nieuwe tags aan te maken, en liefst in de Wiki vastleggen.

Persoonlijk, kijkend naar de voorbeeld screenshots die Commodoortje heeft geplaatst, denk ik dat hooguit 5 tot maximaal 10 van de zichtbare attributen, direct gerelateerd aan adressen, een plaats hebben in OSM, de rest zou weggelaten moeten worden.

Als laatste: het negeren van JOSM validator errors is voor de originele editor dan misschien wel een leuke tijdsbesparing, maar zorgt in de toekomst voor veel extra werk voor diegenen die het originele werk willen aanpassen. Het is niet voor niets dat b.v. in het landelijke BGT (Basisregistratie Grootschalige Topografie), waar je ongetwijfeld van gehoord hebt of ook bijdragen aan moet leveren, een strenge topologie en inhouds controle is ingebouwd.

Het lijkt erop dat gerrit_dankelman de gemaakte afspraak om even te wachten met herstellen naast zich neer heeft gelegd.
Hij heeft vandaag ongeveer 20 changesets geupload.

Waarom?
Wij zijn niet boos op je Gerrit, we zoeken alleen een oplossing voor het geheel wat veroorzaakt is.
Nogmaals een oproep om even te wachten met herstellen.

Er zijn in bovenstaande communicatie al veel vragen aan Gerrit gesteld, helaas worden deze niet per mail maar ook niet op het forum beantwoord.

Het lijkt erop dat Gerrit zijn eigen plan blijft trekken.

Het lijkt er toch op (ik maar even gekeken) dat hij zijn edits stuk voor stuk aan het herstellen is, of zie ik dat niet goed?

Kent denkelijk de reverter plugin JOSM niet; dan gaat het nog wel een tijdje duren.
Ik kan met behulp van Overpass wat helpen.

Blijft hij negatief bezig dan rest ons weinig anders over dan hem te laten blocken.