You are not logged in.

#1 2012-03-06 21:30:57

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Das Problem mit der Komplexität

Wie geht man mit Komplexität in OSM um?

OSM hat ja den Anspruch eine Datenbank über die Realität zu sein. Dazu ist es zunehmend erforderlich, zumindest in Teilbereichen, auch komplexere Zusammenhänge erfassen zu können. Denn früher oder später reicht für einen Anwendungsfall das bisherige Modell garantiert nicht mehr aus, oder jemand möchte einfach zusätzliche Daten erfassen, die er für wichtig hält, und was natürlich möglich sein sollte. Da regliche Relevanzkriterien nur die mögliche Nutzung und Erfassung von Daten einschränken. Soll heißen, wenn sich Leute die Arbeit machen jeden Baum, Gullideckel oder den Betreiber der Hundekottütenspenders zu erfassen, dann ist das auch relevant (Weil wer will das denn sonst wie genau entscheiden?) und wichtig. Den Grad der allgemeinen Nutzbarkeit regelt dann eh die Anzahl der Leute, die das Erfassen und irgendwann wurde immer mal die erste Straße oder der erste Hydrant eingezeichnet.

Das Problem dabei ist nur, das je komplexer das Schema bzw. je schwerer es dadurch ist, weitere Daten hinzufügen bzw. zu korrigieren, um so weniger Mapper werden die Objekte bearbeiten/überprüfen und um so schlechter und älter sind die Daten, sofern sie überhaupt erfaßt wurden. Aus dieser Sicht ist es also sinnvoll, das Erfassen so einfach wie möglich zu machen, wobei es aber auch nicht der Weg sein kann, ein halbgares (wenn nicht heute, dann eben morgen) Schema oder Modell mittels speziellen Editoren durchzudrücken, wo sich später heraustellt, daß man da nciht wirklich drauf aufbauen kann (z.B. Spurerfassung mittels Zusatzstags an einem Weg) bzw. man das Schema eh nur mit Hilfe von Editoren sinnvoll verstehen oder bearbeiten kann und es dann an der Nichtverfügbarkeit der Software für bestimmte Plattformen scheitert. Ich bin der Meinung, das kann eine Hilfe und Arbeitserleichterung sein, aber das sollte nicht die einfache Verständlichkeit und Überprüfbarkeit durch den Menschen ersetzen!

Die andere Sichtweise ist dann, das man einfach bestimmte Informationen erfassen möchte, seinen es nun Fahrspuren, Weichen und Signale, Bürgersteighöhen, die genaue Ausgestaltung von Bojen oder Hydranten oder das tatsächlich vorhandene Fachpersonal von medizinischen Einrichtungen. Dafür braucht man dann ber ein erweitertes Schema und das macht dann unter Umständen auch die ganze Erfassung für den Mapper ohne Hintergrundwissen bzw. ohne Kapazitäten für die Einarbeitung in das verwendete Schema viel zu kompliziert, was dazu führt, das diese und wohlmöglich wichtige Grundinformationen dann üebrhaupt nicht mehr erfasst werden. Andererseits wollen die einen endlich ein Modell auf Spurbasis, statt wie bisher auf Straßenbasis (weil nur so kann man dann perspektivisch an das Erfassen der Bürgesteighöhen und Verläufe denken) und ich z.B. will endlich einen vernüftigen Ersatz für amenity=doctors. So hat jeder seine Ansprüche und fängt an ein Modell dafür zu stricken.

Da kommen dann die nächsten Probleme: Da es ein Modell ist, ist bzw. muß es ja irgendwo begrenzt sein, auch wenn es so genau wie möglich sein sollte, gibt es da durchaus Grenzfälle, spätestens dann wenn sich bestimmte Ereignisse nur schwer vorhersagen lassen, einfach weil sie zum teil auch abhängig vom Zufall sind, sofern man überhaupt eine gute maschinengerechte Darstellung dafür findet. Tendenziell ist aber eine möglichst gutes und genauer Modell aus meiner Sicht zu bevorzugen. Dieses sollte sich dann in der Komplexität frei herunter skalieren lassen, damit der nicht eigearbeitete Mapper zumindest die Grundeigenschaften erfassen kann. Das ist momentan insofern schwierig, als das man für die vernüftige, also erweiterbare und fexibele Darstellung von Zusammenhängen einfach z.B. um Relationen nicht herau kommt. Wie löst man dieses Problem also am besten? Wie macht man das Tagging bzw. Erfassungschema in dieser Hinsicht frei skalierbar, ohne all zu viel Redundanz bzw. Seitenzweige für Sonderfallbehandlungen einführen zu müssen?


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#2 2012-03-06 21:43:58

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,276
Website

Re: Das Problem mit der Komplexität

