Hallo!

OK .. gehen wir mal davon aus, du hast das alles dort erfragt und nichts von urheberrechtlich geschützten Plänen übernommen (dann solltest du Quellenangaben besser ändern und dementsprechend anpassen – das ist keine Lapalie bei OSM, sondern absolut basic - es dürfen keinerlei urheberrechtlich geschützten Daten in die OSM-Datenbank einfließen!).

Auch wenn Pläne da aushängen, kann man das nicht einfach übernehmen – man müsste sich vorher eine Erlaubnis einholen und das auch irgendwo schriftlich dokumentieren (z.B. auf der eigenen Userseite und darauf verweisen beim Mapping mit note=*/source=* o.Ä.). Das ist eigentlich der korrekte Weg in solchen Fällen … Ansonsten kann man nur das mappen, was man durch Erkundung (ohne unerlaubtes Eindringen in private Bereiche etc.) oder Satellitenbilder wie Bing/Saarland DOP20 (= ausdrücklich zur Nutzung für OSM freigegeben, hier aber wohl kaum hilreich) etc. herausfinden kann … Und was gesetzlich erlaubt ist im jeweiligen Land natürlich.

Aber du solltest nochmal klar ausdrücken, was du mit dieser Outline willst – was genau heißt „Die Passage benötige ich als Baukörper einmal modelliert.“? Man trägt ja im Prinzip nichts bei OSM ein, was man nur selbst für irgendein Projekt braucht (hört sich bei deiner Formulierung so an), bzw. wenn, dann sollte es unbedingt den OSM-Regeln entsprechen!

Ich kann also weiterhin nur raten/vermuten hier: geht es darum, anzugeben welcher Bereich im BESITZ von BVK ist? Da stellt sich mir gleich die Frage: gibt es noch Bereiche, die in anderem Besitz sind? Nebenbei: du hättest die Abkürzung BVK vielleicht auch mal irgendwo erläutern/ausschreiben können, z.B. in einer note=* oder im changeset Kommentar, es ist sicher nicht jedem geläufig, ich musste auch erst überlegen. Und in OSM gibt man eher ausgeschriebene Begriffe an als Abkürzungen (Ausnahme: short_name=*).

Dann sollte man dafür unbedingt den Tag owner=* verwenden (Wert am besten ausgeschrieben und nicht als Abkürzung) und nur noch darüber nachdenken, wie man die Fläche OSM-konform angeben kann.

Würde es nicht genügen, owner=BVK (bzw. besser owner=Bayerische Versorgungskammer) allen indoor-Outlines zuzuweisen, auf die das zutrifft (ggf. neue anzulegen, wo keine passenden vorhanden sind – aber ohne Überlappungen)? Diese könnte man, wenn man will, auch noch in einer Relation zusammenfassen, z.B. mit type=site und entsprechenden Tags (auch owner=BVK plus auf jeden Fall eine note=* oder description=* mit klarer Erläuterung). Über solch eine Relation ergibt sich dann auch eine Gesamtfläche (ohne neue Outline!) …

Denn man kann nicht einfach so eine 2. Outline auf die Outline des gesamten Umrisses legen (jedenfalls nicht in diesem Fall innerhalb des Konzepts von „Simple Indoor Tagging“ – siehe osm.wiki/Simple_Indoor_Tagging; es gibt z.B. keinen Tag indoor:part=* wie bei building … oder man müsste den dafür erfinden und mindestens im Wiki dokumentieren oder vorher diskutieren im Forum o.Ä.).

Wenn die Outline so bleiben soll, dann eigentlich nur mit dem Tag owner=Bayerische Versorgungskammer (und ggf. noch name=Diskontopassage) plus note=* oder description=*) – wobei es dann auch Validator-Fehler geben kann, weil ein Haupttag fehlt, der angibt, welche Art von OSM-Objekt das ist – und das ist hier das Kernproblem, ich hoffe, das ist klar geworden! Das wäre wohl nicht die beste Lösung …

Nochmal zusammenfassend die Kernprobleme:
* Kein building (auch kein building:part!) – was könnte also als Haupttag angegeben werden? (Meiner Erfahrung nach gibt es außer indoor=* leider derzeit nichts Passendes für solch ein „Untergrund-Bauwerk“.)
* Wenn man indoor=* Tags benutzen will (für ways!), dann muss/sollte man sich innerhalb der gültigen Definitionen des „Simple Indoor Tagging“ Konzepts bewegen – und das sieht keine überlappenden closed ways auf der gleichen Ebene (die mit level=* angegeben wird) vor und leider auch keine indoor:parts … => Die jetzige Outline ist damit also nicht umsetzbar!

Noch eine Frage:
Sehe ich es richtig, dass sich deine neue Outline und die alte (= way/111498101, mit Haupttag indoor=level) nur in den außen liegenden Treppen-/Rolltreppenzugangsbereichen unterscheiden (die bei deiner weggelassen sind)?

