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: osm.org/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: osm.org/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: osm.org/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: osm.org/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:
osm.org/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 = osm.org/node/12215106381, meine = osm.org/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!

Da ist noch disused:shop=yes bei Moccali Bäckerei. Ich schreib's nur, weil das anscheinend öfters mal passiert. Grüße!

Hallo Tiwi! Du hast sehr viele Straßenlampen z.B. am Schenkelberg oder Winterberg hinzugefügt. Das ist toll! Nur die Positionen sind sehr oft sehr ungenau. Häufig sind sie um mehr als eine Häuserbreite verschoben. Oder diese hier steht mitten auf der Fahrbahn: osm.org/node/12214757122. Ich habe auf dem Schenkelberg schon viele korrigiert, vor Ort, aber das ist sehr mühsam und zeitaufwändig. Viele kann man eigentlich nur vor Ort genau platzieren, wobei du ja „source=survey“ im Änderungssatz angegeben hast. Deshalb versteh ich die großen Ungenauigkeiten nicht ganz ... Viele erkennt man auch gut auf Satellitenbildern, z.B. in JOSM (oft über ihren Schatten). Das seit einigen Monaten verfügbare „Saarland DOP20“ (JOSM) ist z.B. sehr präzise. Benutzt du das (oder andere wie Bing) nicht? Es wäre toll, wenn du auch deine Lampen nochmal nachchecken und besser positionieren könntest. Am besten natürlich vor Ort, oder wenigstens per Satellitenbild (da erkennt man aber auch nicht alle). Viele Grüße und frohes Mapping!

Hallo! Da hast du wohl aus Versehen ein street_cabinet auf die andere Straßenseite verschoben (osm.org/node/7695783614) ... Ich hab's gerade nochmal korrigiert! Ist mir durch Zufall vor Ort aufgefallen ... Viele Grüße!

Kleine Info: Bei der Buchhandlung Zeitlos (St. Arnual) hattest du vergessen, construction:shop=books zu entfernen/umzuwandeln. Ich hab's korrigiert ... Und noch Öffnungszeiten ergänzt. War gestern dort. Grüße!

Kleine Info: deine Änderung des Keys "side" in "sides" bei traffic sign Knoten war nicht korrekt ... Siehe osm.wiki/Key:side. Z.B. bei osm.org/node/263040422. Vielleicht checkst du solche Änderungen nochmal und machst sie rückgängig ...
Viele Grüße!