Ich sehe hier vor allem den Mapper in der Pflicht, der etwas eintragen möchte. Dieser muss sich einfach fragen: Ist diese Info sinnvoll für OSM? Besteht ein realer Bedarf an dieser Information? Wie trage ich es ein, dass bestehende "Standards" nicht zerstört werden und unerfahrene Mapper weiterhin ungestört mappen können?

Dazu ist es natürlich sinnvoll, wenn man sich VOR dem Eintragen mit anderen Mapper abspricht bzw. deren Meinung einholt.

Sicherlich kann derzeit jeder alle Daten in OSM kippen, die er möchte. Irgendwann wird OSM daran zu Grunde gehen oder man wird feste Kriterien vorschreiben müssen. Vor allem in den gut gemappten Gebieten, wo Mapper anscheinend Langeweile zu haben scheinen, ist die Situation, wie sie lange Zeit funktioniert hat so langsam am Umkippen.


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#3 2012-03-06 21:54:01

SunCobalt
Member
From: Eislingen
Registered: 2010-01-09
Posts: 3,807

Re: Das Problem mit der Komplexität

ich glaube, dass der Mapper sich zukünftig mehr und mehr vom Datenmodell entfernt. Ich denke, es wird Plugins o.Ä. geben, die auch schwierige Datenmodelle für den "einfachen Mapper" editierbar machen.  Die paar Power Mapper, die das auf Datenebene beherschen, werden die Datenmenge zukünftig nicht aktuell halten können.


Thomas

Offline

#4 2012-03-06 22:16:05

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Das Problem mit der Komplexität

aighes wrote:

Ich sehe hier vor allem den Mapper in der Pflicht, der etwas eintragen möchte. Dieser muss sich einfach fragen: Ist diese Info sinnvoll für OSM? Besteht ein realer Bedarf an dieser Information? Wie trage ich es ein, dass bestehende "Standards" nicht zerstört werden und unerfahrene Mapper weiterhin ungestört mappen können?

Dazu ist es natürlich sinnvoll, wenn man sich VOR dem Eintragen mit anderen Mapper abspricht bzw. deren Meinung einholt.

Natürlich besteht zumindest für mich ein Bedarf, weil sonst würde ich es ja nicht eintragen wollen! Das löst das Problem, wie mnan die Daten nun erfaßt, also leider nicht. Wie willst du denn sicherstellen, das der unerfahrene Mapper dein neues Modell, was natürlich nichts kaputt macht, von dem was schon da ist, auch versteht? Beziehungsweise wie soll er trotz der Existenz der Daten ungestört mappen können?

aighes wrote:

Sicherlich kann derzeit jeder alle Daten in OSM kippen, die er möchte. Irgendwann wird OSM daran zu Grunde gehen oder man wird feste Kriterien vorschreiben müssen. Vor allem in den gut gemappten Gebieten, wo Mapper anscheinend Langeweile zu haben scheinen, ist die Situation, wie sie lange Zeit funktioniert hat so langsam am Umkippen.

Kriterien im Sinne von Vorschriften helfen da absolut nicht (z.B. können die Abbiegebeschränkungen und das Spurmapping mich mal kreuzweise, trotdem toleriere ich das diese Daten erfasst werden, kommt also immer auf die Sichtweise an), das wäre nur der Tod für die Weiterentwicklung, da braucht man eine abgestufte Lösung, wo der Mapper sein Schwirigkeitslevel wählen kann.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#5 2012-03-06 22:39:50

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,276
Website

Re: Das Problem mit der Komplexität

Nur weil mich das Sortiment vom Aldi interessiert, trage ich es noch lange nicht in die OSM-DB ein. Ebenso möchte ich Routen, die ich mit dem Rad gefahren bin auf einer OSM-Karte visualisieren. Ich trage sie trotzdem nicht in die OSM-DB ein. Warum tue ich das nicht? Nun weil ich der Meinung bin, dass diese Infos nicht in die DB gehören, sondern man diese Infos ruhig extern verwalten kann.

Bevor ich anfange, jeden Pflasterstein als Fläche zu mappen, sollte ich zumindest mal drüber nachgedacht haben, ob dies sinnvoll ist und ob dies OSM weiterbringt oder ob ich nicht lieber eine eigene Datensammlung dafür starte.

Ich möchte ungern zu sehr auf das Spurmapping eingehen, eignet sich aber als Beispiel sehr gut. Wenn ich eine eher harmlose Kreuzung, die man sehr gut mit zwei sich kreuzenden Ways und einem gemeinsamen Node so sehr verkompliziert, dass am Ende zig Abbiegerelationen und ein Wust aus Ways nötig ist, dann sollte ich mich als Mapper schon fragen, ob das OSM nun vorangebracht hat oder eher zurückgeworfen hat. Ein Neuling wird an dieser Kreuzung jedenfalls keine Aktualisierungen mehr vornehmen. Ähnliches auch bei übertriebenen Multipolygonen.