=> Dann könnte man auch überlegen, einfach die alte Outline entsprechend zu ändern (und dort dann owner=BVK hinzufügen), denn die Treppenaufgänge müssen ja nicht Teil der Haupt-indoor-level-Outline sein (bzw. das wäre vielleicht sogar korrekter, sie dort wegzulassen). Dann könnte man deine Outline nochmal löschen et voilà! Oder hast du daran noch irgendetwas Grundlegendes geändert (Bereiche weggelassen/hinzufügt)? Für mich ist es auch nicht ganz leicht, das klar zu überblicken innerhalb der verschiedenen Änderungs-Versionen …

Was übrigens noch fehlen könnte an der Outline: nicht öffentlich zugänglicher Bereich neben Früchte Kreis, der bis zum (Lasten-)Aufzug dort geht – da hatte ich schon öfters drüber nachgedacht, aber bisher keinen Weg gefunden, rauszufinden, bis wohin der genau reicht (man müsste wohl jemanden dort bitte, sich da umzusehen bis in die letzte Ecke … und ein langes Maßband mitnehmen).

Ich hoffe, wir können das bald klären …

Viele Grüße

Hallo!

Danke für die ausführlichen Erläuterungen! Ja, das schafft die Öffentlichkeit, die hier auch etwas gefehlt hat … Jetzt erklärt sich mir auch, warum es einen User „Optiml“ gibt (ist das noch jemand aus euerem Projekt oder nur eine andere Identität von dir?).

Kleine Vorbemerkung: Also wenn du (ihr) wirklich ganz neu auf OSM unterwegs bist/seid (habe die kleine Anzahl deiner/eurer Bearbeitungen gesehen, aber man kann sich ja auch eine neue Identität anlegen), dann hast du dir wirklich mit Diskontopassage und Rathaus-Carré zwei der kompliziertesten Stellen in ganz Saarbrücken ausgesucht für den Anfang ... Da muss man wirklich einiges wissen über die Grundregeln von OSM hinaus. Aber man kann sich ja in alles einarbeiten …

Ich glaube dir, dass du das nicht aus Spaß machst oder um mich (und andere) zu ärgern, aber es muss sich trotzdem korrekt in die OSM-Welt einfügen … in allen Belangen. Und es ist an so komplizierten Stellen wirklich gar kein großer Spaß, wenn man da nachkorrigieren muss usw. Mich hat das jetzt schon einige Stunden gekostet, die ich gerne mit was anderem verbracht hätte – und auch noch bei der Hitze …

Ganz ganz ganz basic ist die Regel bei OSM, dass man nichts aus urheberrechtlich geschützten Quellen eintragen darf! Die Datenbank von OSM muss komplett frei davon bleiben. Daher sind solche „Insiderinformationen“, welcher Gebäudeteil von den Eigentümern oder versorgungstechnisch oder wie auch immer als eigenständiges Gebäude betrachtet wird, eher problematisch. Wenn, dann müsste man sich eigentlich eine offizielle Genehmigung von den Eigentümern einholen und das bei OSM dokumentieren (z.B. auf Userseite) und bei der Bearbeitung als Quelle/Referenz angeben und am besten auch in einer note=* zum Objekt.

Das ist leider nicht so ganz trivial bei OSM …

Das betrifft auch, wie diese Gebäudeteile (intern?) genannt werden, z.B. „Bauteil A“ – sofern das kein Allgemeinwissen ist oder irgendwo am Gebäude (z.B. auf ausgehängten Orientierungsplänen/-schildern) angegeben ist. Das ist hier schon mal eins der Grundprobleme, die es zu klären (und lösen) gilt!

Aber jetzt mal ganz praktisch:

