Angrenzende Landuses Abbilden

TheFive · 2013-09-16 06:55:45

peb12345 wrote:

Aber ich hab' gerade keine Zeit weiter aktiv gegen MP zu arbeiten:-)

Ich glaube es gibt auch kein "gegen oder für MP" arbeiten. Wenn wir offensichtlich der Meinung sind, das wir die nächste Komplexitätsstufe erreicht haben, müssen wir die Basis erweitern.
Mit den vorhandenen Mitteln können wir sicher noch einige Zeit erfolgreich weitermachen. Insbesondere wenn wir uns "zusammennehmen" und wartbare Dinge bauen, also gerade im MP Umfeld uns "Zurücknehmen".

Was meine ich mit Basis erweitern (andere haben da bestimmt bessere Ideen als ich)

Flächenobjekte (ist glaube ich schon Thema)
Mengenreduktion durch Filter in den Editoren (oder noch besser ein selektiveres API, auf dem iPhone mit Go Map wären weniger Daten manchmal gut)
Verbesserte Editoren (Frage sind die MPs nicht wartbar, weil sie MPs sind, oder weil die Editoren nur die Basissachen bei MPs unterstützen ).

Ich fände gerade die API Diskussionen interessant, wo wir das eigentlich diskutiert ?

Christoph

wambacher · 2013-09-16 08:38:09

TheFive wrote:

Ich fände gerade die API Diskussionen interessant, wo wir das eigentlich diskutiert ?

Steht hier - aber unter Diskutieren verstehe ich was anderes. Ist verd. wenig los hier, fast schon tote Hose.

Gruss
walter

EvanE · 2013-09-16 14:04:21

wambacher wrote:

TheFive wrote:
Ich fände gerade die API Diskussionen interessant, wo wir das eigentlich diskutiert ?
Steht hier - aber unter Diskutieren verstehe ich was anderes. Ist verd. wenig los hier, fast schon tote Hose.

Hallo Walter

Nun ja, scheint alles nicht so dringend zu sein.

Eine API-Umstellung ist eine ziemlich große Sache, da ja alle Programme, die auf die API zugreifen, angepasst werden müssen. Dies gilt umso mehr, als die Einführung eines neuen Datentyps für Flächen (das Einzige, was mir dringend / wichtig erscheint) einen harten Schnitt darstellt. Damit geht dann nur alte oder neue Version. Wenn man jetzt noch bedenkt, wie lange der Umstieg auf 64-Bit IDs in den diversen Programmen gedauert hat (was ja vorab ohne Probleme ging), macht man das nur, wenn man es für unvermeintlich hält.

PS-1:
Ich hatte selber damit gerechnet, dass API 0.7 bald nach Abschluss der Lizenz-Umstellung (also in diesem Jahr) angegangen würde. Dem ist offensichtlich nicht so.
PS-2:
Es ist ja - trotz dringendem Wunsch - durchaus noch nicht klar, wie ein Flächendatentyp zu realisieren wäre.

Edbert (EvanE)

wambacher · 2013-09-16 14:14:50

EvanE wrote:

Es ist ja - trotz dringendem Wunsch - durchaus noch nicht klar, wie ein Flächendatentyp zu realisieren wäre.

genau, das ist auch für mich das Allerwichtigste - und auch das Schwierigste.

Gruss
walter

kartler175 · 2013-09-20 15:30:31

* Fehlposting

Last edited by kartler175 (2013-09-20 15:31:23)

TheFive · 2013-09-29 10:26:18

wambacher wrote:

TheFive wrote:
Ich fände gerade die API Diskussionen interessant, wo wir das eigentlich diskutiert ?
Steht hier - aber unter Diskutieren verstehe ich was anderes. Ist verd. wenig los hier, fast schon tote Hose.
Gruss
walter

Im Wiki findet zum Thema Aereas hier noch was statt:
http://wiki.openstreetmap.org/wiki/The_Future_of_Areas

Jochen hat auf seinem SOTM Vortrag, die (grossen Dank an Peda) auch geschnitten vorliegen,
http://osm.won2.de/sotm/d3t1-1610-Joche … or_OSM.mp4
Werbung dafür gemacht.
Der Vortrag ist eine gute Zusammenfassung des Ist mit Aufforderung das Soll noch zu definieren.

morjak · 2013-09-29 10:58:32

TheFive wrote:

Im Wiki findet zum Thema Aereas hier noch was statt:
http://wiki.openstreetmap.org/wiki/The_Future_of_Areas

Ich finde diese ganzen Diskussionen um Areas ehrlich gesagt etwas albern. Alle beschriebenen Ansätze laufen letztendlich mehr oder weniger auf das Multipolygon hinaus, was ja damit eigentlich abgeschafft werden sollte.
Wenn man Flächen nur noch als Multipolygone zulassen würde, wären alle im link erwähnten Probleme schlagartig behoben. Natürlich außer denen, die von Leuten verursacht werden, die nicht begreifen (wollen), dass ein Vieleck von mehreren Kanten begrenzt wird.

Tordanik · 2013-09-29 11:40:53

morjak wrote:

Ich finde diese ganzen Diskussionen um Areas ehrlich gesagt etwas albern. Alle beschriebenen Ansätze laufen letztendlich mehr oder weniger auf das Multipolygon hinaus, was ja damit eigentlich abgeschafft werden sollte.
Wenn man Flächen nur noch als Multipolygone zulassen würde, wären alle im link erwähnten Probleme schlagartig behoben.

