import lantaarnpalen Utrecht

Mee eens. Het heet niet voor niks 'Open’StreetMap. Als je het ‘te druk’ vindt op de kaart, render je het gewoon niet.
En waarschijnlijk zullen niet veel renderers de lantaarnpalen willen weergeven.

Omdat de import guidlines niet zijn aangehouden zou wat mij betreft de hele import ongedaan gemaakt mogen worden. Of iets druk wordt op de kaart of niet vind ik niet zo belangrijk zolang het maar data is waarvoor in de community genoeg critische massa is om het bij te houden. Stap 2 van de import guidelines gaat over “Community Buy-in”. Ik vraag me voor deze lantaarnpalen ernstig af of er voldoende personen zijn om deze actueel te houden zodat we niet over 10 jaar opgescheept zitten met een zeer onbetrouwbare dataset. Voor huizen en adressen is het al lastig om alles actueel te houden laat staan voor lantaarnpalen.

Er zijn gemeentes die putdeksels in de straat in BGT zetten. Het is inmiddels voor velen een koud kunstje om die data in OSM te dumpen maar ook daarvan is mijn verwachting dat 10 jaar later niemand het meer gebruikt omdat de data niet actueel is.

In dat licht ( :wink: ) begrijp ik ook wel de opmerking van Dick dat het erg druk op de kaart wordt. Op zich niet zo heel erg maar als je over 5, 10 of 15 jaar in Utrecht wilt mappen en je komt telkens die lantaarnpalen tegen waar geen hout van klopt dan wordt je daar niet vrolijk van.

Even los van een import is het m.i. verstandig jezelf de vraag te stellen of iets dat je mapt voldoende draagvlak heeft. Ik heb in het verleden losse verkeersborden gemapt maar kwam er later achter dat die nogal eens veranderde en dat dan ook nog eens veel vaker dan ik had gedacht. Wie gaat dat dan allemaal corrigeren?

Whilst the discussion continues about that, it’s perhaps worth mentioning that there are still some “totally misimported items” such as https://www.openstreetmap.org/node/5003583820 in OSM.

Best Regards,

Andy (DWG)

Isn’t that yet another good reason to revert all this?

Yes, but if the consensus of the community here is to “keep it and fix it” rather than “revert and start again” then that would be good also.

Fixing is one but maintaining and keeping up to date is another. I have not read that anyone feels responsible for this. And besides that I think we need at least more then one person feeling responsible.

If there are community members that are willing to fix and maintain please respond.

(NL : Zijn er mensen die dit willen fixen en bijhouden?)

Some?? I found 24091 of them with this overpass.

In my post #8 I made the suggestion to ArjanO that there was a simple way to update the wrong import (24091 nodes) in one step.
I also have a private mail exchange with ArjanO and he wrote he “would look after it” this weekend.
I also asked him to join the conversation here in the forum.

British understatement :slight_smile:

In principe wel, lokaal ben je het sterkst.

Zelf plaats ik wel verkeersborden vooral de C borden met onderborden, vaak ook met omschrijving tekst ( afwijkende teksten of landbouwverkeer etc.) van het verkeersbord/onderbord, dan weet ik op welke basis ik de weg zo heb getagd. Die C borden met forward en backward. Goed om te weten, waar het bord staat en in welke direction. Er zijn nogal wat C borden fout getagt in Openstreetmap. (begrijpelijk, soms moeilijk om de impact van het bord naar de routering te vertalen).

Ook lantaarnpalen, wanneer je de stoep in een dorp/stad tekent, dan is een lantaarnpaal een barrier voor blinde of slechtziende.
Overal kan je vraagtekens bij zetten waarom wel, waarom niet.

Hangt ook af van ontwikkeling in controle systemen.
Vergelijking bron dataset met data in openstreetmap.
Lantaarnpalen en de afstand tot elkaar. Is daar een methodiek in terug te vinden?
Wanneer te kort/ te ver bij elkaar een melding krijgen.
Vergelijking source met niet source palen.
Misschien is hier een overpass setup te maken.

Of een stap verder en dan kom je bij zulke initiatieven terecht.

En zo is het eigenlijk bij elke import, maar ook eigen data/reeds ingevoerde data, vergelijken met andere bron data sets.
Controlesysteem ontwikkeling.
Dit is een specialisme, die enkele van ons bezitten. Binnen de community hier meer aandacht aan geven zou welkom zijn. (scholing).
Ook hier tijd is vaak de beperkende factor.

Hetzelfde geldt ook voor bomen (natural=tree) en nog vele andere losse node tags, die allemaal eenzelfde type controle systeem kunnen gebruiken.

Dan wat betreft lit op de highway, hoe ga je als je lit zet dit met andere brondata controleren?
Waar begint de lit en waar houd de lit op knippen van de weg.
Want waar geen lantaarnpalen staan hoort er geen lit op de weg staan.
Hoe nauwkeurig wordt er getekend?

Ik had eerder al de - retorische - vraag gesteld: “Kan iemand mij vertellen wat voor zin het heeft om (alle?) lantaarnpalen te importeren?”.

Na enkele argumenten gelezen te hebben:
Neen de lantaarnpalen worden in geen enkele mij bekende algemene rendering gerenderd en laten we dat ik hemelsnaam ook niet gaan doen.
Het argument dat het van nut is in verband met sociale (on)veiligheid vind ik erg zwak en geldt bovendien alleen als de l.p.'s juist wel gerenderd worden en de dame met OSM op de GSM op pad gaat. Lijkt me zeer onwaarschijnlijk.