Würden für diese „Gebäude-Teilung“, die wohl dein Hauptanliegen ist, denn auch building:part=* Outlines genügen? Denn die kann man eigentlich nahezu beliebig (auch überlappend) auf ein Gebäude legen, es sollten dabei bloß keine sich widersprechenden Infos wie z.B. building:levels entstehen! (Oder überflüssige, durch andere building:parts bereits wiedergegebene Informationen enthalten, sonst wird jede spätere Datenpflege zum Kraus (was jetzt scho der Fall ist, weswegen ich so wenig wie irgend möglich neue building:parts hinzufügen würde!). Diese kann man dann mit den gewünschten (OSM-konformen!) Tags versehen. Solche Gebäudeteil-Bezeichnungen wie „Bauteil A“ kann man aber eigentlich nicht als name=* angeben (es sei denn es sind allgemein bekannte/benutzte und am Gebäude deutlich angebrachte Namen), sondern vielleicht als ref=* (oder nur als description=* oder note=*).

Das Rathaus-Carré ist schon ein Sonderfall … es ist schon klar, dass es Gebäudeteile gibt und Adressen mit verschiedenen Straßennamen usw., aber für OSM geht eigentlich vor, was sich dort von außen betrachtet architektonisch als EIN Gebäude manifestiert – und es scheint mir hier ziemlich klar zu sein, dass das gesamte Rathaus-Carré eine architektonische Einheit bildet und auch als EIN Komplex geplant und umgesetzt wurde (mit Aussparung des historischen Gebäudes Bahnhofstr. 26, was ja unverändert blieb). Und es ist z.Z. auch in das wirklich große Multipolygon „Rathaus St. Johann“ integriert. Was ggf. diskussionsfähig wäre und vielleicht auch nicht ganz korrekt ist? Aber das zu ändern, sollte wirklich nur jemand mit guten OSM-Kenntnissen – plus guter Ortskenntnis – machen!

Somit ist es nach jetzige Aufbau-Stand dort am korrektesten, dass die einzelnen Adressen-/Hausnummer als Adress-Knoten auf dem Gebäudekomplex liegen (diese geben ja auch schon „Gebäudeteile“ wieder, bloß nicht als exakter Umriss, aber weil es auch nicht von außen und mit erlaubten OSM-Mitteln möglich ist/war zu bestimmen, von wo bis wo genau eine Adresse-/ein Gebäudeteil gilt – dann ist Nicht-Mappen als Outline eigentlich das korrekteste aus OSM-Sicht …). Die Hausnummern sind dagegen am Gebäude angebracht und klar nachvollziehbar. Und es ist auch korrekt, wenn mit building:parts unterschiedliche Gebäudeteile gemappt sind (z.B. verschiedene building:levels etc.), die von außen/vor Ort als solche zu bestimmen sind mit all ihren Eigenschaften.

Hast du einen Vorschlag, wie man das nun machen könnte? Wären weitere (möglichst wenige!) neue building:parts the way to go?

Könntest du dir vorstellen, für nicht-öffentlich zugängliche Informationen (z.B. genaue Bereiche der Gebäudeteile, Gebäudeteil-Bezeichnungen) eine offizielle (schriftliche!) Erlaubnis zur Nutzung in OSM einzuholen und diese (dauerhaft!) in OSM zu dokumentieren, z.B. im Wiki oder auf deiner Userseite?

Viele Grüße!

Hallo Optiml!

Deine Änderung macht diesen Weg hier aber auch nicht besser, das ist dir schon klar, oder (bitte Wiki checken wegen building=* und building:part=*!).

Das mag Validator-Fehler wie überlappende Gebäude beseitigen, ist aber keine Lösung (nur eine weitere Verschleierung des gesamten Problems) ...

Es ist kein building (nach OSM-Definition, auch nicht nach gängiger Definition), und auch kein building:part (denn wo ist dann das zugehörige building?).

Das muss grundlegend geändert (anders gelöst oder sogar wieder gelöscht werden).

Je nachdem, was der Sinn/Zweck davon eigentlich sein soll (nur Besitzerangabe „BVK“ samt Bereich – ich sehe sonst keine neuen Informationen, bzw. nur fehlerhafte wie name?).

Diese Klärung steht noch aus ... solange da am besten da nix mehr ändern ....

Siehe changeset-Kommentare changeset/184419905 und auch eine neue OSM note gibt es: note/5356981. Wenn du interessiert bist, kannst du dort ja was schreiben ....

Viele Grüße!

Mein changeset Kommentar stimmt hier nicht (ein Versehen), das waren Änderungen in der City ...

Hallo!

Ich muss nochmal schreiben … Was hast du denn hier gemacht?

Du hast eine neue Outline für die Diskontopassage angelegt mit name=Diskontopassage BVK-zugeöhrig (inkl. Schreibfehler!) als building=commercial? Das kannst du so nicht machen … Z.B. den name-Tag so verwenden (siehe meine Kommentare von heute in anderem changeset – changeset/184421459). Die Diskontopassage heißt „Diskontopassage“, und daher ist nur dieser Tag korrekt (für alle Teile der Passage).

Und es geht meiner Meinung nach auch nicht als Gebäude (building=commercial), auch nicht mit layer=-1 – denn es erfüllt nicht die Bedingungen, die für Gebäude gelten (siehe Wiki). Man kann das meiner Meinung nach eigentlich nur mit indoor-Tagging machen, weil es komplett unterirdisch ist – so wie ich es angelegt hatte, jedenfalls war das die Methode, die ich am ehesten für tauglich befand, und ich hatte vorher auch recherchiert, wie das in ähnlichen Fällen anderswo gemacht wird – und das ist wohl die gängige Methode (siehe way/111498101 – der Umriss wird als indoor=level eingetragen, und es sollte pro Ebene/Etage nur einen solchen Umriss geben – siehe Simple Indoor Tagging – osm.wiki/Simple_Indoor_Tagging ).

Dann hast du z.B. auch surface=concrete angegeben (Wiki: „The surface key describes the physical surface of roads, footpaths and other surface features, particularly regarding material composition and structure.“) Es ist nur ein Eindruck, aber mir scheint, du bist mit der Verwendung von Tags nicht so ganz vertraut. Dein Objekt ist ein Gebäude, da kann man keine surface angeben, nur building:material für das Fassadenmaterial (oder roof:material).

Es ist ganz schwierig, das sauber zu machen, was du da anscheinend vor hast – daher würde ich dich bitten, die Hintergründe mal zu erläutern.

Ein paar Hinweise, wie man es ggf. machen könnte – es scheint hier ja v.a. um Besitzerinfos zu gehen:
Was zu welchem Besitzer gehört, wird in OSM eigentlich nur selten extra eingetragen – wenn, dann gibt es den Tag owner=* dafür (und auch noch ownership=* für den Typ). Aber wenn man dann auch noch extra outlines braucht, dann dürfte es schwierig werden. Da wäre es eher angezeigt, sich innerhalb der Methoden des „Simple Indoor Taggings“ zu bewegen, wo man ja Räume/Korridore etc. mit Outlines eintragen kann, was ja bereits in großem Umfang stattgefunden hat – diesen Outlines könnte man dann jeweils einen owner=* Tag geben, wenn man das will (und weitere Infos ggf. als note=XY, description=XY oder ref=XY etc. – am besten mit Quelleninfos). Und ggf, neue Bereiche eintragen – aber ohne Überlappungen und Dopplungen! Das wäre der saubere Weg, der mir so ad hoc einfällt.

So wie es jetzt ist, kann es definitiv nicht bleiben … das ist wirklich unsauber.

Dann noch die Quelle: Übersichtspläne BVK – wie sieht es da mit dem Urheberrecht aus? Erfüllt das die Bedingungen für eine Verwendung in OSM? Es dürfen nur Quellen benutzt werden, die frei von Urheberrechtsbeschränkungen sind! Siehe: osm.wiki/DE:FAQ#Welche_Bilder_und_Karten_darf_ich_verwenden,_um_davon_Karten_zu_erstellen? Das ist SEHR WICHTIG! Ein Grundprinzip, damit die OSM-Daten frei bleiben. Ist das nicht erfüllt, müssen darauf basierende Eintragungen wieder gelöscht werden. Bitte auch damit sorgfältig umgehen.

Mir stellen sich da viele Fragen – ich hoffe, du kannst zur Klärung beitragen bzw. deine Edits korrigieren.

Und noch was: du hast da einen Knoten hinzugefügt, der den Weg der Bahnhofstraße „vermurkst“, d.h. stark verbogen hat – node/9213029215. Der war mit der Outline des Gebäudes Bahnhofstraße 36 verbunden. Das sieht sehr nach einem Versehen aus – ich hab den daher wieder gelöscht. Da gibt es ja im Changeset hier auch diese iD-Warnungen (z.B. „warnings:crossing_ways:building-highway“ – das könnte daher kommen).

Viele Grüße!

Hallo!

Könntest du mir bitte mal diese Bearbeitung erklären?

Ich habe vor kurzem erst Stunden damit verbracht, die ganzen building:parts vom Rathaus-Carré zu korrigieren (nach fehlerhaften Bearbeitungen zweier User) und du hast hier jetzt wieder mehrere building:parts in eigenständige Gebäude geändert (und neue Gebäude-Outline angelegt?).

Das geht so nicht .... das gibt schon allein jede Menge Validator-Warnungen in JOSM wegen sich überlappenden building-Outlines (zu Recht!).

Der gesamte Gebäudekomplex ist EIN großes Multipolygon (name=Rathaus St. Johann), nur das Gebäude Bahnhofstraße 26 ist extra gezeichnet, weil es ja als historisches Gebäude auch wirklich ein extra Gebäude ist in dem ganzen Rathaus-Carré und so erhalten geblieben ist.

Und woher kommen diese Namen wie „WE5080 - Bauteil A“? Für den name Tag gelten strenge Regeln bei OSM; siehe Wiki – du kannst das so nicht benutzen. Wenn du da wirklich irgendwelche Bauteilnummern oder Referenz-Codes angeben willst, dann bitte nur als (ggf. neue) building:part Outlines und diese Bezeichnung nicht als name-Tag (vielleicht nur als note=XY oder description=XY oder als ref=XY, dann aber bitte plus eine note, wo diese ref herstammt – oder du musst einen eigenen Sub-Tag dafür „erfinden“, dafür gelten auch Regeln). Und du weißt, dass man bei OSM nicht aus urheberrechtlich geschützten Quellen Dinge übernehmen kann? V.a. ein Name sollte vor Ort verifizierbar sein, nachvollziehbar sein (siehe Wiki osm.wiki/Verifiability).

Und als Changeset-Comment nur „WE5080 - BVK zugehörig“ und „local knowledge“? Wenn man so weitreichende Änderungen macht, wäre ein verständlicher Kommentar und exakte Quellenangaben wirklich wichtig! Ich kann mir darunter nichts vorstellen.

Ich habe das alles daher jetzt nochmal rückgängig gemacht und die name Tags gelöscht. Bitte mach Änderungen dort leichtfertig – das ist schon sehr komplex aufgebaut dort und hat vorher alles gestimmt (mit ziemlicher Sicherheit).

Weitere Fehler, die mir aufgefallen sind: 1x hast du auch building:levels von 4 auf 3 geändert (Gebäudeteil Bahnhofstr. 22/24) – aber es sind definitiv 4. Wie kommst du auf 3? Und was vorher „Gebäudeflügel F“ war, hat 5 Etagen – nicht 4 – das leicht zurück versetzte zählt dazu. Und was du als neues Gebäude Betzenstraße 7–9 angelegt hast, hat 5 Etagen ... ich hab das wieder gelöscht.

Also falls du da wirklich etwas hinzufügen möchtest: bitte nur mit genauer OSM-Sachkenntnis und Sorgfalt. Keine überlappenden building-Outlines; keine neuen Gebäude in das Multipolygon zeichnen (wenn du nicht weißt, was ein Multipolygon ist, mach dort am besten gar nichts).

Und noch was: Wenn man dort etwas ändert, sollte man das meiner Meinung nach auch nur in JOSM machen – nur dort gibt es genügt Validator-Warnungen, wenn man etwas falsch macht oder übersieht. Für iD ist es dort wirklich zu komplex, denke ich.

Sorry, aber ich habe da schon so viel Zeit investiert und muss immer wieder nachbessern. Bitte um Verständnis ... Danke!

Vielleicht kannst du ja auch etwas erklären ...

Viele Grüße!

Hallo!

Kleine Bemerkungen zu deiner Bearbeitung: du hast da das Multipolygon „Rathaus St. Johann“ (mit einem outer und einem inner way) in eine Relation type= building geändert (was für 3D-Modelling gedacht ist). Damit hast du aber das Multipolygon unbrauchbar gemacht – das wird aber weiter benötigt (es gibt einen großen Innenhof/Platz, der ausgespart werden muss). Das wurde inzwischen wieder korrigiert von mir und nw520. Falls du wirklich eine type=building-Relation haben willst (mit allen building:parts, denn hier gibt es viele davon), dann solltest du wohl besser eine zusätzliche Relation dafür anlegen und das Multipolygon unangetastet lassen …

Und auch bei den Änderungen am Rathaus-Carrée (samt Knotenänderungen) war nicht alles sauber. (Hinweis: der gesamte neuere Gebäudeteil heißt „Rathaus-Carrée“ – siehe way/89024220.)

Da waren z.B. Knoten nicht mit allen ways verbunden, die da liegen usw. und v.a hast du den Umriss der building:parts „Gebäudeflügel F“ (way/700240652) und „Rathaus-Carrée“ (way/89024220) falsch geändert. Und wozu dient z.B. dieser neue Knoten: node/13758157254? (Kann der weg?) Ich habe da heute einiges nachkorrigiert (siehe changeset/184329421).

Hat mich einige Zeit gekostet, durchzublicken, was da geändert wurde und was jetzt falsch und richtig ist. Denke aber, jetzt müsste es stimmen. Vielleicht schaust du es dir nochmal an.

Also falls du dort noch etwas machen willst: bitte sehr genau prüfen, was wozu gehört und wie geändert werden muss … es ist recht kompliziert dort … ich habe da schon viel bearbeitet und korrigiert, und kenne die Situation daher recht gut.

Viele Grüße!

Hallo!

Kleine Bemerkungen zu deiner Bearbeitung am Rathaus-Carrée (siehe auch Bemerkungen zu Changeset changeset/181724719!) – die Situation dort ist wirklich komplex …

Du hast dort mit Weg way/1502881591 ein neues Gebäude mit building=retail hinzugefügt. Das kann man dort aber aus mehreren Gründen nicht so machen … V.a. weil es kein eigenständiges Gebäude ist, sondern Teil des Rathaus-Carrées (siehe Weg way/89024220)! name=Bahnhofstr. 28;Betzenstr. 5/ 5, 9): way/1502881591 geht so auch nicht … Siehe Infos zum name-Tag im Wiki.