Die Stärken von OpenStreetMap sind meiner Meinung nach die Aktualität durch eine einfache Datenstruktur, die es jedem ermöglicht dort Änderungen vorzunehmen, wo einem ein Fehler auffällt. Wird das Datenmodell irgendwann so komplex, dass viele Mapper dieses nicht mehr verstehen, dann ist OSM in dieser Form erledigt. Weil dann kann man die Aktualität vergessen.

Ob Vorschriften Helfen oder nicht sei mal dahingestellt. Wenn die Toleranz aber dahin führt, dass man die Daten nicht mehr sinnvoll auswerten kann ( das meint neben der Konsistenz auch die benötigte Rechenpower), dann sollte man sich schon fragen ob das noch der richtige Weg ist. Denn was nutzt eine super dolle DB, in der jeder Pflasterstein gemappt ist, wenn man ein ganzes Rechenzentrum braucht, um mit den Daten etwas anzufangen.


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#6 2012-03-06 23:50:49

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Das Problem mit der Komplexität

aighes wrote:

Nur weil mich das Sortiment vom Aldi interessiert, trage ich es noch lange nicht in die OSM-DB ein. Ebenso möchte ich Routen, die ich mit dem Rad gefahren bin auf einer OSM-Karte visualisieren. Ich trage sie trotzdem nicht in die OSM-DB ein. Warum tue ich das nicht? Nun weil ich der Meinung bin, dass diese Infos nicht in die DB gehören, sondern man diese Infos ruhig extern verwalten kann.