Das einzige Problem, das durch einen Multipolygon-Zwang behoben würde, wäre die Unklarheit, ob ein bestimmtes Tag einen Way zur Fläche macht. Aber davon abgesehen ist die Einführung eines eigenen Area-Datentyps vor allem deshalb interessant, weil damit API-Support für die Verhinderung ungültiger, z.B. selbst-überschneidender Flächen sowie die Möglichkeit zum teilweisen Download von Flächen (aber trotzdem noch mit der Information, wo innen ist) realisiert werden können. Auch eine bessere Konfliktbehandlung wäre wünschenswert. Das alles leisten Multipolygone, so wie sie derzeit umgesetzt sind, nicht. Und das sind auch die eigentlichen technischen Herausforderungen bei der Sache.

Oli-Wan · 2013-09-29 12:15:23

Tordanik wrote:

Aber davon abgesehen ist die Einführung eines eigenen Area-Datentyps vor allem deshalb interessant, weil damit API-Support für die Verhinderung ungültiger, z.B. selbst-überschneidender Flächen [...] realisiert werden [kann].

Glaubst Du dran? Die API erlaubt seit Jahren Wege aus nur einem Knoten, Wege mit mehrfachen identischen Knoten, leere Tagschlüssel und -werte, selbstreferenzierende Relationen, ... also Konstrukte, die noch viel einfacher zu erkennen und zu verhindern wären. (Allerdings würden mehrere Editoren ganz oder teilweise ausfallen, wenn solche Objekte von der API abgelehnt würden.)

streckenkundler · 2013-09-29 12:20:31

Ich finde den Vortrag von Jochen Topf gut, und stellt die Grundlagen einleuchtend dar: einerseits Polygone ohne innere Flächen, dann Polygone mit Löchern (See im Wald - Problem) und dann Multipolygon als Relation. Hier muß man ganz klar unterscheiden zwischen solchen, die ein einzelnes Objekt definieren: Fläche, Linie, Punkt und solche die eine Sammlung von Objekten repräsentieren: Multipolygone, Grenzen, ect.

Tordanik wrote:

Aber davon abgesehen ist die Einführung eines eigenen Area-Datentyps vor allem deshalb interessant, weil damit API-Support für die Verhinderung ungültiger, z.B. selbst-überschneidender Flächen sowie die Möglichkeit zum teilweisen Download von Flächen (aber trotzdem noch mit der Information, wo innen ist) realisiert werden können. Auch eine bessere Konfliktbehandlung wäre wünschenswert. Das alles leisten Multipolygone, so wie sie derzeit umgesetzt sind, nicht. Und das sind auch die eigentlichen technischen Herausforderungen bei der Sache.

Richtig. Mit wenigen Tools (z.B. Clip) ließen sich diverse Geometriefehler (Invalid Geometry) vermeiden. Ich wundere mich ohnehin, daß es Clip bei JOSM nicht gibt.
Das wäre z.B. die richtige Aufgabe um diesen Fehler zu vermeiden: Eine Inner-Fläche grenzt an mindestens zwei Punkten an die Außengrenze. Das kleine MP mit Grünland und Wasser muß aus dem Großen Waldpolygon ausgeschnitten werden. So, wie es jetzt ist, ist es eine fehlerhafte Geometrie, Die wäre es sowohl beim echten Polygon als auch bei einer Multipolygon-Relation. PS: Der Fehler ist schon beseitigt, OSMI ist nur noch nicht alktualisiert.

auf Datentyp Fläche hoffend,

Sven

Tordanik · 2013-09-29 17:35:31

Oli-Wan wrote:

Tordanik wrote:
Aber davon abgesehen ist die Einführung eines eigenen Area-Datentyps vor allem deshalb interessant, weil damit API-Support für die Verhinderung ungültiger, z.B. selbst-überschneidender Flächen [...] realisiert werden [kann].
Glaubst Du dran? Die API erlaubt seit Jahren Wege aus nur einem Knoten, Wege mit mehrfachen identischen Knoten, leere Tagschlüssel und -werte, selbstreferenzierende Relationen, ... also Konstrukte, die noch viel einfacher zu erkennen und zu verhindern wären. (Allerdings würden mehrere Editoren ganz oder teilweise ausfallen, wenn solche Objekte von der API abgelehnt würden.)

Die Möglichkeit zur Validierung ist zumindest ein Faktor, der in den Diskussionen über einen Area-Datentyp eine große Rolle spielt. Du hast aber recht, dass das momentane Fehlen jeglicher brauchbarer Prüfungen nicht optimistisch stimmt, dass dieses Potential auch wirklich genutzt wird. Ich würde es mir allerdings sehr wünschen - genau wie auch die anderen genannten Prüfungen.

Announcement

#51 2013-09-16 06:55:45

Re: Angrenzende Landuses Abbilden

#52 2013-09-16 08:38:09

Re: Angrenzende Landuses Abbilden

#53 2013-09-16 14:04:21

Re: Angrenzende Landuses Abbilden

#54 2013-09-16 14:14:50

Re: Angrenzende Landuses Abbilden

#55 2013-09-20 15:30:31

Re: Angrenzende Landuses Abbilden

#56 2013-09-29 10:26:18

Re: Angrenzende Landuses Abbilden

#57 2013-09-29 10:58:32

Re: Angrenzende Landuses Abbilden

#58 2013-09-29 11:40:53

Re: Angrenzende Landuses Abbilden

#59 2013-09-29 12:15:23

Re: Angrenzende Landuses Abbilden

#60 2013-09-29 12:20:31

Re: Angrenzende Landuses Abbilden

#61 2013-09-29 17:35:31

Re: Angrenzende Landuses Abbilden

Board footer