Die Betzenstraßen-Hausnummern waren ja bereits als Adress-Knoten angelegt. addr:housenumber=28 und addr:street=Betzenstraße stimmten auch nicht, Wenn, dann ist HN 28 Bahnhofstraße (ich hab das jetzt mal als Adressknoten anlegt). building:levels=4 stimmt da auch nicht; es sind 5 (und das ist schon beim building:part vom Rathaus-Carrée angegeben, der auch diesen Teil umfasst). height=12 kann dann wohl auch nicht stimmen …

Hat mich einige Zeit gekostet, durchzublicken, was da geändert wurde etc. Also da ist so viel falsch, dass ich mich entschieden habe, die ganze Outline zu löschen (siehe changeset/184329421). Sie ist überflüssig, weil alles schon durch andere Outlines und v.a. building:part vom Rathaus-Carrée abgedeckt ist. Schau es dir vielleicht nochmal genauer an …

Viele Grüße!

Hallo!

Kleine Bemerkungen zu deiner Bearbeitung am Rathaus-Carrée (siehe auch Bemerkungen zu Changeset changeset/181721862): die Situation dort ist wirklich komplex … ich habe da schon viel bearbeitet und korrigiert, und kenne die Situation daher recht gut.

Du hattest da jetzt eine neue building-Outline hinzugefügt (way/1502896324), was so aber nicht korrekt war. Das ist kein eigenständiges Gebäude, sondern Teil vom „Rathaus-Carée“ (der gesamte neuere Gebäudeteil heißt so – siehe way/89024220!).

