Adresvlakken?

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…:wink:

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.

De genoemde vlakken staan alle dubbel getekend, wat de validator ook netjes laat zien!
De tags/keys Ministerie van EZ, version en visible staan er ook nog steeds.

Welke senior communitylid heeft een voorstel voor de best te bewandelen weg?

Als ik het goed begrijp vernielt ie niet werk van anderen maar voegt ie data toe die arbitrair is omdat:
1 het een import lijkt zonder afstemming
2 het taggen voor de render is (admin_level 7 staat zo mooi)
3 hij key/values gebruikt die niet zijn afgestemd en/of gedocumenteerd

Volgens mij hebben we geen super haast om het op te ruimen dus wellicht komt ie de komende dagen tot inkeer en stemt ie met ons af. Zo niet dan kunnen we een melding maken bij de DWG. Met overpass is het overigens ook zo weer opgeruimd maar laten we de gerrit_dankelman of anders de DWG afwachten mocht dat nodig zijn.

Inderdaad: goed samengevat.

Hij is inmiddels veel handmatig op eigen houtje aan het herstellen, beetje bij beetje.

We wachten nog even rustig af, hoe graag we hem ook zouden willen helpen…:wink:

Beste community ik ben bezig mijn invoer te verwijderen. Door selectie op thema adnin_level 7 lukt dat. Misschien kan Adresvlak of benummervlak op level 12 nog eens worden overwogen. Ik heb hier van geleerd;>}

Beste Gerrit,

Namens de community veel dank dat je (positief) contact met ons hebt opgenomen!

Heb je de site http://overpass-turbo.eu/ geprobeerd? Hier kun je snel van een kaartsnede de gewenste data downloaden en naar JOSM exporteren en daar bewerken.

Laat ons weten wanneer je klaar bent of denkt te zijn, dan kunnen we een check uitvoeren.

Als ik klaar ben zal ik het laten weten. Prettige feestdagen Iedereen.

Beste Mappers,
Ik heb alle gegevens welke op admin_level=7 waren opgevoerd verwijderd.
Gras objecten met Ministerie veld heb ik verwijderd.
Misschien zit er nog een schoonheidsfoutje, dan hoor ik dat wel.