OSM is geen ruimtelijke database voor de gemeente om hun l.p’s, brandkranen, putdeksels duplicaat in te zetten (en dus te onderhouden). Daar hebben de gemeentes hun eigen database voor en de verantwoordelijkheid die te onderhouden. OSM is daar niet voor.

Het mappen van zitbankjes en prullenbakken als andere detailelementen (die worden wel gerenderd): zitbankjes is nuttig in bos en ander natuurgebied: al wandelend kun je besluiten om nog even door te lopen om de krentebollen te eten. In stedelijk gebied mappen van alle bankjes heeft niet zo veel zin - vind ik persoonlijk.

Ook prullenbakken: je gaat toch niet op zoek naar een OSM-prullenbak om het zakje van de krentenbollen in te deponeren?

En de massa-import van dergelijk spul legt de verantwoordelijkheid van het up-to-date houden bij de importeur, maar daar heeft hij of zij meestal zo’n zin niet meer in.

Maar ik kan het mis hebben natuurlijk…

Ik heb vandaag ArjanO nogmaals gevraagd om hier zijn standpunt uiteen te komen zetten.
Als hij niet reageert stel ik voor om dan maar het mislukte deel van zijn import (24000+ zinloze nodes) te verwijderen.

Mee eens…

Van mij mag deze data op zich in osm blijven, maar dan wel onder de voorwaarde dat zowel de technische als de procedurele fouten in deze import gerepareerd worden. Hiermee bedoel ik o.a. het aan leggen van documentatie, discussie met de community over de te gebruiken tags en het verwijderen van alles wat als ‘bad mapping’ gezien kan worden. Als ArjanO hier geen zin in heeft lijkt mij reverten de enige oplossing.

Wat mij betreft worden alle geïmporteerde lantaarnpalen weer verwijderd. Daarna kan alsnog worden besproken of, en zo ja hoe precies, de data in OSM geïmporteerd moet worden.
Er lijkt nu een situatie te ontstaan waarin “mechanical edits” niet volgens de richtlijnen plaatsvinden. Het immers veel makkelijker om zonder enig overleg de data gewoon te dumpen. In de praktijk is er niemand die een import terugdraait, dus waarom zou je ook overleggen.
Volgens mij is die praktijk ongewenst. Als de Nederlandse gemeenschap dit wel oké vindt, kunnen we de wiki aanpassen. Iets in de trant van: “Onbespoken mechanical edits zijn op papier verboden, maar worden in de praktijk vrijwel altijd gedoogd.”
Om toekomstige imports volgens de regels te laten verlopen, is het nodig de richtlijnen daadwerkelijk te handhaven.

Probleem is wel dat het terugdraaien van een (grootschalige) mechanical edit, formeel zelf ook weer een mechanical edit is. Daarvoor is dus ook weer overleg vooraf nodig. Het lijkt me het handigst om de DWG te vragen de import terug te draaien. Ik neem aan dat die zich in dit geval niet aan de richtlijnen voor een mechanical edit hoeven te houden.

Lijkt me trouwens nog best lastig om zo’n import terug te draaien. Sommige lantaarnpalen kunnen inmiddels (per ongeluk) verschoven zijn, die kun je gewoon wissen. Maar wat doe je bv. als iemand inmiddels een voetpad heeft toegevoegd, en daarbij een lantaarnpaal als node hergebruikt heeft? Hoe vind je die gevallen? Volgens mij krijg je zelfs geen conflictmelding, het versienummer van een node verandert vermoedelijk alleen als de node verplaatst wordt of andere tags krijgt.

In het geval er niet achteraf overeenstemming bereikt wordt over eventueel reparatiewerk lijkt me dat het beste. Maar aangezien ArjanO niets van zich laat horen lijkt hij het zelf ook niet zo’n punt te vinden. Of hij is even op vakantie en duikt straks weer enthousiast op om de boel te fixen…

Mocht dat voorkomen, dan kun je, ipv de nodes verwijderen, alle lantaarnpaal tags verwijderen en na een JOSM validatieslag alle unconnected nodes in 1x wegknikkeren. Nodes die onderdeel zijn van een voetpas of landuse blijven zo gehandhaafd.

http://demo.f4map.com/#lat=52.0863570&lon=5.1077668&zoom=18&camera.theta=78.232&camera.phi=22.345

Mooie toepassing, maar je kunt er ook mee zien dat er bij die import een flink deel mislukt is, want de Vleutenseweg staat vol met lantaarpalen, maar die zijn nu niet zichtbaar omdat de tag highway=street_lamp er niet bij staat:

http://demo.f4map.com/#lat=52.0937089&lon=5.1002210&zoom=17&camera.theta=50.901&camera.phi=38.675

I think we’ll take silence for a couple of weeks as a “no” :slight_smile:

My understanding from the comments above is that more people would prefer the the street lights were removed than would prefer that they stay - is that correct?

If so, would anyone like to volunteer to revert the import changesets, or would you like me to do it?

Wat mij betreft - zonder herhaling van alle bovenstaande argumenten - wordt de boel teruggezet. Ga je gang zou ik zeggen.