Also sollte es als building:part eingetragen werden. retail stimmt auch nicht, denn oben sind Büros vom Rathaus etc. name=Bahnhofstraße 20-24 stimmt so auch nicht und name kann man so auch nicht verwenden (siehe Wiki!), die Hausnummern stimmten wohl auch nicht (dort müssten HN 22–24 sein; ich habe mal Adress-Knoten angelegt). Habe diesen name-Tag daher komplett entfernt und es in building:part geändert (siehe changeset/184329421).

Auch die Outline vom Multipolygon „Rathaus St. Johann“ (way/585745388) wurde wohl geändert (oder von von User Optiml?) sowie building:part „Gebäudeflügel F“ (way/700240652) und building:part „Rathaus-Carrée“ (way/89024220) – aber das stimmte jetzt nicht mehr, denn der von dir neue eingezeichnete Teil gehört zu diesen 3 Objekten. Ich hab das auch wieder korrigiert.

Hat mich einige Zeit gekostet, durchzublicken, was da geändert wurde. Bin mir auch nicht 100% sicher, ob das alles von dir war (oder von User @Optiml, der da auch einiges nicht ganz sauber geändert hat).

Also falls du dort noch etwas machen willst: bitte sehr genau prüfen, was wozu gehört und wie geändert werden muss … es ist recht kompliziert dort, da gibt es vieles zu beachten.

