Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 29.06.2013 18:10, schrieb Peter Wendorff: Am 29.06.2013 16:16, schrieb fly: Am 29.06.2013 11:32, schrieb Peter Wendorff: Am 29.06.2013 02:40, schrieb fly: Wenn keine Relationsunterstützung vorhanden ist, müssen alle Änderungen welche Relationen beeinflussen können, nicht möglich sein. Dann kommt der RelationMapper vorbei und meint, eine Relation Hessen anlegen zu müssen, die alle Elemente Hessens enthält. Ja, das ist nicht gewollt, ja, das wird hoffentlich schnellstens von anderen korrigiert, aber darum geht es hier ja gerade: Bis es jemand korrigiert - und machen wir uns nichts vor, im zweifelsfall dauert das schon ein paar Stunden - wäre in einem solchen Fall kein Bearbeiten mehr möglich durch Editoren, die keine Relationsunterstützung haben, denn wenn ich einen Node bearbeite, kann ich aus einer Adresse eine Straßenlaterne machen und die auch noch ans andere Ende der Stadt schieben - auf einmal ist eine Straßenlaterne in 'ner associated_Street-Relation - Relation kaputt. Jetzt wirfst Du aber einiges zusammen ! Solche Sammel-Relation werden leider immer noch zu sehr geduldet, gehören aber gelöscht. Dafür gibt es wahrlich andere Methoden. Das ist mir klar, aber trotzdem ein Problem, was aus deiner Forderung folgt, denn wie soll ein Editor - erkennen, dass es eine Sammelrelation ist? Wenn das aber nicht automatisch erkennbar ist, dann wird ja das Bearbeiten der Relation durch den Editor deiner Vorstellung nach blockiert, und da Relationen nicht unterstützt werden, kann der betroffene Nutzer die Relation auch nicht löschen. Dann muß mensch halt in solchen Fällen über den Graben springen und anfangen zu kommunizieren. * Ein(e) erfahrene(n) lokale(n) Mapper_in persönlich kontaktieren. * Eine Mail an eine Mailingliste schreiben * ein neues Objekt mit fixme=* und note/description=* erstellen * eine neue Note erstellen * einen besseren Editor kennen lernen (vielleicht mit persönlich Anleitung (mail)) * Kontakt zu den Entwickler_innen der Software aufnehmen Das Problem sollte somit nicht lange bestehen und beim nächsten Mal kann sich der/die Betroffene vielleicht schon selber helfen bzw sogar anderen helfen und hat selber auf jeden Fall dazugelernt. Kommunikation ist in unser Gemeinschaft ja definitiv begrüßenswert. [...] Leider werden sehr selten existierende Objekte wiederverwendet und die Editoren sind auch oft nicht hilfreich, allerdings eine Adresse in eine Straßenlaterne zu verwandelt ist wohl nicht empfehlendswert und sollte von einfachen Editoren verhindert werden. Wie denn? Jetzt verlangst du auch noch, dass Editoren alle Tags interpretieren können, einschließlich neuer Tags, denn um sowas sinnvoll zu unterbinden, müsste eine Bedeutungsänderung durch die Änderung von Tags stattfindet. Wie aber sollte das z.B. bei einem neuen ÖPNV-Schema passieren? Insbesondere darf damit nicht verhindert werden, dass eine Bedeutungänderung da vorgenommen wird, wo sie in der Realität aber stattgefunden hat. Wenn also eine Kirche zur Disco wird (schon vorgekommen), dann muss ich das auch entsprechend in OSM anpassen können. Wenn ich dabei gleichzeitig die Position korrigiere, weil die Kirche immer schon 10 Meter zu weit westlich stand - dann ist auch das korrekt. Verrat mir mal, wie eine Software das erkennen und unterscheiden können soll. Um mal wieder zum Thema zurückzukehren: Bei einer associatedStreet-Relation wären solche Änderungen kein Problem. Beim Verschieben kenne ich so einige passierte Anwenderfehler. Ist mir selbst auch schon mit JOSM passiert, obwohl ich eher vorsichtig unterwegs bin und lieber doppelt checke. Wobei ~50 Meter vielleicht eine ansprechende Grenze für Punkte sind, wenn auch wohl die Punktdichte (Wolke) eine Rolle spielt. Richtlinien/-werte könnte mensch erarbeiten zB: * Keine totalen Sinn Veränderungen: * highway=* sollte highway= bleiben * austauschbare Tags für Gebäude (amenity,shop,craft,leisure?) * grobe Geometrieerhaltung (normale Linie bleibt normale Linie, Area bleibt Area) Deutlich weiter ausführbar ! Auch das Verschieben über große Entfernungen ist problematisch und sollte mit einfachen Editoren nicht möglich sein oder kennen die sowas wie incomplete. In meiner Mapperkarriere musste ich bisher nur drei Mal so einen Edit bewerkstelligen, weiß allerdings nicht wie ich das mit iD oder Potlatch2 machen kann ohne eine halbe Großstadt runterzuladen. Beim Verschieben über größere Entfernungen gebe ich dir recht, dass das normalerweise nicht vorkommen sollte, aber ausschließen würd ich's nicht, und ob das aus versehen passiert, bezweifle ich (wenn die Software nicht einen Bug hat - lat/lon vertauscht, negiert oder koordinaten vergessen und auf 0 gesetzt). Ja, solche Fälle bleiben leider immer an der Gemeinschaft hängen, wobei Deine Beispiele leider ein wenig einseitig gewählt sind und zumindest bei Potlatsch2 tickets mit so gravierenden Fehlern leider wesentlich länger brauchen um geschlossen zu werden, als bei
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 29.06.2013 02:40, schrieb fly: Wenn keine Relationsunterstützung vorhanden ist, müssen alle Änderungen welche Relationen beeinflussen können, nicht möglich sein. Dann kommt der RelationMapper vorbei und meint, eine Relation Hessen anlegen zu müssen, die alle Elemente Hessens enthält. Ja, das ist nicht gewollt, ja, das wird hoffentlich schnellstens von anderen korrigiert, aber darum geht es hier ja gerade: Bis es jemand korrigiert - und machen wir uns nichts vor, im zweifelsfall dauert das schon ein paar Stunden - wäre in einem solchen Fall kein Bearbeiten mehr möglich durch Editoren, die keine Relationsunterstützung haben, denn wenn ich einen Node bearbeite, kann ich aus einer Adresse eine Straßenlaterne machen und die auch noch ans andere Ende der Stadt schieben - auf einmal ist eine Straßenlaterne in 'ner associated_Street-Relation - Relation kaputt. Einen Weg aufsplitten: unmöglich für viele Wege, über die Buslinien etc. verlaufen. Zwei Wege mergen: genauso unmöglich, gleiche Begründung. Wenn deine Forderung also eingehalten würden, wären Editoren ohne Relationsunterstützung streng genommen nicht nutzbar. [...] Hast Du denn gute Ideen für die Oberfläche? Vielleicht eine, die sich halbwegs konsistent über Relationentypen hinweg implementieren ließe? [...] Da werden wir wohl nicht drumherum kommen. Da Relationen untereinander sehr verschieden sind, muss man jede einzeln betrachten. [...] Auch ein bisschen Naivität der Entwickler, wie komplex das System generell ist, spielt wohl mit. Wieso wirfst Du jetzt irgendwelche Entwicklern Naivität vor? Naiv, weil sie sich nicht rangetraut haben? Irgendwie falsch. Naiv, weil sie sich das Thema vorgenommen haben, aber daran gescheitert sind? Wer sagt das? Der JOSM-Relationeneditor ist sehr technisch, nicht in allen Belangen klasse, aber er funktioniert. Eine einfache Oberfläche gibt es vielleicht einfach nicht, weil eben keiner eine gute Idee dafür hatte - und das, alles andere als naiv, vielleicht auch erkannt hat. Ich meinte eigentlich eher, dass da leider oft nicht alles beachtet wird und anstatt dann erst mal Änderungen zu verweigern einfach über die Fehler hinweggegangen wird. Die strenge Haltung dazu: Jede Änderung an Objekten, die Teil von Relationen sind, ist zu verweigern. Wie oben bereits begründet funktioniert das nicht, weil es Editoren unbrauchbar machen würde. Wenn die aber nicht gemeint ist: Was sollte dann erlaubt sein und was nicht? [...] Alles gleichzeitig anzuzeigen ist aber ganz schön schwierig, und macht das auch nicht unbedingt besser. Das muss ja auch nicht sein. Da kann man filtern bzw ein-/ausblenden. Doch, das muss sein, wenn Du willst, dass man Relationen nicht kaputtmachen kann. Das muss nicht immer sein - insofern hast Du recht, aber wenn Relationen sichtbar sein sollten, müssten sie per default erstmal alle erkennbar sein, insofern auch alle eingeblendet werden, und auch dann muss es noch halbwegs sinnvoll sein, was man als Nutzer vor sich sieht. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 29. Juni 2013 11:32 schrieb Peter Wendorff wendo...@uni-paderborn.de: Die strenge Haltung dazu: Jede Änderung an Objekten, die Teil von Relationen sind, ist zu verweigern. Wie oben bereits begründet funktioniert das nicht, weil es Editoren unbrauchbar machen würde. Aber doch zurecht. Wenn ein bestimmter Relationstyp oder Subset davon vom Editor nicht unterstützt wird (rein hypothetisches Beispiel: Multipolygon-Relationen mit mehr als einem outer-Member), dann führen bestimmte Modifikationen im Kleinen (einzelner Member) quasi zwangsläufig dazu, dass was größeres (ganze Relation) kaputt geht, von daher wäre es nur sinnvoll, in diesem Fall nicht editieren zu lassen (was wiederum bereits eine Art von Unterstützung wäre). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 29.06.2013 11:32, schrieb Peter Wendorff: Am 29.06.2013 02:40, schrieb fly: Wenn keine Relationsunterstützung vorhanden ist, müssen alle Änderungen welche Relationen beeinflussen können, nicht möglich sein. Dann kommt der RelationMapper vorbei und meint, eine Relation Hessen anlegen zu müssen, die alle Elemente Hessens enthält. Ja, das ist nicht gewollt, ja, das wird hoffentlich schnellstens von anderen korrigiert, aber darum geht es hier ja gerade: Bis es jemand korrigiert - und machen wir uns nichts vor, im zweifelsfall dauert das schon ein paar Stunden - wäre in einem solchen Fall kein Bearbeiten mehr möglich durch Editoren, die keine Relationsunterstützung haben, denn wenn ich einen Node bearbeite, kann ich aus einer Adresse eine Straßenlaterne machen und die auch noch ans andere Ende der Stadt schieben - auf einmal ist eine Straßenlaterne in 'ner associated_Street-Relation - Relation kaputt. Jetzt wirfst Du aber einiges zusammen ! Solche Sammel-Relation werden leider immer noch zu sehr geduldet, gehören aber gelöscht. Dafür gibt es wahrlich andere Methoden. JOSM kann zB mit externen Listen umgehen Leider werden sehr selten existierende Objekte wiederverwendet und die Editoren sind auch oft nicht hilfreich, allerdings eine Adresse in eine Straßenlaterne zu verwandelt ist wohl nicht empfehlendswert und sollte von einfachen Editoren verhindert werden. Auch das Verschieben über große Entfernungen ist problematisch und sollte mit einfachen Editoren nicht möglich sein oder kennen die sowas wie incomplete. In meiner Mapperkarriere musste ich bisher nur drei Mal so einen Edit bewerkstelligen, weiß allerdings nicht wie ich das mit iD oder Potlatch2 machen kann ohne eine halbe Großstadt runterzuladen. Einen Weg aufsplitten: unmöglich für viele Wege, über die Buslinien etc. verlaufen. Genau das sollte der Editor aber automatisch können oder es ganz bleiben lassen, wobei splitten noch einfach ist. Wie sieht das denn beim unglue von iD und Potlatch2 aus ? Wird da drauf hingewiesen, dass mensch gerade Relationen zerpfückt ? Zwei Wege mergen: genauso unmöglich, gleiche Begründung. Das selbe wie splitten, aber häufig eh nicht möglich. Wenn deine Forderung also eingehalten würden, wären Editoren ohne Relationsunterstützung streng genommen nicht nutzbar. Ja, schon ein POI-Editor sollte mit Multipolygonen umgehen können und diese zumindest sichtbar machen. s.u. [...] Hast Du denn gute Ideen für die Oberfläche? Vielleicht eine, die sich halbwegs konsistent über Relationentypen hinweg implementieren ließe? [...] Da werden wir wohl nicht drumherum kommen. Da Relationen untereinander sehr verschieden sind, muss man jede einzeln betrachten. [...] Auch ein bisschen Naivität der Entwickler, wie komplex das System generell ist, spielt wohl mit. Wieso wirfst Du jetzt irgendwelche Entwicklern Naivität vor? Naiv, weil sie sich nicht rangetraut haben? Irgendwie falsch. Naiv, weil sie sich das Thema vorgenommen haben, aber daran gescheitert sind? Wer sagt das? Der JOSM-Relationeneditor ist sehr technisch, nicht in allen Belangen klasse, aber er funktioniert. Eine einfache Oberfläche gibt es vielleicht einfach nicht, weil eben keiner eine gute Idee dafür hatte - und das, alles andere als naiv, vielleicht auch erkannt hat. Ich meinte eigentlich eher, dass da leider oft nicht alles beachtet wird und anstatt dann erst mal Änderungen zu verweigern einfach über die Fehler hinweggegangen wird. Die strenge Haltung dazu: Jede Änderung an Objekten, die Teil von Relationen sind, ist zu verweigern. Wie oben bereits begründet funktioniert das nicht, weil es Editoren unbrauchbar machen würde. Sorry, aber dann sind die Editoren unbrauchbar und für mich nicht akzeptabel. Entweder der Editor verhindert das Verändern oder kann automatisch mit Relationen um gehen oder gibt Warnungen heraus und ermöglicht das manuelle Editieren der Relationen. Die/Der Benutzer_in kann sich dann immer noch entscheiden welchen sie/er verwenden will bzw ob mensch sich die Änderung der Relation zutraut. Deshalb meinte ich auch, dass manche Entwickler_innen in dieser Sache sehr naiv waren/sind. Relationen sind ein Objekttyp und ohne alle Typen zu unterstützen wird es schwierig. Das sieht mensch auch gut and den POI-Editoren. Ohne geschlossene Linien zu unterstützen wird es schwierig und eigentlich müssten auch Multipolygon beachtet werden. Wenn die aber nicht gemeint ist: Was sollte dann erlaubt sein und was nicht? [...] Alles gleichzeitig anzuzeigen ist aber ganz schön schwierig, und macht das auch nicht unbedingt besser. Das muss ja auch nicht sein. Da kann man filtern bzw ein-/ausblenden. Doch, das muss sein, wenn Du willst, dass man Relationen nicht kaputtmachen kann. Das muss nicht immer sein - insofern hast Du recht, aber wenn Relationen sichtbar sein sollten, müssten sie per default erstmal alle erkennbar sein, insofern auch alle eingeblendet werden, und auch dann muss es noch halbwegs
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 29.06.2013 16:16, schrieb fly: Am 29.06.2013 11:32, schrieb Peter Wendorff: Am 29.06.2013 02:40, schrieb fly: Wenn keine Relationsunterstützung vorhanden ist, müssen alle Änderungen welche Relationen beeinflussen können, nicht möglich sein. Dann kommt der RelationMapper vorbei und meint, eine Relation Hessen anlegen zu müssen, die alle Elemente Hessens enthält. Ja, das ist nicht gewollt, ja, das wird hoffentlich schnellstens von anderen korrigiert, aber darum geht es hier ja gerade: Bis es jemand korrigiert - und machen wir uns nichts vor, im zweifelsfall dauert das schon ein paar Stunden - wäre in einem solchen Fall kein Bearbeiten mehr möglich durch Editoren, die keine Relationsunterstützung haben, denn wenn ich einen Node bearbeite, kann ich aus einer Adresse eine Straßenlaterne machen und die auch noch ans andere Ende der Stadt schieben - auf einmal ist eine Straßenlaterne in 'ner associated_Street-Relation - Relation kaputt. Jetzt wirfst Du aber einiges zusammen ! Solche Sammel-Relation werden leider immer noch zu sehr geduldet, gehören aber gelöscht. Dafür gibt es wahrlich andere Methoden. Das ist mir klar, aber trotzdem ein Problem, was aus deiner Forderung folgt, denn wie soll ein Editor - erkennen, dass es eine Sammelrelation ist? Wenn das aber nicht automatisch erkennbar ist, dann wird ja das Bearbeiten der Relation durch den Editor deiner Vorstellung nach blockiert, und da Relationen nicht unterstützt werden, kann der betroffene Nutzer die Relation auch nicht löschen. [...] Leider werden sehr selten existierende Objekte wiederverwendet und die Editoren sind auch oft nicht hilfreich, allerdings eine Adresse in eine Straßenlaterne zu verwandelt ist wohl nicht empfehlendswert und sollte von einfachen Editoren verhindert werden. Wie denn? Jetzt verlangst du auch noch, dass Editoren alle Tags interpretieren können, einschließlich neuer Tags, denn um sowas sinnvoll zu unterbinden, müsste eine Bedeutungsänderung durch die Änderung von Tags stattfindet. Wie aber sollte das z.B. bei einem neuen ÖPNV-Schema passieren? Insbesondere darf damit nicht verhindert werden, dass eine Bedeutungänderung da vorgenommen wird, wo sie in der Realität aber stattgefunden hat. Wenn also eine Kirche zur Disco wird (schon vorgekommen), dann muss ich das auch entsprechend in OSM anpassen können. Wenn ich dabei gleichzeitig die Position korrigiere, weil die Kirche immer schon 10 Meter zu weit westlich stand - dann ist auch das korrekt. Verrat mir mal, wie eine Software das erkennen und unterscheiden können soll. Auch das Verschieben über große Entfernungen ist problematisch und sollte mit einfachen Editoren nicht möglich sein oder kennen die sowas wie incomplete. In meiner Mapperkarriere musste ich bisher nur drei Mal so einen Edit bewerkstelligen, weiß allerdings nicht wie ich das mit iD oder Potlatch2 machen kann ohne eine halbe Großstadt runterzuladen. Beim Verschieben über größere Entfernungen gebe ich dir recht, dass das normalerweise nicht vorkommen sollte, aber ausschließen würd ich's nicht, und ob das aus versehen passiert, bezweifle ich (wenn die Software nicht einen Bug hat - lat/lon vertauscht, negiert oder koordinaten vergessen und auf 0 gesetzt). Einen Weg aufsplitten: unmöglich für viele Wege, über die Buslinien etc. verlaufen. Genau das sollte der Editor aber automatisch können oder es ganz bleiben lassen, wobei splitten noch einfach ist. Wenn Du forderst, ein Editor sollte Relationen unterstützen: Ja, das sollte jeder Editor. Aber wenn das der Punkt ist, dann reden wir hier nicht darüber, was ein Editor können sollte, sondern darüber, wann Editoren verboten/geblockt werden sollten. [...] Die strenge Haltung dazu: Jede Änderung an Objekten, die Teil von Relationen sind, ist zu verweigern. Wie oben bereits begründet funktioniert das nicht, weil es Editoren unbrauchbar machen würde. Sorry, aber dann sind die Editoren unbrauchbar und für mich nicht akzeptabel. Entweder der Editor verhindert das Verändern oder kann automatisch mit Relationen um gehen oder gibt Warnungen heraus und ermöglicht das manuelle Editieren der Relationen. Dann sind wir uns ja quasi einig: Ein Editor, der sich nicht extrem stark beschränkt (z.B. auf einzelne Tags an bestehenden Objekten) ist ohne Unterstützung von Relationen unbrauchbar. Das wollte ich auch nicht bestreiten, sondern deine Forderung, die versehentliche Bearbeitung/Zerstörung von Relationen zu verhindern als nicht realisierbar herausstellen, wenn Relationen nicht generell vom Editor mit unterstützt werden. [...] Das muss ja auch nicht sein. Da kann man filtern bzw ein-/ausblenden. Doch, das muss sein, wenn Du willst, dass man Relationen nicht kaputtmachen kann. Das muss nicht immer sein - insofern hast Du recht, aber wenn Relationen sichtbar sein sollten, müssten sie per default erstmal alle erkennbar sein, insofern auch alle eingeblendet werden, und auch dann muss es noch halbwegs sinnvoll sein, was man
Re: [Talk-de] Wie Adressen richtig richtig mappen?
On 26.06.2013 21:36, Peter Wendorff wrote: Am 26.06.2013 17:08, schrieb fly: Am 26.06.2013 09:07, schrieb Tobias Knerr: Am 26.06.2013 02:05, schrieb fly: On 26.06.2013 01:42, Tirkon wrote: Die große Mehrheit der Mapper wird sie überhaupt nicht kennen. Woran das wohl wieder einmal liegt ? Fehlende Relationsunterstützung der Editor-Software ? Prinzipielle Eigenschaften des Konzepts Relation, die es schwer machen, einfach nutzbare Bedienoberflächen zum Bearbeiten von Relationen anzubieten. Ich denke da eher an eine Mehrheit, welche sich häufig gegen Relationen ausspricht, anstatt sich Gedanken über diese Oberflächen zu machen. Siehe zB auch: https://josm.openstreetmap.de/ticket/8336 Als erstes halte ich nichts von verbergen! Somit sollten nicht nur alle Tags ersichtlich sein sondern auch Mitgliedschaften. Wenn keine Relationsunterstützung vorhanden ist, müssen alle Änderungen welche Relationen beeinflussen können, nicht möglich sein. Als nächstes kommen dann wohl Änderungen bei denen es automatisch möglich ist die Relationen zu erhalten/ergänzen. Dazu muß aber schon einiges beachtet (Reihenfolge,Rollen etc) werden und man muß jeden Typ einzeln betrachten und verstanden haben. Hast Du denn gute Ideen für die Oberfläche? Vielleicht eine, die sich halbwegs konsistent über Relationentypen hinweg implementieren ließe? Multipolygone sind mittlerweile in den großen Editoren als solche angezeigt normalerweise; für Routen gibt es IMHO Stile, aber schon die Frage, wie man dann 10 Buslinien auf der gleichen Straße anzeigen soll, ist nicht mehr einfach zu beantworten - und vom Bearbeiten der Relationen haben wir dabei noch gar nicht gesprochen. Wenn Du aber die einfach nutzbare Bedienoberfläche zum Bearbeiten von Relationen im Allgemeinen meinst, und nicht die zig einfach zu nutzenden UIs zum Bearbeiten einzelner Relationstypen, dann wird es eben schon recht schwierig. Relationen als generisches Konzept sind relativ abstrakt. Ja: Routen, Abbiegebeschränkungen und so weiter jeweils einzeln betrachtet sind konkret, aber das setzt dann eben auch voraus, dass diese Dinge einzeln implementiert werden müssten: Ein UI-Konzept für Routen, ein UI-Konzept für Abbiegebeschränkungen, ein UI-Konzept für Multipolygone Da werden wir wohl nicht drumherum kommen. Da Relationen untereinander sehr verschieden sind, muss man jede einzeln betrachten. Ich glaube schon, dass sich Menschen darüber Gedanken gemacht haben, wie generische Relationenbearbeitung aussehen könnte - aber ob dabei wirklich gute Ideen rausgekommen sind, ist eine andere Frage. Auch ein bisschen Naivität der Entwickler, wie komplex das System generell ist, spielt wohl mit. Wieso wirfst Du jetzt irgendwelche Entwicklern Naivität vor? Naiv, weil sie sich nicht rangetraut haben? Irgendwie falsch. Naiv, weil sie sich das Thema vorgenommen haben, aber daran gescheitert sind? Wer sagt das? Der JOSM-Relationeneditor ist sehr technisch, nicht in allen Belangen klasse, aber er funktioniert. Eine einfache Oberfläche gibt es vielleicht einfach nicht, weil eben keiner eine gute Idee dafür hatte - und das, alles andere als naiv, vielleicht auch erkannt hat. Ich meinte eigentlich eher, dass da leider oft nicht alles beachtet wird und anstatt dann erst mal Änderungen zu verweigern einfach über die Fehler hinweggegangen wird. Und wenigstens anzeigen sollten alle Oberflächen solche Relationen somit kann sie auch jeder Mapper kennen. Wie gesagt: ich meinte nicht verbergen sondern Mitgliedschaften wie Tags anzeigen. Eine geeignete Visualisierung in der Datenebene ist eine andere Baustelle. Und wie? JOSM, iD und soweit ich weiß auch Potlatch benutzen für die Darstellung der OSM-Daten mittlerweile Styling-Sprachen, JOSM-Stile kann man ohne tiefere Programmierkenntnisse auch selbst entwerfen. Wie würdest Du denn eine Relation darstellen? Einzelne Stile gibt es übrigens mittlerweile durchaus - zumindest für Radnetze und deren Routen, Wandernetze und deren Routen sowie Buslinien. Für Abbiegebeschränkungen gibt es ein eigenes UI als Plugin: http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/Turnrestrictions, und ich meine mich zu erinnern, dass ich dazu auch 'nen Stil mal hatte. Generell hat JOSM einiges dazugelernt. Zum Beispiel das automatische setzten von Rollen bei associatedStreet bzw Street. Alles gleichzeitig anzuzeigen ist aber ganz schön schwierig, und macht das auch nicht unbedingt besser. Das muss ja auch nicht sein. Da kann man filtern bzw ein-/ausblenden. Kann ich den zweiten Teil so verstehen, dass du associatedStreet wegen eines fehlenden Features (tabellarische Ansicht der aktuellen Auswahl mit sortierbaren Spalten für die Werte) in den Editoren nutzt? Nein, Ich bin eher ein logisch veranlagter Mensch und habe kein Problem mit Relationen. Außerdem bin ich schreib faul und stupides kopieren ist fehleranfällig. Mein erster Edit war schon mit JOSM und dann bin ich dabei geblieben. Gegen
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 26.06.2013 02:05, schrieb fly: On 26.06.2013 01:42, Tirkon wrote: Die große Mehrheit der Mapper wird sie überhaupt nicht kennen. Woran das wohl wieder einmal liegt ? Fehlende Relationsunterstützung der Editor-Software ? Prinzipielle Eigenschaften des Konzepts Relation, die es schwer machen, einfach nutzbare Bedienoberflächen zum Bearbeiten von Relationen anzubieten. Ich verwende ausschließlich Relationen, nicht nur weil es viele solcher Ausnahmen gibt, sonder auch weil sortierte Relationen eine gute Übersicht über noch fehlende Hausnummern bzw. seltsame Nummerierungen bietet. Nun, wie häufig die Ausnahmen sind wäre natürlich interessant. Bei einer Komplettangabe aller Werte, inkl. Postleitzahl und Ort, sollten sie sich aber doch auch tag-basiert bewältigen lassen. Kann ich den zweiten Teil so verstehen, dass du associatedStreet wegen eines fehlenden Features (tabellarische Ansicht der aktuellen Auswahl mit sortierbaren Spalten für die Werte) in den Editoren nutzt? Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
On 06/24/2013 09:45 PM, Ruben Kelevra wrote: Vielleicht einfach die Straße komplett raus werfen und neu hinzufügen. Kann ja nicht soo ewig dauern und ständig werden die Relationen auch nicht aktualisiert. Ja. Raus werfen ist die richtige Option wenn beim fortgeschrittenen Erfassen von Hausnummern und Adressen die Relation so garnichtmehr zur Realität passt. Nur den Aufwand mit dem neu hinzufügen spare ich mir in dem Fall ;) Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 26.06.2013 09:07, schrieb Tobias Knerr: Am 26.06.2013 02:05, schrieb fly: On 26.06.2013 01:42, Tirkon wrote: Die große Mehrheit der Mapper wird sie überhaupt nicht kennen. Woran das wohl wieder einmal liegt ? Fehlende Relationsunterstützung der Editor-Software ? Prinzipielle Eigenschaften des Konzepts Relation, die es schwer machen, einfach nutzbare Bedienoberflächen zum Bearbeiten von Relationen anzubieten. Ich denke da eher an eine Mehrheit, welche sich häufig gegen Relationen ausspricht, anstatt sich Gedanken über diese Oberflächen zu machen. Siehe zB auch: https://josm.openstreetmap.de/ticket/8336 Auch ein bisschen Naivität der Entwickler, wie komplex das System generell ist, spielt wohl mit. Und wenigstens anzeigen sollten alle Oberflächen solche Relationen somit kann sie auch jeder Mapper kennen. Ich verwende ausschließlich Relationen, nicht nur weil es viele solcher Ausnahmen gibt, sonder auch weil sortierte Relationen eine gute Übersicht über noch fehlende Hausnummern bzw. seltsame Nummerierungen bietet. Nun, wie häufig die Ausnahmen sind wäre natürlich interessant. Bei einer Komplettangabe aller Werte, inkl. Postleitzahl und Ort, sollten sie sich aber doch auch tag-basiert bewältigen lassen. Kann ich den zweiten Teil so verstehen, dass du associatedStreet wegen eines fehlenden Features (tabellarische Ansicht der aktuellen Auswahl mit sortierbaren Spalten für die Werte) in den Editoren nutzt? Nein, Ich bin eher ein logisch veranlagter Mensch und habe kein Problem mit Relationen. Außerdem bin ich schreib faul und stupides kopieren ist fehleranfällig. Mein erster Edit war schon mit JOSM und dann bin ich dabei geblieben. Wenn ich mir die Erfahrungen des europäischen Schüler_innen Projekt ansehe, wurden da gute Erfahrungen mit Anfänger_innen + JOSM gemacht. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
fly high wrote Wenn ich mir die Erfahrungen des europäischen Schüler_innen Projekt ansehe, wurden da gute Erfahrungen mit Anfänger_innen + JOSM gemacht. sehe ich ganz genauso. Meine ersten Erfahrungen mit Josm unter Linux sind von 2010. Damals war es eine Herausforderung, *Josm zum Laufen zu bringen* (besonders mit Sat-Bildern als Hintergrund). Das Arbeiten danach war wirklich kinderleicht. Nur haftet Josm immer noch der Makel For experts only an. Gruss walter - [url=osm.wno-edv-service.de/residentials] Missing Residentials Map 1.13[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Wie-Adressen-richtig-richtig-mappen-tp5766425p5767126.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 26.06.2013 17:08, schrieb fly: Am 26.06.2013 09:07, schrieb Tobias Knerr: Am 26.06.2013 02:05, schrieb fly: On 26.06.2013 01:42, Tirkon wrote: Die große Mehrheit der Mapper wird sie überhaupt nicht kennen. Woran das wohl wieder einmal liegt ? Fehlende Relationsunterstützung der Editor-Software ? Prinzipielle Eigenschaften des Konzepts Relation, die es schwer machen, einfach nutzbare Bedienoberflächen zum Bearbeiten von Relationen anzubieten. Ich denke da eher an eine Mehrheit, welche sich häufig gegen Relationen ausspricht, anstatt sich Gedanken über diese Oberflächen zu machen. Siehe zB auch: https://josm.openstreetmap.de/ticket/8336 Hast Du denn gute Ideen für die Oberfläche? Vielleicht eine, die sich halbwegs konsistent über Relationentypen hinweg implementieren ließe? Multipolygone sind mittlerweile in den großen Editoren als solche angezeigt normalerweise; für Routen gibt es IMHO Stile, aber schon die Frage, wie man dann 10 Buslinien auf der gleichen Straße anzeigen soll, ist nicht mehr einfach zu beantworten - und vom Bearbeiten der Relationen haben wir dabei noch gar nicht gesprochen. Wenn Du aber die einfach nutzbare Bedienoberfläche zum Bearbeiten von Relationen im Allgemeinen meinst, und nicht die zig einfach zu nutzenden UIs zum Bearbeiten einzelner Relationstypen, dann wird es eben schon recht schwierig. Relationen als generisches Konzept sind relativ abstrakt. Ja: Routen, Abbiegebeschränkungen und so weiter jeweils einzeln betrachtet sind konkret, aber das setzt dann eben auch voraus, dass diese Dinge einzeln implementiert werden müssten: Ein UI-Konzept für Routen, ein UI-Konzept für Abbiegebeschränkungen, ein UI-Konzept für Multipolygone Ich glaube schon, dass sich Menschen darüber Gedanken gemacht haben, wie generische Relationenbearbeitung aussehen könnte - aber ob dabei wirklich gute Ideen rausgekommen sind, ist eine andere Frage. Auch ein bisschen Naivität der Entwickler, wie komplex das System generell ist, spielt wohl mit. Wieso wirfst Du jetzt irgendwelche Entwicklern Naivität vor? Naiv, weil sie sich nicht rangetraut haben? Irgendwie falsch. Naiv, weil sie sich das Thema vorgenommen haben, aber daran gescheitert sind? Wer sagt das? Der JOSM-Relationeneditor ist sehr technisch, nicht in allen Belangen klasse, aber er funktioniert. Eine einfache Oberfläche gibt es vielleicht einfach nicht, weil eben keiner eine gute Idee dafür hatte - und das, alles andere als naiv, vielleicht auch erkannt hat. Und wenigstens anzeigen sollten alle Oberflächen solche Relationen somit kann sie auch jeder Mapper kennen. Und wie? JOSM, iD und soweit ich weiß auch Potlatch benutzen für die Darstellung der OSM-Daten mittlerweile Styling-Sprachen, JOSM-Stile kann man ohne tiefere Programmierkenntnisse auch selbst entwerfen. Wie würdest Du denn eine Relation darstellen? Einzelne Stile gibt es übrigens mittlerweile durchaus - zumindest für Radnetze und deren Routen, Wandernetze und deren Routen sowie Buslinien. Für Abbiegebeschränkungen gibt es ein eigenes UI als Plugin: http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/Turnrestrictions, und ich meine mich zu erinnern, dass ich dazu auch 'nen Stil mal hatte. Alles gleichzeitig anzuzeigen ist aber ganz schön schwierig, und macht das auch nicht unbedingt besser. Kann ich den zweiten Teil so verstehen, dass du associatedStreet wegen eines fehlenden Features (tabellarische Ansicht der aktuellen Auswahl mit sortierbaren Spalten für die Werte) in den Editoren nutzt? Nein, Ich bin eher ein logisch veranlagter Mensch und habe kein Problem mit Relationen. Außerdem bin ich schreib faul und stupides kopieren ist fehleranfällig. Mein erster Edit war schon mit JOSM und dann bin ich dabei geblieben. Gegen Schreibfaulheit bietet JOSM ja eine recht gute Autovervollständigung von Tags ;) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 26. Juni 2013 21:36 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wenn Du aber die einfach nutzbare Bedienoberfläche zum Bearbeiten von Relationen im Allgemeinen meinst, und nicht die zig einfach zu nutzenden UIs zum Bearbeiten einzelner Relationstypen, dann wird es eben schon recht schwierig. Relationen als generisches Konzept sind relativ abstrakt. Ja: Routen, Abbiegebeschränkungen und so weiter jeweils einzeln betrachtet sind konkret, aber das setzt dann eben auch voraus, dass diese Dinge einzeln implementiert werden müssten: Ja, definitiv müssen verschiedene Relationstypen einzeln implementiert werden, wenn es einfach werden soll. Ein Multipoligon ist eben was komplett anderes als eine Route oder eine Abbiegebeschränkung, und hat daher auch komplett andere Anforderungen, was Darstellung, Bearbeitung und Auswertung angeht. Den perfekten generischen Relationeneditor, der dazu hin noch einfach ist, und dem Mapper das Denken ein wenig abnimmt, wird es nicht geben (auch wenn JOSM sich redlich bemüht und auch Erfolge vorzuweisen hat ;-) ) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Raimond Spekking raimond.spekk...@gmail.com wrote: Wobei ich mit Straßenrelationen noch nie so recht warum geworden bin. Die große Mehrheit der Mapper wird sie überhaupt nicht kennen. Bei Verwendung von Straßenrelationen wird sich früher oder später jemand finden, der sie nicht erkennt und daher die vermeintlich fehlende Adresse mit dem Tag addr: doppelt. Ich habe associatedStreet nur in Ausnahmesituationen zusätzlich zum addr: Tag genutzt, wenn der gleiche Strassenname in beiden benachbarten Kommunen an deren Grenze existierte und das Haus deutlich näher zur falschen Straße stand. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
On 26.06.2013 01:42, Tirkon wrote: Raimond Spekking raimond.spekk...@gmail.com wrote: Wobei ich mit Straßenrelationen noch nie so recht warum geworden bin. Die große Mehrheit der Mapper wird sie überhaupt nicht kennen. Woran das wohl wieder einmal liegt ? Fehlende Relationsunterstützung der Editor-Software ? Bei Verwendung von Straßenrelationen wird sich früher oder später jemand finden, der sie nicht erkennt und daher die vermeintlich fehlende Adresse mit dem Tag addr: doppelt. Wieso, addr:housenumber bleibt doch am Objekt. Ich habe associatedStreet nur in Ausnahmesituationen zusätzlich zum addr: Tag genutzt, wenn der gleiche Strassenname in beiden benachbarten Kommunen an deren Grenze existierte und das Haus deutlich näher zur falschen Straße stand. Bist Du Schweizer ? (Strasse) Ich verwende ausschließlich Relationen, nicht nur weil es viele solcher Ausnahmen gibt, sonder auch weil sortierte Relationen eine gute Übersicht über noch fehlende Hausnummern bzw. seltsame Nummerierungen bietet. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 23.06.2013 14:24, schrieb fly: Am 21.06.2013 18:44, schrieb Frank: Am 21.06.2013 18:24, schrieb Dirk Sohler: Moin! Wie sieht es eigentlich beim Mappen von Adressen aus? ... 1. Einen Node mit addr:housenumber und entsprechenden weiteren addr:-Tags auf die Hausumrandung an die Eingangsstelle setzen 2. Nur das Haus an sich mit den addr:-Tags versehen 3. Einen Node mit entrance-Tag auf die Umrandung setzen und die ganzen anderen addr:-Tags für das Haus selbst benutzen 4. entrance und alle addr:-Tags auf den Node am Eingangspunkt packen Ich tendiere ja rein vom Logischen her zur Möglichkeit 3, da „Beispielstraße 123 in 12345 Stadthausen“ ja ein konkretes Gebäude, und nicht bloß dessen Eingang bezeichnet. Was am sinnvollsten? Grüße, Dirk Hallo Dirk, für normale Wohnbebauung (z.B. 1- o. 2-Familienhäuser) stimme ich dir zu: alle Tags an den Gebäude-Umring hängen nach dm Prinzip so einfach wie möglich. Bei einem Laden oder einer Kneipe im Gebäude (Besucherverkehr) zusätzlich den Entrance-Node setzen und evtl. die Rollstuhl-Eignung dazu. Die Adresse kann aber am Gebäude bleiben. Bei größeren Gebäuden (mehr-Parteien-Mietshaus) kann es mehrere Eingänge mit verschiedenen Hausnummern geben. Dann rutscht die Addr.-Eingabe auf den Node. Es sei denn, man kann das Gebäude sinnvoll in mehrere Gebäude aufteilen (sichtbare Fugen, Gebäudeteile, Brandschutzmauern). +10 Wo bei niemand einen hindert auch Relationen a la associatedStreet oder Street zu verwenden. Somit bleibt bei mir meist nur addr:house* übrig, selten auch noch addr:postcode, da manche Firmen ja ihre eigene PLZ haben. fly Auch +10. Wobei ich mit Straßenrelationen noch nie so recht warum geworden bin. Zur Firmen-PLZ: Kenne ich ausschließlich als Großkunden-PLZ für den postalischen Zustellbereich, nicht aber als Besucheranschrift. Raimond. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Raimond Spekking raimond.spekking at gmail.com writes: Auch +10. Wobei ich mit Straßenrelationen noch nie so recht warum geworden bin. +100 Zu aufwändig. Wenn ich irgendwo nur die Straßenrelationen sehe, dann trage ich die Tags nach und wo beides vorhanden ist und eine Korrektur fällig ist, korrigiere ich nur die Tags und lasse die Relationen links liegen. Werden die Relationen überhaupt von den gängigen Routing-Lösungen ausgewertet? Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
2013/6/24 Manuel Reimer manuel.s...@nurfuerspam.de Raimond Spekking raimond.spekking at gmail.com writes: Auch +10. Wobei ich mit Straßenrelationen noch nie so recht warum geworden bin. +100 Zu aufwändig. Wenn ich irgendwo nur die Straßenrelationen sehe, dann trage ich die Tags nach und wo beides vorhanden ist und eine Korrektur fällig ist, korrigiere ich nur die Tags und lasse die Relationen links liegen. Werden die Relationen überhaupt von den gängigen Routing-Lösungen ausgewertet? Sowie ich es verstehe benutzt wenigstens Nominatim sie. Es ist keiner verpflichted um die zu machen. Das es zu komplex sei, verstehe ich aber nicht. Alle Haüser und Strassteile selektieren (kann einfach mit Search Ctrl-f). Relation machen type=associatedStreet addr: Save Button anklicken Dann Selektion hinzufügen. Roles gehen automatisch Mal sortieren und fertig. Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Jo-2 wrote Das es zu komplex sei, verstehe ich aber nicht. Das Problem bei associatedStreet Co ist die Pflege, nicht die Erstellung. Wenn jemand neue Adressen nachträgt, muß er wissen - und dran denken- diese auch in die Relation mit einzutragen. Und daran hapert es dann. Ist mir selber in meiner Ecke mit meinen Straßen und meinen Häusern passiert - irgendwann hab ich es dann bleiben lassen. Sogar die Rels sind inzwischen weg. Gruss walter - [url=osm.wno-edv-service.de/residentials] Missing Residentials Map 1.13[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Wie-Adressen-richtig-richtig-mappen-tp5766425p5766712.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
On 24.06.2013 13:21, Walter Nordmann wrote: Jo-2 wrote Das es zu komplex sei, verstehe ich aber nicht. Das Problem bei associatedStreet Co ist die Pflege, nicht die Erstellung. Wenn jemand neue Adressen nachträgt, muß er wissen - und dran denken- diese auch in die Relation mit einzutragen. Und daran hapert es dann. Ist mir selber in meiner Ecke mit meinen Straßen und meinen Häusern passiert - irgendwann hab ich es dann bleiben lassen. Sogar die Rels sind inzwischen weg. Es ist doch kein Problem overpass zu verwenden und alle Hausnummern ohne Relation zu finden und diese entsprechend hinzuzufügen. Vielleicht kann JOSM auch eine Warnung ausgeben falls es Objekte mit addr:street findet und auch eine Relation mit dem gleichen Namen. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
On Mon, Jun 24, 2013 at 12:48:00PM +0200, Jo wrote: 2013/6/24 Manuel Reimer manuel.s...@nurfuerspam.de Raimond Spekking raimond.spekking at gmail.com writes: Auch +10. Wobei ich mit Straßenrelationen noch nie so recht warum geworden bin. +100 Zu aufwändig. Wenn ich irgendwo nur die Straßenrelationen sehe, dann trage ich die Tags nach und wo beides vorhanden ist und eine Korrektur fällig ist, korrigiere ich nur die Tags und lasse die Relationen links liegen. Werden die Relationen überhaupt von den gängigen Routing-Lösungen ausgewertet? Sowie ich es verstehe benutzt wenigstens Nominatim sie. Nun ja, es kann damit mehr oder weniger umgehen, aber vor allem beim Update machen die Relationen immer wieder Probleme, weil es da einen Haufen von unmöglichen Sonderfällen zu beachten gibt, die gar nicht alle abfangen werden können, weil sonst die Updates zu lange dauern würden. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Vielleicht einfach die Straße komplett raus werfen und neu hinzufügen. Kann ja nicht soo ewig dauern und ständig werden die Relationen auch nicht aktualisiert. LG Ruben Am 24. Juni 2013 19:59 schrieb Sarah Hoffmann lon...@denofr.de: On Mon, Jun 24, 2013 at 12:48:00PM +0200, Jo wrote: 2013/6/24 Manuel Reimer manuel.s...@nurfuerspam.de Raimond Spekking raimond.spekking at gmail.com writes: Auch +10. Wobei ich mit Straßenrelationen noch nie so recht warum geworden bin. +100 Zu aufwändig. Wenn ich irgendwo nur die Straßenrelationen sehe, dann trage ich die Tags nach und wo beides vorhanden ist und eine Korrektur fällig ist, korrigiere ich nur die Tags und lasse die Relationen links liegen. Werden die Relationen überhaupt von den gängigen Routing-Lösungen ausgewertet? Sowie ich es verstehe benutzt wenigstens Nominatim sie. Nun ja, es kann damit mehr oder weniger umgehen, aber vor allem beim Update machen die Relationen immer wieder Probleme, weil es da einen Haufen von unmöglichen Sonderfällen zu beachten gibt, die gar nicht alle abfangen werden können, weil sonst die Updates zu lange dauern würden. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 21.06.2013 18:44, schrieb Frank: Am 21.06.2013 18:24, schrieb Dirk Sohler: Moin! Wie sieht es eigentlich beim Mappen von Adressen aus? ... 1. Einen Node mit addr:housenumber und entsprechenden weiteren addr:-Tags auf die Hausumrandung an die Eingangsstelle setzen 2. Nur das Haus an sich mit den addr:-Tags versehen 3. Einen Node mit entrance-Tag auf die Umrandung setzen und die ganzen anderen addr:-Tags für das Haus selbst benutzen 4. entrance und alle addr:-Tags auf den Node am Eingangspunkt packen Ich tendiere ja rein vom Logischen her zur Möglichkeit 3, da „Beispielstraße 123 in 12345 Stadthausen“ ja ein konkretes Gebäude, und nicht bloß dessen Eingang bezeichnet. Was am sinnvollsten? Grüße, Dirk Hallo Dirk, für normale Wohnbebauung (z.B. 1- o. 2-Familienhäuser) stimme ich dir zu: alle Tags an den Gebäude-Umring hängen nach dm Prinzip so einfach wie möglich. Bei einem Laden oder einer Kneipe im Gebäude (Besucherverkehr) zusätzlich den Entrance-Node setzen und evtl. die Rollstuhl-Eignung dazu. Die Adresse kann aber am Gebäude bleiben. Bei größeren Gebäuden (mehr-Parteien-Mietshaus) kann es mehrere Eingänge mit verschiedenen Hausnummern geben. Dann rutscht die Addr.-Eingabe auf den Node. Es sei denn, man kann das Gebäude sinnvoll in mehrere Gebäude aufteilen (sichtbare Fugen, Gebäudeteile, Brandschutzmauern). +10 Wo bei niemand einen hindert auch Relationen a la associatedStreet oder Street zu verwenden. Somit bleibt bei mir meist nur addr:house* übrig, selten auch noch addr:postcode, da manche Firmen ja ihre eigene PLZ haben. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Adressen richtig richtig mappen?
Am 21.06.2013 18:24, schrieb Dirk Sohler: Moin! Wie sieht es eigentlich beim Mappen von Adressen aus? ... 1. Einen Node mit addr:housenumber und entsprechenden weiteren addr:-Tags auf die Hausumrandung an die Eingangsstelle setzen 2. Nur das Haus an sich mit den addr:-Tags versehen 3. Einen Node mit entrance-Tag auf die Umrandung setzen und die ganzen anderen addr:-Tags für das Haus selbst benutzen 4. entrance und alle addr:-Tags auf den Node am Eingangspunkt packen Ich tendiere ja rein vom Logischen her zur Möglichkeit 3, da „Beispielstraße 123 in 12345 Stadthausen“ ja ein konkretes Gebäude, und nicht bloß dessen Eingang bezeichnet. Was am sinnvollsten? Grüße, Dirk Hallo Dirk, für normale Wohnbebauung (z.B. 1- o. 2-Familienhäuser) stimme ich dir zu: alle Tags an den Gebäude-Umring hängen nach dm Prinzip so einfach wie möglich. Bei einem Laden oder einer Kneipe im Gebäude (Besucherverkehr) zusätzlich den Entrance-Node setzen und evtl. die Rollstuhl-Eignung dazu. Die Adresse kann aber am Gebäude bleiben. Bei größeren Gebäuden (mehr-Parteien-Mietshaus) kann es mehrere Eingänge mit verschiedenen Hausnummern geben. Dann rutscht die Addr.-Eingabe auf den Node. Es sei denn, man kann das Gebäude sinnvoll in mehrere Gebäude aufteilen (sichtbare Fugen, Gebäudeteile, Brandschutzmauern). -- Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
