OpenStreetMap
goodidea's Comments
| Changeset | When | Comment |
|---|---|---|
| 184419905 | Hallo! Bedauerlich, dass es keine Antwort mehr gab. Ich hab es daher nun wie angekündigt geändert, also den altem Umrissweg way/111498101 an deinen neuen Weg way/1531349092 (name=Diskontopassage BVK-zugeöhrig) angepasst und 1531349092 dann gelöscht. (Anpassungen = Weglassen der beiden Rolltreppenbereiche in der Bahnhofstraße und von 3 Treppenbereichen am Gebäude Bahnhofstraße 32/Ecke Betzenstraße und vor Gebäude Bahnhofstraße 34/36). Außerdem operator=BVK – Bayerische Versorgungskammer und owner=BVK – Bayerische Versorgungskammer etc. hinzugefügt. Der alte, ursprüngliche Umriss-Weg way/111498101 sollte dem gelöschten Weg way/1531349092 nun entsprechen, mit einer Ausnahme: die Fläche vom Martinshof (Indoor-Raum way/574644597) hat bei 1531349092 gefehlt, die habe ich aber in 111498101 drin gelassen – meines Wissens nach gehört das zur Diskontopassage und ich vermute stark auch zur BVK. Hoffe, dass dies dann hiermit erledigt ist. |
|
| 186026186 | Ich hab es revertiert. Siehe meine Anmerkungen und Feedback zu diesem und weiteren Reverts in changeset/185673805. Denke, das sollte dann jetzt erledigt sein. |
|
| 185673805 | Also ich hab es jetzt doch alles erledigt, wollte es auch hinter mich bringen. Hat 3 Stunden gedauert (aber auch noch ein paar andere Sachen geändert/korrigiert dabei, die der JOSM Validator gemeldet hat). Hier meine Rückmeldungen zu den Reverts: • Ich habe mit 186083738 angefangen (weil von hinten nach vorne, also von neustem zu ältestem changeset am sinnvollsten ist). Da gab es keine Konflikte.
Mein Eindruck: es sind oft ähnliche Tags, die da problematisch waren. Siehst du ja selbst … Und ich bleibe bei meinem Standpunkt: JOSM ist der leistungsfähigste und mächtigste Editor und besonders für komplexe Änderungen zu empfehlen. Wenn ID da nichts gemeldet hat, sagt das ja genug aus. Noch ein Grundsatzgedanke zum Mergen: selbst wenn Tags 100% übereinstimmen, ein Mergen also nichts „kaputt“ macht, gibt es Situationen, wo ich darauf verzichten würde. Beispiel: 2 sidewalk footways, aber von 2 verschiedenen Straßen (siehe etwa hier: way/1307361053 + way/239069206). Grund: hier könnten z.B. noch weitere Detail-Tags wie etwa paving_stones:shape etc. hinzukommen, was sich erfahrungsgemäß gerade bei 2 verschiedenen Straßen häufig unterscheidet. Dann müsste also jemand den gemergten Weg wieder splitten, und die neue Splittung hätte nicht die History eines Teils von vorher). Das passt zu dem, was ich bereits zum Mergen geschrieben hatte: es ist eher nur recht selten wirklich gerechtfertigt, es gibt sehr viel zu beachten und zu bedenken, man sollte sich auch nicht nur nach rein merge-technischen Faktoren entscheiden (oder ob ein Editor was anmeckert oder nicht), sondern auch Überlegungen wie diese miteinbeziehen. Nach meiner wirklich langjährigen Erfahrung (und ich habe auch schon öfters mal was gemerged) lohnt es sich nur sehr selten, sich die Mühe zu machen und man vergisst/übersieht einfach zu leicht irgendetwas (was sich vorherige Mapper vielleicht beim Splitten oder eben bewussten Nicht-Mergen gedacht haben). Das gilt eigentlich generell für alle „Aufräumarbeiten“ bei OSM … Und ich hab dabei auch schon Dinge übersehen und es im Nachhinein bereut – schreibe das nicht einfach so oder gar als Belehrung. Will bloß meine Erfahrungen weitergeben. Daher merge ich zum Beispiel nur noch selten und wenn es wirklich 200% klar ist und am besten auch, wenn ich direkt vor Ort bin und die Situation vor Augen habe). Viele Grüße und weiterhin frohes und ungetrübtes Mappen! |
|
| 183772915 | Hallo unique_identifier! Gerade durch Zufall gesehen, dass du in Scheidt ein Verkehrszeichen, die ich mal getaggt hatte, geändert hast. Und zwar das hier: node/1020924408 • Mein Tagging: DE:274.1-40;357
Mein Tagging war aber korrekt. 274.1-40 ist die ID für ein doppelseitiges Verkehrszeichen (DE:274.1 + DE:274.2). Siehe im offiziellen VZ-Katalog. Diese Nummern für doppelseitige Zeichen sind offizielle Nummern, fehlen aber auf der Wikipedia-Seite der Verkehrszeichen (es gibt einige davon, nicht nur für Tempo 30-Zone; das wollte ich irgendwann auch mal ergänzen). Siehe https://www.verwaltungsvorschriften-im-internet.de/pdf/BMVBW-S32-0001-KF10-BS-A003.pdf, Seite 13. Ich hab mich seit Jahren sehr intensiv mit Verkehrszeichen beschäftigt, bin auch an der Überarbeitung der Wikipedia-Seite beteiligt (und derzeit auch noch dabei, dort Dinge zu korrigieren und zu ergänzen). Also falls du VZ-Taggings von mir siehst: ich würde mal vorsichtig wagen zu behaupten, da dürfte nur rel. selten was falsch sein, zumindest nicht bei neueren Taggings (obwohl ich auch Fehler mache, klar). Und die ID 274.1-30 gibt es zudem auch nicht (nur 274.1, das ist schon Tempo 30-Zone). Ich hab es an ein paar Stellen in Scheidt jetzt geändert, aber nicht alles gecheckt. Ich denke, man sollte immer die offiziellen IDs verwenden ohne falsche Zusätze (ich weiß, dass einige Tools es auch anders anzeigen – ich halte das aber für falsch). Ich hab es daher wieder geändert. Auch dies hier noch korrigiert (auch durch Zufall gesehen): node/13917073142 (DE:250,1026-38 statt DE:250,DE:1026-38). „DE:“ immer nur 1x am Anfang ... Viele Grüße! |
|
| 185673805 | Ich versuche jetzt mal damit anzufangen und schaue, ob es einfach oder schwierig wird. Danke für die Nummern, ein gute Hilfe. Ich schreibe dir dann, was erledigt ist, damit wir nichts doppelt machen oder so ... Und geb dir eine Rückmeldung, wenn Probleme aufgetreten sind. Ich würde dann vielleicht am WE oder die nächsten Tage weiter machen, alles schaffe ich heute bestimmt nicht (vielleicht eins davon). Außer es ist sehr unproblematisch (was ich aber leider nicht erwarte). |
|
| 184715766 | Also du machst merkwürdige Kommentare für meinen Geschmack. Was heißt „Das 3D Modell vom Gebäude war komplett kaputt“? Es war vielleicht noch unvollständig, aber das ist etwas ganz ganz anderes als „kaputt“ (sondern völlig normal auf OSM – es wird eben nach und nach ergänzt). Ich hatte am 08.08.2024 nur zwei building:parts vor Ort eingezeichnet (mit Vespucci – die waren geometisch auch noch nicht perfekt), um die Eingänge dort korrekt positionieren zu können(node/12098199424 und node/12098197451) und weil mein Fokus DARAUF lag, nicht am 3D-Modell des Gebäudes. Nur zur Erklärung … Aber wenn ich schon einen building:part hinzufüge, versuche ich ihn mit möglichst vielen relevanten Tags zu versehen. (wobei da immer noch was fehlen kann = OSM-Normalfall, s.o.). Weiß auch nicht, wie du zu deiner Bemerkung kommst „min_level=1 wäre aber ohnehin falsch an der Stelle, da der building:part kein vollständiges Gebäudegeschoss/raum umfasst.“ Wenn nur in diesem Bereich das erste Geschoss level 1 ist, dann ist das so und korrekt, auch wenn es keinen kompletten Raum umfasst. Wie soll man es sonst taggen? Und zum Titel deines changesets („Fix simple 3D model of building“): da will ich mich nun auch nicht mit dir streiten, du hast da sicher einiges Sinnvolles ergänzt und es besser gemacht als vorher aber teilweise (nach meiner Meinung) auch was „kaputt“ gemacht, was vorher OK war. Und jetzt musste ich es mir natürlich genauer anschauen, um möglichst nichts Falsches zu schreiben (falls doch, dann entschuldige das bitte anstatt dich gleich aufzuregen). Und ich finde einiges nicht korrekt: so gibt es jetzt Überlappungen von building:parts mit sich wiedersprechenden Angaben (z.B. an den Gebäudeecken building:levels=3 und building:levels=4 im Überlappungsbereich). Und ich wundere mich auch gerade über deine Verwendung von building:min_level. Bist du wirklich sicher, dass du da alles korrekt gemacht hast? building:min_level bedeutet ja ausgelassene levels (also wenn eine Gebäude z.B. auf Stützen steht oder Teile davon erst im 1. Geschoss oder noch weiter oben anfangen etc.). Den building:part in der Mitte (way/1533104965) hast du jetzt z.B mit building:levels=4 + building:min_level=4 getaggt. Ich kenne das Gebäude nicht von innen – das würde heißen, da ist oben nur das Dach, also so was wie ein Lichthof? Noch merkwürdiger der große building:part way/1533104964 mit building:levels=4 + building:min_level=3 – würde bedeuten, dass es dort nur ein 4. Stockwerk gibt und 3 darunter ausgelassen sind. Das kann ja eigentlich nicht sein – wäre scon SEHR speziell. Dieser Teil hat glaube ich 4 Stockwerke, und drumherum erstreckt sich ein Bereich mit nur 3 Stockwerken (der sich durch 2 building:parts abbilden lassen würde, aber die sehe ich da jetzt auch nicht – oder sollte es dies hier sein: way/1533104963?). Wenn ich nichts falsch gesehen habe, scheinen die ja alle von dir zu sein (wenn auch an verschiedenen Tagen hinzugefügt, d.h. nicht alles in diesem changeset – z.B. einige Teile am 28.06.). Also ich will jetzt nicht noch mehr Zeit in diese Analyse stecken (war schon viel ...) und mein Fazit wäre: deine Bearbeitungen waren Schritte weiter in Richtung „sauberes 3D-Modell etc.“, aber dein changeset-Commentar etwas zu euphemistisch (sowas wie „Optimized simple 3D model of building“ hätte es besser getroffen), daher sei bitte offen für gerechtfertigte Kritik ... Um es wirklich zu fixen und sauber zu machen, wäre wohl noch (mindestens) ein weiterer Arbeitsschritt notwendig, wo man die building:parts wirklich sauber anlegt, wenn möglich (?) sogar ohne Überlappungen, denn bei „Simple 3D Building“ heißt es ja auch: „avoid overlapping 3D volumes“ (auch wenn überlappende building:parts wohl OK zu sein scheinen – ich denke es ist so gemeint, dass sie sich aber nicht bei den Angaben der 3D „Volumen“ widersprechen sollten, sondern vielleicht in anderem, was für 3D irrelevant ist, sonst kann es natürlich nicht eindeutig gerendert werden, klar …). Also v.a. die building:levels, building:min_levels etc. sind da wohl wichtig zu beachten (und das stimmt derzeit definitiv noch nicht). Ich mach da aber jetzt nichts dran – denke, das ist dein Projekt … gutes Gelingen und weiterhin viele Grüße und wenig Aufregung – ich habe darauf auch keine Lust ... |
|
| 184717151 | Also ich werde mich jetzt hier nicht auf eine Diskussion einlassen, wer hier Profi ist und wer nicht – was sind das bitte für Formulierungen? Also das ist wirklich auch ein merkwürdiges Diskussionsniveau. Siehe auch meine Anmerkungen in changeset changeset/184749336, auch zu Ausrichtung von Saarland DOP20. Wenn ein Gebäude nicht sauber ist, dann sollte man es auch so benennen dürfen, das nennt man Kritik (die das Ziel hat, konstruktiv zu sein, nicht wertend und nicht böse gemeint). Auch hier ähnlich wie Trierer Straße 11 bis 15: die Geometrie dieses Gebäudes (Saarbrücker Straße 245) ist unsauber. Und das war hier vorher definitv besser (wenn auch noch nicht perfekt, s.u.). Müssen wir da wirklich ins Details gehen? Das würde ich mir eigentlich gerne sparen. Schau es dir einfach genauer an … Nur als Beispiel: die 3 Punkte vorne (1418370331, 13971265773, 13398314413) bilden keine gerade Linie. 13971265773 ist nicht genau in der Mitte der anderen beiden, was bei dem Fußweg ja wohl eigentlich so sein müsste. Punkt 13398314413 war vorher definitiv besser positioniert (nach Saarland DOP20). Der vordere Eingang (node/12098199475) ist nicht mit dem building:part dort verbunden. Dein Kommentar „Die Entrance Knoten entlang von Sidewalks werden hier meist nicht mit der Sidewalk verknüpft; siehe der gesamte Rest der Stadt. Wenn du magst kann ich für dich diesen einen verknüpfen.“ ist für mich völlig unverständlich – ich hab mich anscheinend zu unklar ausgedrückt, was ich meine. Es war nicht die Rede von Verbindung mit sidewalk-Weg (du kannst auch sicher sein, dass ich weiß, wie sowas normalerweise gemacht wird – auch wenn es da keine strenge Regel gibt), sondern mit dem Weg des building:parts ... Hoffe, das ist jetzt klar geworden. JOSM zeigt immer zwei „+“-Markierungen in der Mitte von Wegpunkten an, daran erkennt man das schnell. Keine Ahnung, ob ID da genauso gut ist – ich zweifle aber etwas dran. Sonst wäre es dir vielleicht auch gleich aufgefallen. Der vordere, südlichste Eckpunkt des Gebäudes (node/10711128420) könnte auch besser nach Saarland DOP20 positioniert werden (war aber auch vorher schon nicht optimal nach meiner Bearbeitung 25.12.2025 – die Gebäude 243 und 245 scheinen da eine schräge Wand zu haben). Er müsste wohl noch weiter Richtung Süden. DIe Gebäude Trierer Straße 1 und Saarbrücker Straße 245 (und 243) sind aber auch ziemlich speziell und schwierig – z.B. wie Trierer Straße 1 sich an Saarbrücker Straße 245 anfügt (schräge Wand?). Ich erinnere mich gut, dass ich 2025 extra vor Ort war, um mir das anzuschauen, aber selbst dann wird man nicht so 200% schlau draus. Ich glaube aber (weil ich gelernt habe, dass man sich i.d.R. sehr auf Saarland DOP20 verlassen kann), dass die Wand da nicht schräg sein dürfte – also von Punkt 12098199468 zu Punkt 10711128415. Ich hatte das damals dann aber auch so gelassen, weiß nicht mehr genau, warum. Wohl weil es auch vor Ort nicht ganz klar wurde. Das mit building:parts und 3D-Rendering ist geschenkt – wenn Renderer das brauchen, um es sauber zu rendern, kann man das machen. Eigentlich sollten sie es aber auch ohne redundante building:parts schaffen … Wir taggen eigentlich in der Regel nicht für Renderer und vermeiden Redundanzen. Aber du hast Recht: auf der Seite für Simple 3D Buildings wird empfohlen, das ganze Gebäude mit building:parts zu versehen (die sich nicht überlappen sollten, was aber leider auch realitätsfern ist und sich manchmal kaum vermeiden lässt, sofern man nicht eine Vielzahl von building:parts kreiieren will, was bei komplexen Gebäuden dann völlig unübersichtlich wird und kaum noch menschlich wartbar – dann sind nachfolgende Fehler bei weiteren Änderungen vorprogrammiert). Die 3D-Renderer sollten da besser damit umgehen lernen, das würde ich da für den einzig sinnvollen Weg halten … aber das ist nun wirklich ziemlich Off-Topic hier. |
|
| 184749336 | Lass uns bitte nicht über guten Ton streiten ... ich habe versucht, es sachlich darzustellen, es war nichts davon erniedrigend und sollte es schon gar nicht sein – bitte nicht überreagieren. Ich finde das auch nicht OK, dass du da solche Formulierungen bemühst. Ich hatte auch extra erklärt, warum ich etwas frustriert war. So viel zu schreiben, macht mir auch keine große Freude, aber dass ich mir die Mühe mache, könntest du auch etwas mehr honorieren, wenn wir hier schon bei „Stilfragen“ sind ... Das wäre auch mal schön, sowas als Reaktion zu kriegen statt deiner Reaktion. Aber ich habe wirklich schon viele viele Stunden mit Geometrie in Dudweiler und Jägersfreude verbracht (z.B. Im Dezember 2025). In der Trierer Straße hatte ich mal was an Hausnummer 11 und 13 gemacht, aber noch nicht an 15. Also ich hab es jetzt mal so korrigiert, wie ich mir saubere Geometrie vorstellen (alle 3 Gebäude). So sieht man z.B. auf Saarland DOP20 ziemlich gut, dass Gebäude HN 11 und HN 15 vorne noch einen kleinen Vorsprung haben – den hattest du aber auch nicht abgebildet bei deiner Geometrieänderung. Lässt man sowas weg, stimmt es leider insgesamt nicht. Und die Rückseite aller 3 Gebäude verläuft wohl schief (wie öfters mal), es ist also nicht alles rechtwinklig (das hattest du auch so gemacht und war OK, ich hab es bloß noch leicht präzisiert jetzt). Und mein Saarland DOP20 ist ganz gewiss sehr korrekt ausgerichtet (da muss man eigentlich auch so gut wie nie was dran korrigieren). Da brauchst du dir keine Gedanken zu machen. |
|
| 182748919 | Hallo brotmann! Kleine Anmerkung: ich habe den alten Knoten node/927778901 wiederhergestellt und „Kirche die bewegt“ damit getaggt. Denn das ist eigentlich das übliche Vorgehen, wenn an einem Ort etwas Neues eröffnet, wo vorher bereits etwas war. Deshalb behält man dort ja auch einen Knoten (hier mit „disused:shop=yes“, weil es vorher ein Geschäft war.) Denn die „History“ z.B. eines Knotens sollte erhalten bleiben (auch bei einer Umnutzung) … ist jedenfalls schön. Und der Ehemals-Muhlke-Knoten ist immerhin von 2010! Und „Kirche die bewegt“ klein geschrieben, auch wenn es vor Ort großgeschrieben da steht (ich war gestern aich dort vor Ort) – das ist ein Grundprinzip bei OSM-Namen (keine Großbuchstaben bei Namen, selbst wenn sich etwas üblicherweise so schreibt). Hoffe, das ist OK so. Ansonsten alle getaggten Angaben von dir übernommen. Und jetzt ist auch wieder level=0 dabei (= Erdgeschoss) … oder erstreckt es sich über mehr als das Erdgeschoss? – Dann könnte man z.B. auch level=0;1 angeben. Viele Grüße! |
|
| 184421459 | Gibt es noch eine Antwort hierzu? Ich würde das gerne mal erledigen, damit ich es von der To-Do-Liste streichen kann ... Ich warte jetzt mal noch eine Woche, wenn ich bis dahin nichts höre, ändere ich es nach meinem Ermessen. Viele Grüße! |
|
| 184419905 | Gibt es hierzu noch irgendeine Antwort? Wäre freundlich gewesen (meine letzte Nachricht ist jetzt über 1 Monat alt). Zum Beispiel Fragen beantworten – die stellt man ja nicht umsonst. Also ich würde sagen, ich warte jetzt mal noch 1 Woche, und dann ändere ich es nach meinem Ermessen. Interessiert hätte mich z.B. schon, ob denn z.B. die Rolltreppen (und die Häuschen darüber?) nicht zur Diskontopassage gehören und somit nicht Eigentum der BVK sind (sondern Stadt Saarbrücken nehme ich dann an) ... Also wer macht da oben z.B. die Schilder dran, dass man da keine Fahrräder am Geländer mehr absperren darf – ich hatte da ja auf die BVK getippt? Viele Grüße ... und ich hoffe noch auf eine Antwort ... |
|
| 184715766 | Hiiiillfe!!! Wieso hast du hier z.B. min_level=1 gelöscht? Das gehört nicht zum 3D-Tagging, sondern zu „Simple Indoor Tagging“! Bedeutet, dass die erste Etage nicht 0, sondern 1 ist. Das ist also kein „Fix simple 3D model of building“, sondern einfach korrektes Tagging kaputt gemacht .... Also zur Erklärung: da sind Tags für „Simple 3D buildings“ und „Simple Indoor Tagging“ kombiniert – aber korrekt! Hast du denn da vorher mal im Wiki nachgelesen, was der Tag „min_level“ bedeutet? Dann hätte es sich eigentlich erschließen müssen ... Bitte bitte: korrigiere alle solchen Änderungen wieder! Daaaaaanke!!!! Und immer erst mal das Wiki durchforsten, bevor man Tags löscht (die man vielleicht nicht kennt). Es soll User geben, die das mit viel Sorgfalt so hinzugefügt haben .... Viele Grüße! |
|
| 184717151 | Ich niochmal ... Nur zur Info: diese building:part-Fläche braucht es nicht für das Gebäude: way/1533114671, die Gebäudeoutline (way/1151358046) hat schon building:levels=5 – das ist völlig ausreichend für das 3D-Modelling nach „Simple 3D buildings“. Die neue building:part-Fläche fügt hier keinerlei neue Information hinzu. Nur der Sonderteil, den ich angelegt hatte mit building:min_level=1 ist entscheidend, weil anders als der Rest vom Gebäude (da kann man drunter durch laufen). Und auch hier: Geometrie ist jetzt vermurkst. Gebäude Trierer Straße 1 ganz schief usw. Da hatte ich wirklich länger an der Geometrie gearbeitet ... noch nicht sehr lange her. Vorhe ist auch der entrance-Knoten nicht mit allen Wegen verknüpft. Also: da müsste man jetzt wieder alles nochmal säubern ... Ich will dich nicht belehren, aber ich würde dir raten, auch da (noch) Abstand zu nehmen von solchen Bearbeitungen, es wirkt nicht so, als wärst du da sattelfest genug. Oder dich mal in JOSM einzuarbeiten, das lohnt sich dafür. (Und vielleicht mit etwas einfacherem anfangen als Gebäudegeometrie.) Viele Grüße! |
|
| 184749336 | Hallo nochmal ... Bei Geometrie-Korrekturen hat leider auch nicht alles geklappt – mich hat das „fix positioning of some nodes“ hier im Comment etwas aufgeschreckt, da musste ich mal reinschauen (und nur 1 o. 2 Stellen angeschaut). z.B. hast du bei Gebäude way/239247822 Eckpunkte verschoben, die vorher besser gestimmt haben (z.B. der hier: node/1312677621). Da hängt ein Baum drüber, wie man auf Satellitenbild (ich empfehle Saarland DOP20 + JOSM!) gut sieht.
Falls du keine Erfahrung mit solchen Änderungen hast, sei bitte vorsichtiger … Ich habe schin Stunden damit zugebracht, die Geometrie von Gebäuden in Dudweilr (und Jägersfreude) zu optimieren. Man kann das eigentlich nur sauber in JOSM machen, wo es gute Werkzeuge gibt, z.B. zum Orthogonalisieren, Punkte auf eine Linie bringen und regelmäßig verteilen und für saubere Kreise usw. Mit ID kann das fast nur schiefgehen. Nichts für ungut aber es tut etwas weh, wenn viel Arbeit wieder etwas kaputt gemacht wird ... Das ist nicht ganz Sinn der Sache. Es sollte sich verbessern bei Änderungen. Ich bin gerade etwas frustriert, sorry ... Trotzdem viele Grüße und nichts für ungut ... nicht alles kann direkt gut gehen ... |
|
| 185673805 | Hallo Engideer! Nur kurz noch was zu diesem Changeset (siehe meine ganzen Anmerkungen in changeset/186026186). Darauf bin ich jetzt noch durch Zufall gestoßen – ich habe dein Eindruck, dass alle deine Zusammenführungen fehlerhaft sind. Hier nur als Beispiel:
Oder in der Straße „Am Geisenberg“ gab es ein Teilstück mit hazard=children (nicht von mir, aber wohl weil da Schilder stehen, nehme ich an + es an der Schule dort ist) – jetzt hat der gesamte lange Straßenweg (way/27618271) hazard=children – das kann wohl auch nicht stimmen. Ich denke, dir war nicht bewusst, auf was man da alles schauen muss. Ich hab nicht weiter geschaut, aber bei allem, wo ich bisher drauf geschaut habe, war das, was du gemacht hast, nicht OK. Es ist wirklich aufwändig, das nochmal zu korrigieren ... ich hoffe, es war nicht noch viel mehr. Vielleicht kannst du mal schreiben, wo du das überall gemacht hast – und wer das nochmal in Ordnung bringen sollte ... Kannst du das zum Beispiel (zuverlässig) selbst machen? Hast du Erfahrung damit? (Denn dabei kann man ggf. auch noch mehr kaputt machen ...) Ansonsten wäre das einfachste, all diese Changesets zu revertieren (wenn du eine Liste machen könntest mir den changeset-Nummern, wäre das z.B. schon mal eine Hilfe)! Alles andere ist sehr viel Arbeit ... Viele Grüße! |
|
| 186026186 | Hallo Engideer!
Aber du hast dabei sehr viel übersehen – man sollte immer davon ausgehen, dass so gut wie niemand eine Straße ohne Grund splittet. Ich habe mir v.a. Hauptstraße in Jägsersfreude (wo ich sehr viel in mühevoller und sorgfältiger Arbeit erst kürzlich gemacht habe), und auch Sulzbachtalstraße und Dudweiler Landstraße angeschaut, und ich war gestern selbst wieder länger in Jägersfreude – dabei sind mir deine Änderungen aufgefallen. Also ich würde sagen: das kann auf keinen Fall so bleiben. Du bist mit dem „Merge some needlessly split ways“ ziemlich übers Ziel hinaus geschossen – sehr viele Splits (wenn nicht alle?) waren nämlich alles andere als „needless“, sondern völlig korrekt und auch wichtig und richtig so und hatten v.a. einen Grund. Ich will nicht meine Hand dafür ins Feuer legen, dass ALLE Aufsplittungen nötig waren, aber bin mir ziemlich sicher, dass man da nur sehr wenig hätte zusammenführen – also „mergen“ – können. Also ehrlich gesagt grenzt das für mein Gefühl schon an Vandalismus, was du da gemacht hast. Es geht z.B. um Stücke ohne Radwegmarkierungen (auf einer Seite), Stücke mit unterschiedlichen street-parking-Tags (bei der Sulzbachtalstraße z.B gesehen), Stücke mit unterschiedlichen sidewalk-surface-Werten u.v.m., was jetzt verloren gegangen ist und nicht mehr stimmt. Und auch die Tags der neuen Stücke stimmen jetzt teilweise nicht mal mehr untereinander (und bilden v.a. die unterschiedlichen Situationen vor Ort nicht mehr korrekt ab). Bei der Hauptstraße in Jägersfreude, wo du viele Teilstücke zu 2 langen Stücken zusammengefügt hast, hat das 1. Stück (way/238909472) jetzt z.B. diese Tags: cycleway:both:lane=advisory
(Auf dem Stück gibt es Bereiche, wo links KEIN Radweg vorhanden ist – das hatte ich extra sehr präzise an den richtigen Stellen gesplittet und getaggt! Das jetzige Tagging ist falsch und auch noch in sich chaotisch …) sidewalk:both:surface=paving_stones
(Rechts ist der Bürgersteig hauptsächlich asphalt – mal kurz unterbrochen von kleinen paving_stones- oder sett-Stücken an Einfahrten und links ist er paving_stones – ich hatte das vorher extra so getaggt und mir vor Ort gründlich angeschaut! Abgesehen von den sich sidewalk:both:surface=paving_stones ist also falsch und beißt sich ja auch mit den anderen Tags.) Was auch gar nicht mehr stimmt: die Stücke, ab denen maxspeed:conditional=30 @ (Mo-Fr 06:30-17:30) gilt, und wo immer Tempo 50 gilt – ich hatte die Verkehrsschilder auch extra eingetragen, wo es anfängt und aufhört (node/130320471 + node/7813850057) – ist dir das überhaupt aufgefallen und kannst du mir den Verkehrszeichen-Nummern was anfangen (wäre hier z.B. auch wichtig, also z.B. traffic_sign=DE:136-10;274-30,1042-33[Mo-Fr 06:30-17:30]). Jetzt hat die Straße ab Ortsanfang diesen konditionalen maxspeed-Tag … stimmt so aber nicht! Man braucht die Aufsplittungen z.B. dafür – ich hoffe, das ist nun etwas klar geworden. Wie gesagt: man macht Aufsplittungen meist mit gutem Grund (weil das ja ansonsten jeder vermeiden würde, so gut es geht) – das sollte man immer im Hinterkopf haben! Beim 2. Stück (way/1229053316) ist es nicht viel besser … Und die anderen Straßenstücke ebenfalls … Also ich würde dir vorschlagen, dass ich dieses Changeset komplett revertiere – ich denke, das wäre das Beste, denn es wäre eine Riesenarbeit, das alles nochmal neu zu taggen, vor Ort zu checken etc. etc. Ich war schon mehrere Stunden mehrfach allein in Jägersfreude, um da einiges genau zu taggen. Bitte schreib, mir, ob das OK für dich ist – auch das Revertieren kann einige Arbeit bedeuten (z.B. wenn jemand anderes nochmal was dort ändert – daher am besten so schnell wie möglich!), aber ich würde das gerne übernehmen (mit JOSM + Reverter PlugIn, das ist am sichersten). Du könntest dir ja danach die Situation vor Ort nochmal genauer anschauen und vielleicht findest du Stücke, die man wirklich ohne Probleme zusammenführen kann (ich weiß aber wirklich nicht, ob das die Mühe wert ist!). Und ich habe gesehen, dass es von dir noch weitere Changesets mit solchen Straßen-Zusammenlegungsaktionen gibt (zumindest vom Changeset-Comment her klingt es so) – ich habe mir die noch nicht genauer angesehen, befürchte aber nichts Gutes nach dem, was ich jetzt hier gesehen habe (sorry!). Ich weiß ja nicht, wie viel Erfahrung du mit OSM hast, aber weil du das z.B. mit ID gemacht hast (statt z.B. mit JOSM), könnte ich mir vorstellen, dass das vielleicht etwas zu komplex war – ich würde so etwas nur mit JOSM machen, man braucht da eine sehr gute Übersicht über alles. Ich will dir nicht zu nahe treten und dir nichts unterstellen, aber vielleicht solltest du dich mit solchen Änderungen vorerst etwas zurückhalten. Denn das kann für ziemlich viel Unmut auch bei anderen Usern führen. Und es macht evtl. sehr viel Arbeit kaputt und ist u.U. nur sehr aufwändig zu reparieren. Man sollte so etwas nur machen, wenn man sich 200% sicher ist mit ALLEN Tags und wenn man sehr genau die Situation vor Ort kennt, und zwar fast metergenau (viele Fotos sind da z.B. hilfreich). Es wäre eine große Bitte, da sehr sehr sorgfältig zu sein und im Zweifelsfall lieber nix zu machen. Ich hoffe auf eine schnelle Antwort und dein Verständnis, denn ich würde gerne bald noch mehr z.B. in Jägersfreude bis Dudweiler machen, aber so traut man sich nicht, eine der Hauptstraßen dort überhaupt anzufassen – jede neue Änderung macht ein Zurückgehen halt noch schwieriger. Und deine anderen Changesets dieser Art solltest du vielleicht selbst noch mal gründlich unter die Lupe nehmen. Viele Grüße und nichts für ungut … glaub mir, es macht mir auch wenig Spaß, so etwas zu schreiben (und mich damit zu beschäftigen), das kostet auch viel Zeit, die ich lieber für andere OSM-Dinge investieren würde … daher wäre ne schnelle, saubere Lösung dufte … und ich denke das wäre: revertieren. |
|
| 184173318 | Oh, hier kann man die Wiki-Syntax mit {{Key|...}} etc. nicht benutzen, hatte ich vergessen ... sorry ... |
|
| 184173318 | Hallo!
Also ich würde auch dazu tendieren, anzunehmen, dass die eku-Schränke nur von der Telekom benutzt werden. Weißt du zufällig, ob die nur die Metallschränke von eku benutzen (und sogar nur das Modell Nvt-L? – habe das Gefühl, immer nur das sehen, 13 Lüftungsschlitz-Reihen oben). Von eku gibt es ja auch Kunsttoffmodelle, hab ich gesehen. Und MFCs? Werden da auch welche von eku benutzt? Blöd und seltsam, dass die nirgendwo ihr Logo drauf haben. Ich tue mich auch schwer damit, telecom:medium=* zuverlässig zu taggen und hab daher bislang davon abgesehen. Wobei telecom:medium=fibre bei den NVts ja wohl zuverlässig ist, oder irre ich mich da? Falls verschiedene Modelle benutzt werden, könnte ich dir nach was Hilfreiches schicken – hab mir mal eine Übersichtsseite mit den versch. Modellen und Maßen etc. (mit Abbildungen) gemacht zur Sicherheit … Was cooling betrifft: die Tags {{Key|heat}}/{{Key|sound}} hatte ich noch nie gesehen (von der Wiki-Seite von {{Tag|man_made|street_cabinet}}). Es gibt ja noch keinerlei eigene Wiki-Seiten dafür, aber im Proposal sind sie erwähnt – etwas unbefriedigend. Bei Taginfo sieht man ja auch, dass die nur sehr selten benutzt sind (im unteren dreistelligen Bereich – wohl nicht ohne Grund). Für mich fühlen die sich wie etwas seltsame Haupttags an, die so dringend genauer definiert werden sollten. Ich glaube, für Töne emittierende Objekte gab es z.B. auch schon einige Ansätze (evtl. auch Proposals?). Und sound kenne ich v.a. als Subtag bei {{Key|traffic_signals:sound}}. {{Key|cooling:method}} fände ich ja dann weiterhin etwas besser, für {{Value|no}} könnte man ja vielleicht {{Tag|cooling:method||none}} verwenden – einen neuen Wert zu erfinden ist vielleicht besser als gleich einen neuen Key? Oder eben {{Key|cooling}} auch im Wiki dokumentieren …
|
|
| 185075523 | Ich weiß nicht, was es an Tonfall zu kritisieren gibt. Nach 7 Tagen wäre eine Antwort halt mal nett ... Völlig neutrale Formulierung. Man kriegt hier leider oft genug gar keine Antwort, und es ist auch ein Aufwand, sowas überhaupt zu schreiben (und nicht das, was an OSM Spaß macht). Weiß ja nicht, ob du das schon mal gemacht hast und wie deine Erfahrungen da sind ...
|
|
| 185075523 | Hallo? Eine Antwort wäre mal nett ... OSM ist eine Community .... Viele Grüße! |