Viele Grüße!

Jetzt sehe ich gerade noch – im Prinzip das Gleiche steht ja auch bei tactile_paving=incorrect:

“If only one sloped curb at a crossing has tactile paving, this may be considered "incorrect", some mappers prefer the tag tactile_paving=partial on a crossing node instead (because if e.g. one side has a correct tactile paving and the other has none at all, then there is no incorrectly installed tactile paving anywhere).“

(Auch von mir 2023 ergänzt; seitdem nicht beanstandet etc.)

Grüße!

Noch vergessen zu erwähnen: auf der Wiki-Seite von „tactile_paving=partial“ (tactile_paving=partial) steht es auch nochmal genauer, weil ich das dort (schon 2023!) hinzugefügt hatte:

„This tag is usually used when a tactile paving is not installed correctly. In most cases a "partial" tactile paving can be viewed as "incorrect", but at a crossing node with tactile paving only on one side the tactile paving can also be viewed (more precisely) as partially present and not as "incorrect". In such a case, a crossing way could for example have a node with tactile_paving=no on one side and a node with tactile_paving=yes (which is not an incorrect tactile paving) on the other side.“

Wurde seitdem von niemandem beanstandet oder geändert.

Viele Grüße!

Text

————————

2026-06-04

Hallo! Danke für deine Infos ... also ich finde StreetComplete und deren Entscheidungen, in welche Richtung sie die User lenken, wirklich oft unschön. Das hier ist so ein gutes Beispiel, denn dieses tactile_paving=incorrect halte ich für einen schlechten Tag in diesem Fall, weil hier wirklich unpassend. Deshalb hatte ich das mit „partial“ („one_side“ fände ich noch präziser!) extra erwähnt.

Denn dieses „incorrect“ ist ziemlich unklar definiert – im engl. Wiki heißt es „The tag tactile_paving=incorrect is used where tactile paving is installed incorrectly or not used not in a sensible way, e.g. if the paving is symmetric for visual pleasure but on one of the sides it leads to nothing.“

Also der erste Teil der Definition lautet: „incorrect“ ist es, wenn es „incorrect“ ist – was ist das bitte für eine Definition? Gemeint ist aber wohl, wenn das tactile_paving an sich fehlerhaft ist (falsches Muster, falsche Richtung) oder zu früh endet o.Ä., also wenn es zwar da ist, aber nicht richtig benutzt werden kann (und somit ggf. auch gefährlich sein kann oder nur unnütz).

Es passt hier insbesondere nicht, weil es eben NICHT inkorrekt angebracht ist (z.B. falsche Streifenrichtung o.Ä.), sondern korrekt auf einer Seite vorhanden und komplett fehlend auf der anderen. Das ist nicht inkorrekt, sondern nur unvollständig (geht man in die eine Richtung völlig OK, in die andere einfach nicht vorhanden). Also ich fände daher ein Setzen von „incorrect“ ebenso falsch und nur „partial“ (oder „one_side“) zutreffend ....

Wenn du willst, leg ein Issue bei StreetComplete an dafür – aber nach meinen Erfahrungen führt das meist zu wenig, weil man da sehr überzeugt von den eigenen Entscheidungen ist und wenig kritikfähig, jedenfalls nach meinen Erfahrungen ... Ich vermute mal, hier wäre die Antwort, dass „partial“ nicht verbreitet genug ist/nicht genügend ausdiskutiert o.Ä. – aber wer weiß?

(Du hast recht, dass da vorher nur tactile_paving:left und nur tactile_paving:right gesetzt war und kein nur tactile_paving=* ... das stammt noch aus einer Zeit, wo mir der partial-Wert auch noch nicht vertraut war und ich mich daher tactile_paving:left/:right als einzige – wenn auch umstrittene Lösung entschieden hatte).

D.h. du müsstest nicht nur nach partial schauen, sondern auch nach tactile_paving:right/:left oder extra gesetzte Knoten – bzw. einfach vor Ort genau hinschauen, ob es dieser „nur eine Seite“-Fall (und auf der einen Seite nicht in irgendeiner Weise klar „inkorrekt“ = falsch angebracht/aufgebracht) ist ...

