old_operator wirklich etabliert? Aber nirgends im Wiki zu finden? Also ich finde nichts, oder ich bin gerade etwas unfähig. Hab aber auch nur auf die Schnelle geschaut, weil mir das bisher noch nie begegnet ist. Jedenfalls gibt es keine Wiki-Seite, das würde ich dann nicht etabliert nennen ...

(Von einem old: lifecycle Präfix hab ich jetzt auch noch nichts gehört.)

Und wenn former: gut passt, würde ich es auch mal nehmen, auch wenn selten ... Aber was: tut es natürlich auch.

Noch ne kleine Info: von den derzeit 31 Verkehrzeichen im ganzen Saarland mit „274.1[30]" sind 27 von dir, alle in Duweiler. Die 4 anderen sind 6 Jahre alt und in Homburg.

Siehe http://overpass-turbo.eu/s/2aFQ.

Ich finde den Zusatz „[30]” auch deshalb ziemlich problematisch, weil Zusätze mit eckigen Klammern eigentlich nur dort angegeben werden, wo es verschiedene Werte (wie z.B. Texte, Zeitangaben usw.) auf Schildern geben kann. Hier würde das also heißen, dass es z.B. auch 274.1[20] oder 274.1[40] geben könnte für eine 20er-Zone oder 40er-Zone, was aber falsch ist (Bei einer 20er Zone ist die ID ja 274.1-20, und es gibt derzeit nur Schilder für 20er- und 30er-Zonen.)

Ich hoffe, ich konnte das nachvollziehbar erklären ...

Noch eine Anmerkung:
274.1-40 ist die ID für ein doppelseitiges Tempo-30-Schild (vorne 274.1 und hinten 274.2), und 274.1-41 das gleiche für eine 20er-Zone. Weiß nicht, ob du die kennst, diese IDs fehlen nämlich auf der Wikipedia-Seite https://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_der_Bundesrepublik_Deutschland_seit_2017 (sind aber im VZ-Katalog enthalten, also offizielle Nummern, und ich benutze die auch, wenn es zutrifft). Siehe https://www.bundesanzeiger.de/pub/publication/STbFAuLOL8Jnu8pV1JS/content/170411001079M003/BAnzAT29052017B802.pdf (Seite 11).

Noch was Kleines:
Ich hab noch einen Knoten in der Straße „Am Schwimmbad“, den du mit incline=12% und forward getaggt hattest, geändert (mit traffic_sign=DE:108-12); siehe node/13068316262. Und ich würde bei einem Verkehrszeichen auch nicht incline=12% hinzügen, nur am way der Straße – und hier muss es auch incline=-12% heißen, denn die Wegrichtung weist nach unten (hab ich jetzt auch noch geändert).

Viele Grüße und weiterhin frohes Verkehrszeichen-Mapping!

Hallo!

Hmm .. also für mich klingt das nur halb gut, bzw. eigentlich nicht ganz gut. Denn den Key old_operator kann ich im Wiki nicht finden, ist also eine undokumentierte Neu-Kreation (old_operator:wikidata natürlich ebenso). Das finde ich unschön (und nicht gerade ein typischer Fall von „Any Tags you like“), bei so einem wichtigen Tag).

Warum nicht lifecycle-Prefixes benutzen wie z.B. „former:operator=Post“ oder „was:operator=Post“? operator:signed=outdated würde dadurch eigentlich auch überflüssig/redundant, aber das fände ich auch noch OK, wenn an es so angeben will.

Grundsätzlich stellt sich mir aber auch noch die Frage, ob man operator nicht so angeben sollte, wie es halt an einem Objekt, z.B. einem street_cabinet, steht (das ist meine Praxis). Also wenn da „Post“ drauf steht, warum dann nicht operator=Post? Denn wie soll man entscheiden bzw. wissen, ob ein operator veraltet ist? Außer es ist vielleicht Allgemeinwissen oder sehr leicht herauszufinden (im Fall Telekom-Street-Cabinets + „Post“ kann man das vielleicht so sehen, in anderen Fällen wird es da schon schwieriger sein, z.B. Ferngas-Marker mit – auch alter, nicht mehr existierender Firma – operator=Steag. Wobei in dem Fall „Post“ auch auch klar sein sollte, dass operator=Post veraltet ist, aber es liefert die Information, dass es eben so am Objekt steht und dort – noch – nicht aktualisiert wurde).

Hallo nochmal! Bin gerade in Dudweiler.

