DE talk:Luftbilder aus Dortmund/Hausnummern

Methode zum Eintragen

Ich habe in den PLZ-Bereichen 44139, 44135, 44137 und in Kirchhörde bisher das Karlsruhe-Schema benutzt, d.h. für jede Hausnummer existieren die keys addr:city, addr:country, addr:housenumber, addr:postcode, addr:street. Dabei habe ich eine freistehende node auf das Haus (in die Mitte oder in die Nähe des Eingangs) gesetzt. Für das Haus selber existiert lediglich das tag building=yes (Ausnahmen bilden Häuser, bei denen ein Name vergeben wurde, z.B. "Industrie- und Halndelskammer zu Dortmund" o.ä.). Wie macht ihr das/seht ihr das? Das Thema wurde einige Male auf der Mailingliste angesprochen, aber es wäre schön, würden wir zumindest für Dortmund einen gemeinsamen Konsens finden. Da wäre dieser Ort m.E. der Richtige. --MatsH 08:04, 24 March 2010 (UTC)

Wir haben, wie Marc in einem Posting auf der Dortmunder Liste bereits schrieb, uns auf einem der letzten Treffen der Dortmunder Mapper auf ein Adresseintrag auf den Hausumriss bzw. auf den Hauseingang, wenn ein Gebäude mehrere Adressen enthält, geeinigt. Erstere Methode ist im Karlsruher Schema unter http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Einzelnes_Haus_als_Fl.C3.A4che abgehandelt, der zweite Fall auf der Diskussionsseite unter dem Punkt http://wiki.openstreetmap.org/wiki/Talk:Proposed_feature/De:Hausnummern#Mehr_als_eine_Hausnummer_f.C3.BCr_ein_einzelnes_Geb.C3.A4ude.2FNode als Vorschlag von Tordanik eingebracht worden. Dabei interpretiere ich den Begriff "nahe den jeweiligen Eingängen" so, dass ich den Hauseingangspunkt "auf" den Hausumriss setze und zusätzlich noch mit dem zur Zeit noch diskutierten Tag Building=entrance versehe. Als Beispiel habe ich in der Dortmunden Nordstadt den Block, in dem sich unserer Treffpunkt im "Langen August" findet, mit Hauseingängen gemappt, im Block östlich davon sind die Häuser als Fläche getaggt (siehe http://www.openstreetmap.org/?lat=51.527459&lon=7.465475&zoom=18&layers=B000FTF). --M Kucha 12:49, 24 March 2010 (UTC)

Das ist doch mal 'ne Ansage. So wird's gemacht! --MatsH 13:07, 24 March 2010 (UTC)

Mein obiger Beitrag sollte dazu dienen, eine Methode, die den meisten auftretenen Fällen gerecht wird, als Leitlinie für unerfahrene (oder erfahrene, aber von den vielfältigen Alternativen zur Erfassung von Adressen hin und her gerissenen) Mappern zu dienen. Es ist dies ein Weg, mit dem ich persönlich bisher gute Erfahrungen gemacht habe und der den Dortmundern Mappern auch auf dem Treffen plausibel erschien. Es sollte uns aber bewusst sein, dass es viele Alternativen mit genausovielen Befürwortern / Vor- und Nachteilen gibt und damit keiner gehindert werden, nach seiner "best practice" zu mappen. OSM hat bisher und wird auch weiterhin funktionieren. --M Kucha 21:47, 24 March 2010 (UTC)

Die addr:* tags oberhalb von add:street, also postcode,city,country sind in fast allen Fällen redundant und auch nach Karlsruhe-Schema optional. Ich plädiere gegen ihre massenhafte Verwendung Hasemann 15:34, 24 March 2010 (UTC)

Ich stimme Hansemann in allen Punkten zu und mag Redundanz eigentlich auch nicht. Ich möchte aber zu bedenken geben, dass sie nicht grundsätzlich schlecht ist und spätestens der Fallschirmspringer mit defektem Hauptschirm sie zu schätzen lernt. Nach diesem zugegeben sehr schlechten Vergleich einige Punkte, die für die redundante Nutzung aller addr:* tags auf den einzelnen Adressen sprechen. Zum ersten ist vielen Mappern (aus Gründen, die ich selbst schwer nachvollziehen kann) der Gebrauch von Relationen immer noch suspekt. Zum zweiten sind die in der associatedStreet-Relation normalisierten (= nur dort einmal und nicht massenhaft mehrfach bei den Mitgliedern der Ralation verwendeten) addr:* tags beim selektieren eines Hauses im Editor nicht sichtbar, es muss dann erst die beteiligte Relation geöffnet werden. Drittens und für mich am wichtigsten unterstützt der Adress-Layer der Geofabrik die associatedStreet-Relation nicht, so dass eins der aus meiner Sicht brauchbarsten QS-Tools für Adressen im Falle der vorgeschlagenen Redundanzvermeidung nicht mehr genutzt werden kann. Ja, auch ich mappe bewusst nicht für Renderer und andere Tools, aber wir sind a) in einem erfolgsorientierten Pilotprojekt und sollten den Erfolg nicht durch bewusstes Einschränken der Qualitätskontrollen mindern und b) kann die Redundanz auf den membern einer Realtion später immer automatisiert überprüft und auch in die Relation normalisiert werden. Ich halte es daher zur Zeit so, dass ich alle Adresstags auf der Adresse (redundant) festhalte, aber auch die associatedStreet-Relation pflege, da ich diese als natürlich und sinnvoll halte. Ich pflege somit gesehen sogar doppelt redundant, aber ohne schlechtes Gewissens, da wie schon gesagt, alles bei Bedarf in die letzendlich als "beste" ernannte Methode überführbar ist. --M Kucha 21:47, 24 March 2010 (UTC)

Ich habe Worten Taten folgen lassen und die Richtlinien überarbeitet. Frecherweise habe ich ein paar Dinge hinzugeschrieben, die noch nicht diskutiert wurden. MarcelM 00:55, 26 March 2010 (UTC)