Viele Grüße!

Hallo amertz!

Ich war gestern am Brandenburger Platz auf dem Eschberg, ein paar Details checken und ergänzen. Dabei fiel mir auf, dass du bei Treppen dort tactile_paving ergänzt hast (wohl eine Street Complete Aufgabe, nehme ich an). Das ist gut, aber bei einigen stimmte deine Angabe tactile_paving=no nicht.

z.B. hier: way/1078883910 und hier way/1078883926 und hier: way/1078883894 – da ist tactile_paving nur auf einer Seite – da sollte man tactile_paving=partial setzen (oder den seltenen Wert one_side benutzen). Keine Ahnung, ob Street Complete das anbietet (wäre hier aber wichtig – ich empfehle dann einen anderen Editor zu benutzen, Street Complete ist leider oft zu eingeschränkt in solchen Fällen – oder dann eben nichts ändern mit SC …).

Oder hier: way/810603142 – da gehört tactile_paving=yes hin statt no (ist oben und unten!).

Ich habe jetzt nicht alle deine Änderungen durchgecheckt, das waren nur Zufallsfunde.
Vielleicht solltest du das nochmal machen ... Und nächstes Mal vielleicht etwas genauer hinschauen (?). Eigentlich ist das ja sehr eindeutig.

Viele Grüße und weiterhin frohes Mappen!

Hallo amertz!

Bist du dir sicher, das diese Änderung richtig war? Denn das Ingenieurbüro „Hetfile“ ist jetzt doppelt eingetragen: einmal der von dir geänderte Knoten (node/1488862403), einmal dieser ältere, von mir schon 2024 eingetragen, links daneben: node/12360205006.

Vielleicht nochmal überprüfen und ggf. korrigieren. 2 Knoten sollten es auf jeden Fall nicht sein ...

(Außerdem: keine Großschreibung bei Namen, siehe OSM-Wiki ... auch wenn die sich vor Ort so schreiben. Hab ich jetzt mal angepasst. Und old_name sollte man i.d.R. eigentlich auch nicht löschen bei einer solchen Änderung. Hab ich auch nochmal ergänzt.)

Viele Grüße!

Hallo SoulCover! Ja, das mit den Knoten ist der „Gold Level“ ... Aber auch nur sinnvoll möglich, wenn alle (Fuß-)Wege des Überwegs inkl. Bürgersteig-Wege separat gezeichnet sind, damit man dort die Knoten platzieren kann. An diesem Überweg ist das noch sehr unvollständig – nur 1 Weg als footway=crossing (wobei der aus 3 Teilen bestehen müsste mit footway=traffic_island in der Mitte), keine sidewalk-Wege. Da machen Knoten nicht so viel Sinn. In Saarbrücken ist das aber an sehr vielen Stellen umgesetzt, schau dir mal Wilhelm-Heinrich-Brücke an. Hier ein Beispiel: node/8458647013 (mit barrier=kerb, kerb=lowered, tactile_paving=yes). Bin mir aber fast sicher, dass StreetComplete das nicht anzeigt (?). Ich benutze SC nicht, weil es zu viele Einschränkungen hat und viele Fälle nur unzureichend abdeckt. Ist halt oft (zu) stark vereinfachend.

Und ja, du hast recht, dass :left/:right oft als nicht eindeutig bezeichnet wird. Ich seh das etwas anders bei einem Übergangsknoten auf einer Straße (der kein Knotenpunkt mehrerer Straßen ist), ist es meiner Meinung nach klar, dass mit links/rechts die Richtung der Straße gemeint ist, über die der Überweg ja führt. Eigentlich müsste man das nur einmal im Wiki so definieren ... rechts/links in Bezug auf einen crossing-footway würde ja keinen Sinn machen ... Aber ich seh das mittlerweile auch nur noch als optionale Zusatztags an, weil es nicht allg. akzeptiert ist. Auf Nummer sicher ist man aber wohl mit tactile_paving=partial (da fehlt dann eben die Info, auf welcher Seite ist es yes, und wo no, deshalb benutze ich trotzdem die Zusatztags), und perfekt wäre es zusätzlich mit allen separat gezeichneten Wegen + exakten Knoten, die tactile_paving und am besten auch kerb=* angeben (normalerweise an der Bürgersteigkante bzw. Kante von Verkehrsinseln).
Es kann etwas kompliziert werden ... Und darüber wird ja auch viel diskutiert ...
Viele Grüße!

Hallo SoulCover!

Kleine Anmerkung:
Wenn tactile_paving bei einem Überweg nur auf EINER Seite ist, würde ich tactile_paving=partial (oder one_side) statt yes setzen ... Aber keine Ahnung, ob StreetComplete das anbietet (ich empfehle dann einen anderen Editor zu verwenden). Z.B. hier: node/8558384167. Ich hatte da vorher präzise tactile_paving:left/right (in Wegrichtung) mit yes und no gesetzt. Ich war gestern dort und hab es es geändert.

Viele Grüße