Wegen node/13046300107 eine kleine Anmerkung: beim Verkehrszeichen DE:274.1 sollte man auf [30] verzichten, das erschwert die Auswertung. Das Tempo 30 ist durch die Nummer bereits eindeutig angegeben/definiert. Gleiches gilt für 274.2, 274.1-40, 274.1-20, 274.2-20, 274.1-41 (und andere Zeichen).

Mit Verkehrszeichen-Tagging hab ich mich sehr intensiv beschäftigt (auch ein Datastyling für JOSM erstellt, das ich mal veröffentlichen wollte, und Presets für Vespucci mit erweiterten Javascript-Funktionen...).

Viele Grüße!

Hallo! Hab grad durch Zufall gesehen, dass du in dem Changeset u.a. auch Recycling-Container in der St. Johanner Straße in Jägersfreude bearbeitet hast (Knoten 13092027623, 1348136543, 13092027622).

Find ich sehr gut, und du bist ja auch immer sehr gründlich und detailverliebt.

Nur ein paar Anmerkungen dazu, weil ich mir über diese Container, v.a. von ZKE, auch schon viele Gedanken gemacht hab, wie man die am besten taggt und was eher ungünstig ist.

Also: bei den Papiercontainer. würde ich recycling:cartons und recycling:paper_packaging entfernen, weil darunter auch beschichtete Verpackungen fallen (wie Tetra-Paks), die NICHT da rein gehören, sondern in die gelbe Tonne. Und es gibt noch keinen Wert für „unbeschichtete Papierverpackungen“ (wobei das für mich dann auch unter paper oder cardboard fällt). Und die ganze Spezialtags wie books/newspaper usw. würde ich auch entfernen, denn das ist durch paper schon abgedeckt und würde sonst kein Ende nehmen ... es gibt ziemlich viel aus Papier ... (wobei es natürlich auch kein Fehler ist). Ich setze jedoch nur recycling:paper=yes und recycling:cardboard=yes. Sowas wie Papiertapeten=no könnte noch sinnvoll sein ... Aber auch da würde es kein Ende nehmen (Kassenzettel=no, außer die blauen, usw.). Da wäre ja eher eine description mit den Einschränkungen sinnvoller ... Oder ein Link zur ZKE-Sortierhilfe: https://www.zke-sb.de/service/sortierhilfe (Suchbegriff z.B. Tetra oder Papier ...). Aber das hab ich mir bislang erspart.

Und bei den Glascontainter würde ich NUR recycling:glass_bottles=yes setzen und die ganzen recycling:xyz=no Tags entfernen (sonst könnte man da ja auch ALLES mit no aufführen, das macht für mich keinen Sinn). Die sind ja auch glaub ich nicht von dir. Höchstens recycling:glass=no könnte noch sinnvoll sein, weil ja z.B. kein Flachglas oder Trinkgläser mit anderer Glashärte da rein gehören. Evtl. auch recycling:plastic_bottles=no, wobei ich das auch überflüssig finde.

