Was ist denn die Quelle für die vielen Gebäude, die du in diesem Änderungssatz eingetragen hast? Sind die wirklich alle gleich?

Korrektur: Das war am 14.2.2016

Korrektur: Das war am 14.2.2016

Korrektur: Das war am 14.2.2016

Korrektur: Das war am 14.2.2016

Anmerkung: In den meisten Fällen passt es auf fünf bis zehn Meter (d.h. innerhalb der Messgenauigkeit).

Hallo Tocosibirsk,

ich schnappe mir diesen Änderungssatz einfach als Stellvertreter für die anderen von dir.

Ich trage gerade meine Beobachtungen (GPS-Wegpunkte mit Garmin/Samsung Galaxy S5) von meiner Deutschlandpasstour mit rurseekatze vom 22.8.2015 ein. Die meisten Signale hast mittlerweile du eingetragen, aber ein paar Sachen kann ich noch ergänzen.

An einigen Stellen gibt es Unterschiede zwischen uns beiden, was die Lage der Signale angeht. Hast du die Signale irgendwie mit GPS oder so erfasst? Oder reine Streckenkunde mit eigenen Videos/Fotos?

Es wäre nett, wenn du mir Auskunft geben könntest (gern auch per PN), damit ich dementsprechend entscheiden kann.

Viele Grüße

Michael

Was ist denn die Quelle für die Signale, die du eingetragen hast?

Das ist übrigens bei euch ein systematisches Problem. Auch deine Kollegen machen das.

Ihr könnt nicht einfach zwei building=yes + elevator=yes + … übereinander eintragen. Das verletzt erstens osm.wiki/One_feature,_one_OSM_element und zweitens könnt ihr von normalen Datennutzern nicht erwarten, dass die level=* auswerten. Normale (das sind die meisten) Datennutzer erkennen dort zwei Gebäude am selben Ort.

Bitte erfasst daher nur einen Aufzug als Polygon und taggt diesen halt mit level=0;1 (oder wie auch immer das örtliche level-System ist). Dann ist die One-Feature-One-OSM-Object-Regel eingehalten und Nutzer ohne Indoor-Bewusstsein kommen damit auch klar.

Ich möchte dich bitten, daher dies hier in Sonneberg und auch an den anderen Stationen, wo du aktiv warst zu korrigieren. (gilt auch für deine Kollegen, bitte weiterleiten)

Den Vandalismus von 2012 habe ich schon gesehen (frei nach "Wer einmal lügt [Scheiß macht], dem glaubt man nicht" habe ich gleich alle Edits von fufzich genau geprüft). Dass er es ins Forum geschafft hatte, habe ich nicht entdeckt, danke dafür, projecter63.

Ich habe ihm gestern Abend per PN mitgeteilt, dass er gesperrt werden wird, wenn er das noch einmal macht. Bei der Drohung bleibe ich.

Just for documentation purposes: This changeset has been reverted by changeset/13197709 where the changset comment is: "reverting 13082231"

Entschuldigung für das doppelte Posten der Revert-Fertig-Meldung.

Siehe auch meine soeben erstellte OSM-Note: note/515775

Glaub mir (oder beweise das Gegenteil). Das Auswerten von Relationen frisst Zeit. Wenn du z.B. mit libosmium OSM-Daten einliest, geht mindestens das Dreifache an Zeit drauf, wenn du Multipolygone mit verarbeitest.

Wenn wir alle nicht-einmaligen Tags durch Vererbung übergeben wollen, dann sollten wir uns fragen, warum wir nicht z.B. eine Sammelrelation für alle operator=DB Netz AG pflegen?!

Man kann auch eine stop_area-Relation haben und zwei Betriebsstellenrelation, die aber keine ÖPNV-Tags habem. ;-)

Dass wir nicht für einen Renderer/einen speziellen Nutzer taggen, ist ein Argument. Trotzdem tagge ich persönlich immer den Namen an die Halteposition, weil ich nicht von jedem Auswerter verlangen möchte, die Relationen auszuwerten.

Es mag für Mapper und Theoretiker schön elegant aussehen, aber OSM ist ein Projekt von Praktikern, die auch mal auf das, was in Lehrbüchern geschrieben steht, pfeifen. Das Auswerten von Relationen frisst unglaublich viel Zeit (auch wenn man effiziente Wege wählt), da man nicht nur eine Rekursionsebene hat (Ways referenzieren Nodes), sondern zwei (Relationen referenzieren Ways und Nodes, Ways referenzieren Nodes).

Das Weglassen von name an den Objekten und ausschließliche Taggen an der Relation widerspricht dem sonst bei OSM gelebten Grundsatz, Attribute lieber mehrfach (und redundant) zu erfassen, anstatt sie über Sammelrelations-artige Relationen an Relationen zu erfassen.

Dann aber bitte als official_name=* und nicht als name=*. name=* sollte das sein, was vor Ort steht.

Ich war gestern dort und habe zahlreiche Fotos gemacht. Die Erkenntnisse habe ich jetzt in OSM eingetragen. changeset/37243469

Wie gesagt, deine Edits bei network und operator sind ok (ich heiße sie sogar gut).

Es genügt, einen railway=tram_stop pro Haltestelle zu haben (das ist der Node, der mit keinem Gleis verbunden ist). Die Haltepositionen bekommen railway=stop + public_transport=stop_position. Auf der S 2 war das mal so mal so, weil ich die Tram 1, die S 1 und ein paar Linien vor ein paar Monaten schon mal dahingehend verbessert habe. Wie du wohl selber weißt, teilen sich S 2 und 1 bzw. S 1 in der Kaiserstr./Kaiserallee den Fahrweg.

Entschuldigung, aber dein Änderungssatz-Kommentar ist irreführend. osm.wiki/DE:Good_changeset_comments

Du hast in diesem Änderungssatz nicht nur bei network=* das " (KVV)" entfernt und bei operator=* das " (VBK)" durch " GmbH" ersetzt, damit bin ich einverstanden. Du hast aber auch noch zahlreiche railway=stop in railway=tram_stop umgetaggt. Das halte ich für falsch. Die Haltestellen waren schon gemappt (mit einem Zentralnode mit railway=tram_stop). Das genügt IMHO; die Haltepositionen brauch nicht auch noch mit railway=tram_stop beglückt zu werden. Siehe dazu osm.wiki/One_feature,_one_OSM_element

railway=stop ist das Infrastrukturäquivalent zu public_transport=stop_position.

Ich möchte dich daher bitten, das Umtaggen von railway=stop rückgängig zu machen.

Ich war heute Nachmittag vor Ort und habe mir die Örtlichkeit angesehen. Der Tropfen existiert. barrier=hedge passt schon. Mittlerweile ist der Bereich fertig. In der Gartenstr. 69a und 69b sind schon einige Wohnungen bezogen (sieht man daran, dass Zeug auf dem Balkon steht, das nicht nach Baustellenmaterial aussieht), die Geschäftsräume in den Erdgeschossen sind noch nicht fertig.

Ich werde den Änderungssatz gleich revertieren und später meine Ergänzungen aus der Ortsbegehung anbringen.