Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 18.07.2012 20:24, schrieb Tobias Knerr: Die Lösung mit dem Wikipedia-Tag hingegen funktioniert heute bereits gut. Es genügt zwar nicht, wenn es z.B. um Karten in Sammelartikeln für mehrere geografische Objekte geht, die selbst keinen eigenen Artikel bekommen. Diesen Anspruch erhebt es meines Wissens aber auch nicht. +1 Ich finde die Debatte, ob das nun ein Fremdschlüssel ist und welche von beiden Infosammlungen, die wichtigere sei, völlig übertrieben. Eine Auswertung durch WIWOSM ändert für mich auch nicht die Linkrichtung, es bleibt weiterhin eine schwache Referenz von OSM zu WP. Zudem wäre eine Umsiedlung des wikipedia-Tags weit weniger projektfreundlich als es der Zuzug von WIWOSM war, der imho minimalinvasiv geschah. Eine Lösung zu schreiben, die beim Verschieben eines Lemmas in der WP das zugehörige wikipedia-Tag in OSM ändert, oder wenigstens den Nutzer warnt, ist weit einfacher umzusetzen, als das Tag umzusiedeln und sämtliche Software zu brechen, die mittlerweile darauf aufbaut. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 17.07.2012 17:52, schrieb Christian Müller: Am 17.07.2012 08:38, schrieb Frederik Ramm: Allein schon die einfache Frage: Ein Way, der in einer Relation steckt, wird zweigeteilt; wie wirkt sich das auf die Relation aus? kann nicht beantwortet werden, ohne die Relation zu verstehen. Das sehe ich nicht so. Fällt Dir ein Beispiel ein? Abbiegebeschränkungen Oder: Ein Way, der in einer Relation steckt, wird geloescht. Soll die Relation mitgeloescht werden, soll sie ohne diesen Way weiterbestehen, oder muss ein Ersatz-Way in die Relation aufgenommen werden? Das entscheidet der Mapper - die Software muss hiervor geeignet warnen, bzw. die Auflösung dieser Fälle unterstützen. Trotz Warnung muss der Mapper aber dann die Relation verstehen - auch der blutige Anfänger im Zweifelsfall eine seltene Relation, deren Sinn sich ihm nicht einmal erschließt. Weiterhin, verzichtet man auf die bbox-Methode und geht das Problem mit den postal_code-boundaries an, eröffnet sich das Szenario, dass an deren Grenzen eine gleichnamige Straße die postal-boundary schneidet - sind das dann zwei verschiedene Straßen oder eine? Zudem müßte hierfür bei der Post erfragt werden, ob Straßennamen pro postal_code per Definition Post wirklich immer eindeutig sind - imho yes, aber genau weiß ich das nicht. Selbst wenn die Post davon offiziell ausgeht, berücksichtigt sie nur Straßen, an denen es Adressen gibt, alle anderen haben nicht einmal eine Postleitzahl. Der OSM-Datenbank hilft das also im Zweifelsfall nicht, wenn es den gleichen Wegenamen für einen Fussweg mehrfach gibt in der gleichen Gemeinde. 1) Nehmen wir an, Straßenzshg. werden über type=street durch Mapper modelliert: Für eine bbox B lassen sich dann alle Straßen mit Namen N einfach per Overpass oder SQL abfragen. 2) Nehmen wir nun an, Du hast eine Heuristik entwickelt, die trotz mannigfaltiger Geometrien in the wild mittels Bestimmung anhand von nearby- bzw. node-matching Algorithmen halbwegs genau Straßensegmente zu einer Straße zusammenbasteln kann. - Ohne ein neues Objekt in der DB oder in Overpass zu schaffen, welches deine Heuristik kapselt und demzufolge zur Ermittlung mehrerer N in B ersatzweise zu 1) verwendet werden kann, ist das nutzlos. Denn während ich für die Instanz B=Bayern und N=Goethestraße mittels 1) ohne Probleme Resultate erhalte, kann ich das mittels 2) ohne Kapselung gar nicht oder nur so kompliziert, dass es niemand je benutzen wird. Warum sollte man notwendigerweise eine solche Abfrage direkt online über die OSM-Dienste zur Verfügung stellen wollen? Die Frage ist hier wie so oft: wie viel Dienstleister ist OSM, oder inwiefern ist OSM Datenlieferant mit Tools für Mapper und Showcases für User? Die Abfrage 2) ist auch ohne kapselung machbar, wenn sie in ein entsprechendes Tool gepackt werden kann. Nimm die Overpass-API als Beispiel, die IMHO recht einfach lokal installiert werden kann auf einem mehr oder weniger beliebigen Datenextrakt. Füttere deine lokale Overpass-API mit dem Bayern-Extrakt (oder Deutschland-Extrakt), such dir die entsprechende Query aus einem (noch zu entwickelnden) Tool heraus, das das generieren von Queries einfach macht und stell die Frage an deine lokale Datenbank. - Nehmen wir also an die Heuristik wird gekapselt und sorgt dafür, Straßenzusammenhänge tatsächlich richtig zu ermitteln. Dann erfüllt sie den gleichen Zweck wie Relationen vom Typ type=street. Mit dem Unterschied, das letztere von Menschen gepflegt wird und erstere von demjenigen, der die Heuristik erstellt - jemandem, der nie lokales Wissen besitzt, aber alle Fälle genügend genau approximieren können muss. Feststellungen: - falls es diese Heuristik gibt und sie befriedigend genau arbeitet, dann muss sie noch entwickelt werden, andernfalls wäre zu fragen, weshalb sie noch nicht für OSM benutzt wird - es wäre ein API-Wechsel, entweder bei OSM oder Overpass, nötig, der die Heuristik als abfragbares Objekt auf dem Server hinterlegt - die Heuristik anzuwenden benötigt Rechenzeit - 'bottleneck' wurde als Problem bereits angesprochen - eine Möglichkeit, diese Abfrage lokal durchzuführen, würde das Bottleneck auf den Rechner des Users verlagern, die Overpass-API entsprechend zu erweitern durch z.B. eine Overpass-Query-GUI, wäre ein nettes Projekt. - falls Relationen weiterhin als unnötiges Hexenwerk angesehen werden, wären diese Schritte für eine Zahl weiterer Relationen zu wiederholen (type=waterway e.g.) ...innerhalb des Query-GUI-Tools (oder einer darin eingebundenen Scriptsammlung). - _einem_ Entwickler würde die Aufgabe übertragen eine Heuristik zu finden, die genügend genau für _alle_ funktioniert, das dann zu kapseln und als abfragbares Objekt in der DB oder abgeleiteten Projekten zu implementieren ...bzw. im Query-Tool Genauso mit Bundesstrassen - eine Relation, die exakt alle Objekte mit ref=B10 enthaelt, ist unnoetig. Verlaufen irgendwo die B10 und die B12 ein Stueck auf
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 17.07.2012 20:08, schrieb Werner Hoch: Am Dienstag, den 17.07.2012, 02:11 +0200 schrieb Stephan Wolff: Am 16.07.2012 23:04, schrieb Peter Wendorff: - Verlinkung - Ein Wikipediaartikel zu einer Straße sollte nicht mit jedem way sondern mit einem Gesamtobjekt verbunden werden. Inwiefern der Wikipediaartikel überhaupt von osm aus verlinkt werden sollte, und nicht über eine Art XAPI/Overpass-Query, das ist eine andere GEschichte. IMHO gehört der Link eher in die Wikipedia als in die OSM, weil die ganz andere Objekte enthält als OSM enthalten sollte. Der Sinn von Wikipedialinks ist ein anderes Thema, aber wikipedia und url/website-Tags werden verwendet. Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2] nützlich. (Karte-Link neben der Koordinate) s. http://de.wikipedia.org/wiki/Rhein s. http://de.wikipedia.org/wiki/Deutschland Damit können die geographischen Objekte aus OSM in der Karte in Wikipedia dargestellt werden. Den Ansatz andersherum gibt es aber auch, und der wäre genausogut machbar, ohne kuriose Relationen wie Denkmalgeschützte Häuser in Buxtehude anlegen zu müssen. Der würde auf Seiten von Wikipedia eine Auswertung erfordern, was ebensogut machbar ist. Deutsche Bundesstraßen ist kein OSM-Objekt, sondern eine Sammlung von Objekten. +1 +1 Der Artikel in WP hat aber durchaus seine Berechtigung (finde ich). Dazu gehört dann aber eben ein [highway=motorway][ref=A*][bbox=...] als Link hin. Für Bundesstraßen wäre es eher [highway=primary][ref=B*][bbox=...] aber auch das funktioniert nicht korrekt. Für die meisten Artikel in der Wikipedia kann man keine sinnvolle Koordinate angeben. Das schließt aber nicht aus, dass es für einige Artikel sinnvolle Links in beide Richtungen gibt. Hier stellt sich mir nur die Frage, was sich leichter und zuverlässiger verwalten läßt. Eine Relation mit Wikipedia tag oder ein komplexer Ausdruck. Die Bundesstraßen enthalten auch highway=motorway Segmente. Wenn aber ein OSM-Mapper die Relation löscht und neu anlegt, kann nach ID auch nicht mehr gefunden werden - schon bricht das Konstrukt zusammen. Das neu anlegen gleichbedeutender Relationen passiert aber und ist in OSM auch nicht geächtet oder irgendwie unüblich. Das gleiche gilt natürlich auch für andere lineare Objekte wie Flüsse/ Bäche. Oberlauf des Rheins, Unterlauf des Rheins, Rhein - wie viele Objekte willst du denn explizit formulieren? Oder dann doch wieder nur Rhein? Einen Fluss Rhein kenne ich, einen Fluss Oberlauf des Rhein nicht. Die Relation Rhein gibt es schon [1]. Ich erkenne auch hier kein Problem. Hier kann man sich ja an der Wikipedia orientierten. Dort wird nur der Rhein aufgeführt, also sind die Unterabschnitte nicht so wichtig. s. http://de.wikipedia.org/wiki/Rhein Jetzt die Relevanzkriterien der Wikipedia auf OSM zu ziehen, halte ich für falsch. Dann sind also Deines Erachtens Relationen anzulegen für: * http://de.wikipedia.org/wiki/Liste_von_Fl%C3%BCssen_in_Deutschland - wohlgemerkt eine Auswahl von!!! * http://de.wikipedia.org/wiki/Denkmalgesch%C3%BCtzte_Objekte_im_Okres_Brezno Sorry, aber da hinkt diese Forderung meines Erachtens sehr stark. Wenn aber dafür komplexere Query-Links gebraucht werden, dann kann man das auch für die vermeintlich einfachen Fälle umsetzen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Lieber Christian, On Tue, Jul 17, 2012 at 04:09:55PM +0200, Christian Müller wrote: Apropos Nominatim - da könnte man erstmal is_in aufräumen.. Da werden teilweise Gebiete nach ausdehnungslosen place=region nodes benannt, die hunderte km von den Objekten, zu deren Bennenung sie herangezogen werden, entfernt sind. Das ist so gravierend, dass Mapper note= an ihre Gebiete hängen, und sich fragen, warum nach dem vierten Komma ein Begriff steht, den sie überhaupt nicht zuordnen können. Bei einer so freundlich und präzise formulierten Fehlermeldung kann ich natürlich nicht widerstehen, mich sofort darum zu kümmern. Lass mich nur gerade den Papierkorb unterm Schreibtisch hervorholen. In diesem Sinne: *plonk* Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Peter Wendorff schrieb: ohne kuriose Relationen wie Denkmalgeschützte Häuser in Buxtehude anlegen zu müssen. [@Frederik: Dein Einsatz bitte] ;-) Zitat von http://lists.openstreetmap.org/pipermail/talk-de/2012-July/096616.html Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer das Herunterladen zu sortieren. Siehe auch: https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Bye Frederik Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am Mittwoch, den 18.07.2012, 10:28 +0200 schrieb Peter Wendorff: Am 17.07.2012 20:08, schrieb Werner Hoch: Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2] nützlich. (Karte-Link neben der Koordinate) s. http://de.wikipedia.org/wiki/Rhein s. http://de.wikipedia.org/wiki/Deutschland Damit können die geographischen Objekte aus OSM in der Karte in Wikipedia dargestellt werden. Den Ansatz andersherum gibt es aber auch, und der wäre genausogut machbar, ohne kuriose Relationen wie Denkmalgeschützte Häuser in Buxtehude anlegen zu müssen. Der würde auf Seiten von Wikipedia eine Auswertung erfordern, was ebensogut machbar ist. Ja, WIWOSM zeigt meines Wissens nach alles in der Wiki-Seite an, was entsprechend vertagged ist. Es ist egal ob: * 1 Relation erstellt wird mit dem Wikipedia Tag * alle Einzelelemente mit Wikipeda-Tags versehen werden Das Ergebnis ist dasselbe. Dein Vergleich mit den Denkmalgeschützten Häusern hinkt. Sofern die Denkmäler wichtig sind und eine eigene Wikipedia Seite haben, dann kann man den entsprechenden Häusern jeweils ihren eigenen Wikipedia-Link verpassen. s. Eifelturm Der Artikel in WP hat aber durchaus seine Berechtigung (finde ich). Dazu gehört dann aber eben ein [highway=motorway][ref=A*][bbox=...] als Link hin. Für Bundesstraßen wäre es eher [highway=primary][ref=B*][bbox=...] aber auch das funktioniert nicht korrekt. Für die meisten Artikel in der Wikipedia kann man keine sinnvolle Koordinate angeben. Das schließt aber nicht aus, dass es für einige Artikel sinnvolle Links in beide Richtungen gibt. Hier stellt sich mir nur die Frage, was sich leichter und zuverlässiger verwalten läßt. Eine Relation mit Wikipedia tag oder ein komplexer Ausdruck. Die Bundesstraßen enthalten auch highway=motorway Segmente. Wenn aber ein OSM-Mapper die Relation löscht und neu anlegt, kann nach ID auch nicht mehr gefunden werden - schon bricht das Konstrukt zusammen. Das neu anlegen gleichbedeutender Relationen passiert aber und ist in OSM auch nicht geächtet oder irgendwie unüblich. WIWOSM verwendet keine IDs sondern die Wikipedia tags bzw. Interwiki links. Das Konstrukt funktioniert, solange sich die Bedeutung der Wikipedia-Seite nicht verändert. Das gleiche gilt natürlich auch für andere lineare Objekte wie Flüsse/ Bäche. Oberlauf des Rheins, Unterlauf des Rheins, Rhein - wie viele Objekte willst du denn explizit formulieren? Oder dann doch wieder nur Rhein? Einen Fluss Rhein kenne ich, einen Fluss Oberlauf des Rhein nicht. Die Relation Rhein gibt es schon [1]. Ich erkenne auch hier kein Problem. Hier kann man sich ja an der Wikipedia orientierten. Dort wird nur der Rhein aufgeführt, also sind die Unterabschnitte nicht so wichtig. s. http://de.wikipedia.org/wiki/Rhein Jetzt die Relevanzkriterien der Wikipedia auf OSM zu ziehen, halte ich für falsch. Dann sind also Deines Erachtens Relationen anzulegen für: * http://de.wikipedia.org/wiki/Liste_von_Fl%C3%BCssen_in_Deutschland - wohlgemerkt eine Auswahl von!!! * http://de.wikipedia.org/wiki/Denkmalgesch%C3%BCtzte_Objekte_im_Okres_Brezno Nein, beides sind keine geographischen Objekte, sondern Listen/Sammlungen/Collection. Diesen Seiten kann man ebensowenig ein OSM-Objekt zuweisen wie den begriffen Goethe, Mathematik, Universum, Metzger, Bäcker, Sorry, aber da hinkt diese Forderung meines Erachtens sehr stark. Wenn aber dafür komplexere Query-Links gebraucht werden, dann kann man das auch für die vermeintlich einfachen Fälle umsetzen. Der vermeintlich einfache Fall ist, dass sich die Elemente, die zu einer Wikipediaseite gehören eindeutig identifizieren lassen. z.B. mit einem eindeutigen wikipedia tag -- das gibts ja schon. Die Auswertung macht ja schon WIWOSM. Grüße Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 18.07.2012 18:34, schrieb Werner Hoch: Am Mittwoch, den 18.07.2012, 10:28 +0200 schrieb Peter Wendorff: Am 17.07.2012 20:08, schrieb Werner Hoch: Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2] nützlich. (Karte-Link neben der Koordinate) s. http://de.wikipedia.org/wiki/Rhein s. http://de.wikipedia.org/wiki/Deutschland Damit können die geographischen Objekte aus OSM in der Karte in Wikipedia dargestellt werden. Den Ansatz andersherum gibt es aber auch, und der wäre genausogut machbar, ohne kuriose Relationen wie Denkmalgeschützte Häuser in Buxtehude anlegen zu müssen. Der würde auf Seiten von Wikipedia eine Auswertung erfordern, was ebensogut machbar ist. Ja, WIWOSM zeigt meines Wissens nach alles in der Wiki-Seite an, was entsprechend vertagged ist. Es ist egal ob: * 1 Relation erstellt wird mit dem Wikipedia Tag * alle Einzelelemente mit Wikipeda-Tags versehen werden Das Ergebnis ist dasselbe. Dein Vergleich mit den Denkmalgeschützten Häusern hinkt. Sofern die Denkmäler wichtig sind und eine eigene Wikipedia Seite haben, dann kann man den entsprechenden Häusern jeweils ihren eigenen Wikipedia-Link verpassen. s. Eifelturm Leider hinkt der Vergleich eben nicht, weil die Seite Liste der... aus Sicht der Wikipedianer (und evtl. zurecht) doch möglicherweise bitte alle entsprechenden Objekte gleichzeitig anzeigen soll - was nicht dagegen spricht, dass die einzelnen Objekte auf einzelnen Seiten auch nochmal verlinkt sind. Wenn aber ein OSM-Mapper die Relation löscht und neu anlegt, kann nach ID auch nicht mehr gefunden werden - schon bricht das Konstrukt zusammen. Das neu anlegen gleichbedeutender Relationen passiert aber und ist in OSM auch nicht geächtet oder irgendwie unüblich. WIWOSM verwendet keine IDs sondern die Wikipedia tags bzw. Interwiki links. Das Konstrukt funktioniert, solange sich die Bedeutung der Wikipedia-Seite nicht verändert. und solange wir sowas wie den wikipedia-Tag erlauben. Der wikipedia-Tag ist letztlich ein Fremdschlüssel zu einer anderen Datenbank; etwas, was eigentlich in OSM ungerne gesehen wird - sonst könnte ja jeder kommen und eine interne, private Standort-ID für das eigene Unternehmen vergeben. Das kann (im Allgemeinen) niemand verifizieren, korrigieren oder ergänzen. Ich interpretiere den Status Quo hier so, dass im Grunde genommen als Ziel sowas gilt wie die unwichtigere Datenbank hat Fremdschlüssel hin zur wichtigeren Datenbank, nicht andersherum; im Zweifelsfall führe man eine Zwischenschicht für die Verknüpfung ein. Dabei gibt es die Möglichkeit, zu(!) OSM zu linken über - feste objekt-IDs, optional feste versionen. Problem: kann nicht korrigiert werden - feste Position: keine Semantische verknüpfung - manchmal aber eigentlich ausreichend. - komplexere Abfrage: gibt es bisher seltener, ist aber das, was Roland in der Overpass-API mit den stabilen Verweisen umsetzt; ist also auch machbar. Wikipedia ist bisher DER Präzedenzfall dafür, dass 1) feste IDs nicht funktionieren (weil zu viele Links zu oft geändert werden müssten) 2) feste Position nicht ausreicht (weil ja auch gleich das Objekt hervorgehoben werden soll, und deshalb 3) die Abfrage nach Eigenschaften ideal geeignet wäre. Ich hab nichts gegen den wikipedia-Tag an sich; im Gegenteil, ich find ihn enorm praktisch. Aber dieser Tag existierte vor WIWOSM; als es darum ging, von OSM zur Wikipedia zu finden. Wenn das umgedreht wird; wikipedia-Tags also dazu dienen, dass Wikipedia das Objekt in OSM findet, dann ist es meines Erachtens der falsche Ansatz und sollte eben aussterben und durch den Fremdschlüssel auf Seiten der Wikipedia - stabile id per overpass oder ähnliches - ersetzt werden. Jetzt die Relevanzkriterien der Wikipedia auf OSM zu ziehen, halte ich für falsch. Dann sind also Deines Erachtens Relationen anzulegen für: * http://de.wikipedia.org/wiki/Liste_von_Fl%C3%BCssen_in_Deutschland - wohlgemerkt eine Auswahl von!!! * http://de.wikipedia.org/wiki/Denkmalgesch%C3%BCtzte_Objekte_im_Okres_Brezno Nein, beides sind keine geographischen Objekte, sondern Listen/Sammlungen/Collection. Diesen Seiten kann man ebensowenig ein OSM-Objekt zuweisen wie den begriffen Goethe, Mathematik, Universum, Metzger, Bäcker, Dummerweise kann man schon - deshalb haben wir ja haufenweise diese Monsterrelationen: Bundesstraßen in Deutschland, Autobahnen in der Westschweiz oder was auch immer. Sorry, aber da hinkt diese Forderung meines Erachtens sehr stark. Wenn aber dafür komplexere Query-Links gebraucht werden, dann kann man das auch für die vermeintlich einfachen Fälle umsetzen. Der vermeintlich einfache Fall ist, dass sich die Elemente, die zu einer Wikipediaseite gehören eindeutig identifizieren lassen. z.B. mit einem eindeutigen wikipedia tag -- das gibts ja schon. Die Auswertung macht ja schon WIWOSM. Wie gesagt: nichts gegen den Wikipedia-Tag. Ich hab nur was dagegen, Objekte - sprich: Relationen - anzulegen, um einen wikipedia-Tag
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 18.07.2012 10:28, schrieb Peter Wendorff: Am 17.07.2012 20:08, schrieb Werner Hoch: Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2] nützlich. (Karte-Link neben der Koordinate) [...] Damit können die geographischen Objekte aus OSM in der Karte in Wikipedia dargestellt werden. Den Ansatz andersherum gibt es aber auch, und der wäre genausogut machbar, ohne kuriose Relationen wie Denkmalgeschützte Häuser in Buxtehude anlegen zu müssen. Wikipedia hat mit den Artikelnamen ein (meistens) stabiles Linkziel, so dass sich eine Verlinkung in diese Richtung unkompliziert machen lässt. Umgekehrt wäre das nicht so einfach. IDs sind nicht für externe Verwendung gedacht, weil sie sich beim Bearbeiten leicht mal ändern können. Das Erstellen von Queries für die Verlinkung mit Overpass API o.ä. wäre denkbar, ist derzeit aber eher Theorie und nicht unbedingt geeignet für OSM-Laien, wie es Wikipedianer ja sind. Die Lösung mit dem Wikipedia-Tag hingegen funktioniert heute bereits gut. Es genügt zwar nicht, wenn es z.B. um Karten in Sammelartikeln für mehrere geografische Objekte geht, die selbst keinen eigenen Artikel bekommen. Diesen Anspruch erhebt es meines Wissens aber auch nicht. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 18.07.2012 20:24, schrieb Tobias Knerr: Am 18.07.2012 10:28, schrieb Peter Wendorff: Am 17.07.2012 20:08, schrieb Werner Hoch: Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2] nützlich. (Karte-Link neben der Koordinate) [...] Damit können die geographischen Objekte aus OSM in der Karte in Wikipedia dargestellt werden. Den Ansatz andersherum gibt es aber auch, und der wäre genausogut machbar, ohne kuriose Relationen wie Denkmalgeschützte Häuser in Buxtehude anlegen zu müssen. Wikipedia hat mit den Artikelnamen ein (meistens) stabiles Linkziel, so dass sich eine Verlinkung in diese Richtung unkompliziert machen lässt. Umgekehrt wäre das nicht so einfach. IDs sind nicht für externe Verwendung gedacht, weil sie sich beim Bearbeiten leicht mal ändern können. Das Erstellen von Queries für die Verlinkung mit Overpass API o.ä. wäre denkbar, ist derzeit aber eher Theorie und nicht unbedingt geeignet für OSM-Laien, wie es Wikipedianer ja sind. Die Lösung mit dem Wikipedia-Tag hingegen funktioniert heute bereits gut. Es genügt zwar nicht, wenn es z.B. um Karten in Sammelartikeln für mehrere geografische Objekte geht, die selbst keinen eigenen Artikel bekommen. Diesen Anspruch erhebt es meines Wissens aber auch nicht. Soweit sind wir uns glaub ich ziemlich einig. Ich wollte nie was gegen den wikipedia-Tag an sich sagen. Mir ging es einzig und allein um den Sinn von großen Relationen - und da ist das wikipedia-Tag eben kein Argument. Das aber wurde angeführt, um Relationen für Bundesstraßen etc. zu rechtfertigen. Wohl gemerkt: WEIL wir ein wikipedia-Tag anbringen wollen MÜSSEN WIR 3000 und mehr Wege in eine Relation versammeln, die kein Mensch mehr verarbeiten kann - so die Argumentation. Diese Relation ist aber 1) langsam auszuwerten, 2) geht sie immer wieder kaputt (erfahrungsgemäß). Wenn Wikipedia (oder irgendein anderes Projekt) z.B. die Bundesstraße oder Staatsgrenze als ganzes haben will, muss sie also wegen (2) sowieso Korrekturmaßnahmen einpflegen, die hoffentlich darin bestehen können, dass das ref-Tag entsprechend angegeben ist - aber dann ist das direkte auslesen des ref-tags auch nicht so viel schwieriger. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo, On 07/17/12 02:11, Stephan Wolff wrote: Bei Multipolygon, Abbiege- oder Nahverkehrsrelationen mag es zutreffen, bei einfachen Objektrelationen sehe ich es nicht. Durch welche Operationen würde die Relation zerstört? Was sind denn einfache Objektrelationen? Den Begriff hoere ich zum ersten Mal. Jede Relation modelliert eine bestimmte Art von Beziehung, und diese Beziehung muss man verstehen, um sie richtig editieren zu koennen. Allein schon die einfache Frage: Ein Way, der in einer Relation steckt, wird zweigeteilt; wie wirkt sich das auf die Relation aus? kann nicht beantwortet werden, ohne die Relation zu verstehen. Oder: Ein Way, der in einer Relation steckt, wird geloescht. Soll die Relation mitgeloescht werden, soll sie ohne diesen Way weiterbestehen, oder muss ein Ersatz-Way in die Relation aufgenommen werden? Die Abfrage Westring, Kiel liefert etwa 50 einzelne Straßensegmente. Ein Way mit dem Namen 'Westring' ist Mitglieder einer Relation. Der Name des Ways wird nun auf 'Suedring' geaendert. Muss er deswegen aus der Relation entfernt werden... ;) Eine Relation fuer den Westring in Kiel ist dann sinnvoll, wenn sie auch Objekte mit anderem Namen als Westring enthalten soll. Soll sie das nicht, dann kann man sich die Relation sparen. Genauso mit Bundesstrassen - eine Relation, die exakt alle Objekte mit ref=B10 enthaelt, ist unnoetig. Verlaufen irgendwo die B10 und die B12 ein Stueck auf dem gleichen Asphalt, dann wird sie sinnvoll, denn ein ref=B10,B12 am Way will niemand auswerten. Leider haben wir es bei OSM relativ oft mit Menschen zu tun, die die Welt in Datenbankmodellen betrachten und denen wenn schon, dann einheitlich auf die Stirn taetowiert ist. Das fuehrt dann dazu, dass wenn irgendwo in Peru mal zwei Strassen mit unterschiedlichem ref=* auf den gleichen Ways verlaufen, weltweit fuer alle Strassen Relationen eingefuehrt werden muessen ;) - Kartendarstellungen unabhängig von Unterteilungen in einzelne OSM ways auch Renderer oder deren Preprocessing können das zusammenfassen. Theoretisch vielleicht, praktisch nicht. Verstehe ich Dich richtig: Renderer koennten theoretisch gleichzubehandelnde Strassensegmente zusammenfassen, aber dass sie das im Augenblick nicht tun, ist Grund dafuer, diese Zusammenfassung in Relationen vorzunehmen UND DANN ANZUNEHMEN, DASS RENDERER DAHINGEHEND GEAENDERT WERDEN, DIES ZU BERUECKSICHTIGEN? Das scheint mir nicht logisch. Entweder gehen wir davon aus, dass Renderer unvebresserlich sind, dann haben auch Strassenzusammenfassungsrelationen fuer das Rendering keinen Nutzen, oder wir gehen davon aus, dass Renderer durchaus verbessert werden koennen, dann koennte man den hier Nutzen, ueber den hier spekuliert wird, auch ohne Relationen durch Verbesserungen im Renderer erzielen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Tue, Jul 17, 2012 at 02:11:37AM +0200, Stephan Wolff wrote: Wozu also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat die Stadt? Für alle Fragen, die Straßen (im üblichen Sinn) betreffen: - Suche: Wo ist die ...straße? - Aktuell liefert Nominatim zu einer langen Straße oft mehrere Dutzend Treffer von OSM ways. Wenn Nominatim das entsprechend zusammenfassen kann (z.T. tut es das AFAIK), ist das auch da behoben. Die Abfrage Westring, Kiel liefert etwa 50 einzelne Straßensegmente. Das Problem steht irgendwo auf der Todo-Liste. Die Lösung dazu wird aber mit Sicherheit nicht aus der Auswertung irgendwelcher Strassenrelationen bestehen. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Sarah Hoffmann lon...@denofr.de schrieb: On Tue, Jul 17, 2012 at 02:11:37AM +0200, Stephan Wolff wrote: Wozu also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat die Stadt? Für alle Fragen, die Straßen (im üblichen Sinn) betreffen: - Suche: Wo ist die ...straße? - Aktuell liefert Nominatim zu einer langen Straße oft mehrere Dutzend Treffer von OSM ways. Wenn Nominatim das entsprechend zusammenfassen kann (z.T. tut es das AFAIK), ist das auch da behoben. Die Abfrage Westring, Kiel liefert etwa 50 einzelne Straßensegmente. Das Problem steht irgendwo auf der Todo-Liste. Die Lösung dazu wird aber mit Sicherheit nicht aus der Auswertung irgendwelcher Strassenrelationen bestehen. Auf wessen Todo-Liste und woher nimmst Du diese Sicherheit? Klingt wie ein Alleingang. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 17.07.2012 13:22, schrieb Christian Müller: Sarah Hoffmann lon...@denofr.de schrieb: [...] Auf wessen Todo-Liste und woher nimmst Du diese Sicherheit? Klingt wie ein Alleingang. Alleingang nicht unbedingt, aber da Sarah Nominatim-Maintainerin ist, würde ich das mal so akzeptieren ;) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Peter Wendorff wendo...@uni-paderborn.de schrieb: Am 17.07.2012 13:22, schrieb Christian Müller: Sarah Hoffmann lon...@denofr.de schrieb: [...] Auf wessen Todo-Liste und woher nimmst Du diese Sicherheit? Klingt wie ein Alleingang. Alleingang nicht unbedingt, aber da Sarah Nominatim-Maintainerin ist, würde ich das mal so akzeptieren ;) Bitte mal melden. Falls hier noch ein paar Stimmen zusammenkommen, können wir endlich diesen leidigen, zähen und trägen Community-Prozess abschaffen. Ich wäre dann für eine Umfirmierung in OfDSM - OpenforDevsStreetMap. Oder CfjmaraSM - ClosedforjoemapperandrelationaddictsStreetMap. Apropos Nominatim - da könnte man erstmal is_in aufräumen.. Da werden teilweise Gebiete nach ausdehnungslosen place=region nodes benannt, die hunderte km von den Objekten, zu deren Bennenung sie herangezogen werden, entfernt sind. Das ist so gravierend, dass Mapper note= an ihre Gebiete hängen, und sich fragen, warum nach dem vierten Komma ein Begriff steht, den sie überhaupt nicht zuordnen können. Das soll explizit kein rant an die maintainerin sein, aber es passt thematisch ganz gut hier her und ist imho wichtiger, als Lösungen dort zu finden, wo bereits funktionierende bestehen. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 17.07.2012 08:38, schrieb Frederik Ramm: Jede Relation modelliert eine bestimmte Art von Beziehung, und diese Beziehung muss man verstehen, um sie richtig editieren zu koennen. +1 Allein schon die einfache Frage: Ein Way, der in einer Relation steckt, wird zweigeteilt; wie wirkt sich das auf die Relation aus? kann nicht beantwortet werden, ohne die Relation zu verstehen. Das sehe ich nicht so. Fällt Dir ein Beispiel ein? In JOSM ist der Standardfall, den dadurch neu enstandenen Weg an gleicher Position einzufügen. Dieses Verhalten ist mir in den letzten Jahren nicht einmal negativ aufgefallen - weder bei MPs, noch bei Routen, noch bei sonst irgendwelchen Relationen.. Oder: Ein Way, der in einer Relation steckt, wird geloescht. Soll die Relation mitgeloescht werden, soll sie ohne diesen Way weiterbestehen, oder muss ein Ersatz-Way in die Relation aufgenommen werden? Das entscheidet der Mapper - die Software muss hiervor geeignet warnen, bzw. die Auflösung dieser Fälle unterstützen. Speziell für Löschungen sieht JOSM solche Warnungen vor und bietet geeignet Alternativen an - gerade auch beim split / join von ways mit Relationen, wie es mit Potlatch aussieht, ist mir unbekannt. Die Abfrage Westring, Kiel liefert etwa 50 einzelne Straßensegmente. Ein Way mit dem Namen 'Westring' ist Mitglieder einer Relation. Der Name des Ways wird nun auf 'Suedring' geaendert. Muss er deswegen aus der Relation entfernt werden... ;) Das kommt darauf an - wenn die Änderung korrekt ist und die Wirklichkeit reflektiert vermutlich schon. Eine Relation fuer den Westring in Kiel ist dann sinnvoll, wenn sie auch Objekte mit anderem Namen als Westring enthalten soll. Soll sie das nicht, dann kann man sich die Relation sparen. Gibst Du bitte eine Heuristik an, die präzise genug entscheiden kann, wie der Objektzusammenhang ist? Selbst auf Hausnummern als unique-Kriterium wäre kein Verlass, denn die sind ggf. doppelt oder gar nicht in der DB. Es kann durchaus zwei unterschiedliche Straßen mit gleichem Namen in Gebieten geben, die nicht durch zwei einfache bboxes auseinanderzuhalten sind. Weiterhin, verzichtet man auf die bbox-Methode und geht das Problem mit den postal_code-boundaries an, eröffnet sich das Szenario, dass an deren Grenzen eine gleichnamige Straße die postal-boundary schneidet - sind das dann zwei verschiedene Straßen oder eine? Zudem müßte hierfür bei der Post erfragt werden, ob Straßennamen pro postal_code per Definition Post wirklich immer eindeutig sind - imho yes, aber genau weiß ich das nicht. 1) Nehmen wir an, Straßenzshg. werden über type=street durch Mapper modelliert: Für eine bbox B lassen sich dann alle Straßen mit Namen N einfach per Overpass oder SQL abfragen. 2) Nehmen wir nun an, Du hast eine Heuristik entwickelt, die trotz mannigfaltiger Geometrien in the wild mittels Bestimmung anhand von nearby- bzw. node-matching Algorithmen halbwegs genau Straßensegmente zu einer Straße zusammenbasteln kann. - Ohne ein neues Objekt in der DB oder in Overpass zu schaffen, welches deine Heuristik kapselt und demzufolge zur Ermittlung mehrerer N in B ersatzweise zu 1) verwendet werden kann, ist das nutzlos. Denn während ich für die Instanz B=Bayern und N=Goethestraße mittels 1) ohne Probleme Resultate erhalte, kann ich das mittels 2) ohne Kapselung gar nicht oder nur so kompliziert, dass es niemand je benutzen wird. - Nehmen wir also an die Heuristik wird gekapselt und sorgt dafür, Straßenzusammenhänge tatsächlich richtig zu ermitteln. Dann erfüllt sie den gleichen Zweck wie Relationen vom Typ type=street. Mit dem Unterschied, das letztere von Menschen gepflegt wird und erstere von demjenigen, der die Heuristik erstellt - jemandem, der nie lokales Wissen besitzt, aber alle Fälle genügend genau approximieren können muss. Feststellungen: - falls es diese Heuristik gibt und sie befriedigend genau arbeitet, dann muss sie noch entwickelt werden, andernfalls wäre zu fragen, weshalb sie noch nicht für OSM benutzt wird - es wäre ein API-Wechsel, entweder bei OSM oder Overpass, nötig, der die Heuristik als abfragbares Objekt auf dem Server hinterlegt - die Heuristik anzuwenden benötigt Rechenzeit - 'bottleneck' wurde als Problem bereits angesprochen - falls Relationen weiterhin als unnötiges Hexenwerk angesehen werden, wären diese Schritte für eine Zahl weiterer Relationen zu wiederholen (type=waterway e.g.) - _einem_ Entwickler würde die Aufgabe übertragen eine Heuristik zu finden, die genügend genau für _alle_ funktioniert, das dann zu kapseln und als abfragbares Objekt in der DB oder abgeleiteten Projekten zu implementieren Genauso mit Bundesstrassen - eine Relation, die exakt alle Objekte mit ref=B10 enthaelt, ist unnoetig. Verlaufen irgendwo die B10 und die B12 ein Stueck auf dem gleichen Asphalt, dann wird sie sinnvoll, denn ein ref=B10,B12 am Way will niemand auswerten. Nein, dadurch
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am Dienstag, den 17.07.2012, 02:11 +0200 schrieb Stephan Wolff: Am 16.07.2012 23:04, schrieb Peter Wendorff: - Verlinkung - Ein Wikipediaartikel zu einer Straße sollte nicht mit jedem way sondern mit einem Gesamtobjekt verbunden werden. Inwiefern der Wikipediaartikel überhaupt von osm aus verlinkt werden sollte, und nicht über eine Art XAPI/Overpass-Query, das ist eine andere GEschichte. IMHO gehört der Link eher in die Wikipedia als in die OSM, weil die ganz andere Objekte enthält als OSM enthalten sollte. Der Sinn von Wikipedialinks ist ein anderes Thema, aber wikipedia und url/website-Tags werden verwendet. Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2] nützlich. (Karte-Link neben der Koordinate) s. http://de.wikipedia.org/wiki/Rhein s. http://de.wikipedia.org/wiki/Deutschland Damit können die geographischen Objekte aus OSM in der Karte in Wikipedia dargestellt werden. Deutsche Bundesstraßen ist kein OSM-Objekt, sondern eine Sammlung von Objekten. +1 +1 Der Artikel in WP hat aber durchaus seine Berechtigung (finde ich). Dazu gehört dann aber eben ein [highway=motorway][ref=A*][bbox=...] als Link hin. Für Bundesstraßen wäre es eher [highway=primary][ref=B*][bbox=...] aber auch das funktioniert nicht korrekt. Für die meisten Artikel in der Wikipedia kann man keine sinnvolle Koordinate angeben. Das schließt aber nicht aus, dass es für einige Artikel sinnvolle Links in beide Richtungen gibt. Hier stellt sich mir nur die Frage, was sich leichter und zuverlässiger verwalten läßt. Eine Relation mit Wikipedia tag oder ein komplexer Ausdruck. Die Bundesstraßen enthalten auch highway=motorway Segmente. Das gleiche gilt natürlich auch für andere lineare Objekte wie Flüsse/ Bäche. Oberlauf des Rheins, Unterlauf des Rheins, Rhein - wie viele Objekte willst du denn explizit formulieren? Oder dann doch wieder nur Rhein? Einen Fluss Rhein kenne ich, einen Fluss Oberlauf des Rhein nicht. Die Relation Rhein gibt es schon [1]. Ich erkenne auch hier kein Problem. Hier kann man sich ja an der Wikipedia orientierten. Dort wird nur der Rhein aufgeführt, also sind die Unterabschnitte nicht so wichtig. s. http://de.wikipedia.org/wiki/Rhein [1] http://www.osm.org/browse/relation/123924 [2] http://wiki.openstreetmap.org/wiki/WIWOSM ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 17.07.2012 08:38, schrieb Frederik Ramm: Hallo, On 07/17/12 02:11, Stephan Wolff wrote: Bei Multipolygon, Abbiege- oder Nahverkehrsrelationen mag es zutreffen, bei einfachen Objektrelationen sehe ich es nicht. Durch welche Operationen würde die Relation zerstört? Was sind denn einfache Objektrelationen? Den Begriff hoere ich zum ersten Mal. Einfach = nicht komplex (ohne feste Sortierung, vorgeschriebene role- Elemente, ungültige Geometrien). Jede Relation modelliert eine bestimmte Art von Beziehung, und diese Beziehung muss man verstehen, um sie richtig editieren zu koennen. Allein schon die einfache Frage: Ein Way, der in einer Relation steckt, wird zweigeteilt; wie wirkt sich das auf die Relation aus? kann nicht beantwortet werden, ohne die Relation zu verstehen. Für unbekannte Relationen nimmt JOSM beide Teile auf. Das ist bei den hier diskutierten Relationen genau richtig. Der Mapper muss nichts beachten, der Editor nicht geändert werden. Ich vermute, die anderen Editoren verhalten sich ebenso. Eine Relation fuer den Westring in Kiel ist dann sinnvoll, wenn sie auch Objekte mit anderem Namen als Westring enthalten soll. Soll sie das nicht, dann kann man sich die Relation sparen. Namensgleichheit bedeutet nicht Identität. Viele Namen kommen mehrfach vor, manchmal auch in räumlicher Nähe. Genauso mit Bundesstrassen - eine Relation, die exakt alle Objekte mit ref=B10 enthaelt, ist unnoetig. Verlaufen irgendwo die B10 und die B12 ein Stueck auf dem gleichen Asphalt, dann wird sie sinnvoll, denn ein ref=B10,B12 am Way will niemand auswerten. Ist das dein Ernst? Ob B10 in B10;B12 enthalten ist, kann man trivial auswerten. Die Frage, ob zwei ways mit gleichem Namen zusammengehören ist dagegen ungleich schwieriger zu beantworten. - Kartendarstellungen unabhängig von Unterteilungen in einzelne OSM ways auch Renderer oder deren Preprocessing können das zusammenfassen. Theoretisch vielleicht, praktisch nicht. Verstehe ich Dich richtig: Renderer koennten theoretisch gleichzubehandelnde Strassensegmente zusammenfassen, aber dass sie das im Augenblick nicht tun, ist Grund dafuer, diese Zusammenfassung in Relationen vorzunehmen UND DANN ANZUNEHMEN, DASS RENDERER DAHINGEHEND GEAENDERT WERDEN, DIES ZU BERUECKSICHTIGEN? Du hast mich falsch verstanden. Eine Erweiterung der Renderer, um Wege durch eine Umkreissuche und Tagvergleich zusammenzufassen, wäre schwer zu programmieren, aber vor allem würde die Rechenzeit so stark erhöht, dass es nicht praktisch nutzbar ist. Ein vom Mapper explizit erstellte wäre dagegen schnell und einfach auswertbar. Ich möchte das Thema nicht weiter vertiefen. Ich habe nicht gefordert, für alle Straßen sofort Relationen zu erstellen. Meine (weiter bestehende) These ist, dass OSM auf mittlere Sicht für jedes Objekt der realen Welt eine Verknüpfung der dazugehörenden OSM-Elemente benötigt. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Moin, meine erste Antwort hat gmane letzte Woche offenbar verschluckt. Am 09.07.2012 21:47, schrieb Frederik Ramm: Hi, On 09.07.2012 21:28, Stephan Wolff wrote: Selbst diese einfache Heuristik erfordert schon viel Programmier- und Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen. Ja, aber schau Dir mal die aktuellen Nahverkehrsrelationen an und sag mir, welche OSM-Nutzer das durchfuehren kann ;) Nur weil die Daten des Nahverkehrs schlecht auswertbar sind, müssen wir nicht andere Daten ebenfalls schwer nutzbar machen. Der übliche OSM-Ansatz ist es doch, Daten von Ortskundigen erfassen zu lassen und explizit in die Datenbank zu schreiben. Ortskundige, die keinen Hintergrund in Informationstechnologie und Objektmodellierung haben, ja. Wir reden im Zeifel von Leuten, die lieber jede Zeile im OpenOffice mit 10 Leerstellen einruecken als einmal auf Format-Absatz-von links: 1cm zu gehen, wenn Du verstehst, was ich meine ;) Ich traue vielen Mappern zu, einfache Relationen anzulegen. Ein einfaches Editor-Plugin könnte es nochmals einfacher machen. Die Entscheidung, welche ways zu einer Straße gehören, traue ich jedem Mapper eher zu, als Jochens Algorithmus. Selbst den Mappern, die Einrückungen mit Leerzeichen machen. Gerade bei Straßen als namensgebendes Objekte von OSM sollte es ein Ziel sein, diese als Gesamtobjekt für die unterschiedlichsten Fragestellungen auswertbar zu machen. Nein, das sollte nicht das Ziel sein, das hast Du Dir jetzt eben gerade ausgedacht, weil Du es gern so haettest. Der allgemeine Ansatz, zu einem realen Objekt genau ein OSM-Objekt zu erstellen, wurde schon häufig genannt. Warum soll das ausgerechnet für Straßen nicht gelten? Wozu also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat die Stadt? Für alle Fragen, die Straßen (im üblichen Sinn) betreffen: - Suche: Wo ist die ...straße? - Aktuell liefert Nominatim zu einer langen Straße oft mehrere Dutzend Treffer von OSM ways. - Kartendarstellungen unabhängig von Unterteilungen in einzelne OSM ways - Straßenlisten an Kartenausschnitten mit Raster - eine lange Straße soll einmal auftauchen (B2-D5) , zwei Straßen gleichen Namens als zwei Einträge (B2-B3, B4-D5) - Datenbankabfragen: Welche Straßen haben folgende Eigenschaften?, Wie lang ist ...? oder eben auch Wie viele Straßen gibt es in ...? - Verlinkung - Ein Wikipediaartikel zu einer Straße sollte nicht mit jedem way sondern mit einem Gesamtobjekt verbunden werden. Das gleiche gilt natürlich auch für andere lineare Objekte wie Flüsse/ Bäche. (Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not Objekte zu logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht zwingen, eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken, bloss weil ein Tempolimit kommt oder der Bus abbiegt...) Offenbar hat Jans Betreff dazu geführt, dass die Probleme, die bei speziellen Relationen auftreten (Abbiegerelation - Spezialauswertung, Multipolygon - aufwändige Gültigkeitsprüfung, Nahverkehrsrelationen - mühsame Bearbeitung) als Vorurteil auf alle Relationen übertragen werden. Eine neue Datenstruktur, die ausgedehnte, reale Objekte in einem OSM-Objekte abbildet und die nicht Relation heißt, würde die oben genannten Probleme natürlich auch lösen. :-) Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 16.07.2012 19:06, schrieb Stephan Wolff: Moin, meine erste Antwort hat gmane letzte Woche offenbar verschluckt. Am 09.07.2012 21:47, schrieb Frederik Ramm: Hi, On 09.07.2012 21:28, Stephan Wolff wrote: Selbst diese einfache Heuristik erfordert schon viel Programmier- und Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen. Ja, aber schau Dir mal die aktuellen Nahverkehrsrelationen an und sag mir, welche OSM-Nutzer das durchfuehren kann ;) Nur weil die Daten des Nahverkehrs schlecht auswertbar sind, müssen wir nicht andere Daten ebenfalls schwer nutzbar machen. Um mal eine Zwischenposition einzunehmen: Das nicht jeder OSM-User eine Auswertung der Rohdaten vornehmen kann, finde ich nicht tragisch. Jeder OSM-User kann dann eben die ÖPNVKarte oder ähnliche nutzen. [...] Ich traue vielen Mappern zu, einfache Relationen anzulegen. Ein einfaches Editor-Plugin könnte es nochmals einfacher machen. Die Entscheidung, welche ways zu einer Straße gehören, traue ich jedem Mapper eher zu, als Jochens Algorithmus. Selbst den Mappern, die Einrückungen mit Leerzeichen machen. Das Problem liegt gar nicht so sehr beim Anlegen der Relationen - das ist einfach. Das Problem liegt darin, dass die Relationen kaputtgehen, selbst wenn keiner daran was macht. Das ist eben etwas, das mit nodes und ways nicht der Fall ist. Heißt aber: Ich muss Relationen verstehen, um einen Node editieren zu können. Gerade bei Straßen als namensgebendes Objekte von OSM sollte es ein Ziel sein, diese als Gesamtobjekt für die unterschiedlichsten Fragestellungen auswertbar zu machen. Nein, das sollte nicht das Ziel sein, das hast Du Dir jetzt eben gerade ausgedacht, weil Du es gern so haettest. Der allgemeine Ansatz, zu einem realen Objekt genau ein OSM-Objekt zu erstellen, wurde schon häufig genannt. Warum soll das ausgerechnet für Straßen nicht gelten? Und eine Straße mit gemeinsamem Namen ist dann immer ein Objekt? Warum nicht die Bundesstraße, die ein Stückchen auf der Hauptstraße von Woderpfefferwächst verläuft, dann aber davon abbiegt, während die Hauptstraße weiterläuft. Ist jetzt die Bundesstraße ein Objekt oder die Hauptstraße? Ist die Hauptstraße ein Teil der Bundesstraße oder ist die Bundesstraße ein Teil der Hauptstraße? Eigentlich ist ein Teil der Bundesstraße Teil der Hauptstraße - also bräuchtest du doch wieder einen Abschnitt, der irgendwie schon an sich teil der Hauptstraße ist. Wozu also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat die Stadt? Für alle Fragen, die Straßen (im üblichen Sinn) betreffen: - Suche: Wo ist die ...straße? - Aktuell liefert Nominatim zu einer langen Straße oft mehrere Dutzend Treffer von OSM ways. Wenn Nominatim das entsprechend zusammenfassen kann (z.T. tut es das AFAIK), ist das auch da behoben. - Kartendarstellungen unabhängig von Unterteilungen in einzelne OSM ways auch Renderer oder deren Preprocessing können das zusammenfassen. - Straßenlisten an Kartenausschnitten mit Raster - eine lange Straße soll einmal auftauchen (B2-D5) , zwei Straßen gleichen Namens als zwei Einträge (B2-B3, B4-D5) ebenfalls. - Datenbankabfragen: Welche Straßen haben folgende Eigenschaften?, Wie lang ist ...? oder eben auch Wie viele Straßen gibt es in ...? Tja... was ist denn eine Straße? Etwas, was einen in der Gemeinde eindeutigen Namen hat? Wer definiert das so? Ich rede auch von Stichstraßen, wenn diese den gleichen Namen haben wie die, von der diese abgehen. - Verlinkung - Ein Wikipediaartikel zu einer Straße sollte nicht mit jedem way sondern mit einem Gesamtobjekt verbunden werden. Inwiefern der Wikipediaartikel überhaupt von osm aus verlinkt werden sollte, und nicht über eine Art XAPI/Overpass-Query, das ist eine andere GEschichte. IMHO gehört der Link eher in die Wikipedia als in die OSM, weil die ganz andere Objekte enthält als OSM enthalten sollte. Deutsche Bundesstraßen ist kein OSM-Objekt, sondern eine Sammlung von Objekten. Der Artikel in WP hat aber durchaus seine Berechtigung (finde ich). Dazu gehört dann aber eben ein [highway=motorway][ref=A*][bbox=...] als Link hin. Das gleiche gilt natürlich auch für andere lineare Objekte wie Flüsse/ Bäche. Oberlauf des Rheins, Unterlauf des Rheins, Rhein - wie viele Objekte willst du denn explizit formulieren? Oder dann doch wieder nur Rhein? Und wenn ich den Oberlauf verlinken will? Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Moin! Am 16.07.2012 23:04, schrieb Peter Wendorff: Am 16.07.2012 19:06, schrieb Stephan Wolff: Ich traue vielen Mappern zu, einfache Relationen anzulegen. Das Problem liegt gar nicht so sehr beim Anlegen der Relationen - das ist einfach. Das Problem liegt darin, dass die Relationen kaputtgehen, selbst wenn keiner daran was macht. Das ist eben etwas, das mit nodes und ways nicht der Fall ist. Heißt aber: Ich muss Relationen verstehen, um einen Node editieren zu können. Bei Multipolygon, Abbiege- oder Nahverkehrsrelationen mag es zutreffen, bei einfachen Objektrelationen sehe ich es nicht. Durch welche Operationen würde die Relation zerstört? Der allgemeine Ansatz, zu einem realen Objekt genau ein OSM-Objekt zu erstellen, wurde schon häufig genannt. Warum soll das ausgerechnet für Straßen nicht gelten? Und eine Straße mit gemeinsamem Namen ist dann immer ein Objekt? Es mag seltsame Ausnahmen geben, aber im allgemeinen Sprachgebrauch wird solch eine Straße als ein Objekt verstanden. Warum nicht die Bundesstraße, die ein Stückchen auf der Hauptstraße von Woderpfefferwächst verläuft, dann aber davon abbiegt, während die Hauptstraße weiterläuft. Ist jetzt die Bundesstraße ein Objekt oder die Hauptstraße? Ist die Hauptstraße ein Teil der Bundesstraße oder ist die Bundesstraße ein Teil der Hauptstraße? Eigentlich ist ein Teil der Bundesstraße Teil der Hauptstraße - also bräuchtest du doch wieder einen Abschnitt, der irgendwie schon an sich teil der Hauptstraße ist. Ich sehe das Problem nicht. Ein way kann Teil verschiedener Relationen sein. Es könnten noch ein Fernradweg und eine Buslinie denselben way einschließen, ohne dass es datentechnische oder logische Probleme gibt. Wozu also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat die Stadt? Für alle Fragen, die Straßen (im üblichen Sinn) betreffen: - Suche: Wo ist die ...straße? - Aktuell liefert Nominatim zu einer langen Straße oft mehrere Dutzend Treffer von OSM ways. Wenn Nominatim das entsprechend zusammenfassen kann (z.T. tut es das AFAIK), ist das auch da behoben. Die Abfrage Westring, Kiel liefert etwa 50 einzelne Straßensegmente. - Kartendarstellungen unabhängig von Unterteilungen in einzelne OSM ways auch Renderer oder deren Preprocessing können das zusammenfassen. Theoretisch vielleicht, praktisch nicht. - Straßenlisten an Kartenausschnitten mit Raster - eine lange Straße soll einmal auftauchen (B2-D5) , zwei Straßen gleichen Namens als zwei Einträge (B2-B3, B4-D5) ebenfalls. Die Software könnte allenfalls eine Heuristik anwenden, der Mapper vor Ort hat lokales Wissen. - Datenbankabfragen: Welche Straßen haben folgende Eigenschaften?, Wie lang ist ...? oder eben auch Wie viele Straßen gibt es in ...? Tja... was ist denn eine Straße? Etwas, was einen in der Gemeinde eindeutigen Namen hat? Meist wird der Begriff so verwendet. - Verlinkung - Ein Wikipediaartikel zu einer Straße sollte nicht mit jedem way sondern mit einem Gesamtobjekt verbunden werden. Inwiefern der Wikipediaartikel überhaupt von osm aus verlinkt werden sollte, und nicht über eine Art XAPI/Overpass-Query, das ist eine andere GEschichte. IMHO gehört der Link eher in die Wikipedia als in die OSM, weil die ganz andere Objekte enthält als OSM enthalten sollte. Der Sinn von Wikipedialinks ist ein anderes Thema, aber wikipedia und url/website-Tags werden verwendet. Deutsche Bundesstraßen ist kein OSM-Objekt, sondern eine Sammlung von Objekten. +1 Der Artikel in WP hat aber durchaus seine Berechtigung (finde ich). Dazu gehört dann aber eben ein [highway=motorway][ref=A*][bbox=...] als Link hin. Für Bundesstraßen wäre es eher [highway=primary][ref=B*][bbox=...] aber auch das funktioniert nicht korrekt. Für die meisten Artikel in der Wikipedia kann man keine sinnvolle Koordinate angeben. Das schließt aber nicht aus, dass es für einige Artikel sinnvolle Links in beide Richtungen gibt. Das gleiche gilt natürlich auch für andere lineare Objekte wie Flüsse/ Bäche. Oberlauf des Rheins, Unterlauf des Rheins, Rhein - wie viele Objekte willst du denn explizit formulieren? Oder dann doch wieder nur Rhein? Einen Fluss Rhein kenne ich, einen Fluss Oberlauf des Rhein nicht. Die Relation Rhein gibt es schon [1]. Ich erkenne auch hier kein Problem. Viele Grüße Stephan [1] http://www.osm.org/browse/relation/123924 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 11.07.2012 18:01, schrieb Christian Müller: Woher weißt du eigentlich bei aneinandergereihten Gebäuden, ob die Wand an der Stoßstelle wirklich nur eine Wand ist? In aller Regel gibt es diese Wand in der Tat zweimal. In diesem Fall liegen sie dann aber auch nebeneinander ;-) Ich weiß, dass das (noch) Haarspalterei ist - aber mit der Verfügbarkeit der letzten Bing-Bilder sind ja nun mittlerweile auch die Gulli-Deckel sichtbar geworden.. Selbst wenn Du auf Ameisengrösse auflösen kannst wirst Du nicht erkennen ob z.B. ein Doppelhaus aus zwei aneinandergebauten Einzelhäusern besteht oder als Gesamtgebäude mit einer durchgehenden Trennwand gebaut ist. Sowas ist häufig nur mit Bauplan aufzulösen. Die Ausführung der Trennung halte ich jetzt aber nicht gerade für OSM-relevant. Wichtige Information ist dass es sich um zwei getrennt genutzte Gebäude(teile) mit in der Regel wohl eigener Hausnummer handelt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10. Juli 2012 15:44 schrieb Christian Müller cmu...@gmx.de: Stand, keine Befürchtung). Von Jochen wurde weiterhin angeführt, dass zur Not die geografische Nähe genutzt werden könne - ein Beispiel, das die Grenzen dieses Ansatzes klar aufzeigt, sind die Relationen, die Powermapper bilden, um Brücken zu modellieren - vollständig getrennte, aber räumlich eng aneinandergrenzende, physische Strukturen - eine physische Struktur, die alle multimodalen Transportwege trägt Das ist nur ein Beispiel, das mir adhoc einfällt, anhand welchem eine Heuristik versagt, zu entscheiden, wie einfache Wege gruppiert werden müssen, um eine bestimmte Fragestellung (hier: welche Wege gehören zu einer Brücke / which ways make up one bridge) richtig zu beantworten. Habe mir von den vielen Themen mal dieses rausgepickt. Es stimmt zwar, dass man so, wie Brücken derzeit üblicherweise in OSM abgebildet werden (nur als Attribut auf der Straße) nicht feststellen kann, ob es eine Brücke mit parallelen Fahrwegen oder mehrere parallele Brücken sind, aber das liegt daran, dass es da im Prinzip überhaupt noch kein echtes Brückenobjekt gibt. Dieses könnte natürlich eine Relation sein, muss es aber nicht. Man könnte stattdessen auch einfach den Umriss jeder Brücke zeichnen (und z.B. mit building=bridge oder so taggen), dann bräuchte man z.B. solche Krücken wie bridge_name nicht (name und Varianten auf dem Brückenobjekt wäre dann eindeutig, die Straße könnte ihren Namen wie gehabt behalten). Beim Brückenzählen würde man sich auf diese Umrisse verlassen, zumindest für Wege, die über diese Brücken führen, und bei gleichem Layer. Nicht nur spart man sich so die Relation, es wird auch im Editor keine besondere Behandlung nötig, um den Zusammenhang zu erkennen, und den Umriss als Mehrinformation bekommt man auch noch dazu. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 12.07.2012 um 13:47 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Man könnte stattdessen auch einfach den Umriss jeder Brücke zeichnen (und z.B. mit building=bridge oder so taggen), dann bräuchte man z.B. solche Krücken wie bridge_name nicht (name und Varianten auf dem Brückenobjekt wäre dann eindeutig, die Straße könnte ihren Namen wie gehabt behalten). Beim Brückenzählen würde man sich auf diese Umrisse verlassen, zumindest für Wege, die über diese Brücken führen, und bei gleichem Layer. Das wiederum erinnert mich jetzt stark an das von mir vorgeschlagene highway=junction, was im Prinzip das selbe für Kreuzungen machen will. Würde es vielleicht Sinn machen da etwas universelles zu finden? Also eine bestimmt gekennzeichnete Fläche, welche die tatsächliche Ausdehnung von was-auch-immer beschreibt und damit auch gleichzeitig festlegt, dass alle Wege und Knoten innerhalb der Fläche zu einem gemeinsamen Feature gehören. Vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 11. Juli 2012 16:48 schrieb Tobias Knerr o...@tobias-knerr.de: Am 10.07.2012 21:17, schrieb Christian Müller: Aneinandergereihte Gebäude nutzen häufig overlapping ways, da stimme ich Dir ebenso zu. Eigentlich gibt es die Wand nur einmal, welche da durch zwei Wege in OSM repräsentiert wird. Das geschieht aus Bequemlichkeit, nicht weil es logisch und/oder plausibel ist. Wie man am Schlüssel building (und nicht etwa wall o. dgl.) erkennen kann, mappen wir keine Wände, sondern Umrisse von Gebäudeflächen. Daher trifft der Mapper mit der Verwendung zweier Ways keinerlei Aussage über die Anzahl der Wände an dieser Stelle. +1 Das Einzeichnen aneinander gebauter Gebäude mit overlapping ways ist also nicht bloß bequemer und verständlicher, sondern auch 100% korrekt. +1, genauso wie es 100% korrekt ist, 2 Multipolygonrelationen dafür zu verwenden. Solange man durch die nur einen einzigen überlappenden way über 2 Knoten ersetzen kann, finde ich das meistens overkill, wenn man aber (aus anderen Gründen) sowieso schon ein Multipolygon dort vorfindet, dann mache ich oft auch in diesem Fall ein weiteres Multipolygon (anstatt einen overlapping way in einem Multipolygon zu haben, was eher unschön ist). Übrigens sind Wände (barrier=wall / retaining_wall) als linearer way auch nicht immer ausreichend, weil man bei an der Wand angebrachten Objekten nicht mehr weiss, auf welcher Seite sie sind (sofern diese Objekte als node repräsentiert werden, z.B. Briefkästen oder Verkaufs-Automaten). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 12. Juli 2012 14:04 schrieb Martin Vonwald (Imagic) imagic@gmail.com: Das wiederum erinnert mich jetzt stark an das von mir vorgeschlagene highway=junction, was im Prinzip das selbe für Kreuzungen machen will. nur dass es bei Brücken klar ist, was dazu gehört, aber Kreuzungen bzw. eine Kreuzung dürfte eher eine Abstraktion oder Interpretation der realen Welt sein (es ist eher unklar, ob das jetzt 1, 2 oder wieviele auch immer Objekte sind, wie ist denn _eine_ Kreuzung definiert?) Würde es vielleicht Sinn machen da etwas universelles zu finden? Also eine bestimmt gekennzeichnete Fläche, welche die tatsächliche Ausdehnung von was-auch-immer beschreibt und damit auch gleichzeitig festlegt, dass alle Wege und Knoten innerhalb der Fläche zu einem gemeinsamen Feature gehören. universell heisst das way bzw. die geschlossene Variante davon ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 12.07.2012 14:05, schrieb Martin Koppenhoefer: Übrigens sind Wände (barrier=wall / retaining_wall) als linearer way auch nicht immer ausreichend, weil man bei an der Wand angebrachten Objekten nicht mehr weiss, auf welcher Seite sie sind (sofern diese Objekte als node repräsentiert werden, z.B. Briefkästen oder Verkaufs-Automaten). Die tagge ich persönlich üblicherweise davor mit einem node, der nicht teil des wand-ways ist; denn auch bei Gebäuden wäre alles andere nur eine Heuristik. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 11.07.2012 00:50, schrieb Christian Müller: Am 10.07.2012 21:21, schrieb Peter Wendorff: Wenn ich einen overpass-link erzeuge wie (nicht geprüft, nur schematisch) [bbox=][highway][ref=B 7], dann kann man anhand !dieses Links! genausogut diskutieren wie anhand der relations-id 0815, die die gleichen Elemente enthält: - Das Abfragen ist genauso einfach (wenn ich osm.org/browse/* mal ausnehme, das bricht nämlich gerade bei großen Relationen sowieso regelmäßig zusammen). - Das Verteilen des Links ist genauso einfach, nämlich in beiden Fällen per CopyPaste - Das Ändern des Inhalts ist einfacher: ich muss mich nämlich gar nicht darum kümmen, solange ich das ref-Tag richtig setze - Das Ändern des Links ist auch nicht schwieriger; wenn man das überhaupt braucht (dürfte nur dann der Fall sein, wenn auf einmal z.B. die gerade neu eingetragene B 7 in Österreich zufällig die BoundingBox überschneidet) +1 Ist doch alles richtig. Die besagten B-Relationen waren nur ein Beispiel, um das Problem an sich zu verdeutlichen - nicht alle derzeit verwendeten Sammelrelationen dürften auf diese Weise ersetzbar sein. Weiterhin fehlt: - remote josm link ist aber simpel machbar - guck dir das mal bei taginfo an, das erzeugt solche Links ja bereits; die haben dann die Form (Parameter nicht korrekt maskiert für bessere Lesbarkeit) http://localhost:8111/import?url=http://overpass-api.de?api... - die von dir schon angesprochene /browse/ -Geschichte die ist aber doch mit den Relationen jetzt auch nicht besser, das ist also kein Argument. - außerdem dürfte es nervig sein, die bbox in jeder URL anzugeben (hier würden Aliase der admin. Grenzen helfen, etwa [bbox=Europe,Germany]) Ein Tool, dass diese BBox automatisch erzeugt, halte ich aber für relativ einfach machbar. Zudem ist zu schauen, was momentan eigentlich in der Relation gepflegt wird - evtl. sind auch Raststätten, Notrufsäulen etc. dabei, welche die Query ebenso liefern muss, will sie die Relationen ersetzen. Woher hast du das denn jetzt? Nie was von gehört - und wo ist die Grenze? Raststätte, Mc-Doof und Co direkt hinter der Abfahrt? Autohof vierhundert Meter weiter? Versuche eine Query für Overpass zu finden, welche Dir alle Brücken über x (x=Rhein, Elbe, etc.) liefert - das wird kein Einzeiler mehr, sollte es überhaupt nur mit Overpass machbar sein. Das ist richtig, aber gib mir bitte einen Anwendungsfall, der tatsächlich nur diese Abfrage braucht - oder so wenige Abfragen, dass sich eine komplexere Eigeneinrichtung tatsächlich nicht lohnt. Das Beispiel sieht mir bisher ziemlich konstruiert aus. Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine z.B. overpass-query, ist doch sch***-egal. Aus Anwendersicht schon, soll auch so sein. Aus Entwicklersicht offenbar nicht. Ich vermute, auch aus Entwicklersicht ist das egal - nur sind es oft nicht die Entwickler, die das ins wiki einpflegen, sondern Mapper, die es nicht anders kennen. Gemeint war: aus Entwicklersicht ist es nicht egal, ob des Anwenders Daten aus Relation oder Overpass-Query kommt. Sie bevorzugt (momentan) letzteres. Nein. Wie der ANWENDER die Daten bekommt, ist den meisten Entwicklern tatsächlich egal; nur sollten die Informationen, wo möglich, auch außerhalb der Relation vorhanden sein, weil sie sonst von den Anwendungen oft ignoriert werden. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 11.07.2012 07:53, schrieb Manuel Reimer: Christian Müller cmue81 at gmx.de writes: Ich stimme Dir zu, dass overlapping ways dem Nahe kommen. Nur ist die Fangemeinde von overlapping ways auch nicht besonders groß, da sie ebenso wie mancher Relationstyp schlecht oder gar nicht visualisiert werden. Werden Wanderwege, bzw. deren Relationen auf der Hauptkarte visualisiert? Ehrlich gesagt: Wie ich das erste Mal vor dem Problem gestanden habe, einen Wanderweg selber eintragen zu wollen, da war mein erster Gedanke auch einfach Way über die Punkte -- Fertig. Mir erschien eine solche Vorgehensweise, basierend auf meinem bisherigen OSM-Wissen, als durchaus logisch und sinnvoll. Auf sowas wie Wege stückeln und eine Relation bauen bin ich erst garnicht gekommen. Zudem wäre mal eben nachmalen auch einfacher wie Wege zerstückeln und dann alles in Relation kippen. Folge der Relationen ist, dass die Wanderwege von Unwissenden immer wieder kaputt gemacht werden. Man wird also schon deshalb nie arbeitslos werden, weil man immer mal wieder von jemandem verbundene Wege wieder aufsplitten darf, um Linienzüge in Relationen wieder ganz zu machen. Das ist leider nur halb richtig. In den vorhandenen Editoren wäre das Eintragen so tatsächlich viel einfacher, das nachträgliche Bearbeiten ist allerdings erstmal sogar schwieriger, weil das gezielte Auswählen eines Weges von mehreren, die über die gleichen Knoten verlaufen, blöd ist. [...] Weiterhin könnte man argumentieren, das Gebäude, die wirklich so stark verschmolzen sind, dass die Wand hier nicht gedoppelt ist, ein einziges Gebäude sind. Die Wand muss also garnicht eingezeichnet werden. Einerseits aber schon eine wichtige Information, weil man eine solche Trennmauer u.a. aus Brandschutzgründen nicht durchbrechen dürfte (und wenn ich ein Haus einer bestimmten Mindestgröße suche, hilft mir das also nichts); Andererseits auch für OSM sinnvoller als zwei Gebäude einzuzeichnen, weil üblicherweise die Adresse unterschiedlich ist. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Peter Wendorff wendo...@uni-paderborn.de schrieb: Nein. Wie der ANWENDER die Daten bekommt, ist den meisten Entwicklern tatsächlich egal; nur sollten die Informationen, wo möglich, auch außerhalb der Relation vorhanden sein, weil sie sonst von den Anwendungen oft ignoriert werden. Das ist jetzt nicht dein Ernst oder? Wir taggen weder für Renderer, noch für bestimmte oder spezielle Anwendungen. Wenn eine Anwendung nicht mit Relationen umgehen kann, ist das in erster Linie Problem der Anwendung, solange die Relation einen Sachverhalt der Realität adäquat modelliert. Auf Relationen wird nicht aus Gründen der Anwendungskompat. verzichtet, wenn sie der klar einfachere und intuitive Weg sind, Daten einzutragen. Es ist Entwicklern hier ganz klar nicht egal, wo die Daten herkommen, denn aus ihrem Kreise kommt der verständliche Wunsch, dass Sammelrelationen explizit nicht (mehr) aus der main db kommen sollten. Wäre es ihnen egal, könnten sie so belassen werden, denn selbst wenn sie redundant sind, sie modellieren einen Ausschnitt der Realität adäquat. Eine B 2 kann eben sowohl als Route als auch als Eigenschaft des Weges B 2 zu sein, aufgefasst werden. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 11.07.2012 13:12, schrieb Christian Müller: Peter Wendorff wendo...@uni-paderborn.de schrieb: Nein. Wie der ANWENDER die Daten bekommt, ist den meisten Entwicklern tatsächlich egal; nur sollten die Informationen, wo möglich, auch außerhalb der Relation vorhanden sein, weil sie sonst von den Anwendungen oft ignoriert werden. Das ist jetzt nicht dein Ernst oder? Wir taggen weder für Renderer, noch für bestimmte oder spezielle Anwendungen. Wenn eine Anwendung nicht mit Relationen umgehen kann, ist das in erster Linie Problem der Anwendung, solange die Relation einen Sachverhalt der Realität adäquat modelliert. Das ist das typische Missverständnis dieses Schlagworts. Wir taggen nicht für den Renderer meint ja nicht, dass das Tagging Anwendungen/Renderer ignorieren soll. Es meint, dass ein Park nicht korrekt eingetragen ist, wenn man ihn als Wald tagged, nur weil einem das Grün auf der Karte besser gefällt. Ich habe auch nicht für eine bestimmte Anwendung argumentiert, sondern eben für den Großteil: Ein Multipolygon, das ein simples Polygon modelliert, wird aus einigen Anwendungen rausfallen, weil diese damit nicht umgehen können - es hat aber keinerlei praktische Vorteile gegenüber einem geschlossenen Weg. Eine Routen-Relation für eine Straße, nur weil der Name auf aneinanderhängenden Wegen dann nicht mehrfach angegeben werden müsste, hat keinen praktischen Vorteil für irgendeine Anwendung - schon, weil keine Anwendung sich erlauben kannn, die Namen auf den einzelnen Ways komplett zu ignorieren - die Funktionalität muss also trotzdem eingebaut werden. Wenn eine Anwendung nicht mit Relationen umgehen kann, ist das ihr Problem, das ist richtig. Wenn aber die Nutzung von Relationen die Hürde sowohl für Anwendungsentwickler als auch für Mapper anhebt, dann ist das für mich ein eindeutiges Signal, dass es anders vermutlich besser ist. Auf Relationen wird nicht aus Gründen der Anwendungskompat. verzichtet, wenn sie der klar einfachere und intuitive Weg sind, Daten einzutragen. Richtig. Momentan sind sie das aber nicht - weder einfach noch intuitiv einzutragen - und noch weniger gut korrekt zu halten. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Mal ein Beispiel aus der Vergangenheit zu Radrouten/Wanderrouten: Zu Beginn wurden diese einfach an den Weg getaggt, über den diese verlaufen (Bsp: ref_rcn=ThSk). Das funktionierte sehr gut, bis es gehäuft vorkam, dass über manche Wege mehrere Routen verliefen (Bsp: ref_rcn=Ilm;ThSk;Fei). Für meine Karte wäre das vollkommen ausreichend. Mich interessiert die Info, ob auf diesem Weg eine Radroute verläuft und die ganzen Abkürzungen als ein String für den Namen, den man noch mit Stringreplace etwas aufhübschen kann. Projekte wie die Karten von Lonvia dürften damit nur sehr kompliziert umsetzbar sein. Was nun der einfache Weg ist und was nicht halte ich für nebensächlich, sobald ein Editor mit ins Spiel kommt. Den kann man immer so anpassen, dass dieser eine Weg möglichst einfach ist. In josm sind doch eineige Sachen über Relationen nur so einfach, weil josm die Relation speziell behandelt und Tools bereit stellt, einfach damit zu arbeiten. Wenn man sich nicht auf Routenrelationen geeinigt hätte, hätte josm wahrscheinlich andere Tools, die die Arbeit mit Routen unterstützen würden. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Peter Wendorff wendo...@uni-paderborn.de schrieb: Wenn eine Anwendung nicht mit Relationen umgehen kann, ist das ihr Problem, das ist richtig. Wenn aber die Nutzung von Relationen die Hürde sowohl für Anwendungsentwickler als auch für Mapper anhebt, dann ist das für mich ein eindeutiges Signal, dass es anders vermutlich besser ist. Auf Relationen wird nicht aus Gründen der Anwendungskompat. verzichtet, wenn sie der klar einfachere und intuitive Weg sind, Daten einzutragen. Richtig. Momentan sind sie das aber nicht - weder einfach noch intuitiv einzutragen - und noch weniger gut korrekt zu halten. Das ist Ansichtssache. Ich finde sie einfach und intuitiv und möchte in Gebieten mit hohen Datendichten diese Art der Modellierung nicht missen. Sie erhöht die Verständlichkeit und Übersichtlichkeit enorm. Zudem beendet sie das Gezerre um die Debatte, ob Wege überlappend oder ganz dicht beieinander gezeichnet werden sollen. Man zeichnet eine Flächengrenze und ordnet diese den Flächen zu, an denen sie 'teilnimmt' - fertig. Im Prinzip wiederholst Du hier einen ähnlich gelagerten Fall, der zwischen - nur POI für ein Geschäft - nur building+tags für ein Geschäft - beides parallel eingetragen bestand. Es gab einen Zeitpunkt, da reichte es aus, nur die POIs zu betrachten, aber der OSM-Planet hat sich weiter gedreht und sämtliche Software, die heute ernsthaft Geschäfte auswertet, wertet getaggte buildings aus (und transformiert ggf.). Gleiches wird auf absehbare Zeit für Relationen gelten, insbes. MPs. Wenn es eine legacy Software gibt, die damit nicht umgehen kann, müssen die Daten geeignet transformiert werden - wie das z.B. m.W. mkgmap für die POIs macht. Eine einfache Fläche gleich als MP anzulegen, bedeutet gewissermaßen Zukunftssicherheit, denn i.d.R. grenzt jede Fläche an irgendeine oder mehrere andere. Der closed way ist hier nicht die bessere Darstellungsform, sondern ein Überbleibsel aus den Anfängen von OSM. Er wird allenfalls der Bequemlichkeit wegen oder weil man es nicht besser weiß verwendet. Er lässt sich mal schnell eben grob anlegen ohne weiter nachzudenken, aber für die langfristige Pflege der Daten eignet sich ein MP viel besser, weil nur die Abschnitte der Flächengrenze betrachtet/geändert werden müssen, die auch bearbeitet werden sollen, statt immer den kompletten closed way zu bearbeiten. Je größer oder komplexer die zu bearbeitende Fläche ist, umso spürbarer wird dieser Vorteil. Dein Argument, dass Relationen die Hürde anheben, empfinde ich als hypothetisch. Relationen und im speziellen MPs sind als Lösung für Probleme entstanden, die es vorher gab. Wer sich davon abwendet, kehrt zu den alten Problemen zurück - schwacher Datenzusammenhang, approximative Rechnerei als Krücke fehlender Relationen, etc. pp. Ich empfinde als bedenklich, sie zu vermeiden, nur weil sie schlecht gepflegt werden oder von Editoren nur beschränkt unterstützt werden, von unnötigen Sammelrelationen, die sich eindeutig anders zusammensetzen lassen, einmal abgesehen. Das hat etwas von Selbstgeißelung. Ich mache mir doch auch keine Gedanken darüber, ob es ohne Gesundheit geht, nur weil das Gesundheitssystem schlecht funktioniert.. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 21:17, schrieb Christian Müller: Aneinandergereihte Gebäude nutzen häufig overlapping ways, da stimme ich Dir ebenso zu. Eigentlich gibt es die Wand nur einmal, welche da durch zwei Wege in OSM repräsentiert wird. Das geschieht aus Bequemlichkeit, nicht weil es logisch und/oder plausibel ist. Wie man am Schlüssel building (und nicht etwa wall o. dgl.) erkennen kann, mappen wir keine Wände, sondern Umrisse von Gebäudeflächen. Daher trifft der Mapper mit der Verwendung zweier Ways keinerlei Aussage über die Anzahl der Wände an dieser Stelle. Das Einzeichnen aneinander gebauter Gebäude mit overlapping ways ist also nicht bloß bequemer und verständlicher, sondern auch 100% korrekt. Streng genommen müßte ein MP her, welches die Wand in Bezug zu den Gebäuden setzt, an denen sie teilnimmt. Wir zeichnen auch Ländergrenzen nicht doppelt. Egal, wie streng du es nimmst, es muss keineswegs ein MP her - s.o. Dass wir Ländergrenzen nicht doppelt zeichnen, liegt ganz praktisch daran, dass diese - weit mehr gemeinsame Nodes haben als zwei benachbarte Gebäude - eine sehr große Fläche einschließen - wegen der Gesamtlänge ohnehin MP mit zerlegten outers brauchen. Die Anzahl gemeinsamer Nodes benachbarter Gebäude ist hingegen selten höher als 2, die Gesamtzahl der Nodes im einstelligen oder niedrigen zweistelligen Bereich, und die bedeckte Fläche so klein, dass sie ohnehin als Ganzes heruntergeladen wird. Gebäude sind daher ein Musterbeispiel für einen Fall, wo eine pauschale Modellierung über mehrere Ways und eine Relation statt einen einzelnen Way wirklich total fehl am Platz wäre. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 11.07.2012 07:53, schrieb Manuel Reimer: Zudem wäre mal eben nachmalen auch einfacher wie Wege zerstückeln und dann alles in Relation kippen. Folge der Relationen ist, dass die Wanderwege von Unwissenden immer wieder kaputt gemacht werden. Man wird also schon deshalb nie arbeitslos werden, weil man immer mal wieder von jemandem verbundene Wege wieder aufsplitten darf, um Linienzüge in Relationen wieder ganz zu machen. Das passiert auch mit Wegen generell - die werden ebenso regelmäßig repariert. Da beschwert sich niemand. Was hier fehlt, sind eine stärkere Editorintegration, um Relationen zu bearbeiten. Es ist doch ein Modus denkbar, der genauso, wie Du es beschreibst, das Nachzeichnen erlaubt, aber im Hintergrund einfach Wegsegmente bildet und die in eine Relation kippt. Für Routenrelationen würde eine Relation ausgewählt und in der Folge - alle neu angelegten Wege im Hintergrund addiert - Wege, über die gezeichnet wird, entsprechend gesplittet bzw. in Gänze hinzugefügt Josm hat da in letzter Zeit viele kleinere Verbesserungen erhalten, z.B. ist es nicht mehr notwendig, jedesmal den Dialog einer Relation aufzurufen, wenn Elemente hinzugefügt werden sollen. Das lässt sich nun auch über Rechtsklick erledigen. Evtl. wird die Handhabung von Relationen in Zukunft noch stärker integriert, anstatt (durch den Dialog) wie ein Zusatzfeature zu wirken. Woher weißt du eigentlich bei aneinandergereihten Gebäuden, ob die Wand an der Stoßstelle wirklich nur eine Wand ist? In aller Regel gibt es diese Wand in der Tat zweimal. In diesem Fall liegen sie dann aber auch nebeneinander ;-) Ich weiß, dass das (noch) Haarspalterei ist - aber mit der Verfügbarkeit der letzten Bing-Bilder sind ja nun mittlerweile auch die Gulli-Deckel sichtbar geworden.. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Tobias Knerr o...@tobias-knerr.de schrieb: Das Einzeichnen aneinander gebauter Gebäude mit overlapping ways ist also nicht bloß bequemer und verständlicher, sondern auch 100% korrekt. Meinetwegen, jeder Architekt und jedes Katasteramt würde das zwar eindeutig anders sehen, aber für OSM ist es momentan wohl ausreichend - 100% korrekt würde ich in diesem Zshg. nicht verwenden. - wegen der Gesamtlänge ohnehin MP mit zerlegten outers brauchen. Ja, aber Du verwendest auch für eine Ländergrenze mit nur 4 nodes ein MP - ganz einfach weil das dort usus ist. So, umgekehrt hast Du nun zigtausend Gebäude, zu denen es nicht mehr Infos gibt (evtl. geben sollte), als ein Umrißrechteck. Heißt das dann für Dich, weil es bei Gebäuden so üblich ist, dass Du auch echt komplexe Gebäude, wie innerstädtische Bahnhöfe oder überdimensionierte Einkaufstempel ohne MP modellieren willst? Du schreibst es ja selbst, es ist eine Frage der Komplexität. Schau Dir z.B. den Hbf Berlin mit mehreren Ebenen an. Solange man dort nur das Umrißrechteck zeichnet, kommt man ohne MP aus, zugegeben. Mit jedem Detail wächst aber der Datenbestand, closed ways werden länger, oder überlappen sich z.B. bei drei Geschossen und der Modellierung von Halle und innenliegendem Raum schon so sechs Mal. Um Bezüge herstellen zu können schreibst Du deine eigenen Algorithmen und ärgerst Dich dann, das irgendwo ein Node aus der Reihe tanzt, manche Mapper legen sich den extra an, weil sie nicht wissen, wie sie sonst den fünften von sechs überlappenden Wegen selektieren sollen. Anders mit MPs, da zeichne ich einmal die Wände und kann dann Räume, Umriße und Hallen, etc. in Bezug setzen. Gebäude sind daher ein Musterbeispiel für einen Fall, wo eine pauschale Modellierung über mehrere Ways und eine Relation statt einen einzelnen Way wirklich total fehl am Platz wäre. Ok, aber das gilt m.E. nur, solange nicht mehr als ein Umrißrechteck drin ist. Sobald Innenhöfe, Rolltreppen, Aufzüge, mehrere Ebenen und Innenräume hinzukommen empfinde ich overlapping ways als fehleranfälliger und umständlicher in der Wartung. Zudem ist die Wahrscheinlichkeit höher, dass alles heruntergeladen wird und Konflikte beim Editieren erzeugt werden, obwohl ich bsp.-weise nur am Westflügel eines Geb. interessiert bin, oder nur am UG.. Andererseits ist Indoor-Mapping so und so nicht einfach, da hier eine andere Rechtslage besteht (Hausrecht statt Panoramafreiheit). Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 11:51:13PM +0200, Christian Müller wrote: Am 09.07.2012 21:47, schrieb Frederik Ramm: Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben nicht. Genau das ist der Punkt. Schmeißen wir die Relationen weg, verprellen wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren Elementen nur noch in der Relation auftauchen. Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten. Die Konsequenz davon kann natürlich nicht sein, dass man sie einfach abschafft. Die Konsequenz ist, dass man sie durch etwas besseres ersetzt. Oder, realistischer, dass man den one-size-fits-all-Ansatz ergänzt durch Speziallösungen für Spezialfälle, mit denen dann jeweils einfacher zu arbeiten ist. Relationen haben uns neue und tolle Möglichkeiten gebracht. Die wollen wir nicht missen. Aber sie haben uns eben auch eine Menge Schwierigkeiten gebracht. Alle Leute, die ich kenne, die selbst Code schreiben, um Relationen auszuwerten, haben Schwierigkeiten damit. Und die Mapper haben auch ihre Schwierigkeiten damit. Ein kaputter Way hat Auswirkungen nur in der direkten Nachbarschaft dieses Ways. Eine kaputte Relation kann Auswirkungen auf die halbe Welt haben. Das sind einfach Probleme, denen wir uns stellen müssen. Wir müssen überlegen, wie wir konkret Fortschritte erzielen. Das geht am besten, in dem wir uns die Erfahrungen mit OSM anschauen und davon lernen. Wir müssen drüber nachdenken, wie man die OSM-Daten strukturieren so kann, dass sie leichter zu benutzen und auszuwerten sind, ohne die Mächtigkeit des bestehenden Modells einzuschränken. Und dazu muss man halt erstmal rausarbeiten, wo die Probleme sind. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 11:51:13PM +0200, Christian Müller wrote: Am 09.07.2012 21:47, schrieb Frederik Ramm: Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben nicht. Genau das ist der Punkt. Schmeißen wir die Relationen weg, verprellen wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren Elementen nur noch in der Relation auftauchen. Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation ausser den drei wirklich gebrauchten (Routen, Abbiegerelation, Multipolygon) nachweinen würden? Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den Fall ohne Relationen ohnehin implementieren, weil es dieser Fall immernoch der häufiger gebrauchte ist. Mich hat bisher kein einziges Argument gegen Relationen überzeugt. Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für den restlichen OSM-Datenbestand. Ich sehe z.B. immer wieder nicht verbundene Nodes, versehentlich verschobene, etc. Relationen sind wesentlich leichter versehnlich kaputt zu machen als Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern und man nicht sofort sieht, dass man da etwas ändert. Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein spatiale DB ist. Es ist ein Mix - whatever works entscheidet, wer wie etwas modelliert. Natürlich bedeuten diese Freiheiten Komplexität in der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu zwingen, einheitlich zu mappen. Ein Einwirken auf jeden der dann nach Überlegung falsch mappt, wird denjenigen die Lust am Mappen verderben. Wenn du dir zuviel dieser Freiheiten herausnimmst, schränkst du gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach wie möglich zu halten, damit es für alle verständlich bleibt. Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch ein bisschen lästig, aber normalerweise kann man die Tags einfach ignorieren, frei nach dem Motto 'leben und leben lassen'. Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und der gleiche geografische Sachverhalt eben vielfältig modelliert werden kann. Warum begreifen wir das nicht weiterhin als Chance? Warum wird stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten gesucht, wie es Knoten und Weg nunmal sind? Geografische Sachverhalte sollte man über Geometrie ausdrücken und nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob sie jetzt rechts von der Strasse liegt oder links. Aber was ist der Sinn? Diese Information ist bereits in der DB, das heisst die Relation bringt absolut nichts. Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit zu bewahren und die Pflege zu vereinfachen. Sie können evtl. 50+ Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege nur den regional üblichen Namen halten. Auch mit Lookup-Tables/LUT versagt irgendwann der minimalistische Ansatz. Je nachdem, wieviel Information über eine Menge von Wegen oder Knoten gehalten werden soll. Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum dokumentiert und die Art ihrer Implementierung variiert. Die Live-DB, die Live-Toolchain verwendet sie nicht. Zudem wird mit der Auslagerung von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt nur nicht vom Menschen. Jetzt wirfst du irgendwelche technischen Begriffe in den Raum ohne dir wirklich mal einen Kopf gemacht zu haben, wie das ganze eigentlich funktioniert. Redundanz in den Tags ist bisher einfach kein grosses Problem gewesen. Die Art und Weise wie Datenbanken das handhaben, ist effizient genug. Wir haben ganz andere Ecken, wo wir ernsthafte Probleme mit der Effizienz bekommen. In erster Linie bei der Berechnung der Weggeometrien und dem Node-Lookup. Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt sind, ist das mehr an Information und evtl. auch Redundanz eine Chance, gute QM-Tools zu bauen. Am Beispiel der Bundesstraßen z.B. könnte man die Argumente derjenigen aufgreifen, die meinen man könne den Verlauf der Bundesstraße auch programmatisch anhand des ref= zusammenbauen und braucht die Relation gar nicht und gegen das prüfen, was manuell gepflegt wird. In der Summe ergibt das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen kann: - versehentlich Relation beschädigen - versehentlich
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Obwohl ich sicher eine PostGIS DB installieren kann auf Linux oder Windows, ist das fuer mich viel Aufwand, nur zum bestimmen ob etwas in etwas anderes liegt. Auf Android gelingt das schon nicht mehr. Da bin ich dann froh wenn ich sowas nur abfragen kann mittels eine Relation. Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API sind Relationen unschatzbar wertvoll. Polyglot 2012/7/9 Sarah Hoffmann lon...@denofr.de On Mon, Jul 09, 2012 at 01:20:51PM +0200, Frederik Ramm wrote: Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Eventuell sollte man alle diese neuen Datentypen dann in irgendwas gleichartiges kapseln, so dass eine Software, die den Datentyp nicht versteht, nicht total aufgeschmissen ist *duck* Genau aus diesem Grund finde ich Relationen so wie sie sind eigentlich eine geniale Idee, einfach und flexibel. (Aauch in der Verarbeitung, wenn man sich mal eine Minute von osm2pgsql lösen kann.) Wir haben mit Relationen keine technisches Problem sondern ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung von Objekten in der DB explizit mit Relationen modeliert werden müsse und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich dass OSM eine spatiale DB ist und keine relationale. Anstatt also zu überlegen, was man den Leuten alles verbieten müsste, sollten wir die Mapper besser darüber aufklären, warum ihre Relationsmania überflüssig und gefährlich ist. Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen sollte ist die: ist die Relation wirklich nötig oder ist es möglich, meine Information auch in Form von einfachen Tags und geografischen Beziehungen in der DB unterzubringen. Die Antwort auf diese Frage ist eindeutig, dass es möglich ist, und damit sollte die Sache erledigt sein. Ähnliches gilt für Anwendungen, die hier in letzter Zeit diskutiert wurden. (Ich denke mit Schaudern an den Thread zum Eisenbahn-Tagging.) Redundanz ist kein Argument für Relationen. Ich weiss nicht, wie man es anders in einer spatialen Datenbank verarbeiten kann ist kein Argument für Relationen. Ich kann die Daten so leichter runterladen ist kein Argument für Relationen. Das einzige relevante Argument ist: es geht nicht anders[1]. Und das sollten wir allen Mappern klar machen. Wie es eine ungeschriebene on the ground-Regel gibt, sollten wir eine vermeide Relationen-Regel einführen und so oft wie möglich zitieren. Wenn wir es schaffen mehr Selbstdisziplin zu üben und Relationen auf eine Handvoll klar definierter Anwendungsfälle zu begrenzen, braucht es keine Änderung an der API. Gruss Sarah [1] Und bevor man mich jetzt zu sehr beim Wort nimmt: das schliesst auch die Fälle ein, wo es zwar anders ginge, aber nur von hinten durch die Brust etc. ___ 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] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Tue, Jul 10, 2012 at 09:14:10AM +0200, Jo wrote: Obwohl ich sicher eine PostGIS DB installieren kann auf Linux oder Windows, ist das fuer mich viel Aufwand, nur zum bestimmen ob etwas in etwas anderes liegt. Auf Android gelingt das schon nicht mehr. Da bin ich dann froh wenn ich sowas nur abfragen kann mittels eine Relation. Dann sollten wir weiter daraufhinarbeiten, dass es bessere Tools gibt, damit man sowas leichter machen kann. Entweder in dem man diese Tools leichter bei sich installieren kann oder indem es entsprechende APIs gibt. Dummerweise ist es halt sehr schwierig solche Software so zu bauen, dass sie allgemein und performant funktioniert. Und einer der Gründe, warum das so schwierig ist, sind diese Relationen, die man in seinen Tools berücksichtigen muss... Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API sind Relationen unschatzbar wertvoll. Dummerweise funktioniert das so halt in der Praxis nicht. Erstens skaliert es nicht, Du kannst nicht für alles, was Du je abfragen willst, Relationen anlegen (Wege auf Friedhöfen in Frankfurt). Und zweitens erfassen die Mapper das nicht sauber. D.h. Du bekommst im besten Fall einen Teil der Daten. Für Dich mag das genug sein, für die meisten Leute, die OSM-Daten ernsthaft einsetzen wollen, reicht das nicht. Das alles sieht so einfach aus mit den Relationen für solche Nutzungszwecke, aber es ist eine Illusion. Es erspart Dir die harte Arbeit nicht. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo, On 07/10/12 09:14, Jo wrote: Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API sind Relationen unschatzbar wertvoll. Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen sehe, loesche ich sie. Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer das Herunterladen zu sortieren. Siehe auch: https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
2012/7/10 Frederik Ramm frede...@remote.org Hallo, On 07/10/12 09:14, Jo wrote: Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API sind Relationen unschatzbar wertvoll. Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen sehe, loesche ich sie. Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer das Herunterladen zu sortieren. Kein Problem. Musst du machen. Ich war dabei eine Qualitaetskontrolle aufzusetzen so dass das Fahrradnetzwerk und die Buslinien korrekt behalten bleiben koennen. Das funkzioniert aber nur wenn Leute meine Arbeit nicht kaputmachen. Vielleicht ist das ganze dann doch zu viel Zeitverlust. Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo Jochen, On 10.07.2012 08:13, Jochen Topf wrote: Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten. Das liegt weniger am Konzept Relation als an der Komplexität mancher Anwendungsfälle, die wir mit Relationen in der Datenbank abbilden. Softwaretechnisch sind Relationen unproblematisch, auch mit einem Perl-Skript und einem XML-Extrakt kann man die Member von geschachtelten Relationen recht einfach ermitteln. Problematisch ist in der Regel der Umgang mit den Daten, sowohl für den Mapper als auch für den Entwickler. Für den Entwickler ist eine Relation allemal komfortabler als einzelne Knoten und Wege, die über identische Tags verknüpft sind. Auf der Mapper-Seite sehe ich das Problem in der Regel weniger im Datenmodell als im GUI des Editors. Wenn das Datenmodell die Realität und die Denkweise des Nutzers abbildet, dann versteht das auch jeder. Wer es nicht versteht, der hat auch den abzubildenden Anwendungsfall nicht verinnerlicht und sollte die Finger davon lassen, so wie ich von ÖPNV-Relationen. Aber dass eine Straße oder ein Wanderweg aus mehreren Abschnitten bestehen können, die man zusammenfasst und dass man den Namen nur einmal dem zusammengefassten Objekt zuweist, das versteht jeder. Wenn nicht, dann sollte er sich auf das Mappen von einfachen POIs beschränken. Ein echtes Problem sehe ich beim GUI. Selbst für den relativ simplen Fall von Routen-Relationen gibt es mW keine vernünftige Unterstützung und ich könnte auch nicht definieren, wie so etwas aussehen könnte. Das gilt auch auch für eine Tag-basierte Lösung. Je komplexer die Fälle werden, um so mehr (redundante) Tags muss Otto Normalmapper an jedes kleine Wegstück oder Gebäude hängen, Tags, deren Existenz, Syntax und Semantik sich ihm erst durch intensives Wiki-Studium erschließt. Man wird entgegenhalten: dann soll er diese Tags halt erst mal weg lassen, jemand, der es weiß, wird die dann schon erfassen. Dieser jemand ist dann aber sicher auch in der Lage mit Relationen umzugehen. Solange es keine zufriedenstellenden GUI-Lösungen für die komplexen Anwendungsfälle gibt, taugt der Hinweis auf den Normalmapper weder als Argument für noch gegen Relationen. Hier kam ja schon der Vorschlag, wer ein neues Konzept vorschlage, möge auch den Algorithmus für die Auswertung liefern. Wichtiger wäre, dass er beschreibt, wie es im Editor so umgesetzt werden kann, dass auch IT-unbedarfte Nutzer damit umgehen können. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
2012/7/10 Rainer Kluge rklug...@web.de Hallo Jochen, On 10.07.2012 08:13, Jochen Topf wrote: Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten. Das liegt weniger am Konzept Relation als an der Komplexität mancher Anwendungsfälle, die wir mit Relationen in der Datenbank abbilden. Softwaretechnisch sind Relationen unproblematisch, auch mit einem Perl-Skript und einem XML-Extrakt kann man die Member von geschachtelten Relationen recht einfach ermitteln. Problematisch ist in der Regel der Umgang mit den Daten, sowohl für den Mapper als auch für den Entwickler. Für den Entwickler ist eine Relation allemal komfortabler als einzelne Knoten und Wege, die über identische Tags verknüpft sind. Auf der Mapper-Seite sehe ich das Problem in der Regel weniger im Datenmodell als im GUI des Editors. Wenn das Datenmodell die Realität und die Denkweise des Nutzers abbildet, dann versteht das auch jeder. Wer es nicht versteht, der hat auch den abzubildenden Anwendungsfall nicht verinnerlicht und sollte die Finger davon lassen, so wie ich von ÖPNV-Relationen. Aber dass eine Straße oder ein Wanderweg aus mehreren Abschnitten bestehen können, die man zusammenfasst und dass man den Namen nur einmal dem zusammengefassten Objekt zuweist, das versteht jeder. Wenn nicht, dann sollte er sich auf das Mappen von einfachen POIs beschränken. Ein echtes Problem sehe ich beim GUI. Selbst für den relativ simplen Fall von Routen-Relationen gibt es mW keine vernünftige Unterstützung und ich könnte auch nicht definieren, wie so etwas aussehen könnte. Das gilt auch auch für eine Tag-basierte Lösung. Je komplexer die Fälle werden, um so mehr (redundante) Tags muss Otto Normalmapper an jedes kleine Wegstück oder Gebäude hängen, Tags, deren Existenz, Syntax und Semantik sich ihm erst durch intensives Wiki-Studium erschließt. Man wird entgegenhalten: dann soll er diese Tags halt erst mal weg lassen, jemand, der es weiß, wird die dann schon erfassen. Dieser jemand ist dann aber sicher auch in der Lage mit Relationen umzugehen. Solange es keine zufriedenstellenden GUI-Lösungen für die komplexen Anwendungsfälle gibt, taugt der Hinweis auf den Normalmapper weder als Argument für noch gegen Relationen. Hier kam ja schon der Vorschlag, wer ein neues Konzept vorschlage, möge auch den Algorithmus für die Auswertung liefern. Wichtiger wäre, dass er beschreibt, wie es im Editor so umgesetzt werden kann, dass auch IT-unbedarfte Nutzer damit umgehen können. Um es mich einfacher zu machen mit die Fahrradnetzwerke um zu gehen habe ich in JOSM mapcss verwendet. So sieht es jetzt aus wie in Potlatch. Das vorteil ist aber das ich die ein und ausschalten kann. Also wenn ich auf Wandernetzwerke arbeite mach ich sichtbar, wenn Fahrradnetzwerke mit Knoten schalte ich die ein. Und das geht auch gut mit OPNV-Netzwerke und ihre Haltestellen. Fuer die Haltestellen kann man dan noch einfach waehlen ob man die Namen oder die Zonen (zone numbers), oder etwas anderes sichtbar machen will und sogar in unterschiedliche Farben. Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das warscheinlich noch etwas laenger dauern... Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote: On 10.07.2012 08:13, Jochen Topf wrote: Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten. Das liegt weniger am Konzept Relation als an der Komplexität mancher Anwendungsfälle, die wir mit Relationen in der Datenbank abbilden. Softwaretechnisch sind Relationen unproblematisch, auch mit einem Perl-Skript und einem XML-Extrakt kann man die Member von geschachtelten Relationen recht einfach ermitteln. Problematisch ist in der Regel der Umgang mit den Daten, sowohl für den Mapper als auch für den Entwickler. Für den Entwickler ist eine Relation allemal komfortabler als einzelne Knoten und Wege, die über identische Tags verknüpft sind. Sorry, aber das ist Unsinn. Hast Du schonmal die Daten für den ganzen Planeten mit Perl-Skript verarbeitet und dabei die Relationen richtig aufgelöst und das ganze dann immer aktuell gehalten, wenn sich die OSM-Daten ändern? Auf kleinen Extrakten zu arbeiten und ab und zu mal dieses oder jenes zu checken, das mag einfach sein. Aber mit wenigen Daten arbeiten ist immer einfach. Hier geht es um Daten in der Größenordnung von hunderten Gigabytes mit tausenden von Änderungen pro Minute. Da wird es dann plötzlich ziemlich schwierig, mit den Daten vernünftig zu arbeiten. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
2012/7/10 Jochen Topf joc...@remote.org On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote: On 10.07.2012 08:13, Jochen Topf wrote: Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten. Das liegt weniger am Konzept Relation als an der Komplexität mancher Anwendungsfälle, die wir mit Relationen in der Datenbank abbilden. Softwaretechnisch sind Relationen unproblematisch, auch mit einem Perl-Skript und einem XML-Extrakt kann man die Member von geschachtelten Relationen recht einfach ermitteln. Problematisch ist in der Regel der Umgang mit den Daten, sowohl für den Mapper als auch für den Entwickler. Für den Entwickler ist eine Relation allemal komfortabler als einzelne Knoten und Wege, die über identische Tags verknüpft sind. Sorry, aber das ist Unsinn. Hast Du schonmal die Daten für den ganzen Planeten mit Perl-Skript verarbeitet und dabei die Relationen richtig aufgelöst und das ganze dann immer aktuell gehalten, wenn sich die OSM-Daten ändern? Auf kleinen Extrakten zu arbeiten und ab und zu mal dieses oder jenes zu checken, das mag einfach sein. Aber mit wenigen Daten arbeiten ist immer einfach. Hier geht es um Daten in der Größenordnung von hunderten Gigabytes mit tausenden von Änderungen pro Minute. Da wird es dann plötzlich ziemlich schwierig, mit den Daten vernünftig zu arbeiten. Deswegen brauchen wir auch das Ameisenarmee das wir sind. Dafuer habe ich auch dokumentiert was ich gemacht habe. Ich habe es aber mit Python innerhalb von JOSM aufgesetzt. Es ist tatsaechlich unmoeglich fuer ein Person um alle Daten von der ganze Welt richtig zu halten. Dafuer mussen wir alle zusammenarbeiten und das so vernunftig moeglich tun. Relationen helfen uns dabei. 1000x Duplizierte Daten sind viel schwerer richtig zu halten als Abstraktionen. http://wiki.openstreetmap.org/wiki/User:Polyglot/Some_ways_to_simplify_editing_cycle_node_routes_with_JOSM Hier koennt ihr sehen wie es aussieht mit mapcss: http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging#Split_nodes_and_the_tentacles_extending_the_routes_to_connect_them Die Mittel um Relationen auszuwerten und visualiesieren im Editor sind tatsaechlich da. Und dies geht ueber die Qualitaetskontrolle: http://wiki.openstreetmap.org/wiki/Quality_control_with_Python_script_in_JOSM Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On 10.07.2012 10:49, Jochen Topf wrote: On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote: auch mit einem Perl-Skript und einem XML-Extrakt kann man die Member von geschachtelten Relationen recht einfach ermitteln. Problematisch ist in der Regel der Umgang mit den Daten, sowohl für den Mapper als auch für den Entwickler. Für den Entwickler ist eine Relation allemal komfortabler als einzelne Knoten und Wege, die über identische Tags verknüpft sind. Sorry, aber das ist Unsinn. Hast Du schonmal die Daten für den ganzen Planeten mit Perl-Skript verarbeitet und dabei die Relationen richtig aufgelöst und das ganze dann immer aktuell gehalten, wenn sich die OSM-Daten ändern? Ich kann mir kaum vorstellen, dass jemand auf die Idee kommt, so etwas mit Perl zu machen. Wenn du auf dem Planetfile aufsetzst und die für solchen Fälle geeigneten Tools benutzst, dann wird der Vorteil durch Relationen erst recht deutlich. Es ist immer einfacher, die Relation Goethestraße in einer Gemeinde zu suchen und dann die einzelnen Members abzuarbeiten als sämtliche Goethestraßen in der Gemeinde zu suchen und zu prüfen, ob die vielleicht zusammenhängend sind bzw. nahe beieinander liegen. Insbesondere dann, wenn du auch noch berücksichtigst, dass es keine Seltenheit ist, dass es mehrere Straßen mit demselben Namen in einer Gemeinde gibt. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On 10.07.2012 10:24, Jo wrote: Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das warscheinlich noch etwas laenger dauern... Das zeigt doch, dass diese Lösungen nicht für den Normalmapper ohne besondere IT-Kenntnisse verfügbar sind. Der benützt Potlatch2, wenn es hoch kommt Josm ohne Plugins. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
2012/7/10 Rainer Kluge rklug...@web.de On 10.07.2012 10:24, Jo wrote: Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das warscheinlich noch etwas laenger dauern... Das zeigt doch, dass diese Lösungen nicht für den Normalmapper ohne besondere IT-Kenntnisse verfügbar sind. Der benützt Potlatch2, wenn es hoch kommt Josm ohne Plugins. Das zeigt das jemand mit IT-kenntnisse aussuchen muss wie das funkzionieren kann. Wenn der das dan dokumentiert, dann ist es aber relative einfach fuer jeder der lesen kann und Instruktionen folgen will, das auch zu machen. Das ist jedenfalls was ich vor einege Monaten gemacht habe (investigate and document). Jedenfalls ist der Welt kompliziert, also kann die Darstellung/Representation auch nicht total unkompliziert sein und werden Abstraktionen immer notwendig sein. Relationen helfen uns dabei. Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Ihr redet ein klein wenig an einander vorbei. Die Relation ist einfacher. Aber eben nicht alle Goethestraßen sind auf diese weise eingetragen und für diese muss man dann trotzdem den komplexeren Algorithmus entwerfen. Wenn man also gleich nur den komplexeren Algorithmus nutzt, spart man sich das auslesen der Relation. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hi, Am 10.07.2012 08:33, schrieb Sarah Hoffmann: Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation ausser den drei wirklich gebrauchten (Routen, Abbiegerelation, Multipolygon) nachweinen würden? Es ist deine Ansicht, dass dies die drei einzigen sind, die wirklich gebraucht werden. Du kennst das Wiki, Leute haben sich über Jahre Gedanken darüber gemacht, wo deren Meinnung nach Relationen sinnvoll sind. Ich denke nicht, dass Du intensiv genug geforscht hast, um deren Arbeit mit ein bisschen m.E. zu entkräften. Ich persönlich habe in letzter Zeit waterway, bridge, site Relationen genutzt. Speziell bei den waterways erhältst Du z.B. keinen eindeutigen Strang von Quelle zur Mündung. Auch eine Relation garantiert da nichts, aber wenn ich mir vorstelle, dass ich mir einen Hauptflusslauf erstmal Weg für Weg über Overpass oder einer lokalen DB ziehen müsste, mit einem gut möglichen overhead von 2/3 falschen Positiven, kommt mir das Grauen. Z.B. gibt es viele gleich benannte Nebenarme, Fahrrinnen, Schleusenarme, etc. - ich verlasse mich auch nicht auf die Relation allein, verwende sie aber als Ausgangspunkt. Weiterhin siehst Du z.B. am Rhein-Delta, dass ein Tag-Matching+Node-Verbindung nutzender Algorithmus versagen wird, denn in den Niederlanden heißt der Rhein schonmal Rijn und fließt über Waal, Lek, etc. ab. Das sind nur ein paar der Spezialitäten, die mir hier anwendungsspezifisch einfallen, es gibt sicher 'zig andere, aber nicht jeder hat die Zeit und die Muße auf dieser Liste gegen den Minimalismus anzukämpfen. Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den Fall ohne Relationen ohnehin implementieren, weil es dieser Fall immernoch der häufiger gebrauchte ist. Ja, aber er ist die klar schlechtere Approximation gegen eine gewissenhaft gepflegte Relation. Im Prinzip sollte das Fallback-Methode sein. Ich stimme zu, dass es für viele Relationstypen Nachholbedarf bei der Spezifikation gibt, um etwa einen ähnlich guten Dokumentationsgrad, wie bei den MPs zu erreichen. Relationen sind wesentlich leichter versehnlich kaputt zu machen als Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern und man nicht sofort sieht, dass man da etwas ändert. Mit der von Dir erstellten Cycling-Map (Kompliment übrigens) weißt Du doch, wie man sie sichtbar macht. Ich finde nicht, dass die Unsichtbarkeit ein Argument gegen Relationen ist und finde umgekehrt, dass z.B. auch nicht verbundene Nodes wenn sie Nahe beieinander oder aufeinander liegen, schwer identifizierbar sind. Zudem werden die Routen auch in Editoren visualisiert, das kam auch nicht über Nacht. Visualisierungen für andere Relationen werden auch kommen, je nach Bedarf. Wenn du dir zuviel dieser Freiheiten herausnimmst, schränkst du gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach wie möglich zu halten, damit es für alle verständlich bleibt. Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch ein bisschen lästig, aber normalerweise kann man die Tags einfach ignorieren, frei nach dem Motto 'leben und leben lassen'. Das ist total subjektiv. Verlege ich den Weg mit 15 kryptischen Tags, ohne mir deren Inhalt anzuschauen, entstehen Fehler in evtl. größerem Maße, als wenn jemand Relationen bricht, die ein anderer nachpflegt. Natürlich bedeutet das alles Aufwand, der vergrößert sich aber ohne Relationen nur. Ich bin der Auffassung, dass in Gebieten mir hoher Datendichte und evtl. auch vielen Relationen es unabdingbar ist, dass sich ein Mapper Gedanken macht, /was/ er /wie/ ändert. Ob er da, für den Fall er macht sich keine Kopf, 15 Relationen bricht oder 15 kryptische Tags dorthin verlängert, wohin sie nicht gehören, spielt eine untergeordnete Rolle. Es geht immer zu Lasten derer, die gewissenhaft arbeiten. So ist das nunmal - wie sagtest Du: das ist kein technisches Problem, sondern ein menschliches.. Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und der gleiche geografische Sachverhalt eben vielfältig modelliert werden kann. Warum begreifen wir das nicht weiterhin als Chance? Warum wird stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten gesucht, wie es Knoten und Weg nunmal sind? Geografische Sachverhalte sollte man über Geometrie ausdrücken und nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob sie jetzt rechts von der Strasse liegt oder links. Aber was ist der Sinn? Diese Information ist bereits in der DB, das heisst die Relation bringt absolut nichts. Siehe unten, Beispiel Liste
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 09:43, schrieb Frederik Ramm: Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen sehe, loesche ich sie. Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer das Herunterladen zu sortieren. Siehe auch: https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Der Theorie dazu schließe ich mich an, nur wenn die Praxis so aussehen soll, dass jeder, der einen längeren Wasserlauf, das Netz der Bundesstraßen, etc. laden will, Overpass kennen, lernen und nutzen muss, um diesen praktischen Eimer zu vermeiden, funktioniert das /praktisch/ nicht. Die Leute legen diese Eimer an, weil es praktisch ist und weil sie keine Alternativen kennen / haben. Nicht jeder legt sich einen planet dump auf seinen Rechner und bastelt sich anschließend seine persönlichen Anfragen. Es ist unpraktisch größere Gebiete als bounding box zu laden, wenn man doch nur sehr wenige Features darin braucht. Deshalb existieren solche Sammlungen. Der Sache quasie mit dem Feuerlöscher hinterherzulaufen, ist auf Dauer ebenso unpraktikabel. Was fehlt sind Alternativen - vielleicht ein paar Presets an Overpass-Queries für die häufigsten, falsch angelegten Relationen in den Editoren Anstatt die falsch angelegte Relation einfach zu löschen, verschiebt man sie. Z.B. könnte unter Verwendung der gleichen ID ein Overpass-Preset angelegt werden. Damit wäre das ein echter Ersatz für die Relation-ID. Hinter der Preset-ID - e.g. overpass-api.de/api/preset/12345 stünde dann eine (Overpass-)Anfrage, die den Inhalt generiert, den die unerwünschte Relation gehabt hätte. Damit hätten wir auch gleich ein hübsches Kriterium, wann eine Relation überflüssig ist - ganz grob: lässt sie sich durch ein Overpass-Preset ersetzen (ohne das Overpass in der Flut der Anfrage sinkt), ist sie überflüssig. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo Christian, manchmal frage ich mich bei Deinen Beitraegen, ob Du sie absichtlich so lang und vielschichtig machst, dass niemand darauf in Gaenze antworten kann, damit Du dann das letzte Wort hast ;) Dennoch, es ist ohne eine solche Relation (momentan) mitnichten wirklich einfach - mit seinem Lieblingseditor effizient alle Brücken entlang der Elbe zu laden ... - eine einfache, in drei Minuten geschriebene Anfrage z.B. für die Overpass API zu erstellen, die diese Brücken zurückgibt ... Ich bin gern bereit, darueber zu diskutieren, ob und wenn ja welche Relationen noetig sind, um die Realitaet ausreichend zu beschreiben. Ich bin aber nicht bereit, zu akzeptieren, dass Relationen als praktisches Downloadwerkzeug benutzt werden. Relationen sind keine Sammel-Eimer fuer komfortables Downloaden. Wenn das einreisst, haben wir in Nullkommanix ausser der Bruecken ueber die Elbe-Relation auch noch die Flussbauwerke an der Elbe und die Flussnahe Bebauung an der Elbe und die Uferflaechen der Elbe und was vielleicht sonst noch alles praktisch sein koennte. Oft genug beobachte ich hier schon, dass irgendjemand in OSM Mist macht und andere dann fast reflexartig nachziehen, und nichtsahnend begruenden: Analog zur Relation 'Bundesstrassennetz in Deutschland' habe ich hier mal angefangen, die Kreisstrassen des Main-Tauber-Kreises in eine Relation zu packen... hrnn! Also: Relationen, deren Hauptzweck das einfachere Abrufen der Daten ist, sind nicht ok. Und die von Dir angebrachte Begruendung andere Methoden sind halt zu schwierig mag zwar stimmen und sie koennte ein Grund dafuer sein, dass diese Relationen entstehen, aber sie ist keine *Berechtigung* fuer diese Relationen. Ich bleibe dabei - reine Sammlungen gehoeren geloescht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Christian Müller wrote: Der Theorie dazu schließe ich mich an, nur wenn die Praxis so aussehen soll, dass jeder, der einen längeren Wasserlauf, das Netz der Bundesstraßen, etc. laden will, Overpass kennen, lernen und nutzen muss, um diesen praktischen Eimer zu vermeiden, funktioniert das /praktisch/ nicht. Warum? Was ist so falsch daran, mal bei den Wissenden nachzufragen, wie man X aus der DB fischen kann? Um ehrlich zu sein, habe ich vor einiger Zeit auch mal mit dem Gedanken gespielt, eine Relation zu missbrauchen, um für eigene Zwecke gewisse POIs schnell zu holen. Es sprechen mehrere Punkte dagegen: - Wenn die Relation von unwissenden verändert wird, dann bekomme ich die Infos, die ich wollte, nicht mehr. - Ich müsste selber manuell die Relation aktuell halten. Also brav jeden neuen POI dort auch wieder reinwerfen. Ein passendes (X|Overpass)API-Query funktioniert automatisch und immer. Ich muss den neuen POI nur anlegen. - Relation und schnell bestimmte Daten abrufen bedeutet, gerade bei unwissenden, häufig auch, dass die die normale API dafür missbrauchen wollen. Die ist für solche automatischen Abfragen aber nicht gedacht! Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Frederik Ramm wrote: (Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not Objekte zu logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht zwingen, eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken, bloss weil ein Tempolimit kommt oder der Bus abbiegt...) Gibt es denn dafür eine Alternative? Um das Tag Tempolimit auf 30 korrekt zu setzen, muss man die Straße doch zerschneiden, wenn nicht die gesamte Straße betroffen ist. Für die in Relationen angelegten Wanderrouten ebenfalls, denn man legt ja nur das Stückchen Weg in die Relation, auf dem die Route verläuft. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 17:09, schrieb Frederik Ramm: Also: Relationen, deren Hauptzweck das einfachere Abrufen der Daten ist, sind nicht ok. Und die von Dir angebrachte Begruendung andere Methoden sind halt zu schwierig mag zwar stimmen und sie koennte ein Grund dafuer sein, dass diese Relationen entstehen, aber sie ist keine *Berechtigung* fuer diese Relationen. +1 anders wollte ich das eigentlich auch nicht verstanden wissen. Dennoch wäre es wesentlich einfacher, die Ersteller solcher Relationen davon zu überzeugen, es nicht zu tun, wenn es eine brauchbare, einfache non-sql-hacking Alternative gäbe. Ob die alternativlose Löschung auf Dauer überzeugt, ist doch fraglich. Ich denke, wenn es eine Community-pflegbare Liste von Preset-Queries auf die ein oder andere Weise auf Overpass geben würde, fänden sich genügend Leute, die helfen categories aus der main db zu entfernen. Allerdings bedeutet diese Umverteilung von Information (preset-query statt explizite Sammelrelation) auch eine gewisse Dezentralisierung und es ist mehr als fraglich, ob sich diese Verfahrensweise beim Umgang mit gewünschten Kategorien dann außerhalb D verbreitet und auch dort überzeugt. Parallel zum planet dump bräuchte es dann auch einen preset-query dump, um das mal etwas weiter zu spinnen. Gruß ps: nein, ich schreibe vielschichtige mails nicht, damit die Leute weglaufen.. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 17:56, schrieb Manuel Reimer: Christian Müller wrote: Der Theorie dazu schließe ich mich an, nur wenn die Praxis so aussehen soll, dass jeder, der einen längeren Wasserlauf, das Netz der Bundesstraßen, etc. laden will, Overpass kennen, lernen und nutzen muss, um diesen praktischen Eimer zu vermeiden, funktioniert das /praktisch/ nicht. Warum? Was ist so falsch daran, mal bei den Wissenden nachzufragen, wie man X aus der DB fischen kann? Das kann ich Dir auch nicht abschließend beantworten. Ich reflektiere nur den durch mich wahrnehmbaren, aktuellen Stand der DB und versuche Gründe zu finden, weshalb die deiner Meinung nach unwissenden in einer Vielzahl von Fällen auf die Komplexität (oder Einfachheit) von X aus der DB fischen verzichten und Relationen für Zwecke verwenden, die jenseits dessen liegen, was von ihren Designern angedacht war. Und Overpass funktioniert ja nun auch noch nicht ewig, vorher war zwar das unflexiblere Xapi da, aber beides scheint nicht als Alternative zur Sammelrelation wahrgenommen zu werden. Es ist auch nicht das gleiche - stell Dir vor, die Community des Wiki-Projekts Germany würde die Bundesstraßen nicht über Relationen pflegen - im Wiki müssten sie nun ellenlange Overpass-URLs angeben, um sich auszutauschen oder Templates für Overpass bauen. So wird stattdessen einfach das Template für die Relationen wiederverwendet und man erhält eine Vielzahl von Links obendrauf (remote josm link, relation analyzer, etc. pp.). Es scheint also eine ganze Menge Vorteile zu geben, Relationen zu missbrauchen, anstatt Overpass-Queries hin- und herzuschieben. Evtl. ändert sich das jetzt mit der starken Verfügbarkeit von Overpass, wer weiß. - Relation und schnell bestimmte Daten abrufen bedeutet, gerade bei unwissenden, häufig auch, dass die die normale API dafür missbrauchen wollen. Die ist für solche automatischen Abfragen aber nicht gedacht! Mir brauchst Du das nicht erzählen ;-) Und das Argument nicht dafür gedacht, nun ja, ich muss Dir nicht erzählen, dass Pudel und Handys in Mikrowellen getrocknet werden? Dass die Thermoskanne statt für Heißgetränke auch zum kühl halten verwendet wird? Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 18:02, schrieb Manuel Reimer: Frederik Ramm wrote: (Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not Objekte zu logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht zwingen, eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken, bloss weil ein Tempolimit kommt oder der Bus abbiegt...) Gibt es denn dafür eine Alternative? Um das Tag Tempolimit auf 30 korrekt zu setzen, muss man die Straße doch zerschneiden, wenn nicht die gesamte Straße betroffen ist. Für die in Relationen angelegten Wanderrouten ebenfalls, denn man legt ja nur das Stückchen Weg in die Relation, auf dem die Route verläuft. imho gibt es dazu keine Alternative. Es sei denn man verbietet Wege in Relationen zukünftig und definiert auch die Routen nur über nodes - um letztere wiederzuverwenden, bräuchte man einen Weg nicht zu zerhacken. Relationen mit anonymen Punkten zu pflegen dürfte hingegen niemandem Spaß machen, zudem wächst die Mitgliederzahl in Relationen. Zugegeben, in Gebieten mit hohen Datendichten werden Wege so stark zerhackt, dass der Abstand zur Nutzung der Einzelnodes ohnehin nicht mehr groß ist. Das betrifft aber gerade bei Routen vorzugsweise nur die Teilabschnitte, die durch Städte verlaufen. Über Land dürfte die Einsparung der Listenlänge, dadurch dass way_ids statt node_ids verwendet werden, enorm sein und bleiben. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 19:12, schrieb Christian Müller: [...] Allerdings bedeutet diese Umverteilung von Information (preset-query statt explizite Sammelrelation) auch eine gewisse Dezentralisierung und es ist mehr als fraglich, ob sich diese Verfahrensweise beim Umgang mit gewünschten Kategorien dann außerhalb D verbreitet und auch dort überzeugt. Parallel zum planet dump bräuchte es dann auch einen preset-query dump, um das mal etwas weiter zu spinnen. Ich halte das mit diesen Presets für gar keine so schlechte Sache, aber ich sehe darin absolut keine Notwendigkeit für eine preset-query. Wenn, dann für einen komfortablen Overpass-Query-Editor, der das erstellen solcher Queries nach individuellen Wünschen erlaubt. Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja (zum Glück) auch keine Sammlung von Relations-IDs, die man komplett herunterladen kann, sondern höchstens einzelne Relationen, die auf einzelnen Wikiseiten verlinkt sind oder so. Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine z.B. overpass-query, ist doch sch***-egal. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 19:48, schrieb Christian Müller: Am 10.07.2012 18:02, schrieb Manuel Reimer: Frederik Ramm wrote: (Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not Objekte zu logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht zwingen, eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken, bloss weil ein Tempolimit kommt oder der Bus abbiegt...) Gibt es denn dafür eine Alternative? Um das Tag Tempolimit auf 30 korrekt zu setzen, muss man die Straße doch zerschneiden, wenn nicht die gesamte Straße betroffen ist. Für die in Relationen angelegten Wanderrouten ebenfalls, denn man legt ja nur das Stückchen Weg in die Relation, auf dem die Route verläuft. imho gibt es dazu keine Alternative. Es sei denn man verbietet Wege in Relationen zukünftig und definiert auch die Routen nur über nodes - um letztere wiederzuverwenden, bräuchte man einen Weg nicht zu zerhacken. Sorry, aber jetzt wirds stumpf. Jetzt willst du eine Relation benutzen, um eine geordnete Liste von Nodes zu erhalten, die dann im editor am besten auch noch als Linienzug dargestellt wird? Das haben wir schon, nennt sich way und ist genau das. Dafür würde es reichen, bewusst mehrere ways über die gleichen nodes zu legen - etwas, was auch heute schon möglich ist (und genutzt wird - und außerdem z.B. bei Wänden, die sich zwei benachbarte Gebäude teilen, IMHO sinnvoller sind als dafür Multipolygone zu missbrauchen, nur um diese trennwand nicht doppelt als way eintragen zu müssen). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 20:48, schrieb Peter Wendorff: Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja (zum Glück) auch keine Sammlung von Relations-IDs, die man komplett herunterladen kann, sondern höchstens einzelne Relationen, die auf einzelnen Wikiseiten verlinkt sind oder so. Es wird hier argumentiert, dass eine einzelne Bundesstraßenrelation an sich schon Blödsinn ist, da sie Wege sammelt, die durch eine einfache ref=query ebenso erhalten werden können. Ich bin gegen individuelle Queries - wenn sie ein Ersatz für Sammelrelationen sein sollen, müssen sie öffentlich und damit diskutier- und im Notfall auch änderbar sein. Eben so, wie die Sammelrelation auch öffentlich einseh- und änderbar ist. Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine z.B. overpass-query, ist doch sch***-egal. Aus Anwendersicht schon, soll auch so sein. Aus Entwicklersicht offenbar nicht. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 20:52, schrieb Peter Wendorff: Am 10.07.2012 19:48, schrieb Christian Müller: imho gibt es dazu keine Alternative. Es sei denn man verbietet Wege in Relationen zukünftig und definiert auch die Routen nur über nodes - um letztere wiederzuverwenden, bräuchte man einen Weg nicht zu zerhacken. Sorry, aber jetzt wirds stumpf. Jetzt willst du eine Relation benutzen, um eine geordnete Liste von Nodes zu erhalten, die dann im editor am besten auch noch als Linienzug dargestellt wird? Der Vorschlag ist gar nicht mal von mir - er kam im Zusammenhang mit ÖPNV-Relationen schonmal, weil sich deren Mapper beschweren, dass die Relationen durch Geometrieänderungen der Wege häufig zerstört werden. Die Theorie ist, nur bestimmte nodes zu mappen und den Rest durch einen Router erledigen zu lassen. Ich stimme Dir zu, dass overlapping ways dem Nahe kommen. Nur ist die Fangemeinde von overlapping ways auch nicht besonders groß, da sie ebenso wie mancher Relationstyp schlecht oder gar nicht visualisiert werden. Aneinandergereihte Gebäude nutzen häufig overlapping ways, da stimme ich Dir ebenso zu. Eigentlich gibt es die Wand nur einmal, welche da durch zwei Wege in OSM repräsentiert wird. Das geschieht aus Bequemlichkeit, nicht weil es logisch und/oder plausibel ist. Streng genommen müßte ein MP her, welches die Wand in Bezug zu den Gebäuden setzt, an denen sie teilnimmt. Wir zeichnen auch Ländergrenzen nicht doppelt. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 21:03, schrieb Christian Müller: Am 10.07.2012 20:48, schrieb Peter Wendorff: Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja (zum Glück) auch keine Sammlung von Relations-IDs, die man komplett herunterladen kann, sondern höchstens einzelne Relationen, die auf einzelnen Wikiseiten verlinkt sind oder so. Es wird hier argumentiert, dass eine einzelne Bundesstraßenrelation an sich schon Blödsinn ist, da sie Wege sammelt, die durch eine einfache ref=query ebenso erhalten werden können. Ich bin gegen individuelle Queries - wenn sie ein Ersatz für Sammelrelationen sein sollen, müssen sie öffentlich und damit diskutier- und im Notfall auch änderbar sein. Eben so, wie die Sammelrelation auch öffentlich einseh- und änderbar ist. Wenn ich einen overpass-link erzeuge wie (nicht geprüft, nur schematisch) [bbox=][highway][ref=B 7], dann kann man anhand !dieses Links! genausogut diskutieren wie anhand der relations-id 0815, die die gleichen Elemente enthält: - Das Abfragen ist genauso einfach (wenn ich osm.org/browse/* mal ausnehme, das bricht nämlich gerade bei großen Relationen sowieso regelmäßig zusammen). - Das Verteilen des Links ist genauso einfach, nämlich in beiden Fällen per CopyPaste - Das Ändern des Inhalts ist einfacher: ich muss mich nämlich gar nicht darum kümmen, solange ich das ref-Tag richtig setze - Das Ändern des Links ist auch nicht schwieriger; wenn man das überhaupt braucht (dürfte nur dann der Fall sein, wenn auf einmal z.B. die gerade neu eingetragene B 7 in Österreich zufällig die BoundingBox überschneidet) Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine z.B. overpass-query, ist doch sch***-egal. Aus Anwendersicht schon, soll auch so sein. Aus Entwicklersicht offenbar nicht. Ich vermute, auch aus Entwicklersicht ist das egal - nur sind es oft nicht die Entwickler, die das ins wiki einpflegen, sondern Mapper, die es nicht anders kennen. Übrigens verstehe ich ehrlich gesagt gar nicht, wofür man ernsthaft gerade eine Bundesstraße vollständig braucht: Für das Netz aller Bundesstraßen vielleicht - aber dann hab ich vermutlich auch mehr Power, weil ich damit ja irgendwas anfangen will; dann tut's die Datenbank mit 'nem z.B. einmaligen Germany-Extrakt auch nicht mehr. Fürs Routing und für die meisten Render-Aufgaben (Karten, 3D und alle anderen, die mir einfallen, brauche ich immer auch zusätzliche Daten. Für eine ernstzunehmende Analyse muss ich mir auch angucken, was evtl. falsch ist oder rundrum liegt - also brauche ich auch da mehr/alle Daten. (Bitte versteh das jetzt aber nicht als Ausflucht aus der Diskussion; die Frage stellt sich unabhängig vom Sinn und Unsinn solcher Relationen im Vergleich zu Tags) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 10.07.2012 21:21, schrieb Peter Wendorff: Wenn ich einen overpass-link erzeuge wie (nicht geprüft, nur schematisch) [bbox=][highway][ref=B 7], dann kann man anhand !dieses Links! genausogut diskutieren wie anhand der relations-id 0815, die die gleichen Elemente enthält: - Das Abfragen ist genauso einfach (wenn ich osm.org/browse/* mal ausnehme, das bricht nämlich gerade bei großen Relationen sowieso regelmäßig zusammen). - Das Verteilen des Links ist genauso einfach, nämlich in beiden Fällen per CopyPaste - Das Ändern des Inhalts ist einfacher: ich muss mich nämlich gar nicht darum kümmen, solange ich das ref-Tag richtig setze - Das Ändern des Links ist auch nicht schwieriger; wenn man das überhaupt braucht (dürfte nur dann der Fall sein, wenn auf einmal z.B. die gerade neu eingetragene B 7 in Österreich zufällig die BoundingBox überschneidet) +1 Ist doch alles richtig. Die besagten B-Relationen waren nur ein Beispiel, um das Problem an sich zu verdeutlichen - nicht alle derzeit verwendeten Sammelrelationen dürften auf diese Weise ersetzbar sein. Weiterhin fehlt: - remote josm link - die von dir schon angesprochene /browse/ -Geschichte - außerdem dürfte es nervig sein, die bbox in jeder URL anzugeben (hier würden Aliase der admin. Grenzen helfen, etwa [bbox=Europe,Germany]) Zudem ist zu schauen, was momentan eigentlich in der Relation gepflegt wird - evtl. sind auch Raststätten, Notrufsäulen etc. dabei, welche die Query ebenso liefern muss, will sie die Relationen ersetzen. Versuche eine Query für Overpass zu finden, welche Dir alle Brücken über x (x=Rhein, Elbe, etc.) liefert - das wird kein Einzeiler mehr, sollte es überhaupt nur mit Overpass machbar sein. Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine z.B. overpass-query, ist doch sch***-egal. Aus Anwendersicht schon, soll auch so sein. Aus Entwicklersicht offenbar nicht. Ich vermute, auch aus Entwicklersicht ist das egal - nur sind es oft nicht die Entwickler, die das ins wiki einpflegen, sondern Mapper, die es nicht anders kennen. Gemeint war: aus Entwicklersicht ist es nicht egal, ob des Anwenders Daten aus Relation oder Overpass-Query kommt. Sie bevorzugt (momentan) letzteres. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Christian Müller cmue81 at gmx.de writes: Ich stimme Dir zu, dass overlapping ways dem Nahe kommen. Nur ist die Fangemeinde von overlapping ways auch nicht besonders groß, da sie ebenso wie mancher Relationstyp schlecht oder gar nicht visualisiert werden. Werden Wanderwege, bzw. deren Relationen auf der Hauptkarte visualisiert? Ehrlich gesagt: Wie ich das erste Mal vor dem Problem gestanden habe, einen Wanderweg selber eintragen zu wollen, da war mein erster Gedanke auch einfach Way über die Punkte -- Fertig. Mir erschien eine solche Vorgehensweise, basierend auf meinem bisherigen OSM-Wissen, als durchaus logisch und sinnvoll. Auf sowas wie Wege stückeln und eine Relation bauen bin ich erst garnicht gekommen. Zudem wäre mal eben nachmalen auch einfacher wie Wege zerstückeln und dann alles in Relation kippen. Folge der Relationen ist, dass die Wanderwege von Unwissenden immer wieder kaputt gemacht werden. Man wird also schon deshalb nie arbeitslos werden, weil man immer mal wieder von jemandem verbundene Wege wieder aufsplitten darf, um Linienzüge in Relationen wieder ganz zu machen. Aneinandergereihte Gebäude nutzen häufig overlapping ways, da stimme ich Dir ebenso zu. Eigentlich gibt es die Wand nur einmal, welche da durch zwei Wege in OSM repräsentiert wird. Das geschieht aus Bequemlichkeit, nicht weil es logisch und/oder plausibel ist. Streng genommen müßte ein MP her, welches die Wand in Bezug zu den Gebäuden setzt, an denen sie teilnimmt. Als Einsteiger erscheint es mir durchaus logisch und plausibel, zwei Gebäude einfach als zwei Gebäude zu zeichnen. Wir kommen in dem Zusammenhang in die Region, wo man sich das Mappen mit Relationen eindeutig unnötig kompliziert macht. Woher weißt du eigentlich bei aneinandergereihten Gebäuden, ob die Wand an der Stoßstelle wirklich nur eine Wand ist? In aller Regel gibt es diese Wand in der Tat zweimal. Für den Mapper, der das ganze nur von außen betrachtet, ist das nicht ersichtlich. Wenn es die Wand zweimal gibt, dann wäre es sogar korrekt, die Gebäude etwas voneinander zu trennen. Also keine Nodes sharen zu lassen. Weiterhin könnte man argumentieren, das Gebäude, die wirklich so stark verschmolzen sind, dass die Wand hier nicht gedoppelt ist, ein einziges Gebäude sind. Die Wand muss also garnicht eingezeichnet werden. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 02:52:02AM +0200, Stephan Wolff wrote: Ich sehe durchaus die von den anderen Beteiligten genannten Probleme bei der Relationserstellung, -pflege und -auswertung. Insbesondere bleibt das Henne-Ei-Problem zwischen Softwareanpassung und Relationsnutzung. Trotzdem betrachte ich die Zusammenfassung mehrerer Teilobjekte in Relationen als Zukunftsmodell von OSM. Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen Objekten in der Art und Weise, wie Relationen das tun. Was wir brauchen sind Objekte, die der Mapper verstehen kann, die sein Bild der Welt umsetzbar machen. Abstrakte Punkte für POIs, abstrakte Linien für Straßen, das geht grad noch so. Aber das Konzept Multipolygon ist schon schwierig genug, wenn man es dann noch auf eine ungeeignete andere Abstraktion aufsetzt, also die Relationen, dann ist das nicht mehr handhabbar. Das zeigt die Praxis jeden Tag. Man könnte natürlich alles auf die Tools schieben und sagen, dass die Tools (also Editor, Renderer, usw.) halt diese Objekte, die ein User verstehen soll, auf Basis von Nodes, Ways, und Relations darstellen sollen. Das habe ich eine Weile auch gedacht, dass das funktioniert. Bei einfachen Objekten klappt das vielleicht. Nicht aber bei Relationen. Eine Relation, die so halber wie eine Multipolygon-Relation aussieht, aber kein gültiges Multipolygon erzeugt läßt sich nicht auf einem höheren Abstraktionsgrad als Multipolygon darstellen. Will man auf dem höheren Abstraktionsgrad arbeiten, so muss sichergestellt sein, dass die Relation darunter immer gültig ist, immer gewissen Strukturvorraussetzungen genügt. Das können wir aber nicht, weil einzig die zentrale OSM-Datenbank diese Gültigkeit sicherstellen könnte. Und die tut das nicht. Und wenn man den Schritt geht, dass man in höheren Abstraktionen denkt, die die Welt näher am User modellieren, dann gibt es eigentlich auch keinen Grund mehr, das auf Relationen aufzubauen, weil die komplex sind und schwierig und langsam zu verarbeiten. Dann sollte man besser eine Datenstruktur finden, die dem Modell angepasst ist und von der man sich sehr genau überlegt hat, wie man sie effizient verarbeiten kann. Ich sehe Relationen als eine Möglichkeit, Prototypen zu bauen. Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte. Wir können mit Relationen uns solchen Objekten annähern und ausprobieren, wie sie vielleicht aussehen könnten. Aber irgendwann müssen wir den Schritt tun und sagen: Okay, diese Art der Relation ist so wichtig, dass wir ein echtes Objektmodell dafür machen müssen, das genau dieses Modell abbildet und definiert und sauber zu verarbeiten ist. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo Jochen, On 09.07.2012 08:49, Jochen Topf wrote: Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen Objekten in der Art und Weise, wie Relationen das tun. Menschen denken durchaus in Relationen. Wenn jemand sagt, dass der Laden X in der Hauptstrasse 47 liegt, dann meint er nichts anderes als: das Shop-Objekt mit name=X ist Mitglied der Building-Relation mit addr:street=Hauptstrasse und addr:housenumber=47. Nichtsdestotrotz, da gebe ich dir recht, haben die meisten Menschen Probleme, wenn es darum geht, diese Denkweise in Datenstrukturen umzusetzen. Relationen sind eine effiziente Methode der Datenmodellierung. Sie vermeiden Redundanz, sind änderungsfreundlich und für Anwendungen einfach zu verarbeiten. Nicht umsonst sind relationale Datenbanken seit Jahrzehnten beliebt und verbreitet. Die Alternative zu Relationen ist ein Bottom-Up-Ansatz, bei dem die gemeinsamen Eigenschaften an jedes Element gehängt werden und die Elemente über eine gemeinsame Kennung zusammengefasst werden. Darüber, dass wir das nicht wollen, herrscht sicher Konsens. Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte. Das sind nichts anderes als Relationen mit fest vorgegebenen Eigenschaften und Regeln. So etwas kann und soll man in den Editoren realisieren. In der Datenbank sollten wir uns die Flexibilität des Relationskonzepts erhalten. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte. Das sind nichts anderes als Relationen mit fest vorgegebenen Eigenschaften und Regeln. So etwas kann und soll man in den Editoren realisieren. In der Datenbank sollten wir uns die Flexibilität des Relationskonzepts erhalten. Aus meiner Sicht bedeutet die Einführung eines Multipolygon-Objekts nicht automatisch die Abschaffung der Relationen. Relationen sind so etwas wie eine eierlegende Wollmilchsau. Man kann fast alles damit modellieren. Im Umfeld von OSM, wo es keine genauen Reglen für die Modellierung (ich meine das Taggen) gibt, ist dies auf Dauer nicht handhabbar. Wenn man sich allein die unterschiedlichen Tagmöglichkeiten für Multipolygone anschaut (nur die Wege getaggt, nur das MP getaggt, beides getaggt, Wege getaggt aber unterschiedlich etc.), dann wird schnell klar, das jede Applikation hier Problem bekommen muss, da nicht wirklich klar ist, was denn nun gültig ist und was nicht. Die Umsetzung einer eierlegenden Wollmilchsau führt immer zu großen Problemen mit der Komplexität, wodurch das eigentliche Konzept nicht mehr handhabbbar ist. Also kann ich Jochens Sicht nur zustimmen: Relationen sind zur Zeit eine gute Variante um Modellierungen auszuprobieren. Auf Dauer muss man aber die wesentlichen Konzepte festlegen und in der Datenbank sicherstellen. Eine scheinbare Einschräkung, die sich aber lohnt. Dadurch können sich Editoren und andere Applikationen auf die Implementierung einer Variante festlegen und die wertvolle Ressource Zeit kann auf sinnvollere Tätigkeiten verwendet werden. WanMil Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 09:53:38AM +0200, Rainer Kluge wrote: On 09.07.2012 08:49, Jochen Topf wrote: Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen Objekten in der Art und Weise, wie Relationen das tun. Menschen denken durchaus in Relationen. Wenn jemand sagt, dass der Laden X in der Hauptstrasse 47 liegt, dann meint er nichts anderes als: das Shop-Objekt mit name=X ist Mitglied der Building-Relation mit addr:street=Hauptstrasse und addr:housenumber=47. Nichtsdestotrotz, da gebe ich dir recht, haben die meisten Menschen Probleme, wenn es darum geht, diese Denkweise in Datenstrukturen umzusetzen. Relationen sind eine effiziente Methode der Datenmodellierung. Sie vermeiden Redundanz, sind änderungsfreundlich und für Anwendungen einfach zu verarbeiten. Nicht umsonst sind relationale Datenbanken seit Jahrzehnten beliebt und verbreitet. Die Alternative zu Die Relationen, die wir bei OSM haben, haben NICHTS mit den Relationen zu tun, wie man sie von relationalen Datenbanken kennt. Die Relationen bei OSM sind eben keine effiziente Methode der Datenmodellierung, sie sind nicht änderungsfreundlich und sie sind nicht einfach zu verarbeiten. Relationen ist ein Bottom-Up-Ansatz, bei dem die gemeinsamen Eigenschaften an jedes Element gehängt werden und die Elemente über eine gemeinsame Kennung zusammengefasst werden. Darüber, dass wir das nicht wollen, herrscht sicher Konsens. Die Alternative zu Relationen sind neue Datenstrukturen, die genau das machen, was wir wollen. Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte. Das sind nichts anderes als Relationen mit fest vorgegebenen Eigenschaften und Regeln. So etwas kann und soll man in den Editoren realisieren. In der Datenbank sollten wir uns die Flexibilität des Relationskonzepts erhalten. Wie ich beschrieben habe, funktioniert dieser Ansatz nicht. Du kannst nicht sicherstellen, dass alle Editoren die Daten immer in gültiger Weise editieren, solange das die zentrale Datenbank nicht macht. Dadurch wird jeder Editor und jeder User dieser Editoren aber immer mit der Möglichkeit konfrontiert, dass die Daten ungültig sind, was diese fest vorgegebenen Eigenschaften und Regeln angeht. Und damit sind die dann eben nicht fest vorgegebenen. Und damit haben wir das durcheinander, dass wir jetzt haben. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Vermutlich ist der richtige Ansatz genau das Zwischending: Relationen weiterhin erlauben, aber etablierte Relationentypen nach und nach in die API fest aufnehmen. Das viel berühmte freie Tagging-Schema ist klasse, funktioniert aber eben auch nur, solange die Freiheit sich darauf beschränkt, nicht standardisierte Bereiche nach bestem Wissen und Gewissen frei einzutragen; es ist eben nicht gleichzusetzen mit Anarchie. Wenn wir Relationen erlauben, ist das das äquivalent zum freien Tagging auf der Ebene der Datenstrukturen: Sie erlauben Dinge, die kaum möglich wären ohne: rollenbesetzte Bezüge zwischen verschiedenen Objekten in OSM nur über Tags abzubilden wäre ziemlich gruselig. Aber Standards sollten sich eben auch da bilden; und wenn diese soweit festliegen, dass sie zum allgemeinen Konsens gehören, dann spricht meines Erachtens nach nichts dagegen, diese auch fest in der API einzubauen. Für wäre dabei als erstes ein Flächentyp fällig, der Multipolygone und einfache Polygone unterstützt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 08:49, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 02:52:02AM +0200, Stephan Wolff wrote: Ich sehe durchaus die von den anderen Beteiligten genannten Probleme bei der Relationserstellung, -pflege und -auswertung. Insbesondere bleibt das Henne-Ei-Problem zwischen Softwareanpassung und Relationsnutzung. Trotzdem betrachte ich die Zusammenfassung mehrerer Teilobjekte in Relationen als Zukunftsmodell von OSM. Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen Objekten in der Art und Weise, wie Relationen das tun. Das glaube ich nicht. In OSM besteht eine Straße meist aus mehreren Objekten mit gleichem Namen und unterschiedlichen Eigenschaften. Kein Mensch würde sagen, dass es drei hintereinanderliegende Goethestraßen gibt. Fast jeder beschreibt eine Straße, deren Abschnitte sich z.B. in der erlaubten Geschwindigkeit unterscheiden. Das gleiche gilt für andere zusammengesetzte Objekte. Natürlich gibt es in OSM abstrakte Relationsobjekte (z.B. Abbiegerelationen) oder schlecht umsetzbare Konzepte (z.B. Buslinien mit mehreren Varianten). Aber um solche Relationen geht es in Jans Frage nicht. Was wir brauchen sind Objekte, die der Mapper verstehen kann, die sein Bild der Welt umsetzbar machen. +1 Man könnte natürlich alles auf die Tools schieben und sagen, dass die Tools (also Editor, Renderer, usw.) halt diese Objekte, die ein User verstehen soll, auf Basis von Nodes, Ways, und Relations darstellen sollen. Im idealen Renderer sollte es keinen Unterschied machen, wie ein Objekt OSM-intern angelegt ist. Ein Split eines Weges sollte keine Auswirkung auf die Darstellung des Namens haben. Eine Suche würde zu einem realen Objekt genau einen Treffer bei OSM liefern. Im idealen Editor könnten zusammengesetzte Objekte durch Vererbung der Tags fast transparent sein, so dass der Mapper bei Änderungen der Geometrie nichts von der internen Struktur sieht. Das ist alles natürlich sehr mühsam umzusetzten. Und wenn man den Schritt geht, dass man in höheren Abstraktionen denkt, die die Welt näher am User modellieren, dann gibt es eigentlich auch keinen Grund mehr, das auf Relationen aufzubauen, weil die komplex sind und schwierig und langsam zu verarbeiten. Dann sollte man besser eine Datenstruktur finden, die dem Modell angepasst ist und von der man sich sehr genau überlegt hat, wie man sie effizient verarbeiten kann. Wie würde sich die Datenstruktur von einer Relation unterscheiden? Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo, On 07/09/12 12:02, Peter Wendorff wrote: Vermutlich ist der richtige Ansatz genau das Zwischending: Relationen weiterhin erlauben, aber etablierte Relationentypen nach und nach in die API fest aufnehmen. Ja, das ist auch das, was vermutlich passieren wird. Ein spezieller Flaechen- und vielleicht sogar ein spezieller Routen-Datentyp in der API 0.7, dann fallen schonmal 90% aller Relationen raus, und wenn die sich mengenmaessig dann wieder aufrappeln, erfindet man wieder was neues... Ein Problem, das wir haben, ist leider, dass OSM aufgrund der immer groesseren Landschaft von Anwendungen immer statischer wird. Die Zeit, in der man mal eben von einem auf den andren Tag die API inkompatibel veraendern konnte, ist leider vorbei. Jeder neue Datentyp, den wir erfinden, muss in Dutzenden von Applikationen unterstuetzt werden, wenn es nicht ein Riesengejammer geben soll. Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Eventuell sollte man alle diese neuen Datentypen dann in irgendwas gleichartiges kapseln, so dass eine Software, die den Datentyp nicht versteht, nicht total aufgeschmissen ist *duck* Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 9. Juli 2012 12:50 schrieb Stephan Wolff s.wo...@web.de: Das glaube ich nicht. In OSM besteht eine Straße meist aus mehreren Objekten mit gleichem Namen und unterschiedlichen Eigenschaften. Kein Mensch würde sagen, dass es drei hintereinanderliegende Goethestraßen gibt. wirklich einfach ist das aber trotzdem nicht überall. Klar, wenn es sich um hintereinanderliegende Straßensegmente handelt, die z.B. wegen unterschiedlichem Belag oder einer Abbiegerestriktion etc. aufgesplittet wurden, dann würde ein Mensch die zusammenfassen. Habe aber hier in historischen Stadtkernen in letzter Zeit öfters den Fall erlebt, dass mehrere Straßen denselben Namen hatten, weil auch z.B. Stichstraßen denselben Namen bekommen hatten, oder weil sich die Straße geteilt und nach einigen Häusern wieder verbunden hat. Dreimal derselbe Name einer Straße an einer Kreuzung mit 3 Straßen kommt durchaus in der Realität vor und ist nicht mehr ganz eindeutig (eine Straße ist m.E. für einen Menschen linear, wenn Stiche oder Aufsplittungen vorkommen wird man nicht mehr unbedingt von *einer* Straße sprechen bzw. zumindest auf diesen besonderen Umstand hinweisen). Konkretes Beispiel: http://www.openstreetmap.org/browse/way/170356491 http://www.openstreetmap.org/browse/way/170431940 Im idealen Renderer sollte es keinen Unterschied machen, wie ein Objekt OSM-intern angelegt ist. Ein Split eines Weges sollte keine Auswirkung auf die Darstellung des Namens haben. +1, da wäre es wünschenswert, wenn Segmente von Straßen für die Darstellung des Namens im Renderer (bzw. der Datengrundlage) zusammengefügt würden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Jochen Topf joc...@remote.org wrote: Die Alternative zu Relationen sind neue Datenstrukturen, die genau das machen, was wir wollen. Das hatten wir ja auch beim Hacking WE im Umfeld Polygondatentyp diskutiert. Was wir eigentlich brauchen ist ein Datentyp für Flächen, Routen und Abbiegeregeln. Die bisherigen Relationen verführen die Leute IMO Dinge zu modellieren, die hinterher kein Mensch mehr auswerten kann. Gruss Sven -- This APT has Super Cow Powers. (apt-get --help on debian woody) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Frederik Ramm wrote: Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Das schließt aber nicht aus, dass man serverseitig eine gewisse Qualität von Relationen erzwingt. So könnte man z.B. bei Multipoligon-Relationen auf dem Server direkt deren Plausibilität prüfen und wenn das nicht hinhaut, dann direkt ablehnen. Genau so kann man die zunehmende Kreativität mit Relationen so etwas dämpfen. Was der Server nicht kennt, das kann auch nicht hochgeladen werden -- Fertig. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 01:20:51PM +0200, Frederik Ramm wrote: Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Eventuell sollte man alle diese neuen Datentypen dann in irgendwas gleichartiges kapseln, so dass eine Software, die den Datentyp nicht versteht, nicht total aufgeschmissen ist *duck* Genau aus diesem Grund finde ich Relationen so wie sie sind eigentlich eine geniale Idee, einfach und flexibel. (Aauch in der Verarbeitung, wenn man sich mal eine Minute von osm2pgsql lösen kann.) Wir haben mit Relationen keine technisches Problem sondern ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung von Objekten in der DB explizit mit Relationen modeliert werden müsse und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich dass OSM eine spatiale DB ist und keine relationale. Anstatt also zu überlegen, was man den Leuten alles verbieten müsste, sollten wir die Mapper besser darüber aufklären, warum ihre Relationsmania überflüssig und gefährlich ist. Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen sollte ist die: ist die Relation wirklich nötig oder ist es möglich, meine Information auch in Form von einfachen Tags und geografischen Beziehungen in der DB unterzubringen. Die Antwort auf diese Frage ist eindeutig, dass es möglich ist, und damit sollte die Sache erledigt sein. Ähnliches gilt für Anwendungen, die hier in letzter Zeit diskutiert wurden. (Ich denke mit Schaudern an den Thread zum Eisenbahn-Tagging.) Redundanz ist kein Argument für Relationen. Ich weiss nicht, wie man es anders in einer spatialen Datenbank verarbeiten kann ist kein Argument für Relationen. Ich kann die Daten so leichter runterladen ist kein Argument für Relationen. Das einzige relevante Argument ist: es geht nicht anders[1]. Und das sollten wir allen Mappern klar machen. Wie es eine ungeschriebene on the ground-Regel gibt, sollten wir eine vermeide Relationen-Regel einführen und so oft wie möglich zitieren. Wenn wir es schaffen mehr Selbstdisziplin zu üben und Relationen auf eine Handvoll klar definierter Anwendungsfälle zu begrenzen, braucht es keine Änderung an der API. Gruss Sarah [1] Und bevor man mich jetzt zu sehr beim Wort nimmt: das schliesst auch die Fälle ein, wo es zwar anders ginge, aber nur von hinten durch die Brust etc. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 04:26:26PM +0200, Manuel Reimer wrote: Frederik Ramm wrote: Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein area oder route oder turnrestriction auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding ganz weg. Das schließt aber nicht aus, dass man serverseitig eine gewisse Qualität von Relationen erzwingt. So könnte man z.B. bei Multipoligon-Relationen auf dem Server direkt deren Plausibilität prüfen und wenn das nicht hinhaut, dann direkt ablehnen. Genau so kann man die zunehmende Kreativität mit Relationen so etwas dämpfen. Was der Server nicht kennt, das kann auch nicht hochgeladen werden -- Fertig. Das Problem ist hier wieder die Komplexität und ungeeignete Datenhaltung der Relationen. Es wäre für den Server mit erheblichem Aufwand verbunden, Multipolygon-Relationen auf Korrektheit zu prüfen, genauso wie das für jeden anderen auch schwierig ist. Das dem zentralen Server aufzubürden ist sehr problematisch. D.h. wir brauchen m.E. erst eine bessere Datenstruktur, die leichter auf Korrektheit geprüft werden kann. Insbesondere muss diese Datenstruktur die Eigenschaft haben, dass es eine genau definierte Liste an Operationen gibt, die auf ihr ausgeführt werden kann. Und der Server kann sicherstellen, dass die Datenstruktur als ganzes korrekt bleibt, wenn nur diese Operationen ausgeführt werden. Und das *ohne* dass jedesmal die gesamten Daten neu überprüft werden müssen. Sowas müßte sich machen lassen, aber ich glaube nicht, dass das basierend auf Relationen geht. Das ganze ist daher so wichtig, weil wir sehr große Objekte haben (Grenze von Russland z.B.). Der Stand der Dinge heute ist so, dass das Verschieben eines Nodes in Sibirien die gesamte Grenze ungültig machen kann. Und das läßt sich nur prüfen, wenn man das gesamte Ding betrachtet. Davon müssen wir wegkommen, wenn wir jemals robusten Datenstrukturen haben wollen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 9. Juli 2012 16:18 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Das hatten wir ja auch beim Hacking WE im Umfeld Polygondatentyp diskutiert. Was wir eigentlich brauchen ist ein Datentyp für Flächen, Routen und Abbiegeregeln. das kann man ja gerne machen und damit den Großteil der Relation sozusagen erschlagen (im Prinzip ist ein Datentyp da doch auch nur ein Spezialfall einer Relation, oder?). Die bisherigen Relationen verführen die Leute IMO Dinge zu modellieren, die hinterher kein Mensch mehr auswerten kann. Menschen können bestimmte Relationen viel eher auswerten als Computerprogramme, insbesondere, wenn man anfängt, sich mehr Rollen auszudenken, um damit verschiedene Objekte untereinander in Beziehung zu setzen. Aufgrund der Kenntnis der Verhältnisse in der realen Welt kann man sich da sicher meist irgendwas zusammenreimen. Ein kaum genutzter Relationstyp (oder role eines members) ist so ähnlich wie ein seltenes tag: nur wenige wenn überhaupt werden das auswerten, es kann aber trotzdem eine coole Spezialanwendung geben, die gerade das nutzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 16:43, schrieb Sarah Hoffmann: Wir haben mit Relationen keine technisches Problem sondern ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung von Objekten in der DB explizit mit Relationen modeliert werden müsse und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich dass OSM eine spatiale DB ist und keine relationale. Das ist eine sehr freie Interpretation von OSM. Zu den Geodaten gehört es auch, die in der realen Welt bestehenden Zusammengehörigkeit von Objekten abzubilden. Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen sollte ist die: ist die Relation wirklich nötig oder ist es möglich, meine Information auch in Form von einfachen Tags und geografischen Beziehungen in der DB unterzubringen. Warum sollte man immer Tags gegenüber Relationen bevorzugen? Oft sind verschiedene Datenmodelle möglich. Ich würde für jeden Einzelfall eine Abwägung der Vor- und Nachteile vornehmen. Die Antwort auf diese Frage ist eindeutig, dass es möglich ist, und damit sollte die Sache erledigt sein. Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 13:34, schrieb Martin Koppenhoefer: Dreimal derselbe Name einer Straße an einer Kreuzung mit 3 Straßen kommt durchaus in der Realität vor und ist nicht mehr ganz eindeutig (eine Straße ist m.E. für einen Menschen linear, wenn Stiche oder Aufsplittungen vorkommen wird man nicht mehr unbedingt von *einer* Straße sprechen bzw. zumindest auf diesen besonderen Umstand hinweisen). Natürlich ist es nicht immer eindeutig, ob eine Sache zu Kategorie A oder B gehört, ob zwei Dinge eigenständig sind oder zusammengehören. Aber man sollte beide Fälle in den Daten ausdrücken können. Zusammentreffende Straßen mit gleichem Namen würde ich meist als eine verzweigte Straße und nicht als mehrere Straßen interpretieren. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote: Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland ermitteln. Warum sollte das nicht gehen? Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 19:17, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote: Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland ermitteln. Warum sollte das nicht gehen? Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße gehören. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 08:01:51PM +0200, Stephan Wolff wrote: Am 09.07.2012 19:17, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote: Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland ermitteln. Warum sollte das nicht gehen? Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße gehören. Klar, die haben dann einen gemeinsamen Node. Außer in dem seltenen Fall, dass eine Straße eine Unterbrechung hat. Will man das auch noch richtig erfasssen, dann muss man ggf. über die Nähe gehen. Wobei sich bei sowas dann schon die Frage stellt, ob man das als eine Straße oder als mehrere verstehen will. Das hängt dann von der genauen Fragestellung ab. Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand vielleicht richtig angelegt hat oder auch nicht. Wenn jemand ausversehen eine Relation falsch angelegt hat, z.B. zwei Relationen statt eine, dann bekommste mit Relationen falsche Daten und würdest daher eh den Weg über die Nodes bzw. die Nähe gehen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 20:31, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 08:01:51PM +0200, Stephan Wolff wrote: Am 09.07.2012 19:17, schrieb Jochen Topf: On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote: Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der Goethestraßen in Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen vollständig ersetzen eindeutig mit nein zu beantworten. Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland ermitteln. Warum sollte das nicht gehen? Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße gehören. Klar, die haben dann einen gemeinsamen Node. Selbst diese einfache Heuristik erfordert schon viel Programmier- und Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen. Schon bei Straßen mit zwei Richtungsfahrbahnen oder Straßen mit Kreisverkehr scheitert die Heuristik. Außer in dem seltenen Fall, dass eine Straße eine Unterbrechung hat. Will man das auch noch richtig erfasssen, dann muss man ggf. über die Nähe gehen. Das wird niemand mehr programmieren. Der übliche OSM-Ansatz ist es doch, Daten von Ortskundigen erfassen zu lassen und explizit in die Datenbank zu schreiben. Gerade bei Straßen als namensgebendes Objekte von OSM sollte es ein Ziel sein, diese als Gesamtobjekt für die unterschiedlichsten Fragestellungen auswertbar zu machen. Wenn die Tools noch nicht so weit sind, kann man übergangsweise mit den tagbasierten Daten arbeiten :-)) Wobei sich bei sowas dann schon die Frage stellt, ob man das als eine Straße oder als mehrere verstehen will. Das hängt dann von der genauen Fragestellung ab. Bei getrennten Richtungsfahrbahnen, Unterbrechungen durch Kreisverkehre oder durch spätere Umbauten bleibt es eine Straße. Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand vielleicht richtig angelegt hat oder auch nicht. Falsche Daten führen natürlich immer zu falschen Ergebnissen. Falsche Relationen fallen genauso auf, wie falsche name-Tags. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hi, On 09.07.2012 21:28, Stephan Wolff wrote: Selbst diese einfache Heuristik erfordert schon viel Programmier- und Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen. Ja, aber schau Dir mal die aktuellen Nahverkehrsrelationen an und sag mir, welche OSM-Nutzer das durchfuehren kann ;) Der übliche OSM-Ansatz ist es doch, Daten von Ortskundigen erfassen zu lassen und explizit in die Datenbank zu schreiben. Ortskundige, die keinen Hintergrund in Informationstechnologie und Objektmodellierung haben, ja. Wir reden im Zeifel von Leuten, die lieber jede Zeile im OpenOffice mit 10 Leerstellen einruecken als einmal auf Format-Absatz-von links: 1cm zu gehen, wenn Du verstehst, was ich meine ;) Gerade bei Straßen als namensgebendes Objekte von OSM sollte es ein Ziel sein, diese als Gesamtobjekt für die unterschiedlichsten Fragestellungen auswertbar zu machen. Nein, das sollte nicht das Ziel sein, das hast Du Dir jetzt eben gerade ausgedacht, weil Du es gern so haettest. Es gibt m.E. keinen zwingenden Grund dafuer. Router oder Renderer koennen schlau genug sein, drei aneinanderstossende Goethestrassen als folgen Sie der Goethestrasse zu interpretieren. Und wenn in der Goethestrasse eine Luecke ist, dann darf man auch nicht mehr sagen folgen Sie Wozu also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat die Stadt? (Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not Objekte zu logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht zwingen, eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken, bloss weil ein Tempolimit kommt oder der Bus abbiegt...) Bei getrennten Richtungsfahrbahnen, Unterbrechungen durch Kreisverkehre oder durch spätere Umbauten bleibt es eine Straße. Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben nicht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Mon, Jul 09, 2012 at 09:28:03PM +0200, Stephan Wolff wrote: Klar, die haben dann einen gemeinsamen Node. Selbst diese einfache Heuristik erfordert schon viel Programmier- und Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen. Schon bei Straßen mit zwei Richtungsfahrbahnen oder Straßen mit Kreisverkehr scheitert die Heuristik. Was Du da haben willst ist halt schon eine sehr spezielle Fragestellung. Da macht das auch nichts, wenn das etwas schwieriger ist. Und was ist, wenn morgen jemand kommt, der alle 30er-Zonen in Bayern zählen will oder alle Wege auf Friedhöfen im Ruhrgebiet. Willste dann auch immer neue Relationen einführen und die alle pflegen lassen? Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand vielleicht richtig angelegt hat oder auch nicht. Falsche Daten führen natürlich immer zu falschen Ergebnissen. Falsche Relationen fallen genauso auf, wie falsche name-Tags. Ja, aber falsche Ways sind schnell erkannt und gefixt. Falsche Relationen sind viel schwieriger zu erkennen und zu fixen. Damit wird es immer so sein, dass Du Dich auf die Relationen nicht verlassen kannst. Und daher gehste dann in der Praxis bei der Auswertung den aufwändigeren, aber robusteren Weg ohne die Relationen. Dann kannste die Dir die Relationen aber einfach sparen. Ein anderes Beispiel: In Multipolygon-Relationen sollte man eigentlich Rollen outer und inner vergeben. Aber das blicken die Leute nicht und machen es häufig falsch. Wenn man die Multipolygon-Relationen also auswerten will, dann ignoriert man einfach die Rollen und setzt die Multipolygone auch ohne diese Information zusammen. Das geht ganz gut. Auf jeden Fall geht es besser, als sich auf die Angaben der Mapper zu verlassen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 09.07.2012 21:47, schrieb Frederik Ramm: Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben nicht. Genau das ist der Punkt. Schmeißen wir die Relationen weg, verprellen wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren Elementen nur noch in der Relation auftauchen. Mich hat bisher kein einziges Argument gegen Relationen überzeugt. Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für den restlichen OSM-Datenbestand. Ich sehe z.B. immer wieder nicht verbundene Nodes, versehentlich verschobene, etc. Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein spatiale DB ist. Es ist ein Mix - whatever works entscheidet, wer wie etwas modelliert. Natürlich bedeuten diese Freiheiten Komplexität in der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu zwingen, einheitlich zu mappen. Ein Einwirken auf jeden der dann nach Überlegung falsch mappt, wird denjenigen die Lust am Mappen verderben. Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und der gleiche geografische Sachverhalt eben vielfältig modelliert werden kann. Warum begreifen wir das nicht weiterhin als Chance? Warum wird stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten gesucht, wie es Knoten und Weg nunmal sind? Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit zu bewahren und die Pflege zu vereinfachen. Sie können evtl. 50+ Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege nur den regional üblichen Namen halten. Auch mit Lookup-Tables/LUT versagt irgendwann der minimalistische Ansatz. Je nachdem, wieviel Information über eine Menge von Wegen oder Knoten gehalten werden soll. Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum dokumentiert und die Art ihrer Implementierung variiert. Die Live-DB, die Live-Toolchain verwendet sie nicht. Zudem wird mit der Auslagerung von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt nur nicht vom Menschen. Wenn wir schon so radikal sein wollen und so einen tollen Leitspruch wie vermeide Relationen gebären wollen, warum dann nicht gleich auch auf die Struktur way verzichten. Eigentlich reicht es doch, wenn wir alles auf dem Node taggen. Mapper machen nur Fehler, wenn sie sich mit der Komplexität eines way's auseinandersetzen sollen. (..) Weiterhin spielt die Arbeitsweise beim Mappen in diese Problematik. Ich würde weder diejenigen verprellen, die strukturiert arbeiten und sagen: Ich lege mir Bundesstraßenrelationen an, weil mir dann die Pflege dieses Netzes einfacher fällt., noch diejenigen, die in einem weißen Gebiet unstrukturiert alles mögliche anlegen und von Relationen gar nichts wissen und sie aufgrund des Datenstandes evtl. gar nicht brauchen. Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt sind, ist das mehr an Information und evtl. auch Redundanz eine Chance, gute QM-Tools zu bauen. Am Beispiel der Bundesstraßen z.B. könnte man die Argumente derjenigen aufgreifen, die meinen man könne den Verlauf der Bundesstraße auch programmatisch anhand des ref= zusammenbauen und braucht die Relation gar nicht und gegen das prüfen, was manuell gepflegt wird. In der Summe ergibt das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen kann: - versehentlich Relation beschädigen - versehentlich ref löschen Es ist unwahrscheinlich, das beides zeitgleich passiert. Gäbe es hingegen eine explizite Relation nicht, würde ein Fehler durch ein fehlendes ref Tag am way nicht auffallen - allein auf die Heuristik alle Wege, die sich einen Knoten teilen zu bauen, ist weltfremd und idealisiert imho viel zu stark. Hier wünscht sich der Informatiker die Welt herbei, wie sie sein sollte. Beispielsweise ist der Verlauf von Landesstraßen heute vielfach in Teilabschnitten durch Bundesstraßen ersetzt worden und dadurch fragmentiert. Weiterhin sehe ich nicht ein, weshalb, nur weil es für Routing und Rendering abkömmlich ist, auf den exotischeren Anwendungsfall wieviele Goethestraßen gibt es in X verzichtet werden sollte, wenn er mit etwas Grips und gutem Willen in der DB ohne viel Zauber und Zusatzarbeit modellierbar ist. Die Fragen, die sich hier viele stellen, ist doch eher, wieviel Relation ist gut? Wie kann vermieden werden, dass die Nutzung von Relationen, die spatiale Verwendbarkeit einer Auswertung auf einfacheren Ebenen wie Punkt / Weg schadet? Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo, siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen so unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht geben. spatialite bietet für kleinere Projekte gute Möglichkeiten mit OSM-Daten zu arbeiten, erfordert aber etwas Ahnung von SQL. Ich muss meine Aussage mal ein wenig korrigieren. Ich habe nicht gesagt, dass Relationen generell kompliziert auszuwerten sind. Das ist es nur bei der Art und Weise, wie ich bisher die Datenbank der OLM befüllt habe. Für mich waren die site-Relationen in diesem Fall im Verhältnis zum Nutzen zu schiwerig auszuwerten, der benötigte Arbeits- und Rechenaufwand lohnte sich für mich nicht unbedingt. Mittlerweile muss ich mich da aber etwas selbst korrigieren, denn mir ist noch ein einfacherer Weg der Auswertung eingefallen, als ich erst gedacht hatte. Jetzt sollte zumindest der Rechenaufwand recht klein sein. Die Sache mit dem Arbeitsaufwand verschiebe ich dann mal auf die Zeit nach dem Urlaub... ;) Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hi! Relationen sind ein ganz schwieriges Kapitel. Erstmal stellt sich die Frage, um was für Relationen es geht. Es gibt quasi niemanden, der Relationen als solche in aller Allgemeinheit auswertet für irgendwas. Denn für was sollen die denn gut sein? Relationen stellen ja nur erstmal Verbindungen zwischen verschiedenen OSM-Elementen her. Was diese Verbindungen bedeuten sollen, das ergibt sich aus dem Typ der Relation, den Tags und den Roles. Es gibt viele verschiedene Typen von Relationen, z.B. Multipolygone, Routes, Abbiegerelationen, usw. Etwa ein halbes Dutzend, die eine Rolle spielen. Genauso wie bei Tags gilt auch hier, jeder kann Typen von Relationen erfinden, das heisst aber nicht, dass die jemand auswertet. Multipolygon-Relations (bzw. boundary) sind die einzigen, die von vielen Leuten wirklich ausgewertet werden. Das liegt daran, dass dafür Support in osm2pgsql und diverser anderer Software vorhanden ist. Es gibt einige Leute, die sich Spezialsoftware geschrieben haben für Routenrelationen. Aber schon da gibt es Unterschiede. Wanderrouten sind halt was anderes als ÖPNV-Routen. Es braucht da jede Menge Spezialhandling. Abbiegerelationen werden von einigen Navi-Programmen verwendet. Die Flexibilität von Relationen macht sie so schwierig in der Handhabung. Immer wird auf andere Elemente verwiesen. Die muss man also auch vorhalten, um eine Relation verarbeiten zu können. Und das ganze kann rekursiv sein, also von einer Relation kann auf eine andere verwiesen werden. Geographisch können Relations sehr sehr gross werden (Grenze von Russland), man kann also einen großen Job nicht so einfach in Teile aufteilen, wie das bei anderen OSM-Daten manchmal geht. Da sich OSM-Daten ständig ändern, muss man die Daten nachführen. Ändert sich ein Node in Siberien, der in einem Way ist, der in einer Relation ist, so ändert sich was auch immer diese Relation darstellt. Dazu kommt, die schlechte Definition, was denn genau welches Tag, welche Role in einer Relation bedeutet. Vielfach gibt es deutliche Unterschiede, wie verschiedene Leute diese Relations im Detail taggen. Damit muss man dann auch umgehen. Das ist mit Tags an Nodes und Ways auch nicht anders, aber es gibt viel mehr Freiheitsgrade, viel mehr Variation, viel mehr durcheinander, wie Leute Taggen. Und es gibt auch viel mehr Möglichkeiten, die Daten fehlerhaft einzutragen. Es ist z.B. schwierig einen kompletten Satz Grenzen aus OSM-Daten zu extrahieren, weil jeden Tag irgendwelche davon kaputt sind. All diese Dinge kann man für kleine Datensätze vielleicht in den Griff bekommen und wenn man keine Updates fahren will. Aber für den ganzen Planeten und immer aktuell und schnell in der Verarbeitung, das ist schwierig. Das sieht man auch daran, wie wenig Leute das wirklich machen. Jochen On Sat, Jul 07, 2012 at 11:09:31PM +0200, Jan Tappenbeck wrote: Date: Sat, 07 Jul 2012 23:09:31 +0200 From: Jan Tappenbeck o...@tappenbeck.net To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch?? Moin ! ich möchte mal wieder eine Frage an die Allgemeinheit stellen auch auf die Gefahr hin zerrissen zu werden. Es geht konkret um ein Zenario was Relationen und Hausnummern betrifft und nachfolgend bitte keine Diskussion über diese Relation ist aber doof, weil Es geht um die Frage wie ist soetwas überhaupt vernünftig und performant in der Auswertung zu realisieren. Das Beispiel kann sicherlich auch auf andere Relationen übertragen werden. Immer werden verschiedene Elemente bei Relationen zusammengeführt die irgendetwas gemeinsam haben und man so verhindern will das Redundante Daten entstehen. Auf dem letzten Stammtisch in Lübeck [1] haben wir über die verschiedenen Geschäfte und die Adressen gesprochen. Einfacher Fall: in einem Gebäude sind mehrere Geschäfte enthalten. Nun macht es keinen Sinn auf jeden POI eine Adresse zu legen und deshalb gibt es zum Beispiel die Building-Relation [2] (zu der wir uns in etwas abgewandelter Form [1] entschieden haben) um Gebäude, Eingänge, Geschäfte miteinander zu verknüpfen. Wie gesagt nur ein Beispiel - geiches läßt sich auch auf Straßen-Relationen etc. übertragen (Straßenname am Objekt überflüssig, weil Gebäude gehört ja zur Straße). Die Frage die ich nun stellen möchte - ist es überhaupt irgendwie möglich solche Verbindungen performant aufzuschlüsseln? und gibt es vielleicht schon Programm(teile) dafür von denen ich nicht weiß. Ein weiteres Beispiel hierzu. Ich habe das ganze einmal mit der OpenLinkMap [3] abgecheckt und da werden solche Verbindungen über Relationen nicht ausgewertet. Dann habe ich mich an Alexander gewandt und nachgefragt. Ich fasse die ausführliche Antwort kurz zusammen: Er sieht keinen einfachen Lösungsansatz dazu und vermutlich wird zuviel Performance dabei auf der Strecke bleiben. Wenn dem so ist - wir zwar nicht für die Renderer (damit auch nicht für andere
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder?Fluch??
On Sat, Jul 07, 2012 at 11:58:14PM +0200, Christian Müller wrote: siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen so unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht geben. Das sind einige der wenigen Ausnahmen. Und schau Dir mal an, was für ein Aufwand diese Leute treiben mussten, um das zum Laufen zu bekommen. Das sind alles Speziallösungen die sehr genau auf den Anwendungsfall zugeschnitten sind und die typischerweise auch nur in genau einer Installation weltweit existieren. Es ist schon beachtlich, was diese Leute da geleistet haben, und spricht eher dafür, wie schwierig die Arbeit mit Relationen eben ist. :-) spatialite bietet für kleinere Projekte gute Möglichkeiten mit OSM-Daten zu arbeiten, erfordert aber etwas Ahnung von SQL. Kleinere Projekte sind immer einfach. :-) Ich finde spatialite auch prima und habs für ein paar Dinge benutzt. Für etwas komplexere Queries sieht man aber schnell die Performance einbrechen, da hat die PostgreSQL doch mehr drauf. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo zusammen, Es geht konkret um ein Zenario was Relationen und Hausnummern betrifft und nachfolgend bitte keine Diskussion über diese Relation ist aber doof, weil Es geht um die Frage wie ist soetwas überhaupt vernünftig und performant in der Auswertung zu realisieren. Das Beispiel kann sicherlich auch auf andere Relationen übertragen werden. Immer werden verschiedene Elemente bei Relationen zusammengeführt die irgendetwas gemeinsam haben und man so verhindern will das Redundante Daten entstehen. Wiederholte Tag-Werte sind keineswegs eine Belastung, sondern werden in der Regel höchst effizient verarbeitet. Der Grund dafür ist, dass dies in den OSM-Daten sehr häufig vorkommt: Straßennamen sind stets eingetragen als gleiche name=irgendwas-Werte von beieinander liegenden Ways. Weil dies so extrem häufig ist, hat jede nahezu Software, die OSM-Daten verarbeitet, irgendeine Form von Kompression gleicher Tag-Werte. Z.B. werden die Tag-Werte in eine separate Tabelle ausgelagert, es gibt ein Dictionary, in dem die vorkommenden Werte eingetragen werden oder ähnliches. Umgekehrt werden Relationen deutlich seltener verwendet, auf sehr verschiedene Weisen (siehe Jochens eMail) und sind daher nicht so sehr durchoptimiert. Es ist daher auch noch niemand auf die Idee gekommen, jede Straße als eine eigene Relation zu schreiben, um den Straßennamen nicht redundant zu speichern. Von daher würde ich keine Bedenken haben, die gleiche Hausnummer sehr oft wieder zu speichern. Die Tools kennen und können das von Straßennamen her. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 08.07.2012 11:02, schrieb Roland Olbricht: Hallo zusammen, Es geht konkret um ein Zenario was Relationen und Hausnummern betrifft und nachfolgend bitte keine Diskussion über diese Relation ist aber doof, weil Es geht um die Frage wie ist soetwas überhaupt vernünftig und performant in der Auswertung zu realisieren. Das Beispiel kann sicherlich auch auf andere Relationen übertragen werden. Immer werden verschiedene Elemente bei Relationen zusammengeführt die irgendetwas gemeinsam haben und man so verhindern will das Redundante Daten entstehen. Wiederholte Tag-Werte sind keineswegs eine Belastung, sondern werden in der Regel höchst effizient verarbeitet. Der Grund dafür ist, dass dies in den OSM-Daten sehr häufig vorkommt: Straßennamen sind stets eingetragen als gleiche name=irgendwas-Werte von beieinander liegenden Ways. Weil dies so extrem häufig ist, hat jede nahezu Software, die OSM-Daten verarbeitet, irgendeine Form von Kompression gleicher Tag-Werte. Z.B. werden die Tag-Werte in eine separate Tabelle ausgelagert, es gibt ein Dictionary, in dem die vorkommenden Werte eingetragen werden oder ähnliches. Umgekehrt werden Relationen deutlich seltener verwendet, auf sehr verschiedene Weisen (siehe Jochens eMail) und sind daher nicht so sehr durchoptimiert. Es ist daher auch noch niemand auf die Idee gekommen, jede Straße als eine eigene Relation zu schreiben, um den Straßennamen nicht redundant zu speichern. ...abgesehen von Ausnahmen wie z.B. Autobahnen, bei denen das IMHO auch nicht notwendig wäre. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Sat, Jul 07, 2012 at 11:09:31PM +0200, Jan Tappenbeck wrote: Moin ! ich möchte mal wieder eine Frage an die Allgemeinheit stellen auch auf die Gefahr hin zerrissen zu werden. Es geht konkret um ein Zenario was Relationen und Hausnummern betrifft und nachfolgend bitte keine Diskussion über diese Relation ist aber doof, weil Es geht um die Frage wie ist soetwas überhaupt vernünftig und performant in der Auswertung zu realisieren. Das Beispiel kann sicherlich auch auf andere Relationen übertragen werden. Immer werden verschiedene Elemente bei Relationen zusammengeführt die irgendetwas gemeinsam haben und man so verhindern will das Redundante Daten entstehen. Auf dem letzten Stammtisch in Lübeck [1] haben wir über die verschiedenen Geschäfte und die Adressen gesprochen. Einfacher Fall: in einem Gebäude sind mehrere Geschäfte enthalten. Nun macht es keinen Sinn auf jeden POI eine Adresse zu legen und deshalb gibt es zum Beispiel die Building-Relation [2] (zu der wir uns in etwas abgewandelter Form [1] entschieden haben) um Gebäude, Eingänge, Geschäfte miteinander zu verknüpfen. Wie gesagt nur ein Beispiel - geiches läßt sich auch auf Straßen-Relationen etc. übertragen (Straßenname am Objekt überflüssig, weil Gebäude gehört ja zur Straße). Du meinst die associatedStreet relation? Ich habe damit mal angefangen und halte die fuer unbrauchbar. Die erste definition enthielt die notwendigkeit das nur EINE Straße darin enthalten sein durfte. Spaetestens wenn jemand irgendwo die Straße splittet um eine route zu erzeugen dann sind alle associatedStreet kaputt. Und Spaetestens seit dem Address view im OSM Inspector wissen wir das wir die explizite zuordnung zu einer Straße nicht brauchen. Relationen sind schoen um dinge abzubilden die sich anders nicht abbilden lassen. Gerade bei Geschaeften spricht aber nichts dagegen die Adresse auf allen nodes zu haben. Das ist einfach und fuer jeden gut zu pflegen. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 08.07.2012 12:28, schrieb Florian Lohoff: Relationen sind schoen um dinge abzubilden die sich anders nicht abbilden lassen. Gerade bei Geschaeften spricht aber nichts dagegen die Adresse auf allen nodes zu haben. Das ist einfach und fuer jeden gut zu pflegen. Flo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Kann nur dann zum Problem werden, wenn ich nach einer Adresse Suche und dann 35 Mal das mehr oder weniger selbe Ergebnis bekommen. Macht das Navigieren nicht gerade übersichtlich. Es wurde einmal der Ansatz diskutiert: Hausnummer auf die Gebäudefläche und alle POI die darin liegen, bekommen die Adresse dann automatisch, aber keine Ahnung, ob es da konkrete Entwicklungen gibt. LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
On Sun, Jul 08, 2012 at 05:06:25PM +0200, Jimmy_K wrote: Am 08.07.2012 12:28, schrieb Florian Lohoff: Relationen sind schoen um dinge abzubilden die sich anders nicht abbilden lassen. Gerade bei Geschaeften spricht aber nichts dagegen die Adresse auf allen nodes zu haben. Das ist einfach und fuer jeden gut zu pflegen. Flo Kann nur dann zum Problem werden, wenn ich nach einer Adresse Suche und dann 35 Mal das mehr oder weniger selbe Ergebnis bekommen. Macht das Navigieren nicht gerade übersichtlich. Es wurde einmal der Ansatz diskutiert: Hausnummer auf die Gebäudefläche und alle POI die darin liegen, bekommen die Adresse dann automatisch, aber keine Ahnung, ob es da konkrete Entwicklungen gibt. Aber das man 23 Adressen an nahezu derselben Position findet ist ja einfacher wegzuoptimieren als irgendwelche relations aufzuloesen. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 08.07.2012 17:06, schrieb Jimmy_K: Am 08.07.2012 12:28, schrieb Florian Lohoff: Relationen sind schoen um dinge abzubilden die sich anders nicht abbilden lassen. Gerade bei Geschaeften spricht aber nichts dagegen die Adresse auf allen nodes zu haben. Das ist einfach und fuer jeden gut zu pflegen. Flo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Kann nur dann zum Problem werden, wenn ich nach einer Adresse Suche und dann 35 Mal das mehr oder weniger selbe Ergebnis bekommen. Macht das Navigieren nicht gerade übersichtlich. Es wurde einmal der Ansatz diskutiert: Hausnummer auf die Gebäudefläche und alle POI die darin liegen, bekommen die Adresse dann automatisch, aber keine Ahnung, ob es da konkrete Entwicklungen gibt. Sehe ich recht ähnlich. Da aber jeder Tagt, wie er möchte muss ein Auswerter sowohl mit der site-Relation klar kommen, als auch mit der von dir angesprochenen Annahme, als auch mit der Situation, dass jedes Objekt eine eigene Hausnummer hat. Das führt zu einem recht hohen Aufwand, den nicht jeder leisten möchte. Wenn man sich nicht auf eine Variante einigt wird es immer eine Glücksache sein, ob es ausgewertet wird und wie dann das Ergebnis ist. In der Theorie kann man mit jedem obigen Ansatz einen Algorithmus schreiben, der etwas sinnvolles ausspuckt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 08.07.2012 11:26, schrieb Peter Wendorff: Es ist daher auch noch niemand auf die Idee gekommen, jede Straße als eine eigene Relation zu schreiben, um den Straßennamen nicht redundant zu speichern. ...abgesehen von Ausnahmen wie z.B. Autobahnen, bei denen das IMHO auch nicht notwendig wäre. Ich möchte in dem Zshg. auf [1] verweisen - dato hat fast jede Bundesstraße ihre eigene Relation, so auch viele Landes-, bzw. Staatsstraßen. Auch innerorts ist OSM mit immerhin rund 12.000 Relationen vom Typ street dabei [2], welche gesplittete Wege gleichen Namens explizit in Relation setzen. Dennoch sind Basisinformationen, wie name, ref, highway stets auf den Primitiven Weg / Knoten vorhanden. Anstatt eine Lanze für oder gegen die Redundanzfreiheit zu brechen, lassen sich auch positive Aspekte einer sich überschneidenden Datenhaltung finden: - Robustheit - ist ein Faktum sowohl als Relation, als auch über Tags an den Primitiven gemappt, steigt z.B. die Anzahl der Methoden, die QM-Tools verwenden können, um Plausibilität und Konsistenz der Daten zu prüfen - am Beispiel der Bundesstraßen wäre z.B. denkbar, dass man das Ergebnis einer errechneten Relation (alle ways mit ref=B x) mit gemappten Relationen vergleicht, zusätzlich zu den gängigen Tests auf Lücken für Route-Relationen - im Bezug auf das Tagging entsteht eine Robustheit dadurch, dass es unwahrscheinlich ist, dass ein Mapper sowohl auf dem way als auch in der Relation versehentlich das gleiche ändert/löscht - Wartbarkeit / Datenmanagement - existieren sowohl Relation als auch Primitiven, kann der Mapper Information gewichten, d.h. bestimmte Informationen redundant halten, andere nicht - bsp.-weise könnte man sich der Übersichtlichkeit wegen entscheiden, auf den Primitiven nur die nötigste Information zu taggen (ref/name), während die Relation Zusatzinformation hält (tmc, name:de, name:en, name:xyz, ..) - damit bleiben die einfacheren und vermutlich häufigeren Anwendungsfälle auch ohne Relation-Lookup lösbar - Zugänglichkeit - Verschiedene Leute verwenden verschiedene Mapping-Methoden. Während die strukturierteren Leute sich evtl. gezielt mit einem bestimmten Thema beschäftigen (sei es Bundesstraßen, Wasserläufe, Geschäfte, etc.) und es demnach begrüßen, wenn sie, statt einem Gebiet, gleich über eine Relation die jeweils zu bearbeitenden Daten selektiv in ihren Editor ziehen können, um den aktuellen Stand zu prüfen, interessiert diese Art des Zugangs den Pionier im relativ datenlosen Gebiet kaum. Gruß Christian [1] http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bundesstra%C3%9Fen [2] http://taginfo.openstreetmap.org/search?q=type%3Dstreet ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo! ich möchte mal wieder eine Frage an die Allgemeinheit stellen auch auf die Gefahr hin zerrissen zu werden. doof, weil Es geht um die Frage wie ist soetwas überhaupt vernünftig und performant in der Auswertung zu realisieren. Das Beispiel kann sicherlich auch auf andere Relationen übertragen werden. Immer werden verschiedene Elemente bei Relationen zusammengeführt die irgendetwas gemeinsam haben und man so verhindern will das Redundante Daten entstehen. Die Frage die ich nun stellen möchte - ist es überhaupt irgendwie möglich solche Verbindungen performant aufzuschlüsseln? und gibt es vielleicht schon Programm(teile) dafür von denen ich nicht weiß. Relation sind nicht grundsätzlich schlecht und können performant abgearbeitet werden. Es gibt aber dennoch in der Praxis gute und schlechte Nutzung von Relationen die es einem Programm mehr oder weniger schwierig machen, diese zu verarbeiten. Leider befürchte ich, dass die Einhaltung einige Kriterien, die es einer Software einfacher machen, es einem Mapper schwieriger machen. Grundsätzlich ist das OSM-Format (im weitesten Sinne) für eine Software immer dann gut, wenn es eine eindeutige Anwendung gibt, wenn ein Problem auf eine Art gemappt wird. Mehrere Varianten zu implementieren ist doof, speziell Ergebnisse beider Ansätze dann wieder zusammenzuführen. Turn Restrictions sind daher OK, Die verschiedenen Hausnummern-Ansätze daher eher schlecht. Schlecht ist auch, wenn Relationen zu einer unscharfen oder lokalen Suche führen, da Referenzen nicht direkt sind. D.h.statt Objekte über die Id zu referenzieren werden sie über ihren Namen referenziert (Die Bahnhofsstr. vor dem Haus ist für Software leider algorithmisch nicht so simpel auf zu lösen wie für den Mapper). Ich verstehe, das direkte Objektreferenzen fragil sind, aber warum klappt bei Turn Restrictions dies, aber bei Hausnummern nicht? Multipolygon und Turn Restrictions sind daher hier OK, Hausnummern Relationen eher nicht. Ich vermute mal,dass es weitere solche Regeln gibt, die die Qualität eines Mappings -speziell von Relationen - aus der Sicht einer Software-Auswertung bewertbar macht. Eine Diskussion und eine Liste wäre ggf. hilfreich und könnte dem nicht-programmierenden Mapper Problemzonen klarer machen, Als Softwareentwickler bin ich dafür, dass jeder Mapper für seine Syntax auch einen performanten Algorithmus liefern muss ;-), aber ich kann den Widerstand der Mapper verstehen. Ich würde mir aber öfters wünschen, dass wenn man nicht für den Renderer mapped, dann doch die Software im Allgemeinen nicht ganz aus den Augen läßt, die das wieder zusammenstoppeln muss. Manches mit Liebe gemappte Feature wäre vermutlich schon längst sichtbar(er), wenn es denn einfach auszuwerten wäre. -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo! Ich möchte in dem Zshg. auf [1] verweisen - dato hat fast jede Bundesstraße ihre eigene Relation, so auch viele Landes-, bzw. Staatsstraßen. Auch innerorts ist OSM mit immerhin rund 12.000 Relationen vom Typ street dabei [2], welche gesplittete Wege gleichen Namens explizit in Relation setzen. ich habe mal versucht, eben über Autobahn-Relationen dass Autobahnnetz vollständig aufzubauen. Das wäre hilfreich gewesen, um eine optimierte (aka punktreduzierte) Variante des Netzes für niedrige Zoomlevel zu erzeugen. Das ist kläglich gescheitert. Zum einen, weil die bestehenden Export Extrakte mit Relationen nicht pfleglich genug umgehen zum anderen(die Strategie wäre da für jeden Relationstyp auch möglicherweise eine andere), weil die Relationen einfach nicht vollständig waren. Ein Qualitätsproblem, welches dazu führt, dass ich Relationen nun nur noch für ein paar wenige Zwecke auswerte - für diesen aber eben nicht. Diese Arbeit war für meine Ziele umsonst :-/ - Robustheit - ist ein Faktum sowohl als Relation, als auch über Tags an den Primitiven gemappt, steigt z.B. die Anzahl der Methoden, die QM-Tools verwenden können, um Plausibilität und Konsistenz der Daten zu prüfen - am Beispiel der Bundesstraßen wäre z.B. denkbar, dass man das Ergebnis einer errechneten Relation (alle ways mit ref=B x) mit gemappten Relationen vergleicht, zusätzlich zu den gängigen Tests auf Lücken für Route-Relationen - im Bezug auf das Tagging entsteht eine Robustheit dadurch, dass es unwahrscheinlich ist, dass ein Mapper sowohl auf dem way als auch in der Relation versehentlich das gleiche ändert/löscht Für eine Softwarenutzung irrelevant. Automatisches Auflösen von Widersprüchen ist sehr aufwändig und eine Entscheidung hat eine offensichtliche 50/50 Chance. Da schenke ich mir die Relation gleich, wenn möglich. - Wartbarkeit / Datenmanagement - existieren sowohl Relation als auch Primitiven, kann der Mapper Information gewichten, d.h. bestimmte Informationen redundant halten, andere nicht - bsp.-weise könnte man sich der Übersichtlichkeit wegen entscheiden, auf den Primitiven nur die nötigste Information zu taggen (ref/name), während die Relation Zusatzinformation hält (tmc, name:de, name:en, name:xyz, ..) - damit bleiben die einfacheren und vermutlich häufigeren Anwendungsfälle auch ohne Relation-Lookup lösbar Das Verteilen von Daten zu einem Objekt über mehrere andere Objekte macht es Software sehr viel schwieriger diese Daten zusammenzuführen. Es sind viel mehr Daten gleichzeitig in der Luft zu halten. Das bedeutet, geringere Performance, mehr Hauptspeicherbedarf. Widersprüche (s.o.) können auftreten. Software hätte gerne Datenlokalität. Es gibt schön Gründe warum Datenbanken normalisiert sein sollen. - Zugänglichkeit - Verschiedene Leute verwenden verschiedene Mapping-Methoden. Während die strukturierteren Leute sich evtl. gezielt mit einem bestimmten Thema beschäftigen (sei es Bundesstraßen, Wasserläufe, Geschäfte, etc.) und es demnach begrüßen, wenn sie, statt einem Gebiet, gleich über eine Relation die jeweils zu bearbeitenden Daten selektiv in ihren Editor ziehen können, um den aktuellen Stand zu prüfen, interessiert diese Art des Zugangs den Pionier im relativ datenlosen Gebiet kaum. Verschiedene Zugänge zu Daten ist für Software OK, da man flexibler gegenüber mehreren Lösungsansätzen ist. Dafür muss aber alle Zugänge zu allen Daten führen. Das ist bei OSM eher nicht der Fall. Obige Aspekte spiegeln die Sicht eines Mapper wieder. Die Punkte sind aus seiner Sicht nicht falsch. Die Sicht des Mappers ist aber nur eine Sicht, die Sicht einer Software und deren Entwickler ist eine andere. Es gelten andere Kriterien,die teilweise im Widerspruch zu den Kriterien des Mappers sind. Will man nicht nur an der Bearbeitungs-Useability des Mappers arbeiten sondern auch an der Qualität des Software-erstellten Ergebnisses, sind diese Kriterien mehr in Einklang zu bringen. Zu viel Mach es wie du willst macht es der Software schwer, zu viel Genau nach Schema und mit klarer Definition und nicht anders sorgt dafür, dass die Mapper wegrennen. Haben beide Seiten mehr Fingerspitzengefühl und Verständnis für die Bedürfnisse des anderen, kann was Tolles daraus werden :-) -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Christian Müller wrote siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen so unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht geben. Das würde ich so nicht unterschreiben. Der Umgang mit Relationen ist in der ÖPNV-Karte alles andere als Einfach. Um große Datenmengen oder gar den ganzen Planeten verarbeiten zu können muss man da schon ein gehörige Portion Hirnschmalz reinstecken. Verschachtelte Relationen, wie sie von manchen ÖPNV-Mappern teilweise verwendet werden, kann beispielsweise auch die ÖPNV-Karte nicht auswerten. Ich würde daher aus Sicht des Datenverarbeiter nur zu Relationen raten, wenn die Information nicht anders darstellbar ist. Insbesondere wenn es um einen neuen Relationstyp geht, den noch niemand auswertet und somit nicht geklärt ist, ob sich das auch in großem Stil auswerten lässt. Gruß, Melchior -- View this message in context: http://gis.19327.n5.nabble.com/Relationen-aus-der-Sicht-der-Auswertung-Segen-oder-Fluch-tp5715546p5715614.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] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Moin, ich finde Jans Ansatz grundsätzlich sinnvoll. Für die meisten Relationstypen wäre auch eine universelle Vorverarbeitung möglich, bei der alle key/value Paare der Relation mit einem Präfix in die Mitgliedselemente kopiert werden. Dann könnten die bestehenden Programme diese Daten wie üblich verarbeiten. OSM wird bislang hauptsächlich zum Kartenmalen benutzt. Dafür reicht es meist aus, wenn jedes Teilobjekt unabhängig existiert und alle Eigenschaften enthält. Möchte man OSM eher als Geodatenbank verstehen, die die Kartenerstellung nur als eine Anwendung unter vielen unterstützt, dann wird es nötig, einem Objekt der realen Welt auch genau ein Objekt in OSM zuzuordnen. Bislang liefert z.B. eine Suche nach Kreuz Rendsburg in Nominatim vier unabhängige Treffer; eine Relation, die die Abfahrten zusammenfasst, könnte einen Treffer im Mittelpunkt erzeugen. Abfragen wieviele Objekte mit Eigenschaft X gibt es im Bereich Y (z.B. wieoft gibt es Goethestraße in Deutschland) wären dann kein Problem. Mit den aktuellen Datenstrukturen könnte man nur eine Heuristik nutzen (zwei Straßen mit gleichem Namen gehören zusammen, wenn der Abstand ) um mit sehr viel Mühe einen ungenauen Wert zu erhalten. Selbst die Kartendarstellung könnte profitieren, wenn nicht jede Aufteilung eines Weges (z.B. Geschwindigkeitsbegrenzungen bei Straßen) zu zwei unabhängigen Objekten mit gleichem Namen führt, sondern ein zusammenhängendes Objekt den Namen trägt. Ich sehe durchaus die von den anderen Beteiligten genannten Probleme bei der Relationserstellung, -pflege und -auswertung. Insbesondere bleibt das Henne-Ei-Problem zwischen Softwareanpassung und Relationsnutzung. Trotzdem betrachte ich die Zusammenfassung mehrerer Teilobjekte in Relationen als Zukunftsmodell von OSM. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
