Bekommen Straßen auch addr-Keys?

S-Man42 wrote:

Wie sieht es aber mit den Straßen aus? Reicht bei denen einfach der name- und postal_code-Key? Oder sollte da auch addr:[street|country|suburb|city|postcode] rein für bessere Zuordnungen?

Ich dachte, postal_code läge hinter uns... Dafür gibt es doch heutzutage PLZ-Relationen. Ganz zu schweigen davon, daß bisweilen die Häuser links und rechts einer Straße unterschiedliche Postleitzahlen haben.
Zu den addr:*-Tags: Kannst du einer Straße eine Postkarte schicken? Na also.

Oli-Wan wrote:

S-Man42 wrote:

Wie sieht es aber mit den Straßen aus? Reicht bei denen einfach der name- und postal_code-Key? Oder sollte da auch addr:[street|country|suburb|city|postcode] rein für bessere Zuordnungen?

Ich dachte, postal_code läge hinter uns... Dafür gibt es doch heutzutage PLZ-Relationen. Ganz zu schweigen davon, daß bisweilen die Häuser links und rechts einer Straße unterschiedliche Postleitzahlen haben.
Zu den addr:*-Tags: Kannst du einer Straße eine Postkarte schicken? Na also.

Ich kann mich aus meiner Erfahrung heraus nur an einen Fall (seinerzeit in Dortmund) erinnern wo ich ein addr:* an einer Straße sinnvoll fand.
Das war eine Stichstraße und an diese, wurden mittels addr:housenumber die Hausnummern in der Stichstraße erfasst. Fand ich besser als an den Straßennamen noch die Hausnummern zu hängen. Es war klar was gemeint war und sobald die Hausnummern einzeln erfasst waren, konnte das addr:housenumber wieder von der Stichstraße entfernt werden.

@S-Man42: An die Straße kann man die ganze Latte an is-in:* dranhängen, damit eindeutig ist, zu welchem Ort, Kreis, Regierungsbezirk, Land, Staat diese Straße genau gehört. Ein addr:* Tagg gehört meines Erachtens nicht dazu.

Edbert (EvanE)

@Oli-Wan: Mir ist noch nie eine PLZ-Relation über den Weg gelaufen, dafür massenhaft postal_code-Keys. Wie sollte ich nun verfahren. Alle Sachen, wo ich postal_code finde, in eine Relation hängen, sofern ich die passende finde...
@EvanE: is_in habe ich bisher auch kaum gesehen bei Straßen. Ist das jetzt Konsens, sollte ich das generell machen oder war das eher ein "vielleicht könnte man mal". Kam jetzt für mich nicht so raus...

S-Man42 wrote:

Mir ist noch nie eine PLZ-Relation über den Weg gelaufen, dafür massenhaft postal_code-Keys. Wie sollte ich nun verfahren. Alle Sachen, wo ich postal_code finde, in eine Relation hängen, sofern ich die passende finde...

Nein, PLZ-Relationen sind Multipolygone. Diese hier: http://www.openstreetmap.org/browse/relation/1332918 fällt mit der admin-Grenze zusammen, aber es gibt auch welche, die separat eingetragen sind, etwa diese: http://www.openstreetmap.org/browse/relation/1626795 . Wo PLZ auf diese Weise erfaßt sind, braucht man die Straßen nicht mehr entsprechend zu taggen; m.E. sollte man postal_code an Straßen dort sogar ausdrücklich bleiben lassen. PLZ-Bereiche ändern sich bisweilen: ein Polygon ist dann schnell neu zugeschnitten; hängt postal_code an den Straßen, muß man diese Tags auch noch allesamt ändern (oder entsorgen).

@Oli-Wan: Danke, dann schau ich mal, wo ich das Polygon finde 😄
@EvanE: Nochmal zu is_in. Habe gerade mal ins Wiki geschaut. Da wird empfohlen einfach is_in:suburb = Bornim anzugeben, was wiederum is_in:city = Potsdam hat, usw. So dass man eben nicht an jede Straße angeben muss: Bornim; Potsdam; Brandenburg; Germany; Europe und man sich eher hochhangeln kann. Wird das schon genutzt oder soll ich wirklich an jeden Fitzelzweig den ganzen Kladderadatsch ranklemmen? Wie sieht es mit der Sprache aus? Die Beispiele im Wiki sind komplett auf Englisch gehalten...

is_in ist mMn eine Altlast, die mit der flächendeckenden Verfügbarkeit von Gemeindegrenzen (in der Regel) unnötig ist.

S-Man42 wrote:

@EvanE: Nochmal zu is_in. Habe gerade mal ins Wiki geschaut. Da wird empfohlen einfach is_in:suburb = Bornim anzugeben, was wiederum is_in:city = Potsdam hat, usw. So dass man eben nicht an jede Straße angeben muss: Bornim; Potsdam; Brandenburg; Germany; Europe und man sich eher hochhangeln kann. Wird das schon genutzt oder soll ich wirklich an jeden Fitzelzweig den ganzen Kladderadatsch ranklemmen? Wie sieht es mit der Sprache aus? Die Beispiele im Wiki sind komplett auf Englisch gehalten...

Die Latte an is_in:* Taggs stammt noch aus einer Zeit, als es noch keine Relationen gab und damit auch keine Grenz-Relationen. Orte wurden durch einen place-Knoten eher grob markiert. Da wurde is_in:* einerseits genutzt, um die Hierarchie zwischen Orten, Kreisen, Länder und Staaten aufzuzeigen. Andereseits wurde es an Straßen benutzt, um allfälligen falschen Zuordnungen bei der Suche entgegenzuwirken.

Heute braucht man is_in:* kaum noch. Bei Grenzfällen kann es aber immer noch nützlich sein. Ein Tagg ist eben einfacher für den Menschen zu verstehen als eine nicht direkt sichtbare Gebiets-Grenze/-Fläche.

Ich erhalte is_in, wo es benutzt wird, aber pappe es nicht an jede Straße. Letztlich ist da auch viel Geschmackssache und persönliche Vorliebe dabei. Da wo die Gemeindegrenze eine Straße quert mag es mancher auch heute noch an der Straße diesseits und jenseits der Grenze nützlich finden und setzen.

Edbert (EvanE)

OK, kurz gesagt an eine Straße kommt eigentlich nur noch ein name-Tag (von highway und so Kram natürlich abgesehen.)?

S-Man42 wrote:

OK, kurz gesagt an eine Straße kommt eigentlich nur noch ein name-Tag (von highway und so Kram natürlich abgesehen.)?

Was is_in betrifft ja, bis auf wenige besondere Situation (z.B. ggfs. bei Grenzen).
Ansonsten kann man noch über lanes, maxspeed, max*, incline usw. nachdenken.
Aber man muss ja auch noch etwas für den nächsten Mapper übrig lassen. 😉

Edbert (EvanE)

Ja, lanes, lit, maxspeed, surface, etc. meinte ich mich "highway und so Kram"... 🙂 Alles klar, danke.

Sry, noch eine Frage zur postal_code-Relation:
Muss ich die Straßen noch als inner-Member ins Multipolygon eintragen oder mache ich genau gar nichts mehr (heißt: die Straßen sind automatisch mit der PLZ versehen, in dessen Grenzen sie sich befinden)

Soweit ich das verstanden habe hiesse "inner" "etwas das ausgeschnitten wird", also ein "Loch" das nicht zu der Gesamtfläche gehört -> Einfach nichts machen.
Wäre ja auch schlimm, wenn hinter jedem, der das nicht bemerkt hat noch jemand aufräumen müsste ;-)

Danke. Dann lasse ich es jetzt 🙂

EvanE wrote:

Die Latte an is_in:* Taggs stammt noch aus einer Zeit, als es noch keine Relationen gab und damit auch keine Grenz-Relationen.
Edbert (EvanE)

Halb richtig. Relation Nummer eins wurde 2008 erstellt. Korrekt ist, dass der is_in-Tag benötigt, bevor Grenz-Relationen gemappt waren.

Oli-Wan wrote:

Zu den addr:*-Tags: Kannst du einer Straße eine Postkarte schicken? Na also.

Das ist auch die Frage, die ich immer stelle. "addr:*" würde ich nur an Objekten taggen, von denen man sagt "die haben eine Adresse". Eine Strasse oder ein Briefkasten oder ein Baum haben das normalerweise nicht.

Bye
Frederik

Moins,

woodpeck wrote:

"addr:*" würde ich nur an Objekten taggen, von denen man sagt "die haben eine Adresse". Eine Strasse oder ein Briefkasten oder ein Baum haben das normalerweise nicht.

normalerweise 😎

Gruß Wolf

malenki wrote:

EvanE wrote:

Die Latte an is_in:* Taggs stammt noch aus einer Zeit, als es noch keine Relationen gab und damit auch keine Grenz-Relationen.
Edbert (EvanE)

Halb richtig. Relation Nummer eins wurde 2008 erstellt. Korrekt ist, dass der is_in-Tag benötigt, bevor Grenz-Relationen gemappt waren.

Auch nicht ganz richtig. Die Relation Nummer 1 wurde 2008 nicht erstellt, sondern gelöscht.
Die älteste erhaltene Relation ist die Nummer11 Erstellt am 12. August 2006. Also gab es wohl schon immer Relationen.