Und zum ZKE-Kleidercontainer: da würde ich wie du recycling:clothes=yes und recycling:shoes=yes setzen (bei anderen operators sind auch noch Sachen wie bags, belts oder Bettzeug etc. explizit angeben, bei ZKE glaub ich nicht). Und als Farbe finde ich da colour=mediumvioletred (aus dem Extended colour set; https://www.w3.org/TR/css-color-3/#svg-color) am passendsten. pink ist schon ziemlich anders (und ich mag die extended colour Werte ganz gerne, gegenüber HEX-Werten). Ich hatte vorher auch mal darkorchid, aber jetzt nicht mehr ... Wäre cool, wenn man das einheitlich hätte (nebenbei erwähnt: ich hab das in meinem Datastyling auch schon mit Extra-Icon drin ...). Aber natürlich kein Muss ...

Bei den Glascontainern benutze ich übrigens auch noch colour=gray und bei Papier gray oder darkgreen ...

Alles nur kleine, nicht extrem wichtige Details ... wollte es nur mal mitteilen.

Viele Grüße und frohes Mappen ...

Ich habe im Moment keine Energie für solche Forumsdiskussionen, tut mir leid.

Ich kann höchstens Fotos beisteuern der Fälle, die das Unausgegorene bei marker=aerial vs. marjer=post zeigen (insbesondere dann bei Detailtags wie colour + material), und die bei mir in der Region die Regel sind, insbesondere bei Ferngaspfosten. Solche Beispielfotos, die eben die Schwachstellen im derzeitigen Kategoriesierungskonzept und den Detailtags zeigen, und die wohl automatisch Fragen aufwerfen sollten, fehlen derzeit im Wiki (auch bei Wikimedia Commons gibt es kaum was Brauchbares, das meine Fälle in guter Qualität zeigt, ich könnte bald einige gute Fotos hinzufügen). Aber ich hoffe darauf, dass auch andere erkennen, dass es problematische Fälle gibt, und sowieso noch Verbesserungen stattfinden. Ich habe mich da eher auf langes Warten und Hoffen eingestellt ... Und suche mir solange Übergangslösungen. Mir fehlt wirklich mittlerweile meistens die Kraft und Ausdauer für die Forumsdiskussionen und die Art, wie sie sehr oft geführt werden. Von den Ergebnissen bzw. doch sehr oft Nicht-Ergebnissen ganz zu schweigen.

Kleine Anmerkung: ich bin jetzt erst auf diese Änderungen von dir gestoßen. Du hast wohl eine allemeine roof=yes „Säuberung“ durchgeführt in verschiedenen Gegenden (und noch anderen Changesets von 2023).

Das hier zumindest fällt eigentlich unter „mechanical edit“ (bitte mal nachlesen im Wiki; ich denke nicht, dass die Kriterien dafür hier erfüllt sind). Das Hauptproblem bei solchen Edits ist, dass man möglicherweise nicht an alles denkt, nicht alles auf dem Schirm hat ... und zu schnell schießt ... wie hier der Fall. Denn:

roof=yes war hier nicht sinnfrei. Es diente zur Unterscheidung von aerial markern mit einem vertikalen roten Rechteck (siehe z.B. osm.wiki/File:Gasmarker_Flugzeichen.jpg von solchen mit rotem Dach, z.B.: https://commons.wikimedia.org/wiki/File:Stegelitz_(M%C3%B6ckern)_-_HD37_W%C3%B6We1.jpg). Diese Information ist durch deine Löschung verloren gegangen. Ich hab die von dir geänderten Knoten aber jetzt nochmal überarbeitet mit anderen Tags (ATYL), weil ich weiß, dass alle diese marker ein rotes (Plastik-)Dach haben (und kein rotes Rechteck). Ich finde es wichtig bzw. schön, wenn diese Information mit dabei ist, denn es ist ja schon recht markant und ein großer Unterschied zu einem roten Rechteck für eine „aerial detection“.

Du hättest vor der Änderung vielleicht auch einfach mal nachfragen können ...

Viele Grüße + nix für ungut ...

Das Konzept bleibt schlecht und unausgereift, ich habe ja nun genügend detailliert erklärt, wozu es führt.

Briefkasten mit support=post ist eben gerade KEIN passender Vergleich.

Zeigt mir, dass du an einer ernsthaften Diskussion nicht interessiert bist.

In einen Briefkasten-Pfosten wirst du nur schwer einen Brief einwerfen können.

Aber diese Gaspfosten mit rotem Dach haben eine Doppelfunktion. Sie sind sowohl marker=post als auch marker=aerial (wenn überhaupt, siehe meine obige Abmerkungen).

Und sie sind meiner Meinung nach sogar MEHR marker=post als aerial, denn ihre Hauptfunktion dürfte sehr sicher die Erkennung vom Boden aus sein, auch die Details (ref, position) sind nur vom Boden aus ablesbar, nicht aus der Luft.

Das wird alles vom Konzept bei marker=aerial nicht berücksichtigt.

Noch eine Anmerkung wegen shape und warum ich mich dagegen entschieden habe: keiner der shape Werte würden für ein Dach passen. triangular_prism vielleicht am ehesten, jedoch ist es eben KEIN geschlossener 3D-Körper, wie z.B. ein boundary_stone mit einer solchen Form.

triangle würde meiner Meinung nach auch nicht passen. Und was soll man sonst nehmen? Und shape=roof (bzw. xyz:shape=roof) oder shape=gabled_roof widerspricht der Definition von shape (Werte sollen 2- oder 3-dimensionale Formen beschreiben).

Der alte, unpopulär gewordene Zusatztag roof=yes hatte meiner Meinung durchaus seine Berechtigung (er drückt auch aus, dass ein Dach eher ein ZUSATZ ist zu einem eher zutreffenden marker=post). Den gab es lange für pipeline=marker und hält sich bis heute, ich habe ihn kürzlich erstmals auch bei marker=aerial als roof=no gesehen, was mich auch etwas verblüfft hat. Vielleicht ein marker mit rotem, vertikalem Rechteck (man weiß es nicht, weil Tags wie die von mir benutzten fehlen)? Vielleicht wollte der User das damit ausdrücken bzw. fand es ausdrückenswert, dass dieser aerial-Marker KEIN Dach hat (sondern was anderes – aber ohne anzugeben, was; eine note wäre z.B. eine Notlösung) und fand keine bessere Möglichkeit ... Was auch nachvollziehbar ist.

Beispiel: node/12744244560

Diese Beispiele alleine zeigen doch schon, wie unausgereift und verbesserungswürdig das gesamte Konzept bei marker=aerial ist ... Das ist nicht zuende gedacht worden, es führt zu Verwirrung und uneinheitlichem und nicht klar interpretierbarem Tagging in der Praxis, das ist bei dem schlechten Konzept schon fast unausweichlich.

Ganz davon abgesehen fängt das Problem für mich schon bei der Frage an, ob man solche Marker (z.B. mit rotem, verikalem Rechteck) überhaupt als aerial marker ansehen kann. Ist gesichert, dass so ein rotes Rechteck einer Detektion aus der Luft dient??? Oder nur der besseren Erkennbarkeit vom Boden aus. Denn sehr häufig stehen so ausgestattete Marker unter dichten Bäumen oder mitten in dichtem Gestrüpp, und sind sehr wahrscheinlich mit der besten Luftbeobachtung vom oben nicht zu sehen, höchstens vielleicht im Winter, wenn die Bäume kein Laub haben. Aber das nur am Rande und als Ergänzung.

Das sehe ich anders.

Material sollte das Material des GESAMTEN Objekts beschreiben, das getaggt ist, dann wäre metal;plastic nötig, und man weiß nicht mehr, was plastic, was metal ist. Ich finde es so präziser und eindeutiger. Und werde diese Tags solange benutzen (ANY TAGS YOU LIKE!) bis es eine saubere, allgemeine Lösung gibt. Dann kann man es ggf. leicht anpassen.

An shape hatte ich auch gedacht, aber das fand ich auch schwierig. Was soll man für ein rotes Dach als shape nehmen? triangualar_prism? Und bei "rectangular" fehlt mir die vertikale Anbringung.

Ich finde diese Pfosten mit Dach oder vertikalem rotem Rechteck eh schwierig als “aerial”, dann es sind eigentlich eher marker=post mit einem „aerial Zusatz“, und die dominierende Farbe ist Gelb, nicht Rot des Dachs (Gelb als Symbilfarbe für Gas). Daher sträubt sich in mir alles, hier colour=red zu setzen, während absolut identisch aussehende Pfosten (häufig nicht weit entfernt) ohne Dach colour=yellow bekommen.

Das ist meiner Meinung nach sehr schlecht gelöst im Wiki für marker=aerial. Andere User scheinen damit auch Probleme zu haben, denn ich hab neu getaggte Pfosten (marker=aerial) mit rotem Dach gesehen, die colour=yellow haben. Beispiel: node/12744247704

Es gibt ja auch eine Regel, nach der ein Tag den ÜBERWIEGENDEN oder dominierenden Teil eines Merkmals abbilden soll (so hat es wohl der User beim Beispiel davor gemacht!), wenn ein Weg mit surface=paving_stones z.B. eine kleine asphaltierte Stelle hat, würde ich trotzdem surface=paving_stones setzen (bei nicht klar dominanten, gemischten Oberflächen eher paved).

Hier wäre wie bei material meiner Meinung nach eigentlich colour=red;yellow korrekt, oder eher colour=yellow, wenn man das Dominierende taggen will, als colour=red.

Und wenn man genauer angeben will, welcher Teil welche Farbe resp. Material hat, kann man das mit Detailtags, auch support:colour, support:material tun, das ist mein Standpunkt.

Daher werde ich die Tags weiter benutzen, sie tun ja auch keinem weh. Any tags you like ....

Und es erleichtert z.B. ein präzises DataStyling (z.B. mit verschiedenen Icons) enorm. Bei colour=red könnte wohl niemand sagen, ob nun der gesamte Pfosten rot ist (es gibt solche roten Pfosten bei utility=power, die identisch wie die gelben Gaspfosten aussehen!), bei colour=yellow umgekehrt das Gleiche.

Ich finde eine Wiki-Definition, die Farbe oder Material nur für einen TEIL eines Objekts definiert, völlig unintuitiv und faktisch falsch. Bei amenity=bench gibt es z.B. das gleiche Dilemma. Schnell wird colour oder material bei solchen Definition zu skunked Tags, weil User in der Praxis sich nicht nach solchen willkürlichen, unintuitiven Definitionen richten. Detailtags sind für mich da der einzige saubere, klare Weg.

Wie es sich z.B. auch für highway=crossing mehr und mehr durchsetzt (z.B. mit crossing:markings=* und crossing:signals=*).

What's your problem with this tag?

I want to express what the tag expresses (it has a red roof). I know, this is an old tag (it was in the wiki at pipeline=marker), now undocumented at marker=*, but I saw it in use with markers, and there is no good alternative so far (IMO it's NOT a marker=aerial, because there is nothing written on the roof, although the roof may be for an aerial detection, but I'm not sure – it may also be a weather protection for the post or to better see it from the ground – some of these poles only have a red vertical rectangle instead of such a roof, then I don't tag this with roof=yes). The appropriate tag is definitely maker=pole, you can only see the plate with the information from the ground.

Anyway, I still use it for these cases (ATYL!), because it is very noticeable on such a post.

Here is an example (not in my region, but it's the same): https://commons.wikimedia.org/wiki/File:Stegelitz_(M%C3%B6ckern)_-_HD37_W%C3%B6We1.jpg

Oder hast du opening_hours:signed=no nur aus Versehen entfernt? Habe nämlich gerade gesehen, dass du auch check_date:opening_hours=2023-01-21 hinzugefügt hast – das war der Tag, an dem ich opening_hours:signed=no hinzugefügt hatte.
Vielleicht kannst du es dir mal anschauen ...

Grüße!

Hallo! Du hast z.B. hier: node/6422000217 opening_hours:signed=no entfernt. Bist du dir da sicher? Ich hatte das 2023 hinzugefügt und bin bei sowas eigentlich immer sehr gründlich.

Kann natürlich sein, dass dort mittlerweile Offnungszeiten dran stehen. Aber wieso hast du sie dann nicht auch hinzugefügt? Kann ich nicht ganz verstehen ...
Viele Grüße.

Hello! You disconnected 2 street_sid3 parkings from the road. This is a bad idea. Then there is no access to the parking (routing!). Street_side parking areas should be connected with the street ... Or you have to add driveways, which is worse than connecting them to the street. I hope you agree ... Thank you!

Hi! Wie kommst du dazu, bei diesem Überweg surface=asphalt in paving_stones zu ändern: way/111324818? Ist definitiv asphalt (wie die ganze Bleichstraße). Ich ändere es nochmal ... Aber bitte aufpassen bei so Microtagging-Sachen ... merci! Und Grüße!

Hallo! Bitte nächstes Mal nicht wheelchair=yes/no/... entfernen, wenn ein Shop auf disused:shop geändert wird. Das ändert sich ja i.d.R. nicht durch das disused ... Sonst wird es vielleicht vergessen, es wieder hinzuzufügen, wenn der Shop wieder öffnet ...

Siehe:
node/3319986952/history

DANKE! Und Grüßen!

Wie gesagt: man kann es grob ermitteln anhand der Luftbilder (und es dann in einer note vermerken, dass es nicht präzise ist). Man könnte natürlich auch nur einen Knoten in die Mitte setzen, auch wenn das etwas witzlos ist ...

Könnte dir auch ein altes Foto von mir von 2022-08 schicken, da sieht man zumindest an einer Seite, wo die Grube anfängt. Und es scheinen ja auch 2 unterirdische Etagen zu sein, wobei die Tiefgarage wahrscheinlich v.a. 1. UG ist, denn darunter wurden kleinere Räume gebaut, vielleicht Technik- oder Kellerräume. Vielleicht geht die Tiefgarage aber auch über 2 Etagen ... Keine Ahnung.

Hallo FahRadler!

Wir waren wohl beide gestern/vorgestern an den Großherzog-Friedrich-Höfen aktiv und es hat sich etwas überschnitten. Ich war gestern (30.03.) dort, und vorher ein paar Mal im Februar, daher kenne ich die Fläche ganz gut. Ich habe die Gebäude noch etwas präzisiert (man sieht die Umrisse schon einigermaßen auf Bing bzw. ein paar Details vor Ort gecheckt). Ist wahrscheinlich immer noch nicht perfekt.

Was ich insbesondere anmerken wollte: du hast in diesem Änderungssatz die Fläche der Großherzog-Friedrich-Höfe, die davor landuse=construction hatte, zu amenity=parking (underground) geändert. Ich hab das wieder geändert, und zwar zu landuse=residential und die parking-Tags entfernt (und landuse-Flächen in dem Gebiet gerade eben insgesamt aktualisiert; das Ganze war noch von EINER landuse=commercial-Fläche umgeben). Erstens, weil sonst nur die Tiefgarage „Großherzog-Friedrich-Höfe“ heißen würde, und zweitens, weil ich sehr sicher bin, dass da zwar die (soweit ich weiß) größte Tiefgarage in Saarbrücken entstanden ist, die aber trotzdem (auch soweit ich weiß) nicht die GESAMTE Fläche der Großherzog-Friedrich-Höfe umfasst (z.B. wohl nicht die Ein-/Ausfahrtbereiche im Neugäßchen oder dort, wo Großherzog-Friedrich-Straße 51 ist, etc.) Man kann es aktuell noch auf Bing oder Mapbox erahnen (z.B. wo Baustellenfahrzeuge stehen), oder wenn man vorher mal das tiefe Loch gesehen hat. Ich hab davon auch noch mind. ein Foto.

Falls du Genaueres weißt über die Ausmaße der Tiefgarage, dann trag sie doch bitte gesondert nochmal ein (am besten mit layer=-1 denke ich). Hoffe, das ist so OK für dich. Ansonsten weiterhin frohes Mapping und weitere Verbesserungen dort ... da gibt es sicher noch so einiges ... Grüße!

Hallo .... das war allerdings auch immer nur sporadisch geöffnet, nicht regelmäßig ... Viele Jahre kann das glaub ich nicht her sein.

Den Knoten zu löschen ist allerdings nicht ganz so toll ... besser wäre es, disused:amenity=restaurant zu verwenden (mit old_name=Die konkrete Utopie), damit er weiter verwendet werden kann, falls mal was Neues reinkommt ... Das ist eigentlich üblich in solchen Fällen (es sei denn, die Räume wurden z.B. in eine Wohnung umgewandelt oder Ähnliches ...).

Ich stelle ihn daher vielleicht nochmal her – oder du könntest das machen, z.B. mit JOSM ...

Viele Grüße!

Hallo Tiwi! Ich hatte dir ja schon mal geschrieben in einem Änderungssatz wegen street_lamps (ohne Antwort?) ... ich stoße auf immer mehr Unsauberkeiten und Fehler ...

Ich würde dich wirklich bitten, deine Eintragungen nochmal zu überprüfen.

Gerade sah ich z.B., dass du auf dem Möbel Martin Parkplatz an der Ostspange in diesem Änderungssatz (Okt. 2024) Lampen gemappt hast, genau an Stellen, wo ich auch schon Lampen eingetragen hatte – und zwar im Juni 2024, also vor dir. Jetzt sind da 2 Lampen im Abstand von 2,5 m ... Und da ist definitiv nur EINE (meine ist denke ich genauer platziert, ich hab das vor Ort gemacht).

Also das ist nur nicht nur einmal so, sondern an mehreren Stellen, z.B.: deine = node/12215106381, meine = node/11967449929.

Und du hast sie als bent_mast eingetragen, ich als straight_mast. Und die sind auch nicht gebogen .... es sind gerade Masten, an den 10 Lampen befestigt sind.

Wenn schon Microtagging, dann doch bitte auch ganz präzise (Merkmale + Position + nix doppelt eintragen), das wäre wirklich super ... denn das alles zu checken und zu korrigieren ist eine Mörderarbeit ...

Eine Rückmeldung wäre auch mal nett ... Z.B. mit Infos, wie du das mappst.(Wirklich vor Ort wie es dein source=survey aussagt? Denn dann verstehe ich vieles nicht.)

Ich habe jetzt schon viele deiner Lampen korrigiert, z.B. zuletzt an der Ostspange im Kreisel (da waren sie z.B. VOR der bereits eingezeichneten Leitplanke platziert, sie stehen aber DAHINTER!), am Winterberg, Schenkelberg, Theodor-Heuss-Straße usw. Aber du hast ja anscheinend an sehr vielen Stellen welche eingetragen ... man kommt da kaum nach.

Wäre schön, wenn du dich beteiligen würdest am Verbessern – wie schon gesagt: am besten vor Ort und mit eingeschalteten Satellitenbild (ich empfehle: „Saarland DOP20“; kann man z.B. auch für Vespucci vor Ort manuell hinzufügen; oder in JOSM ist es bereits in der Imagery-Liste). Und Orientierung an bereits gemappten Objekten ...

Viele Grüße!