Ja, das geht aber nicht in allen Fällen, da braucht man zumindest eien ID in die externe Datenbank und prinzipiell kann man aber alle Lageinformationen von realen Objekten erfassen, und sei es der Ort, wo die Waren in deinem Lieblingsaldi gerade liegen. Ist nur nicht sinnvoll bei einem festen bekannten Sortiment (Nutzwert der Info am konkreten Objekt ist nur für Ausländer und Leute die noch nie in min. 2 verschiedenen  Aldi's waren gegeben) und außerdem wird morgen da vielleicht eh mal wieder umgeräumt und man müßte dann neu mappen. Die persönliche Lieblingsradroute ist ja nicht von Allgemeininteresse, also nutzt die niemandem was in den Ursprungsdaten.

aighes wrote:

Bevor ich anfange, jeden Pflasterstein als Fläche zu mappen, sollte ich zumindest mal drüber nachgedacht haben, ob dies sinnvoll ist und ob dies OSM weiterbringt oder ob ich nicht lieber eine eigene Datensammlung dafür starte.

Klar bringt es OSM weiter, weil vorher waren die Pflastersteine ja noch nicht erfasst gewesen und es sind ja in der Realität vorhandenen Objekte, wenn auch nicht unbedingt von größerem Allgemeininteresse, aber so etwas ist eben etwas für Nischenmapper! Schließlich ist ja maxspeed=* auch keine Straßeneigenschaft die mich als Fahrradfahrer interessiert, da sehe ich bestenfalls ein entsprechendes Schild in der Realität heraumstehen, was aber nicht gemappt wird, sondern man richtet allgemeiner nutzbare Daten wie die Straße als weg als solches zu sehr auf den Autofahrer-Anwendungsfall aus, was dann dazu führt, das sie jedesmal gesplittet werden muß, wenn sich gerade mal wieder eine der für Kraftfahrer relevanten Eigenschaften geändert hat. 

aighes wrote:

Ich möchte ungern zu sehr auf das Spurmapping eingehen, eignet sich aber als Beispiel sehr gut. Wenn ich eine eher harmlose Kreuzung, die man sehr gut mit zwei sich kreuzenden Ways und einem gemeinsamen Node so sehr verkompliziert, dass am Ende zig Abbiegerelationen und ein Wust aus Ways nötig ist, dann sollte ich mich als Mapper schon fragen, ob das OSM nun vorangebracht hat oder eher zurückgeworfen hat. Ein Neuling wird an dieser Kreuzung jedenfalls keine Aktualisierungen mehr vornehmen. Ähnliches auch bei übertriebenen Multipolygonen.

Da gibts als Beispiel z.B. auch noch den ÖPNV, da ist die Realität auch sehr komplex und vor allem zeigt das Beispiel, das man nicht alles auf ein paar vermeintlich einfache Zusatztags reduzieren kann. Frei nach dem Motto: Hauptsache es funktioniert für Kraftfahrer ausreichend gut, die restlichen Anwendungen müssen dann mit dem für sie nicht passenden Schema bzw. den nicht gemappten, obwohl in der Realität vorhandenen, Objekten leben, deren Eigenschaften sich somit nicht erweitern lassen. Wenn an einer Kreuzung sich z.B. 3x3 Wege in einem Gitter mit passendem Befahrbahrkeitseigenschften schneiden, ist das vielleicht etwas unüberlichtlich, aber leicht nahzuvollziehen und zu ergänzen. Abbbiegerelationen bracuht man dann im Normalfall nicht, denn Wenn man beide Wege am Schnittpunkt nur vorwärts befahren kann, ist doch klar, das man da dann nur entweder rechts bzw. nur links abbiegen kann. Diese sichtbaren und existenten Objekte versteht ein nicht eingearbeiter Mapper eher, als den kunstvoll gestrickten Modellcode für den Parser/Spezialeditor.

aighes wrote:

Die Stärken von OpenStreetMap sind meiner Meinung nach die Aktualität durch eine einfache Datenstruktur, die es jedem ermöglicht dort Änderungen vorzunehmen, wo einem ein Fehler auffällt. Wird das Datenmodell irgendwann so komplex, dass viele Mapper dieses nicht mehr verstehen, dann ist OSM in dieser Form erledigt. Weil dann kann man die Aktualität vergessen.

Das würde ja heißen man erfasst so komplizierte Sachen wie die Fahrspuren gar nicht erst, weil die Kraftfahrer können ja schließlich aus dem Fenster sehen, die sind also eher für das explizite Mapper der Bordsteinkante für den Rollirouter interessant, für den das ja überhaupt erst die möglichen Strecken im Sinne von highway=* ergibt.

aighes wrote:

Ob Vorschriften Helfen oder nicht sei mal dahingestellt. Wenn die Toleranz aber dahin führt, dass man die Daten nicht mehr sinnvoll auswerten kann ( das meint neben der Konsistenz auch die benötigte Rechenpower), dann sollte man sich schon fragen ob das noch der richtige Weg ist. Denn was nutzt eine super dolle DB, in der jeder Pflasterstein gemappt ist, wenn man ein ganzes Rechenzentrum braucht, um mit den Daten etwas anzufangen.

Man müßte über die API oder sonstige Mechanismen eben noch die Detailstufe die man bearbeiten oder abrufen möchte festlegen können. Oder die Editoren müssen das passend aufbereiten bzw. ausblenden, Poitlatch 2 ist da echt ein erster guter Ansatz in die richtige Richtung, da kann jeder Anfänger einen der dort vorhandenen POIs eintragen, ohne das dem erfahreneren Mappern die Möglickeiten durch ein beschränktes Datenmodell genommen werden. Gerade die Rechenpower ist ja auch ein Argument gegen nur abstrakt definierte Wege, ob nun cyclewy=track oder Abbiegespuren am Weg. Da muß man nämlich erst mal das Wegmodell im Rechner generieren, das man sonst fertig vorfinden würde, nur um dann die eigentliche verarbeitung im Anschluß mahen zu könen, und dazu ist es noch nicht mal genau genug, verglichen mit den direkt abgebilderen Objekten aus der Realität. Da erkauft man sich also das vermeitliuche einfachere Mappen durch erhöhten Rechenaufwand.

Last edited by Fabi2 (2012-03-06 23:52:53)


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#7 2012-03-07 18:30:47

schlauchboot
Member
Registered: 2009-08-24
Posts: 319

Re: Das Problem mit der Komplexität

aighes wrote:

Ich möchte ungern zu sehr auf das Spurmapping eingehen, eignet sich aber als Beispiel sehr gut. Wenn ich eine eher harmlose Kreuzung, die man sehr gut mit zwei sich kreuzenden Ways und einem gemeinsamen Node so sehr verkompliziert, dass am Ende zig Abbiegerelationen und ein Wust aus Ways nötig ist, dann sollte ich mich als Mapper schon fragen, ob das OSM nun vorangebracht hat oder eher zurückgeworfen hat. Ein Neuling wird an dieser Kreuzung jedenfalls keine Aktualisierungen mehr vornehmen. Ähnliches auch bei übertriebenen Multipolygonen.

Losgelöst von dem konkreten Beispiel würde ich das so nicht unbedingt unterschreiben. Was ein Neuling (Gelegenheitsmapper, ...) ändern kann, hängt nicht nur davon ab, wie komplizert das Datenmodell ist, sondern entscheidend von den zur Verfügung stehenden Editoren. Dabei muß man dann zwischen einfachen und komplexen Sachverhalten unterscheiden. Es gibt bestimmt viele Beispiele für sachlich einfache Änderungen innerhalb komplexer Sachverhalte. Ein guter Editor könnte hier bestimmt von dem notwendigerweise komplexen Datenmodell abschirmen. Vielleicht wird es in der Zukunft eine ganze Reihe von mobilen Apps geben, die genau das leisten werden -- wer weiß?

P.S: In diesem Sinne wäre ein guter Editor, der maximal das Verständnis eines mehr oder weniger komplexen Sachverhaltes erfordert, und nicht auch das Verständnis des möglichweise komplexeren zugrundeliegenden Datenmodells. Letzteres bliebe den Experten vorbehalten.

Offline

#8 2012-03-07 20:59:12

Jimmy_K
Member
Registered: 2011-01-05
Posts: 562

Re: Das Problem mit der Komplexität

Wäre natürlich zu überlegen, ob (ähnlich wie bei den Einstellungen von JOSM), es auch für das Mappen einen Anfänger- und einen Expertenmodus geben sollte.

Offline

#9 2012-03-07 21:25:30

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Das Problem mit der Komplexität

Jimmy_K wrote:

Wäre natürlich zu überlegen, ob (ähnlich wie bei den Einstellungen von JOSM), es auch für das Mappen einen Anfänger- und einen Expertenmodus geben sollte.

Das kann vielleicht besser über die Datenstrukturen die die API ausliefert gelöst werden, das hätte dann den Vorteil das alle Editoren was davon haben oder man macht eine passende Referenz-lib bzw. gelcih beides. Hauptsachen man denkt überhaupt erst mal üder dieses Problem der Kompexitätsschere nach.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#10 2012-03-07 21:25:57

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Das Problem mit der Komplexität

Jimmy_K wrote:

Wäre natürlich zu überlegen, ob (ähnlich wie bei den Einstellungen von JOSM), es auch für das Mappen einen Anfänger- und einen Expertenmodus geben sollte.

Es gibt doch schon jetzt diesen expertenmodus. Zugang nur für jene welche das Wiki lesen können. Denn das Wissen darüber ist die Vorraussetzung für die Anwendung.
Es gibt nur leider zwei andere Probleme. Unwissenheit schützt die Daten leider nicht.
Und sicher gibt es auch Menschen, welche es zwar gefunden haben, aber ohne es richtig zu verstehen anwenden.

Offline

#11 2012-03-08 09:14:14

Radeln
Member
From: RLP
Registered: 2010-08-02
Posts: 947

Re: Das Problem mit der Komplexität

Fabi2 wrote:

Kriterien im Sinne von Vorschriften helfen da absolut nicht (z.B. können die Abbiegebeschränkungen und das Spurmapping mich mal kreuzweise, trotdem toleriere ich das diese Daten erfasst werden, kommt also immer auf die Sichtweise an), das wäre nur der Tod für die Weiterentwicklung, da braucht man eine abgestufte Lösung, wo der Mapper sein Schwirigkeitslevel wählen kann.

Bei dem Durcheinander sind grundlegende und natürlich nicht zementierte Regeln absolut notwendig.


Gruß
Josef

Offline

#12 2012-03-08 09:22:17

Radeln
Member
From: RLP
Registered: 2010-08-02
Posts: 947

Re: Das Problem mit der Komplexität

viw wrote:
Jimmy_K wrote:

Wäre natürlich zu überlegen, ob (ähnlich wie bei den Einstellungen von JOSM), es auch für das Mappen einen Anfänger- und einen Expertenmodus geben sollte.

Es gibt doch schon jetzt diesen expertenmodus. Zugang nur für jene welche das Wiki lesen können. Denn das Wissen darüber ist die Vorraussetzung für die Anwendung.
Es gibt nur leider zwei andere Probleme. Unwissenheit schützt die Daten leider nicht.
Und sicher gibt es auch Menschen, welche es zwar gefunden haben, aber ohne es richtig zu verstehen anwenden.

Das Wiki lesen lesen können, ist eine Sache, der derzeitige Zustand eine andere:
- Infos zu einem Thema an unterschiedlichen Orten
- teilweise widersprüchlich / nicht eindeutig
- Proposals nicht klar genug abgesetzt. Haben IMHO im Wiki für die OSM Bearbeitung nichts zu suchen.


Gruß
Josef

Offline

#13 2012-03-08 21:41:02

Yggdrasil
Member
Registered: 2010-09-12
Posts: 187

Re: Das Problem mit der Komplexität

Will da auch mal etwas Senf dazugeben.
Was mich persönlich an unserer Datenstruktur stört und vermutlich auch Anfänger abschreckt, ist das zerhackstückeln von Wegen, aufgrund abstrakter Dinge wie z. B. eine Radroute, die ein Stückchen auf der Straße lang geht, oder Geschwindigkeitsbegrenzungen und Brücken.

Dies könnte durch intelligente Relationen besser gelöst werden. z. B.
relation
type=maxspeed
maxspeed=50
From node 2345
Via way 45678
To node 7654

Wäre sogar abwärtskompatibel, falls ein preprocessor ("butcher.jar" wink) vor der Weiterverarbeitung die Wege entsprechend zerhackt. Somit könnte jeder nur die für ihn relevanten Relationen auswerten ohne Unmengen an teilweise schwer händelbaren Unmengen an ways in der DB zu haben.
Siehe auch Parallelthreads über Brücken und Spurmapping

Ich fürchte, jetzt hab' ich ein Fass aufgerissen...

Offline

#14 2012-03-08 22:10:43

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: Das Problem mit der Komplexität

Dafür wird aber das anbringen der entsprechenden Informationen ungleich schwieriger. Was macht denn der Anfänger, der feststellt, dass in der Maxspeed=50 Straße ein Stück 30 ist? Aktuell muss er 'nur' den Weg an zwei Punkten spalten (wofür die Editoren doch ganz gut gerüstet sind) und im mittleren Stück den Wert ändern. So wie von dir beschrieben, müsste aber die Relation in zwei Teilrelationen aufgeteilt werden (was nicht nur mit unseren aktuellen Editoren schwer ist, sondern auch theoretisch kein ganz leichtes Problem für den Computer ist) sowie eine weitere Relation anlegen im gewünschten Bereich (gut, dafür wären wären die Editoren dann hoffentlich gerüstet, jetzt sind sie's nicht) und die Eigenschaften da antragen. Und was ist, wenn Knoten ausgetauscht werden? Oder der Weg aus irgendeinem wichtigen Grund gespalten werden muss? Nein, die Hackstückelei mag nicht immer schön sein, aber ich glaube nicht, dass das wirklich ein Problem für Anfänger ist. Mich hat's jedenfalls nicht abgeschreckt. Dann lieber den umgedrehten Weg gehen und die kleinen Stücke mit Relationen aneinander ketten. Das ist immer abwärtskompatibel, könnte aber von den Editoren so dargestellt werden, als gäbe es nur ein Objekt, wenn das gewünscht wäre.

Offline

#15 2012-03-08 23:40:05

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Das Problem mit der Komplexität

Yggdrasil wrote:

Was mich persönlich an unserer Datenstruktur stört und vermutlich auch Anfänger abschreckt, ist das zerhackstückeln von Wegen, aufgrund abstrakter Dinge wie z. B. eine Radroute, die ein Stückchen auf der Straße lang geht, oder Geschwindigkeitsbegrenzungen und Brücken.

Ich denke auch das stört weniger, sollte aber nach Möglichkeit konzeptionell vermieden werden, und ist für Anfänger immer noch besser als sich gleich mit Relationen beschäftigen zu müssen.

Yggdrasil wrote:

Dies könnte durch intelligente Relationen besser gelöst werden. z. B.
relation
type=maxspeed
maxspeed=50
From node 2345
Via way 45678
To node 7654

Besser und mehr an der Realität ist es aus nmeiner Sicht, gerade bei den ganzen Verkehrszeichen, doch das Schild an sich als Knoten zu mappen und dann dessen Richtung anzugeben. Zum Beispiel mit:
http://wiki.openstreetmap.org/wiki/Rela … ional_node


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#16 2012-03-09 06:36:25

Yggdrasil
Member
Registered: 2010-09-12
Posts: 187

Re: Das Problem mit der Komplexität

Fabi2 wrote:
Yggdrasil wrote:

Was mich persönlich an unserer Datenstruktur stört und vermutlich auch Anfänger abschreckt, ist das zerhackstückeln von Wegen, aufgrund abstrakter Dinge wie z. B. eine Radroute, die ein Stückchen auf der Straße lang geht, oder Geschwindigkeitsbegrenzungen und Brücken.

Ich denke auch das stört weniger, sollte aber nach Möglichkeit konzeptionell vermieden werden, und ist für Anfänger immer noch besser als sich gleich mit Relationen beschäftigen zu müssen.

Das ist eine Frage der Unterstützung durch den Editor.


Fabi2 wrote:
Yggdrasil wrote:

Dies könnte durch intelligente Relationen besser gelöst werden. z. B.
relation
type=maxspeed
maxspeed=50
From node 2345
Via way 45678
To node 7654

Besser und mehr an der Realität ist es aus nmeiner Sicht, gerade bei den ganzen Verkehrszeichen, doch das Schild an sich als Knoten zu mappen und dann dessen Richtung anzugeben. Zum Beispiel mit:
http://wiki.openstreetmap.org/wiki/Rela … ional_node

Ich denke, das wird schwierig. Die Zuordnung zum Weg stelle ich mir schwer vor. Und wenn einer das aufhebende Schid nicht einträgt, ist der ganze Planet plötzlich Tempo-30-Zone... Das Modell müsste die Möglichkeit bieten, von... bis ... darzustellen. Daher meine Idee mit den nodes in einer Relation.

Offline

#17 2012-03-09 08:00:57

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Das Problem mit der Komplexität

Yggdrasil wrote:

Will da auch mal etwas Senf dazugeben.
Was mich persönlich an unserer Datenstruktur stört und vermutlich auch Anfänger abschreckt, ist das zerhackstückeln von Wegen, aufgrund abstrakter Dinge wie z. B. eine Radroute, die ein Stückchen auf der Straße lang geht, oder Geschwindigkeitsbegrenzungen und Brücken.

Dies könnte durch intelligente Relationen besser gelöst werden. z. B.
relation
type=maxspeed
maxspeed=50
From node 2345
Via way 45678
To node 7654

Wäre sogar abwärtskompatibel, falls ein preprocessor ("butcher.jar" wink) vor der Weiterverarbeitung die Wege entsprechend zerhackt. Somit könnte jeder nur die für ihn relevanten Relationen auswerten ohne Unmengen an teilweise schwer händelbaren Unmengen an ways in der DB zu haben.
Siehe auch Parallelthreads über Brücken und Spurmapping

Ich fürchte, jetzt hab' ich ein Fass aufgerissen...

Dieser Vorschlag ist mir sehr sympatisch. Ich hatte ihn in ähnlicher Weise auch schon geäußert. Allerdings wollte ich nur Relationen von Punkten. Wege sind ja auch nichts anderes. Das hatte aber damals keinen Anklang gefunden, weil es die Datenmenge aufblähen würde. Außerdem würde es die Keys von den Objekten trennen, was sehr viel Vor/Nacharbeit von den Editoren verlangt. Wenn das aber im Zuge von Spurmpping sowieso gemacht werden müsste, warum nicht?
Deine Beispiele könnte man übrigens noch weiter fortsetzen. Wenn sich zum Beispiel die Kategorie der Straße ändert.

Offline

#18 2012-03-09 08:35:32

marek kleciak
Member
Registered: 2010-10-11
Posts: 8,421

Re: Das Problem mit der Komplexität

Intelligente Realtionen sind ein sehr guter Vorschlag! Ich würde an dieser Stelle gleich eine Wiki Seite in der man diese Idee ausbaut und weiter spezifiziert anlegen.

Was die Idee "da braucht man eine abgestufte Lösung, wo der Mapper sein Schwirigkeitslevel wählen kann" angeht, wollte ich in Garching das Konzept der Level of Details vorstellen, bei der es fünf verschiedene Levels gibt. Wie man´s integriert bekommt ist eine andere Geschichte...

Offline

#19 2012-03-09 08:53:56

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,848

Re: Das Problem mit der Komplexität

Yggdrasil wrote:

...
Dies könnte durch intelligente Relationen besser gelöst werden. z. B.
relation
type=maxspeed
maxspeed=50
From node 2345
Via way 45678
To node 7654
...
Ich fürchte, jetzt hab' ich ein Fass aufgerissen...

hmm Das funktioniert sicher, wenn ein way betroffen ist. Wenn aber mehrere ways zusammengefasst z.B. diese maxspeed erhalten sollen, was z.B. bei Spurmapping sinnvoll ist, funktioniert das nicht mehr, weil mehrere from/to/via anfallen. Komma-separated ist sicher keine Lösung.


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#20 2012-03-09 09:14:10

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Das Problem mit der Komplexität

hurdygurdyman wrote:
Yggdrasil wrote:

...
Dies könnte durch intelligente Relationen besser gelöst werden. z. B.
relation
type=maxspeed
maxspeed=50
From node 2345
Via way 45678
To node 7654
...
Ich fürchte, jetzt hab' ich ein Fass aufgerissen...

hmm Das funktioniert sicher, wenn ein way betroffen ist. Wenn aber mehrere ways zusammengefasst z.B. diese maxspeed erhalten sollen, was z.B. bei Spurmapping sinnvoll ist, funktioniert das nicht mehr, weil mehrere from/to/via anfallen. Komma-separated ist sicher keine Lösung.

Das ist eine Relation. Man muss hier nicht bei einem via Weg aufhören. Vielleicht verwechselst du das mit den Abbiegebeschränkungen.

Das Problem was ich aber sehe ist, das der Präprozess künstlich aufgebläht wird. Denn wenn man einfach einen "Weg" über den Weg zeichnet an dem die Eigenschaften gelten, dann weiß der nachfolgende Prozess gleich welche Knoten betroffen sind und braucht sie nicht über ein "Routing" herausfinden.
Denn es wäre ja auch möglich die from to in verkehrter Richtung anzugeben. (engegen der Wegrichtung)

Offline

#21 2012-03-10 10:40:01

Radeln
Member
From: RLP
Registered: 2010-08-02
Posts: 947

Re: Das Problem mit der Komplexität

aighes wrote:

Sicherlich kann derzeit jeder alle Daten in OSM kippen, die er möchte. Irgendwann wird OSM daran zu Grunde gehen oder man wird feste Kriterien vorschreiben müssen. Vor allem in den gut gemappten Gebieten, wo Mapper anscheinend Langeweile zu haben scheinen, ist die Situation, wie sie lange Zeit funktioniert hat so langsam am Umkippen.

+1

Wie sieht es da eigentlich mit der 3D Geschichte aus?
http://www.openstreetmap.org/?lat=53.96 … 01&zoom=14.

Wäre es nicht möglich, die 3D Geschichte in einer getrennten Datenbank, die auf die 'normalen' OSM Daten zurückgreift, zu führen, um das Datenvolumen in Grenzen zu halten.

BTW, bin absoluter Datenbanklaie


Gruß
Josef

Offline

#22 2012-03-10 11:07:23

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,634
Website

Re: Das Problem mit der Komplexität

Radeln wrote:

Wäre es nicht möglich, die 3D Geschichte in einer getrennten Datenbank, die auf die 'normalen' OSM Daten zurückgreift, zu führen, um das Datenvolumen in Grenzen zu halten.

Bei manchen 3D-Informationen ist das tatsächlich ein vielversprechender Ansatz und einige 3D-Entwickler überlegen auch schon, so etwas in Gang zu bringen. Das wäre dann aber für z.B. detaillierte texturierte 3D-Gebäudemodelle gedacht. Wenn es nur um einige zusätzliche Tags - z.B. height und roof shape - an einem ohnehin eingezeichneten Gebäudeumriss geht, dann steht der Aufwand für eine gesonderte Datenbank und die Verknüpfung zwischen OSM und dieser Datenbank in keinem vernünftigen Verhältnis zu Art und Umfang der Daten.

Speziell die in deinem Beispiel verwendeten 3dr:* Tags sind natürlich sehr fragwürdig, weil sie kryptische Nummern verwenden, die keiner ohne Wiki-Studium versteht. Das kann man aber leicht beheben, indem man stattdessen einen der alternativen 3D-Taggingvorschläge mit menschenlesbaren Werten verwendet. Mit einem mapperfreundlich gestalteten Proposal kann man generell schon viel zur Reduzierung der Komplexität tun.


OSM in 3D: OSM2World

Online

#23 2012-03-10 11:43:19

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Das Problem mit der Komplexität

Radeln wrote:
aighes wrote:

Sicherlich kann derzeit jeder alle Daten in OSM kippen, die er möchte. Irgendwann wird OSM daran zu Grunde gehen oder man wird feste Kriterien vorschreiben müssen. Vor allem in den gut gemappten Gebieten, wo Mapper anscheinend Langeweile zu haben scheinen, ist die Situation, wie sie lange Zeit funktioniert hat so langsam am Umkippen.

+1

Wie sieht es da eigentlich mit der 3D Geschichte aus?
http://www.openstreetmap.org/?lat=53.96 … 01&zoom=14.

Wäre es nicht möglich, die 3D Geschichte in einer getrennten Datenbank, die auf die 'normalen' OSM Daten zurückgreift, zu führen, um das Datenvolumen in Grenzen zu halten.

BTW, bin absoluter Datenbanklaie

Man könnte vieles. Es ist nur eine Frage der Sicherheit. In der OSM Datenbank ist jedes Objekt eindeutig mit einer ID versehen. Über diese ID kann man jetzt die Objekte zweifelsfrei zu ordnen. Soweit so schön.
Wenn aber jemand des Weges kommt und meint der Gebäudegrundris gefällt mir nicht, ihn löscht und neu erstellt, dann gibt es eine neue ID. Schade um die Arbeit.
Das gleiche trifft auf zusätzliche Geometrien zu. Wenn in der OSM Datenbank wirklich nur der Grudriss ist, dann zerstört schon eine Verschiebung oder anderweitige Veränderung daran zu einem völligen zerstören des 3D Objektes.
Das ist ungefair genauso, wie wenn du straßen/Punkte in Bereichen löschst die nicht vollständig runtergeladen sind. Du siehst nicht ob weitere Objekte davon abhängig sind. Relationen und Überrelationen sind genau solche Probleme und die sind schon in der selben Datenbank. Es ist also alles eine Frage des Editors dich davor zu bewahren/warnen.

Offline

Board footer

Powered by FluxBB