Was ich gerade noch gesehen habe: Osmose zeigt eine Warnung an für surface=anti-slip auf dem kleinen Wegstück, das damit getaggt ist („Bad tag value|Concerns tag: 'surface=anti-slip'“) ... Weil es undokumentiert ist? Oder wegen des Bindestrichs (mit Underscore wäre wohl besser, aber „anti_slip“ ist noch seltener – nur 1x verwendet)?

Nur zur Info ... das meinte ich aber damit, dass ich undokumentierte (oder neu erfundende) Werte nur ungern benutze.

Denn eigentlich müsste man es im Wiki dokumentieren (bzw. erst im Forum diskutieren?) und dann noch ein Issue für Osmose oder andere Validatoren anlegen etc. ...

Hallo Lukas! Ich hab deine Nachricht heute erst gesehen … Ja, da könntest du recht haben – oder es ist ein schwieriger (Grenz-)Fall. Ich glaube nicht, dass es ein Versehen war, ich erinnere mich aber nicht mehr ganz genau. Die Fotos zeigen es wohl richtig (ich hab auch eins von 2021, sieht genauso aus), aber man kann daraus nicht klar ableiten, was es ist. Typisches (blankes) metal_grid ist es wohl nicht von der „obersten Oberfläche“ her gesehen. concrete oder asphalt stimmt aber ziemlich sicher auch nicht. Es könnte gut sein, dass es Metall ist (bzw. wirklich eine Art metal_grid!) mit einer Anti-Rutschbeschichtung, die wie Beton aussieht auf den Fotos. Es kann sein, dass ich 2023 metal_grid gesetzt hatte, weil der Weg daraus besteht (ob nun mit oder ohne dünne Beschichtung) und mir das als der am wenigsten falsche Wert erschien, also der am ehesten passende (ohne was Neues zu erfinden – was ich immer zu vermeiden versuche). Und weil concrete definitiv nicht gestimmt hat ... Meist bin ich da schon recht gründlich und schau es mir vor Ort an.

Was ich jetzt noch gesehen habe: nw520 hat 2024 bei einem Teilstück zur Treppe den (undokumentierten) Wert surface=anti-slip (mit surface:note=Metall mit Anti-Rutschbeklebung) gesetzt (weltweit nur 45x benutzt). Siehe way/399937342. Aber den Hauptweg nicht geändert – was auch seltsam (und v.a. inkonsistent!) ist. Es ist sicherlich die gleiche Oberfläche. Da müsste man wohl nochmal hin ... Vielleicht kann man auch material=metal (oder metal_grid) und surface=anti-slip setzen? Oder surface=metal_grid + anti_slip=yes? ;-)

Vielleicht hast du ja eine Idee ... Bzw. kannst mir sagen, wie du es machen würdest.

Viele Grüße und danke für den Hinweis

Ja, kein Problem. Ich komme da öfters vorbei, vielleicht sogar heute noch. An den fraglichen Stellen stimmt es wahrscheinlich auch, nehme ich mal an. Es sind auch neue Häuser fertig gebaut oder noch in Bau, von denen nur wenige bisher sichtbare Hausnummern haben (im 3. Bauabschnitt). Ich versuch es im Auge zu behalten. VG!

Hall Teddy73!

Im Neubaugebiet Franzenbrunnen hattest du 2021 mal Hausnummern eingetragen mit der note "Neubau, Hausnr geraten".

Das war nicht immer so ganz glücklich geraten ... ;-)

Z.B. die obere Häuserreihe in der Echternacher Straße ... hier etwa ist es HN 28 statt der geratenen HN 16: way/974090922. Falsch war es ab der jetzigen HN 10. Und 12 und 14 scheint es nicht zu geben, hab ich jedenfalls nicht gesehen.

Ich war gestern dort + war erst mal sehr verwirrt wegen den eingetragenen Hausnummern und denen vor Ort (weil ich auch die note nicht gleich gesehen hab ...). Und mir ist es eigentlich auch nur durch Zufall überhaupt aufgefallen. Hat dann etwas gedauert, bis ich durchgeblickt hab, was zu ändern war und was die richtigen Nummern sind (das falsche Raten lag dort vielleicht an der 2. zurückgesetzten Häuserreihe, die halt mit nummeriert sind – vielleicht gab es die 2021 noch nicht?).

D.h.: vielleicht nächstes Mal besser doch nicht raten. Denn die waren jetzt 4 1/2 Jahre lang falsch ... Es fällt eben kaum auf und man kommt nicht ohne weiteres auf die Idee, dass solche Hausnummern falsch sein könnten. Ich denke, es ist besser, gar keine HN anzugeben, wenn es nicht klar ist. (Wenn neue Häuser keine HN haben, checkt es sicher eher mal jemand bzw. ein fixme, z.B. „Hausnummer noch zu ergänzen sobald bekannt“ könnte sinnvoll sein.)

Wollte es bloß mitteilen ...

Da sind jetzt noch ein paar Häuser mit dieser Note (Louis-Pergaud-Straße 13 bis 25 und Anita-Augspurg-Straße 8, 10, 11, 12) – das hab ich erst zuhause gesehen. Sollte man wohl auch nochmal checken zur Sicherheit und die note dann entfernen.

Viele Grüße und happy Mapping!