Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Torsten Breda torst...@gmail.com wrote: Die Komplexität beispielsweise eines Straßenzuges besteht in der Wirklichkeit aus wechselnden Eigenschaften, wie Maxspeed, Befahrung durch Buslinie, Wechsel des Stra0ennamens etc. Diese in der Realität existierende Fakten müssen in OSM 1:1 abgebildet werden. Eine Lösung kann also niemals weniger komplex als die Wirklichkeit sein. Das wage ich zu bezweifeln. Natürlich hat das Abbild der Daten eine entsprechende Komplexität. Auf Userseite muss dies jedoch nicht gegeben sein. Man bearbeitet ja auch kein Foto pixelweise, nur weil es aus Pixeln besteht. Ich will das Ganze einmal abkürzen, da Ich vermute, dass wir hier aneinander vorbeireden. Möglicherweise habe ich nicht weit genug ausgeholt und vermeintlich Selbstverständliches fortgelassen. Wenn ich eine Karte als Foto ansehe und pixelweise bearbeitete, dann ist das ja gerade die unnötige Verkomplizierung (und zwar in höchster Vollendung), gegen die ich mich in meinem gesamten Posting stemme. Ziel meines Modells ist es, eine Geschwindigkeitsbeschränkung, den Verlauf einer Buslinie, die ununterbrochene Mittlinie oder die Leitlinie etc. genau dort in die Karte einzuzeichnen, wo man sie in Wirklichkeit vorfindet (und das nenne ich Komplexität(sgrad) der Wirklichkeit), ohne dabei die Straße unnötig an jedem Punkt aufsplitten zu müssen, an dem sich eine Eigenschaft ändert. Denn in Wirklichkeit ist die Straße an diesen Punkten auch durchgehend. Hält man sich dies vor Augen, wird klar, dass Deine Lösung nicht funktionieren kann, wie ich unten an Beispielen zeigen werde. Das stimmt nicht. Vielleicht hast du mich in der Lösungsbeschreibung nicht richtig verstanden. Um das zu prüfen, folgendes Beispiel. - | Modul | editierbar | sichtbar | - | Straßen |o | x | - | Landnutzung |o | x | - | Gebäude |o | o | - | Routen |o | o | - | Grenzen |x | x | - | ÖPNV|o | o | - Bei dieser Oberfläche gäbe es beispielsweise die Möglichkeit, ÖPNV auf sichtbar und editierbar zu schalten, aber die Straßen in beiden Fällen außen vor zu lassen ... oder umgekehrt. Es geht darum unnötige Fakten auszublenden und, im Gegensatz zu einer editorbasierten Lösung, ein System zu schaffen, dass Bearbeitungen an Teildatenmengen erlaubt, ohne andere Daten zu beschädigen. Richtig! Dennoch kann ich beispielsweise eine Buslinie nicht getrennt von einer Straße bearbeiten. Der Bus kann eben nur dort fahren, wo auch eine Straße existiert. Wenn ich also die Buslinie bearbeite, muss zwangsläufig auch der Straßenverlauf beachtet werden oder der Bus fährt über die Wiese oder durch Häuser. Umgekehrt muss sich bei der Manipulation des Verlaufes der Straße, auch der Verlauf der Buslinie ändern. Ebenso kann ich einen auf der Straße markierten Bushaltepunkt[1] nicht ausblenden, wenn ich die Straße verschiebe, denn die Haltestelle muss ebenfalls verschoben und daher neu verortet werden. Das ist aber nicht möglich, wenn diese ausgeblendet bleibt. (Das gilt natürlich analog für diejenigen Punkte, wo eine Straßeneigenschaft (z.B. Maxspeed) beginnt oder endet.) OT: Kann mir jemand sagen, warum ich nicht so auf Kosenamen auf der Mailingliste stehe? Warum ich mich schwer tue, Teilnehmer mit Kosenamen genau so ernst zu nehmen, wie solche, die ihren Realnamen dabeischreiben? Wobei ich hiermit nicht Tirkon meine, über den ich mir auf der Fossgis bereits mein eigenes Bild machen konnte. Natürlich kann ich Dir auf diese rhetorische Frage keine Antwort geben. Ich kann Dir nur erklären, welche Beweggründe es geben kann, einen Nick zu verwenden. Die heutige Datensammelwut und -Zusammenführung (Stichwortbeispiele: Vorratsdatenspeicherung und ELENA) schafft einen gläsernen Menschen. Der Nickname kann dagegen schützen. Die Verwendung des Realnamens allerorten macht eine Zusammenführung der Daten einfach. Insofern empfinde ich den von einigen Personen in deutschen Newsgroups geforderten Realnamen für nicht mehr zeitgemäß. Gerade in naturwissenschaftlichen Gruppen wird dies auch zunehmend nicht mehr moniert. Die große Mehrheit akzeptiert dort inzwischen Nicknames. Bei englisch- und französischsprachigen Gruppen ist das ohnehin kein Thema. Auch in der Wikipedia sind Nicks gang und gäbe. Ferner hilft der Nick solchen Personen, welche (zumindest lokal) im öffentlichen Licht stehen. So können sie sich eine kleine Privatsphäre schaffen, in der sie wie jeder andere in der Community operieren können, ohne dass sein Restleben dort immer wieder thematisiert
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 11. März 2010 18:10 schrieb Tirkon tirko...@yahoo.de: Torsten Breda torst...@gmail.com wrote: Die Komplexität beispielsweise eines Straßenzuges besteht in der Wirklichkeit aus wechselnden Eigenschaften, wie Maxspeed, Befahrung durch Buslinie, Wechsel des Stra0ennamens etc. Diese in der Realität existierende Fakten müssen in OSM 1:1 abgebildet werden. Eine Lösung kann also niemals weniger komplex als die Wirklichkeit sein. Das wage ich zu bezweifeln. Natürlich hat das Abbild der Daten eine entsprechende Komplexität. Auf Userseite muss dies jedoch nicht gegeben sein. Man bearbeitet ja auch kein Foto pixelweise, nur weil es aus Pixeln besteht. Ich will das Ganze einmal abkürzen, da Ich vermute, dass wir hier aneinander vorbeireden. Möglicherweise habe ich nicht weit genug ausgeholt und vermeintlich Selbstverständliches fortgelassen. Ich habe dich schon verstanden, keine Sorge. Wenn ich eine Karte als Foto ansehe und pixelweise bearbeitete, dann ist das ja gerade die unnötige Verkomplizierung (und zwar in höchster Vollendung), gegen die ich mich in meinem gesamten Posting stemme. Ziel meines Modells ist es, eine Geschwindigkeitsbeschränkung, den Verlauf einer Buslinie, die ununterbrochene Mittlinie oder die Leitlinie etc. genau dort in die Karte einzuzeichnen, wo man sie in Wirklichkeit vorfindet (und das nenne ich Komplexität(sgrad) der Wirklichkeit), ohne dabei die Straße unnötig an jedem Punkt aufsplitten zu müssen, an dem sich eine Eigenschaft ändert. Denn in Wirklichkeit ist die Straße an diesen Punkten auch durchgehend. Du erzeugst dadurch Pseudo-Ways. Das macht es nicht einfacher. Bei dieser Oberfläche gäbe es beispielsweise die Möglichkeit, ÖPNV auf sichtbar und editierbar zu schalten, aber die Straßen in beiden Fällen außen vor zu lassen ... oder umgekehrt. Wer sagt dir, das diese Möglichkeit bestehen würde Das wäre doch Unsinnig. Natürlich würde ÖPNV auch Straßen mitaktivieren, aber eben nicht umgekehrt. Ich dachte, das wäre klar gewesen. Es geht darum unnötige Fakten auszublenden und, im Gegensatz zu einer editorbasierten Lösung, ein System zu schaffen, dass Bearbeitungen an Teildatenmengen erlaubt, ohne andere Daten zu beschädigen. Richtig! Dennoch kann ich beispielsweise eine Buslinie nicht getrennt von einer Straße bearbeiten. Der Bus kann eben nur dort fahren, wo auch eine Straße existiert. Wenn ich also die Buslinie bearbeite, muss zwangsläufig auch der Straßenverlauf beachtet werden oder der Bus fährt über die Wiese oder durch Häuser. Umgekehrt muss sich bei der Manipulation des Verlaufes der Straße, auch der Verlauf der Buslinie ändern. Dem habe ich nie wiedersprochen, oder wo habe ich behauptet, dass diese Kombination möglich wäre??? Ebenso kann ich einen auf der Straße markierten Bushaltepunkt[1] nicht ausblenden, wenn ich die Straße verschiebe, denn die Haltestelle muss ebenfalls verschoben und daher neu verortet werden. Das ist aber nicht möglich, wenn diese ausgeblendet bleibt. (Das gilt natürlich analog für diejenigen Punkte, wo eine Straßeneigenschaft (z.B. Maxspeed) beginnt oder endet.) Das musst du mir nicht erklären. In meinem Eingangsposting (vielleicht noch mal lesen) habe ich geschrieben, dass es Regeln geben soll, die die Abhängigkeit der Module untereinander beschreibt. Natürlich wäre diese Kombination unsinnig. OT: Kann mir jemand sagen, warum ich nicht so auf Kosenamen auf der Mailingliste stehe? Warum ich mich schwer tue, Teilnehmer mit Kosenamen genau so ernst zu nehmen, wie solche, die ihren Realnamen dabeischreiben? Wobei ich hiermit nicht Tirkon meine, über den ich mir auf der Fossgis bereits mein eigenes Bild machen konnte. Natürlich kann ich Dir auf diese rhetorische Frage keine Antwort geben. Ich kann Dir nur erklären, welche Beweggründe es geben kann, einen Nick zu verwenden. Wie du schon selber feststellst, habe ich diese Frage nicht gestellt. Netter Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Torsten Breda torst...@gmail.com wrote: Ziel meines Modells ist es, eine Geschwindigkeitsbeschränkung, den Verlauf einer Buslinie, die ununterbrochene Mittlinie oder die Leitlinie etc. genau dort in die Karte einzuzeichnen, wo man sie in Wirklichkeit vorfindet (und das nenne ich Komplexität(sgrad) der Wirklichkeit), ohne dabei die Straße unnötig an jedem Punkt aufsplitten zu müssen, an dem sich eine Eigenschaft ändert. Denn in Wirklichkeit ist die Straße an diesen Punkten auch durchgehend. Du erzeugst dadurch Pseudo-Ways. Das macht es nicht einfacher. Im Gegensatz zum Zeichnen sollte das Einzeichnen (von Maxspeed, Busroute, Mittellinie) in die Karte suggerieren, dass man nicht irgendwo in der Gegend rummalt, sondern dieses mehr oder weniger genau entlang eines Straßenzuges erfolgt. Der Editor gibt dann beispielsweise durch Einfärbung der Route Rückmeldung, welche Straße er als getroffen ansieht und speichert sie schließlich als Relation und !!nicht!! als Pseudo-Way ab. Jetzt kann ich jede Relation für sich grafisch ausweiten oder kürzen, ohne eine andere zu schädigen. Wenn ich den Verlauf der Straße zurechtzupfe, könnten die Relationen durch verschiedenfarbige Farbbalken parallel zur Straße dargestellt werden. Eventuell reicht es auch, einen einzelnen Balken zu nutzen, der an jedem Anfang/Ende einer Relation, zwischen zwei Farben wechselt und für unaufgelöste Hotspots eine weitere Farbe verwendet, welche zur besseren Wahrnehmung eine Mindestgröße annimmt. Auch getaggte Punkte auf der Straße, wie Bahnübergänge und Zebrastreifen, werden gekennzeichnet. So wird unmittelbar beim Zupfen des Verlaufs klar, wenn man einen Problempunkt mit der Maus in der Hand hält. Bei Mausdrüberhalten oder Anklicken eines Problempunktes könnten nähere Infos (Anfang/Ende von Maxspeed, Buslinie) und zur Lösch- bzw Verschiebeproblematik angezeigt werden. Ich weiß, dass so etwas nicht einfach zu programmieren ist. Mir fällt allerdings kein Mittel ein, welches das OP-Problem besser mildern und transparenter machen könnte. Bei dieser Oberfläche gäbe es beispielsweise die Möglichkeit, ÖPNV auf sichtbar und editierbar zu schalten, aber die Straßen in beiden Fällen außen vor zu lassen ... oder umgekehrt. Wer sagt dir, das diese Möglichkeit bestehen würde Das wäre doch Unsinnig. Natürlich würde ÖPNV auch Straßen mitaktivieren, aber eben nicht umgekehrt. Ich dachte, das wäre klar gewesen. Eben nicht. Das war der Knackpunkt. Jetzt erklärt sich vieles, auch unter der Kategorie nie behauptet. Das musst du mir nicht erklären. In meinem Eingangsposting (vielleicht noch mal lesen) habe ich geschrieben, dass es Regeln geben soll, die die Abhängigkeit der Module untereinander beschreibt. Und genau da setzt das von mir beschriebene Konzept der unteilbaren Wege mit Eigenschaftsrelationen an. Analog zur obigen grafischen Beschreibung stellt die Unteilbarkeit der Straßenzüge den ununterbrochenen Straßenkörper dar, auf dem die Relationen unabhängig voneinander aufgebracht werden. (Wie die darunter liegenden Schichten das in der Datenbank darstellen, steht auf einem anderen Blatt.) Durch diese Unabhängigkeit brauchen Abhängigkeitsregeln für die Relationen untereinander erst gar nicht aufgestellt zu werden. Es bleiben also nur noch die Regeln zwischen Straßenkörper (way) einerseits und Relation sowie getaggte Punkte andererseits. Durch das Konzept können nun diese beiden Mengen mit wenig Aufwand bestimmt werden: 1) Knickpunkte der Straße 2( Anfangs- und Endpunkte der Relationen sowie getaggte Punkte. Wenn ich mich nicht täusche, braucht man zur Abhängigkeitbeschreibung der Module untereinander für die Gruppe 1) und für die Gruppe 2) jeweils eine Lösch- und eine Bewegungsregel, die nicht allzu kompliziert sein dürfte. Dann wäre mit vier Regeln das gesamte Gefahrpotential beschrieben. Eine geringe Anzahl von Regeln hilft natürlich ungemein. Sobald man sich alle verinnerlicht hat, kann man für jede ein Handlungsschema einüben und möglicherweise veröffentlichen. Man ersetze in obiger Beschreibung Straße durch way und verallgemeinere sie so. Wermutstropfen: Eventuell machen Vaterrelationen sowie Areas das Regelschema komplexer. Falls dies für Veterrelationen zutrifft, könnte man möglicherweise durch Auflöung der Vaterrelation in die Elemente Tochterrelationen diesem beikommen. Dabei bleibt aber aus Usersicht die Vaterrelation erhalten. In dieser Richtung kann ich das Problem noch nicht so ganz greifen. Es muss wohl erst einmal sacken. Ich kenne mich mit der OSM Datenbank nicht aus. Intuitiv vermittelt sich mir das beschriebene Prinzip als eines, das vom bisherigen Schema abweicht und eventuell eine Konvertierung des Datenbestandes notwendig machen könnte. Daher der Begriff OSM 2.0. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 11. März 2010 23:51 schrieb Tirkon tirko...@yahoo.de: Torsten Breda torst...@gmail.com wrote: Ziel meines Modells ist es, eine Geschwindigkeitsbeschränkung, den Verlauf einer Buslinie, die ununterbrochene Mittlinie oder die Leitlinie etc. genau dort in die Karte einzuzeichnen, wo man sie in Wirklichkeit vorfindet (und das nenne ich Komplexität(sgrad) der Wirklichkeit), ohne dabei die Straße unnötig an jedem Punkt aufsplitten zu müssen, an dem sich eine Eigenschaft ändert. Denn in Wirklichkeit ist die Straße an diesen Punkten auch durchgehend. Du erzeugst dadurch Pseudo-Ways. Das macht es nicht einfacher. Im Gegensatz zum Zeichnen sollte das Einzeichnen (von Maxspeed, Busroute, Mittellinie) in die Karte suggerieren, dass man nicht irgendwo in der Gegend rummalt, sondern dieses mehr oder weniger genau entlang eines Straßenzuges erfolgt. Der Editor gibt dann beispielsweise durch Einfärbung der Route Rückmeldung, welche Straße er als getroffen ansieht und speichert sie schließlich als Relation und !!nicht!! als Pseudo-Way ab. Jetzt kann ich jede Relation für sich grafisch ausweiten oder kürzen, ohne eine andere zu schädigen. Sag ich doch, Pseudoways. Du vermischst in deinem Vorschlag Datengrundlage und Visualisierung im Editor. Was die Datengrundlage angeht, so kannst du das schon genau so, wie heute verwenden, wenn du möchtest, siehe: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Segmented_Tag . Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Hallo Liste Als ich vor einigen Jahren bei OSM angefangen habe, war die Welt noch einfach. Man erfasste Straßen und ihre Namen, dazu noch ein paar POIs - fertig! Viel Diskussionsbedarf bestand nicht, wenn man sich auf die einzelnen Keys geeinigt hatte. So einfach ist es heute aber nicht mehr. Die Komplexität der OSM-Welt nimmt ständig zu. Wer sich heute mal eine Innenstadt in JOSM anschaut, weiß was ich meine. Da gibt es neben den Straßen und POIs viele andere Dinge, die in der Karte zu sehen sind. Landflächen, Plätze, Buslinien, Grenzen, Brücken, Stromleitungen, Tunnel und und und... Wer in so einem Gebiet wirklich nur eine Kleinigkeit ändern möchte, muss höllich aufpassen, das er keine Relationen beschädigt, Straßen mit Flächen verbindet, Maxspeed löscht oder auf eine falsche Straße ausweitet, Löcher in Wanderrouten erzeugt und so weiter. Man muss sich immer mit der sonstigen Verwendung der Elemente vertraut machen, um nicht die Arbeit der Anderen zu stören oder zu beschädigen. Oder man aggiert nach dem Motto Augen zu und durch, Wird schon schiefgehen oder Die Fehler die ich mache wird schon jemand richten. Wer sich mal mit der Pflege von Boundarys, ÖPNV-Relationen oder sonstigen komplexeren Dingen beschäftigt hat, weiß ein Lied davon zu singen. Durch dieses Dilemma entstehen verschiedene Probleme: 1. Der Einstieg in das Thema OSM wird immer komplizierter. Mal eben eine fehlende Straße einzeichnen - so wie es früher war - funktioniert nur noch im Niemandsland. 2. Immer mehr Energie wird in die Pflege/Reparatur der Daten aufgewendet. 3. Ein sinnvolles Bearbeiten ist nur noch durch wenige Experten möglich. 4. Importe werden sehr kompliziert. - Gespendete Daten müssen mit größter Vorsicht oder händich eingefügt werden. Wie kann man das Lösen? Einfach zu lösen ist dieses Problem mit Sicherheit nicht. Momentan versuchen wir Fehler passiv zu vermeiden. Damit meine ich, dass die Editoren, wie JOSM, vor möglichen Fehlern warnen, bspw wenn eine Relation geteilt, eine Straße verschoben oder Straßen mit verschiedenen Eigenschaften verbunden werden. Eigentlich müssten JOSM und Co noch viel mehr Fehler abfangen, damit diese gar nicht erst in die Datenbank kommen. Dadurch wird das Editieren zwar sicherer, jedoch nicht einfacher. Es kann also nur eine Teillösung sein, beseitigt jedoch nicht das Grundproblem. Was ist das Grundproblem? OSM ist monolithisch! - Alles ist miteinander verknüpft und verwoben. Eine kleine Änderung kann große Wirkung haben und Bereiche oder Sachverhalte ändern, die man gar nicht verändern wollte. Was fehlt, ist die Modularität! Modularität? Wäre OSM (bzw. die OSM-Datenbank) modularer aufgebaut, beziehungsweise wären Elemente modular zu bearbeiten, so könnten andere Baustellen komplett ausgeblendet werden. Man hätte ein festes Grundgerüst und darauf die einzelnen Module, die man je nach Absicht voneinander unabhängig benutzen könnte. So einfach, wie es sich anhört, ist es nicht zu realisieren! - Stimmt, einfach ist es wirklich nicht, aber wie könnte es aussehen? Das Grundgerüst wären die Nodes. Sie halten die einzelnen Module zusammen. Node 1234567 bleibt node 1234567, egal in welchem Modul. Aber was ist mit Ways? - Ways sind in der Datenbank momentan ein Sonderfall. Sie beschreiben zum Beispiel einen Weg, indem sie die verwendeten Nodes auflisten. Damit unterscheiden sie sich eigentlich nicht viel von Relationen. Eine Relation ist eine Sammlung verschiedener, zu einander in Verhältnis gebrachter, Elemente. Genau das macht auch der Way mit den Nodes. Also - weg mit dem Datenelement way, ist ja doch nur ne verkappte Relation. Da blickt doch dann keiner mehr durch? Diese Angst habe ich nicht. Es ist nur eine Frage der Visualisierung. Da sich beim Thema way fast nur der Name ändert, dürften die Unterschiede gering sein. Wenn ich an die Abschaffung der segments im Oktober 2007 zurückdenke, erinnere ich mich, dass das für den Anwender eine sehr leichte Umstellung war. Warum sollte es in diesem Fall anders sein? Dieses war der erste Streich! Wie könnte es aussehen, dass mit den Modulen? Momentan ist JOSM ein Rohdaten-Editor. Es lässt sich alles ändern und das meiste wird visualisiert. Nicht alles, da viele Relationen nur als Tabellenansicht zu sehen sind und nicht oder nur nach dem Markieren auf der Karte gezeichnet werden. Könnte man jedoch vor dem Editieren auswählen, welches Themengebiet man bearbeiten möchte, so wäre JOSM ein Spezialeditor für alle Module, die es unterstützt und würde trotzdem nichts an Funktionalität verlieren. JOSM würde fragen: Was möchten sie Bearbeiten und sehen? Man bekäme eine Auswahl geliefert, in der man wählen könnte, welche Module editierbar sind und welche nur optisch erscheinen. - | Modul | editierbar | sichtbar | - | Straßen |o | x | - | Landnutzung |o | x |
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Hallo, Torsten Breda wrote: Das Grundgerüst wären die Nodes. Sie halten die einzelnen Module zusammen. Node 1234567 bleibt node 1234567, egal in welchem Modul. Machst Du es Dir da nicht zu einfach - es koennte doch sein, dass der Node 1234567 im Modul Deutschland vor 100 Jahren gar nicht auftaucht ;-) Momentan ist JOSM ein Rohdaten-Editor. Es lässt sich alles ändern und das meiste wird visualisiert. Nicht alles, da viele Relationen nur als Tabellenansicht zu sehen sind und nicht oder nur nach dem Markieren auf der Karte gezeichnet werden. Könnte man jedoch vor dem Editieren auswählen, welches Themengebiet man bearbeiten möchte, so wäre JOSM ein Spezialeditor für alle Module, die es unterstützt und würde trotzdem nichts an Funktionalität verlieren. JOSM hat schon ein (per default abgeschaltetes) Filter-Feature, mit dem man genau das machen kann, bestimmte Sachen ausblenden oder un-editierbar machen. Es gibt aber eine Menge Usability-Probleme, egal ob man das auf Editorseite oder, wie von Dir vorgeschlagen, auf Datenbankseite macht. Was zum Beispiel passiert, wenn ich in einem Modus arbeite, in dem nur Strommasten sichtbar sind und ich einen Strommasten versehentlich auf amenity=restaurant umtagge - wie kriege ich den dann jemals wieder? - und aehnliche Dinge. Ich glaube, dass man das einigermassen gut auf Editorseite hinbekommen kann. Allerdings zwingt uns irgendwann eventuell die immer wachsende Datenmenge, auch partielle Downloads zum Editieren zu erlauben, mit all den potentiellen Fehlerquellen - schon heute kann man ja theoretisch auf Basis eines XAPI-Files im JOSM editieren, aber dabei koennte man ja einen Node verschieben, ohne zu sehen, dass der noch von anderen Ways genutzt wird, und dadurch Chaos erzeugen usw. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 10. März 2010 13:06 schrieb Frederik Ramm frede...@remote.org: Hallo, Torsten Breda wrote: Das Grundgerüst wären die Nodes. Sie halten die einzelnen Module zusammen. Node 1234567 bleibt node 1234567, egal in welchem Modul. Machst Du es Dir da nicht zu einfach - es koennte doch sein, dass der Node 1234567 im Modul Deutschland vor 100 Jahren gar nicht auftaucht ;-) Dann taucht er halt nicht auf. Ist das schlimm? Momentan ist JOSM ein Rohdaten-Editor. Es lässt sich alles ändern und das meiste wird visualisiert. Nicht alles, da viele Relationen nur als Tabellenansicht zu sehen sind und nicht oder nur nach dem Markieren auf der Karte gezeichnet werden. Könnte man jedoch vor dem Editieren auswählen, welches Themengebiet man bearbeiten möchte, so wäre JOSM ein Spezialeditor für alle Module, die es unterstützt und würde trotzdem nichts an Funktionalität verlieren. JOSM hat schon ein (per default abgeschaltetes) Filter-Feature, mit dem man genau das machen kann, bestimmte Sachen ausblenden oder un-editierbar machen. Wie komme ich da ran? Das Ghost-plugin funktioniert (zumindest bei mir) mit der latest nicht mehr. Es gibt aber eine Menge Usability-Probleme, egal ob man das auf Editorseite oder, wie von Dir vorgeschlagen, auf Datenbankseite macht. Was zum Beispiel passiert, wenn ich in einem Modus arbeite, in dem nur Strommasten sichtbar sind und ich einen Strommasten versehentlich auf amenity=restaurant umtagge - wie kriege ich den dann jemals wieder? - und aehnliche Dinge. So wie bisher. Falls ich aber gerade in einem Spezialeditor arbeite, kommt eine Warnung Bist du sicher, dass in diesem Strommast ein McDonalds ist? Scherz beiseite. Wenn ich Restaurants einzeichnen will, dann lade ich nur das POI-Modul mit den Straßen als view-only. Dann komme ich gar nicht an den Strommast ran. Das Datenzerstören, geht momentan noch viel einfacher, nur dass man es nicht so schnell merkt. Ich glaube, dass man das einigermassen gut auf Editorseite hinbekommen kann. Ist natürlich auch eine Möglichkeit, jedoch was nützt ein Editor, der alles Prima macht, wenn ein anderer Editor alles wieder kaputt macht. (Es müsste also in jeden Editor eingebaut werden) Oder es müssten Regeln gemacht werden, wie zB Wenn ein Editor Funktion X nicht hat (zB Relationen sortieren), dann darf er Y nicht tun (Relationen ändern). Allerdings zwingt uns irgendwann eventuell die immer wachsende Datenmenge, auch partielle Downloads zum Editieren zu erlauben, mit all den potentiellen Fehlerquellen - schon heute kann man ja theoretisch auf Basis eines XAPI-Files im JOSM editieren, aber dabei koennte man ja einen Node verschieben, ohne zu sehen, dass der noch von anderen Ways genutzt wird, und dadurch Chaos erzeugen usw. Genau das war der Ursprung meiner Überlegung. Ich hatte mich gefragt, ob ich mir Boundarys über XAPI ziehen soll, um die schneller reparieren zu können, oder ob ich mit Josm nur die Relationen lade. Beides war mir zu kritisch. Daher habe ich mir überlegt, wie man das modularisieren kann. Dabei Fehler zu vermeiden und Regeln aufzustellen, wann ein node/way/relation verändert werden darf und wann er sich dagegen streubt, wird noch eine große Aufgabe (Vielleicht ja mit API 0.999) Netter Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Hi, Torsten Breda wrote: Wie komme ich da ran? Das Ghost-plugin funktioniert (zumindest bei mir) mit der latest nicht mehr. displayfilter=true setzen in der preferences-Datei. Ist ziemlich maechtig, aber ziemlich wenig dokumentiert ;-) da kansnt Du praktisch believige Such-Anfragen formulieren und aus diesen Dein aktuelles Modul zusammensetzen lassen. Ist natürlich auch eine Möglichkeit, jedoch was nützt ein Editor, der alles Prima macht, wenn ein anderer Editor alles wieder kaputt macht. (Es müsste also in jeden Editor eingebaut werden) Oder es müssten Regeln gemacht werden, wie zB Wenn ein Editor Funktion X nicht hat (zB Relationen sortieren), dann darf er Y nicht tun (Relationen ändern). Regeln, Vorschriften, Zwaenge... ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 10. März 2010 13:54 schrieb Frederik Ramm frede...@remote.org: Hi, Torsten Breda wrote: Wie komme ich da ran? Das Ghost-plugin funktioniert (zumindest bei mir) mit der latest nicht mehr. displayfilter=true setzen in der preferences-Datei. Ist ziemlich maechtig, aber ziemlich wenig dokumentiert ;-) da kansnt Du praktisch believige Such-Anfragen formulieren und aus diesen Dein aktuelles Modul zusammensetzen lassen. Danke, schau ich mir mal an Ist natürlich auch eine Möglichkeit, jedoch was nützt ein Editor, der alles Prima macht, wenn ein anderer Editor alles wieder kaputt macht. (Es müsste also in jeden Editor eingebaut werden) Oder es müssten Regeln gemacht werden, wie zB Wenn ein Editor Funktion X nicht hat (zB Relationen sortieren), dann darf er Y nicht tun (Relationen ändern). Regeln, Vorschriften, Zwaenge... ;-) Die Fehler, die durch ein Bearbeiten von Teildaten entstehen, können genauso bei der Bearbeitung der Gesamtdaten entstehen (wenn man nicht aufpasst). Es muss ja kein Zwang sein, jedoch ein Hinweis würde nicht schaden. Den node/way den du verschieben/löschen willst ist auch Bestandteil einer Relation/Grenze/Fluß/Landfläche. Willst du wirklich? Du kannst auch die Elemente voneinander trennen und separat korrigieren! Würde jetzt auch schon helfen. Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 10. März 2010 14:01 schrieb Torsten Breda torst...@gmail.com: Am 10. März 2010 13:54 schrieb Frederik Ramm frede...@remote.org: Hi, Torsten Breda wrote: Wie komme ich da ran? Das Ghost-plugin funktioniert (zumindest bei mir) mit der latest nicht mehr. displayfilter=true setzen in der preferences-Datei. Ist ziemlich maechtig, aber ziemlich wenig dokumentiert ;-) da kansnt Du praktisch believige Such-Anfragen formulieren und aus diesen Dein aktuelles Modul zusammensetzen lassen. Danke, schau ich mir mal an Das ist ja genial. Ist ja 1000mal besser, als ghost! Warum ist das nicht dokumentiert? Kann dadurch viel kaputt gehen? Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Torsten Breda schrieb: Am 10. März 2010 14:01 schrieb Torsten Breda torst...@gmail.com: Am 10. März 2010 13:54 schrieb Frederik Ramm frede...@remote.org: Hi, Torsten Breda wrote: Wie komme ich da ran? Das Ghost-plugin funktioniert (zumindest bei mir) mit der latest nicht mehr. displayfilter=true setzen in der preferences-Datei. Ist ziemlich maechtig, aber ziemlich wenig dokumentiert ;-) da kansnt Du praktisch believige Such-Anfragen formulieren und aus diesen Dein aktuelles Modul zusammensetzen lassen. Danke, schau ich mir mal an Das ist ja genial. Ist ja 1000mal besser, als ghost! dito. Jetzt kann ich endlich diese dämlichen landuses auf Wegen ausblenden ;-) Wenn man jetzt noch die Knoten einer Rechteckauswahl gezielt abwählen kann, um nur den Wegelementen einen Wert zuzuweisen... Gruß und Dank, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 10. März 2010 15:03 schrieb Andre Joost andre+jo...@nurfuerspam.de: Torsten Breda schrieb: Am 10. März 2010 14:01 schrieb Torsten Breda torst...@gmail.com: Am 10. März 2010 13:54 schrieb Frederik Ramm frede...@remote.org: Hi, Torsten Breda wrote: Wie komme ich da ran? Das Ghost-plugin funktioniert (zumindest bei mir) mit der latest nicht mehr. displayfilter=true setzen in der preferences-Datei. Ist ziemlich maechtig, aber ziemlich wenig dokumentiert ;-) da kansnt Du praktisch believige Such-Anfragen formulieren und aus diesen Dein aktuelles Modul zusammensetzen lassen. Danke, schau ich mir mal an Das ist ja genial. Ist ja 1000mal besser, als ghost! dito. Jetzt kann ich endlich diese dämlichen landuses auf Wegen ausblenden ;-) Wenn man jetzt noch die Knoten einer Rechteckauswahl gezielt abwählen kann, um nur den Wegelementen einen Wert zuzuweisen... Das geht über Bearbeiten-Suchen... aus der Auswahl entfernen Suchbegriff: type:node oder in der Auswahl suchen Suchbegriff type:way Bitteschön Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Torsten Breda schrieb: Am 10. März 2010 15:03 schrieb Andre Joost : Wenn man jetzt noch die Knoten einer Rechteckauswahl gezielt abwählen kann, um nur den Wegelementen einen Wert zuzuweisen... Das geht über Bearbeiten-Suchen... aus der Auswahl entfernen Suchbegriff: type:node oder in der Auswahl suchen Suchbegriff type:way Ja, funktioniert. ... oder in der Spalte K den Haken rausnehmen oder setzen. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Frederik Ramm schrieb: displayfilter=true setzen in der preferences-Datei. Ist ziemlich maechtig, aber ziemlich wenig dokumentiert ;-) Ähemm, allerdings... ;-) Da bei mir die Spalten 1,2,4,5,6 mit .. beschriftet sind, könnte ich 'ne kleine Erläuterung bekommen? Soviel hab ich schon experimentell ermittelt: 1=Filter aktiv 2=Hide/Disable 3=Filtertext 4=Nodes verbergen 5=? 6=? (H) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 10. März 2010 16:16 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Frederik Ramm schrieb: displayfilter=true setzen in der preferences-Datei. Ist ziemlich maechtig, aber ziemlich wenig dokumentiert ;-) Ähemm, allerdings... ;-) Da bei mir die Spalten 1,2,4,5,6 mit .. beschriftet sind, könnte ich 'ne kleine Erläuterung bekommen? Sieht bei mir genau so aus und die Spaltenbreite ist nicht zu verschieben Soviel hab ich schon experimentell ermittelt: Einfach mal mit dem Mauszeiger drüberfahren, dann kommt ein Tooltip. Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Hallo, Torsten Breda wrote: Das ist ja genial. Ist ja 1000mal besser, als ghost! Warum ist das nicht dokumentiert? Kann dadurch viel kaputt gehen? Das ist deshalb noch ein Schatten-Feature, weil es eine ganze Anzahl von Problemchen aufwerfen kann, die in der Lage sind, Anfaenger total zu verwirren. Das muesste alles erst noch in groesserem Kreis ge-beta-testet werden, bevor man es auf die Massen loslassen kann. Die ... in den Ueberschriften sind ja nur der Anfang ;-) Wirklich cool waere dann auch ein eingebauter Satz von Standardfiltern oder eine Moeglichkeit, diese leicht mit anderen Usern auszutauschen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 10. März 2010 16:48 schrieb Frederik Ramm frede...@remote.org: Hallo, Torsten Breda wrote: Das ist ja genial. Ist ja 1000mal besser, als ghost! Warum ist das nicht dokumentiert? Kann dadurch viel kaputt gehen? Das ist deshalb noch ein Schatten-Feature, weil es eine ganze Anzahl von Problemchen aufwerfen kann, die in der Lage sind, Anfaenger total zu verwirren. Das muesste alles erst noch in groesserem Kreis ge-beta-testet werden, bevor man es auf die Massen loslassen kann. Falls mir was auffällt mach ich ein Ticket. Wirklich cool waere dann auch ein eingebauter Satz von Standardfiltern oder eine Moeglichkeit, diese leicht mit anderen Usern auszutauschen. Recht hast du! Im Packet mit entsprechenden styles und presents ergäbe sich dann in Windeseile ein Spezialeditor. Das ist ein echter Fortschritt. DANKE JOSM-DEV-TEAM! Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
moin ich schnippel mal nen bissel was raus. auch wenn du schon einige dinge korrekt aufgezählt hast. On 10.03.2010, at 11:31, Torsten Breda wrote: Durch dieses Dilemma entstehen verschiedene Probleme: 1. Der Einstieg in das Thema OSM wird immer komplizierter. Mal eben eine fehlende Straße einzeichnen - so wie es früher war - funktioniert nur noch im Niemandsland. Jain, ich habe schon straßen in innenstädten eingefügt. problemlos, allerdings muß man schon die tags kennen um eine straße gebäude o.ä. richtig zu kennzeichnen. Und genau da hast du recht mal eben ist nicht möglich. 2. Immer mehr Energie wird in die Pflege/Reparatur der Daten aufgewendet. hmm sehe ich nicht wirklich so, allerdings tummel ich mich auch eher in regionen wo sich wenig ändert oder gelegentlich in krisenregionen. beides dürfte nicht wirklich der norm entsprechen. 3. Ein sinnvolles Bearbeiten ist nur noch durch wenige Experten möglich. sicherlich abhängig von den tools. und ich denke hier ist der entscheidene punkt. tools wie jetzt für das iPhone entwickelt werden machen das bearbeiten deutlich leichter auch für n00bs ;-) 4. Importe werden sehr kompliziert. - Gespendete Daten müssen mit größter Vorsicht oder händich eingefügt werden. hm da vermute ich mal das es korrekt ist. ich kann mir eigentlich kein bereich vorstellen wo dies nicht so ist. egal ob es ne einzelhandelskette, denkmäler oder ackerflächen sind. Nun eure Meinung zu dem Thema: Seht ihr die Eingangs beschriebenen Probleme genau so? s.o. Glaubt ihr, dass man die Probleme mittelfristig lösen muss? Wie gesagt einige dinge sind schon im lösungsprozess. klar es muß sich was tuen, aber ich denke auch das eine größere nutzergemeinde auch dazu führt das mehr leute mit guten ideen für verbesserungen kommen. Was haltet ihr von der (Pseudo-)Modularisierung? gute idee. Habt ihr eine andere Lösung? vereinheitlichung von tags. wenn ich mir die sache mit den seezeichen anschaue zum beispiel. das ist nen krampf. auch wäre es ne idee wenn man mal ein bot hätte der auswertet welche tags wie häufig verwendet werden und automatisch tags umschreibt. also nehmen wir hier mal locksmith wenn dieser häufiger verwendet wird als zum beispiel Schlüsseldienst oder Schlüsselmacher dann sollte dieser Bot so konfiguriert werden das diese tags umgeschrieben werden. zudem sollten dann die entsprechenden wiki seiten direkt auf das standardisierte tag verweisen (weiterleitung) und garnicht erst die alten tags anzeigen. klar das geht nicht zu 100% automatisiert aber wenn sich leute hinsetzen und da in regelmäßigen abständen (oder auf zuruf) eine entsprechende tabelle pflegen mit tags und aliasen dann sollte es möglich sein. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 10. März 2010 19:42 schrieb AssetBurned openstreet...@assetburned.de: Was haltet ihr von der (Pseudo-)Modularisierung? gute idee. Habt ihr eine andere Lösung? vereinheitlichung von tags. Das ist ein ganz anderes Problem und hat meiner Meinung nach sehr wenig mit dem hier beschriebenen Sachverhalt zu tun. wenn ich mir die sache mit den seezeichen anschaue zum beispiel. das ist nen krampf. auch wäre es ne idee wenn man mal ein bot hätte der auswertet welche tags wie häufig verwendet werden und automatisch tags umschreibt. also nehmen wir hier mal locksmith wenn dieser häufiger verwendet wird als zum beispiel Schlüsseldienst oder Schlüsselmacher dann sollte dieser Bot so konfiguriert werden das diese tags umgeschrieben werden. zudem sollten dann die entsprechenden wiki seiten direkt auf das standardisierte tag verweisen (weiterleitung) und garnicht erst die alten tags anzeigen. klar das geht nicht zu 100% automatisiert aber wenn sich leute hinsetzen und da in regelmäßigen abständen (oder auf zuruf) eine entsprechende tabelle pflegen mit tags und aliasen dann sollte es möglich sein. -1 Vertipper sind das eine, jedoch muss man sehr vorsichtig sein, wenn man automatisiert Tags durch vermeintlich bessere ersetzt. Ich bin also anderer Meinung, als Herr Assetburned. Jedoch beteilige ich mich weder in den Seezeichen-Sachen, noch an größeren Diskussionen des Taggingschemas. Ich nehme immer der Tag der mir passend erscheint oder der mir als erstes in die Finger kommt. Ein Insider mag da anderer Meinung sein. Netter Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Zwei Kommentare: 2. Immer mehr Energie wird in die Pflege/Reparatur der Daten aufgewendet. Und genau das wird die Zukunft von OSM sein und gerade in deutschen Städten beginnt die Zukunft schon jetzt: Es geht nicht mehr um die Erfassung, sondern vornehmlich um die Datenpflege. Das reine Mappen im Sinne von neu eintragen wird mehr und mehr in den Hintergrund treten, je vollständiger wir sind. 4. Importe werden sehr kompliziert. - Gespendete Daten müssen mit größter Vorsicht oder händich eingefügt werden. hm da vermute ich mal das es korrekt ist. ich kann mir eigentlich kein bereich vorstellen wo dies nicht so ist. egal ob es ne einzelhandelskette, denkmäler oder ackerflächen sind. Importe waren und sind nie unsere Stärke. Unsere Stärke ist die Möglichkeit, die Datenerfassung auch auf großen Gebieten crowdzusourcen. Importe sind in meinen Augen in Anfangszeiten eine Möglichkeite gewesen, einen Datengrundstock zu bilden. Für ein im Bereich des Importdatensatzes schon erfasstes Gebiet macht ein Import immer weniger Sinn. Da lohnt es sich eher darauf zu warten, dass die verbliebenen Daten früher oder später auf herkömmlichen OSM-Wege erfasst werden. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Torsten Breda torst...@gmail.com wrote: Die Komplexität der OSM-Welt nimmt ständig zu. Auch ich habe das schon einmal thematisiert. Mein Vorschlag war #hnlich wie Deiner, nämlich eine All-in-One konfigurierbare Karte zu haben. die als Hintergrund für den Editor geschaltet, nur das Editieren der sichtbaren Objekte zulässt. Aber auch dies ist nicht unproblematisch und nur in Grenzen machbar. Wie kann man das Lösen? Die Komplexität beispielsweise eines Straßenzuges besteht in der Wirklichkeit aus wechselnden Eigenschaften, wie Maxspeed, Befahrung durch Buslinie, Wechsel des Stra0ennamens etc. Diese in der Realität existierende Fakten müssen in OSM 1:1 abgebildet werden. Eine Lösung kann also niemals weniger komplex als die Wirklichkeit sein. Sie kann höchstens vermeiden, dass durch ihre Implementierung zusätzliche Komplexität geschaffen wird. Hält man sich dies vor Augen, wird klar, dass Deine Lösung nicht funktionieren kann, wie ich unten an Beispielen zeigen werde. Was aber getan werden kann, ist es, die Sache nicht unnötig zu verkomplizieren. Verschiebe ich also eine Straße, so müssen zwangsläufig deren Eigenschaften mitverschoben werden. Aus diesem Grunde ist Dein Vorschlag nicht umsetzbar, Relationen von der Sie beheimatenden Straße loszulösen. Und daher kann der ÖPNV in Form von Bussen nicht unabhängig von einer Straße editiert werden. Das Problem bei der Sache ist es. dass sich beispielsweise Busse innerhalb des ÖPNV nicht von den Straßen trennen lassen, weil sie als Relationen auf den Straßen liegen. Wenn man zum Beispiel einen Straßenabschnitt in zwei Teile zerlegen muss, weil sich beispielsweise die Höchstgeschwindigkeit ändert, dann ändert sich auch die Relation eines dort fahrenden Busses. Beide Abschnitte müssen dort jetzt in der richtigen Reihenfolge aufgenommen werden. (Ein Punkt, an dem Potlatch übrigens scheitert, weil er die Teilstücke durcheinanderwürfelt und somit jede jede betroffene Relation beim Teilen einer Straße zerstört.) Die Relation wird also infolge der Änderungen an der Straße geändert. Es gibt aber auch umgekehrte Beispiele, bei denen eine Änderung an der Relation eine Änderung an der Straße nach sich zieht. Wenn ein Bus beispielsweise links abbiegt und die darunter liegende Straße durchgehend ist, muss ich die Straße an der Abbiegestelle teilen. Hier ist es also die Erfassung der Buslinie (Relation), welche ursächlich ist. Beide genannten Fälle sind aber eine zusätzliche unnötige Verkomplizierung, welche nicht durch die Realität, sondern durch das verwendete Datenmodell verursacht wird. Hier könnte also eine Vereinfachung ansetzen. Eine bessere Trennung von Straßenkörper, seiner Eigenschaften und der Eigenschaften untereinander ist aber erst dann machbar, wenn ein weiterer Vorschlag von mir umgesetzt würde: Das Straßennetz ist so aufgebaut, dass jede Straße grundsätzlich unteilbar von Verzweigungknoten bis Verzweigungsknoten läuft. Geteilt wird nur noch, wenn ein neuer Verbindungsknoten eingefügt wird. Alle Eigenschaften werden nur noch als Relationen getaggt. Diese Eigenschaftsrelationen, welche dann die Tags ersetzen, können im Rahmen einer vorbestimmten Auflösung an jedem Punkt auf der Straße (bzw way) beginnen oder enden. All dies käme aber einem OSM 2.0 gleich. Die neuen Relationen müssen in der Lage sein, eine ganze Straße (von Verzweigungknoten bis Verzweigungsknoten) aufzunehmen. Darüber hinaus müssen sie Teile einer solchen Straße von Koordinate X1Y1 bis Koordinate X2Y2 (oder bis zum Ende) aufnehmen können, ohne die Straße selbst hierfür teilen zu müssen. Solche durch Relationen verursachten Punkte könnten in der Straßendarstellung anders dargestellt als die Verzweigungsknoten. Dadurch wird klar, dass hier eine neue Eigenschaft beginnt oder endet und dieser Punkt ohne nähere Prüfung nicht verschoben werden darf. Dadurch wird die abgebildete Komplexität der Wirklichkeit in OSM besser deutlich. Denn auch in der Wirklichkeit geht ein Haltevorbot, eine Buslinie, eine durchgezogene Mittellinie, ein Bürgersteig, Maxspeed etc von hier über diese Route nach dort. Und genau so würde es dann in OSM abgebildet, ohne dass der Straßenkörper hierzu verkomplizierend in immer mehr Stücke zerteilt werden muss. Wenn dann noch jemand das Ganze grafisch programmieren könnte, könnte man jede Eigenschaft von hier über diese Route bis dort in die Karte reinmalen. Die 1:1 Abbildung der Realität würde nochmals verbessert. Eine weitere Vereinfachungsmöglichkeit kann es nicht geben, da die Komplexität durch die abzubildende Wirklichkeit gegeben ist. Das OSM 2,0 stellt aber sicher, dass sie durch das Datenmodell nicht zusätzlich verkompliziert wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Frederik Ramm schrieb: Hallo, Torsten Breda wrote: Das ist ja genial. Ist ja 1000mal besser, als ghost! Warum ist das nicht dokumentiert? Kann dadurch viel kaputt gehen? Das ist deshalb noch ein Schatten-Feature, weil es eine ganze Anzahl von Problemchen aufwerfen kann, die in der Lage sind, Anfaenger total zu verwirren. Das muesste alles erst noch in groesserem Kreis ge-beta-testet werden, bevor man es auf die Massen loslassen kann. Das funktioniert doch schon mit der alten tested 2564. Hätte man das damals [tm] schon freigeschaltet/veröffentlicht, wäre der beta-test längst gelaufen. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Chris-Hein Lunkhusen schrieb: Da bei mir die Spalten 1,2,4,5,6 mit .. beschriftet sind, könnte ich 'ne kleine Erläuterung bekommen? Soviel hab ich schon experimentell ermittelt: 1=Filter aktiv 2=Hide/Disable 3=Filtertext 4=Nodes verbergen 5=? 6=? (H) Komisch bei mir kommts einmal mit den Punkten, auf dem anderen Rechner mit A, S, K, I und M. Gleiche 2564-tested-windows-exe-Version auf Windows XP. Immerhin aber mit Tooltipüs bei Mausannäherung. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Am 10. März 2010 22:58 schrieb Tirkon tirko...@yahoo.de: Torsten Breda torst...@gmail.com wrote: Die Komplexität der OSM-Welt nimmt ständig zu. Auch ich habe das schon einmal thematisiert. Mein Vorschlag war #hnlich wie Deiner, nämlich eine All-in-One konfigurierbare Karte zu haben. die als Hintergrund für den Editor geschaltet, nur das Editieren der sichtbaren Objekte zulässt. Aber auch dies ist nicht unproblematisch und nur in Grenzen machbar. Es wird ja durch das von Frederik beschriebene Hidden-Feature bereits umgesetzt. Wie kann man das Lösen? Die Komplexität beispielsweise eines Straßenzuges besteht in der Wirklichkeit aus wechselnden Eigenschaften, wie Maxspeed, Befahrung durch Buslinie, Wechsel des Stra0ennamens etc. Diese in der Realität existierende Fakten müssen in OSM 1:1 abgebildet werden. Eine Lösung kann also niemals weniger komplex als die Wirklichkeit sein. Das wage ich zu bezweifeln. Natürlich hat das Abbild der Daten eine entsprechende Komplexität. Auf Userseite muss dies jedoch nicht gegeben sein. Man bearbeitet ja auch kein Foto pixelweise, nur weil es aus Pixeln besteht. Hält man sich dies vor Augen, wird klar, dass Deine Lösung nicht funktionieren kann, wie ich unten an Beispielen zeigen werde. Das stimmt nicht. Vielleicht hast du mich in der Lösungsbeschreibung nicht richtig verstanden. Es geht darum unnötige Fakten auszublenden und, im Gegensatz zu einer editorbasierten Lösung, ein System zu schaffen, dass Bearbeitungen an Teildatenmengen erlaubt, ohne andere Daten zu beschädigen. Verschiebe ich also eine Straße, so müssen zwangsläufig deren Eigenschaften mitverschoben werden. Aus diesem Grunde ist Dein Vorschlag nicht umsetzbar, Relationen von der Sie beheimatenden Straße loszulösen. Und daher kann der ÖPNV in Form von Bussen nicht unabhängig von einer Straße editiert werden. An welchem Punkt habe ich gesagt, dass man eine Relation unabhängig von einer Straße editieren sollte? Das Umgekehrte ist die Absicht. Straße editieren ohne auf Relationen und co achten zu müssen, da die Fehler im Hintergrund vermieden werden. [...] Die Relation wird also infolge der Änderungen an der Straße geändert. Genau das soll das System erlauben, da die Module sowohl hierarchisch aufeinander Aufbauen oder aber nebeneinander funktionieren können, je nach Modul. Eine bessere Trennung von Straßenkörper, seiner Eigenschaften und der Eigenschaften untereinander ist aber erst dann machbar, wenn ein weiterer Vorschlag von mir umgesetzt würde: Das Straßennetz ist so aufgebaut, dass jede Straße grundsätzlich unteilbar von Verzweigungknoten bis Verzweigungsknoten läuft. Geteilt wird nur noch, wenn ein neuer Verbindungsknoten eingefügt wird. Alle Eigenschaften werden nur noch als Relationen getaggt. Diese Eigenschaftsrelationen, welche dann die Tags ersetzen, können im Rahmen einer vorbestimmten Auflösung an jedem Punkt auf der Straße (bzw way) beginnen oder enden. All dies käme aber einem OSM 2.0 gleich. Wie kommst du auf 2.0??? Wieso sollte eine Straße unteilbar sein??? Der Vorschlag hat aber auch nicht wirklich was mit meiner Idee zu tun. Die neuen Relationen müssen in der Lage sein, eine ganze Straße (von Verzweigungknoten bis Verzweigungsknoten) aufzunehmen. Darüber hinaus müssen sie Teile einer solchen Straße von Koordinate X1Y1 bis Koordinate X2Y2 (oder bis zum Ende) aufnehmen können, ohne die Straße selbst hierfür teilen zu müssen. Solche durch Relationen verursachten Punkte könnten in der Straßendarstellung anders dargestellt als die Verzweigungsknoten. Dadurch wird klar, dass hier eine neue Eigenschaft beginnt oder endet und dieser Punkt ohne nähere Prüfung nicht verschoben werden darf. Dadurch wird die abgebildete Komplexität der Wirklichkeit in OSM besser deutlich. Im Gegenteil! Die Komplexität nimmt zu. Da kann man ja direkt wieder segments einführen. Ich will jeden Punkt verschieben, löschen oder umtaggen können, wenn ich es für richtig halte (Auch wenn ich dafür 10 Warnungen wegklicken muss, die den Anfänger davor bewahren etwas kaputt zu machen). [...] Eine weitere Vereinfachungsmöglichkeit kann es nicht geben, da die Komplexität durch die abzubildende Wirklichkeit gegeben ist. Das OSM 2,0 stellt aber sicher, dass sie durch das Datenmodell nicht zusätzlich verkompliziert wird. Kannst du diese Aussagen bitte untermauern? Ich halte die Behauptungen, dass Es eine weitere Vereinfachungsmöglichkeit nicht geben kann und dass dein OSM 2.0 sicher stellt, dass es nicht komplizierter wird für aus der Luft gegriffen. Danke für deine Kritik Torsten Breda P.S. OT: Kann mir jemand sagen, warum ich nicht so auf Kosenamen auf der Mailingliste stehe? Warum ich mich schwer tue, Teilnehmer mit Kosenamen genau so ernst zu nehmen, wie solche, die ihren Realnamen dabeischreiben? Wobei ich hiermit nicht Tirkon meine, über den ich mir auf der Fossgis bereits mein eigenes Bild machen konnte. ___ Talk-de mailing
