defektes Multipolygon- See als residential

Nop · 2011-02-05T17:32:52.000Z

So, die Karte ist grade noch etwas langsam, weil sie beim Rendern einiges nachzuholen hat, aber sie sieht wieder deutlich bewohnter aus.

bye
Nop

hurdygurdyman · 2011-02-05T17:38:34.000Z

Nop:

…
ROTFL!!!

Zuerst dachte ich ja, jrahe redet von der RWK. Die Reparatur der MP-Seen war erfolgreich, sind alle wieder zu sehen. Sie sind sogar besonders gut erkennbar, weil jetzt so ziemlich alles andere auf der Karte fehlt. Die ist momentan völlig im Eimer - ich bin dran…

Aber daß gleichzeitig zwei unabhängige Karten bei der Darstellung desselben Problemfeatures ihre normalen Features verlieren, daß ist schon ein irrsinniger Zufall.

bye
Nop

Hi Nop,
War länger nicht hier. Hatte mich gerade gefreut, weil alle Problem-Seen (incl. meiner Test-Tümpel) voll waren. Drücke dir die Daumen, dass du das wieder hinbekommst.
Hoffentlich fängt jetzt keiner an, sämtliche geschlossenen natural=water-ways in MP zu verwandeln

kellerma · 2011-02-05T17:50:56.000Z

…

hurdygurdyman · 2011-02-06T16:58:15.000Z

hurdygurdyman:

…
Warum allerdings die Mainau überschwemmt ist, muss ich mal checken
…

Die Mainau ist immer noch überschwemmt.
http://www.wanderreitkarte.de/index.php?lon=9.1944&lat=47.7031&zoom=15
Der Inselumriss ist inner-way des Überlinger-See-MP und outer-way des Mainau-MP. Der Way selbst hat keine Flächen-Tags mehr.
Wenn sich die WuR aufbaut, sieht man kurz eine grüne Fläcghe, die dann aber vom blauen Wasser überschwemmt wird.

Wenn ich mir die inner-ways des MP Mainau ansehe, denke ich, dass dort ein MP gar nicht erforderlich ist. Die landuse=basin sind m.E. falsch getaggt, da es sich um Springbrunnen handelt. Der Streichelzoo als inner macht für mich keinen Sinn und die eine landuse=water als inner könnte( , wie ich jetzt gelernt habe) als outer des Überlinger Sees getaggt werden (, wobei ich mir nicht sicher bin ob es diese Fläche dort wirklich gibt).

kellerma · 2011-02-07T05:34:16.000Z

Hi Michael,

#7212641 Montag, 07. Februar 2011, 05:30 Uhr Mainau simplified according to hurdygurdyman

Ciao,
Frank

hurdygurdyman · 2011-02-07T06:48:09.000Z

kellerma:

Hi Michael,

#7212641 Montag, 07. Februar 2011, 05:30 Uhr Mainau simplified according to hurdygurdyman

Ciao,
Frank

Danke Frank!
Nach meiner Lernphase der letzten Tage hätte ich es genauso gemacht.
… (aber nicht getraut )

hurdygurdyman · 2011-02-08T08:13:53.000Z

Gute Nachricht !!
Nop war erfolgreich. Alle kleinen und großen Seen und Tümpel sind wieder voll Wasser (soweit ich das überblicke)

Und die Mainau ist aus ihrem Atlantis-Dasein errettet, wobei wohl die Vereinfachung durch Frank (kellerma) eine wesentliche Rolle spielt.

Bliebe jetzt nur noch, transparent zu machen, welche Ursachen zum Verschwinden von MP’s oder deren Teilen führen können und wie man diese vermeidet bzw. was bei komplexen MP zu tun ist, damit diese durch Renderer dargestellt werden.

edit:
Wer kann mal checken, ob navit und mapfactor die MP-Darstellung auch beherrschen?

aighes · 2011-02-08T08:22:07.000Z

Einfach an das halten, was im wiki dokumentiert ist und bei der Größe eines Multipolygons den gesunden Menschenverstand nicht abschalten.

hurdygurdyman · 2011-02-08T08:26:08.000Z

aighes:

Einfach an das halten, was im wiki dokumentiert ist und bei der Größe eines Multipolygons den gesunden Menschenverstand nicht abschalten.

… was aber z.B. das unbeabsichtigte “zerhacken” eines MP mit Editoren, welche davor nicht warnen, als eine Fehlerquelle noch nicht ausschließt.

Nop · 2011-02-08T09:35:41.000Z

hurdygurdyman:

Wer kann mal checken, ob navit und mapfactor die MP-Darstellung auch beherrschen?

Habe das letzen Monat mit den Entwicklern diskutiert, navit enthält keine Unterstützung für MPs.

bye
Nop

hurdygurdyman · 2011-02-08T11:14:58.000Z

Nop:

…
Habe das letzen Monat mit den Entwicklern diskutiert, navit enthält keine Unterstützung für MPs.
…

Mit dieser Zielsetzung:
Navit is a car navigation system with routing engine.
geht es navit primär um’s routing für Autos, wobei topografische Details eher zweitrangig sind. Machen andere reine Auto-navis genauso. Da interessieren doch nur ways. Der gestresste Autofahrer hat doch sowieso nur den Asphalt im Fokus und darf durch landschaftliche Vielfalt nicht abgelenkt werden

aighes · 2011-02-08T11:16:02.000Z

hurdygurdyman:

aighes:

Einfach an das halten, was im wiki dokumentiert ist und bei der Größe eines Multipolygons den gesunden Menschenverstand nicht abschalten.

… was aber z.B. das unbeabsichtigte “zerhacken” eines MP mit Editoren, welche davor nicht warnen, als eine Fehlerquelle noch nicht ausschließt.

Sowas kann man nie ausschließen.

Es bringt aber wenig, wenn man sich jetzt eine Möglichkeit ableitet, wie man das Eintragen kann. Dann schreien andere rum… Es wurde ein “Standard” gefunden, wie man mit solchen Objekten umgehen kann. Die Mapper wissen, wie sie es eintragen können udn die Renderer können schauen, welche Daten sie erwarten müssen.

Wenn der Standard deiner Meinung nach Mist ist, sollte man die Diskussion darüber nicht unbedingt hier führen, sondern auf der taging-Liste.

Nop · 2011-02-08T12:21:21.000Z

hurdygurdyman:

Mit dieser Zielsetzung:
Navit is a car navigation system with routing engine.
geht es navit primär um’s routing für Autos, wobei topografische Details eher zweitrangig sind. Machen andere reine Auto-navis genauso. Da interessieren doch nur ways. Der gestresste Autofahrer hat doch sowieso nur den Asphalt im Fokus und darf durch landschaftliche Vielfalt nicht abgelenkt werden

Naja, für mich sind Wälder auch nützliche Orientierungshinweise beim Autofahren. Wenn ich auf der Karte sehe: Kurz vor dem Waldrand abbiegen, kann ich das in real viel besser nachvollziehen als eine abstrakte Angabe “in 435m”.

Auf meinen Karten lasse ich Felder sowieso grundsätzlich weg, da das IMHO eine völlig nutzlose und schnell veraltende Info ist, die lediglich dafür sorgt, daß im allgemeinen Bunt die Straßen nicht mehr erkennbar sind. Mapnik ist da ein besonders trauriges Beispiel eines Agrarkatalogs, in dem man eigentlich nur noch die Autobahnen auf Anhieb findet.

Aber die Implementierung von MPs ist nicht trivial. Das Navit Maptool hat keine PostGIS-Datenbank zur Verfügung, die das mal eben übernimmt, und die Renderer sind keine Mapnikserver sondern müssen auf allen möglichen Mobiles laufen. Da ist das eine etwas größere Aufgabe. Ebenso wie für das Dutzend oder so ähnlicher Applikationen.

Leider denken die Leute, die sich immer kompliziertere Konstrukte in der OSM DB ausdenken, anscheinend nicht daran, daß sie die Nutzbarkeit der Daten immer weiter herabsetzen.

bye
Nop

hurdygurdyman · 2011-02-08T12:24:18.000Z

aighes:

Sowas kann man nie ausschließen.

Sicher nicht, aber man kann nach Wegen suchen, derartige Fehler zu minimieren.

Es bringt aber wenig, wenn man sich jetzt eine Möglichkeit ableitet, wie man das Eintragen kann. Dann schreien andere rum… Es wurde ein “Standard” gefunden, wie man mit solchen Objekten umgehen kann. Die Mapper wissen, wie sie es eintragen können udn die Renderer können schauen, welche Daten sie erwarten müssen.

Ich bezweifele, dass alle Mapper wissen, was sie eintragen können, und bewundere die Programmierer der Renderer, welche es trotz der babylonischen Vielfalt an Varianten trotzdem oft schaffen, das meiste optisch umzusetzen.

Wenn der Standard deiner Meinung nach Mist ist, sollte man die Diskussion darüber nicht unbedingt hier führen, sondern auf der taging-Liste.

Keine Ahnung, woher du ableitest, dass ich den Standard als Mist bezeichne. Ich versuche nur, mit dem Forum Wege aus sicht der Mapper zu finden, die das Arbeiten mit Multipolygonen für alle einfacher und fehlerresistenter machen.

Mist definiere ich übrigens so:
Vordergründig abstoßendes Abfallprodukt eines Verdauungsprozesses, das bei sinnvoller Verwendung durchaus wachstumsfördernd ist

Ich gehe davon aus, dass du mit taging-Liste das talk-de meinst.
Meine Intention, bei OSM mitzumachen, war, dass ich als ursprünglich experimenteller Nutzer von Garmin-Maps aus OSM-Daten dem Projekt etwas zurückgeben wollte, indem ich mit meinen Möglichkeiten zur Datenmenge und Datenqualität beitrage. Das ist auch heute noch so. Der Prozess, wie aus dem Daten-Input ein Daten-Output wird, übersteigt meine technischen Kenntnisse und zeitlichen Möglichkeiten. Dies hindert mich aber nicht daran, Kritik und Anregungen aus Anwendersicht im Interesse des Projektes als Ganzes zu äußern. talk-de ist mir einfach zu sperrig und unübersichlich.

Die Multipolygone sind nur ein Beispiel dafür, wie schwer es für den Otto-Normal-Mapper ist, bestimmte erforderliche Arbeitschritte anhand der Wiki u.a. valide bei Mapping zu beachten.

hurdygurdyman · 2011-02-08T14:31:51.000Z

Nop:

Naja, für mich sind Wälder auch nützliche Orientierungshinweise beim Autofahren. Wenn ich auf der Karte sehe: Kurz vor dem Waldrand abbiegen, kann ich das in real viel besser nachvollziehen als eine abstrakte Angabe “in 435m”.

Auf meinen Karten lasse ich Felder sowieso grundsätzlich weg, da das IMHO eine völlig nutzlose und schnell veraltende Info ist, die lediglich dafür sorgt, daß im allgemeinen Bunt die Straßen nicht mehr erkennbar sind. Mapnik ist da ein besonders trauriges Beispiel eines Agrarkatalogs, in dem man eigentlich nur noch die Autobahnen auf Anhieb findet.
…
Leider denken die Leute, die sich immer kompliziertere Konstrukte in der OSM DB ausdenken, anscheinend nicht daran, daß sie die Nutzbarkeit der Daten immer weiter herabsetzen.

Sehe ich auch so, dass neben den Straßen gewisse geografische Informationen die Orientierung erleichtern. Aber für die Aufgabe eines Navis, welches jemandem, der des Kartenlesens unkundig ist, vorbetet, wo’s langgeht, ist das primär nicht notwendig.

Es ist die Kunst des Kartografen, die zweckorientiert beste Darstellung zu wählen, hierzu gehört auch wesentlich die Kunst des Weglassens. Allerdings halte ich Seen, die relativ unverändert bleiben, für ein wichtiges darzustellendes Element nicht nur wegen möglicher Fährverbindungen.

Ein im Vergleich zur guten Reit- und Wanderkarte auch interessanter Ansatz zur topografischen Orientierung sind m.E. auch diese Karten, die ich alternativ zur RuWK installiert habe, weil sie meinen südwestdeutschen Bereich gut abdecken:
http://www.kowoma.de/gps/freieKarten/osmkowomafreizeitkarte.html
Die ist sogar Fußgängerroutingfähig (manchmall allerdings mit komischen Zick-zack-Linien) und zeigt in der Dezember-Version den Bodensee

Zum Thema komplizierte Konstrukte und Nutzbarkeit spare ich mir Wiederholungen…

aighes · 2011-02-08T16:16:21.000Z

Ich hatte dich zumindest bisher so verstanden, als das du das Schema an sich für falsch hälst und nicht nur die “Umsetzung” in den Editoren. Wenn ich dich falsch verstanden hab, hat sich der Rest ja im Prinzip erledigt.

Mit der tagging-Liste meinte ich: http://lists.openstreetmap.org/pipermail/tagging/, talk-de ist auch nicht “besser” als das Forum. Wenn sollte man darüber international diskutieren, wenn man das Schema an sich ändern möchte.

Nop · 2011-02-08T17:04:41.000Z

aighes:

Ich hatte dich zumindest bisher so verstanden, als das du das Schema an sich für falsch hälst und nicht nur die “Umsetzung” in den Editoren. Wenn ich dich falsch verstanden hab, hat sich der Rest ja im Prinzip erledigt.

Dann sag’s ich jetzt halt: Ich halte es für Grundfalsch, für dieselbe Sache mal ein Polygon mit Tags, mal mehrere Polygone mit Tags und eine Sammelrelation und mal eine Relation die wie ein Polygon interpretiert wird und Polygone ohne Tags zu verwenden.

Es wäre sinnvoller (und nicht allzu schwer) Objekte zu definieren, die alle drei Fälle auf verständliche Art ohne Wechsel der Perspektive darstellen können. Beispiel hab’ ich unter “maximale Größe eines MP” schon gepostet.

bye
Nop

Fabi2 · 2011-02-08T17:35:15.000Z

Nop:

Leider denken die Leute, die sich immer kompliziertere Konstrukte in der OSM DB ausdenken, anscheinend nicht daran, daß sie die Nutzbarkeit der Daten immer weiter herabsetzen.

Soweit ich weis, ist das Ziel ist nicht mehr die Produktion einer Datenbank zur Darstellung einer langweiligen, nur aus 5 Linientypen und sonst nur leeren Flächen bestehenden Autokarte, sondern die möglichst gute und realitätsnahe Abbildung der Realität auf die Datenbank. Da braucht man nun mal auch komplexere Strukturen, das bei deren Einsatz der Benutzer möglichst gut unterstützt werden sollte, ist natürlich auch klar.

de_muur · 2011-02-08T20:50:20.000Z

Fabi2:

sondern die möglichst gute und realitätsnahe Abbildung der Realität auf die Datenbank. Da braucht man nun mal auch komplexere Strukturen, das bei deren Einsatz der Benutzer möglichst gut unterstützt werden sollte, ist natürlich auch klar.

Nein, man braucht keine sonderlich komplexe Struklturen. Davon hat keiner was. Je einfacher die Strukturen gehalten werden, um so leichter kommen damit die Mapper zurecht und umso leichter ist dann auch die automatische Auswertung. Alles, was uebermaessig kompliziert eingetragen wird, ist reines Ausleben des Spieltriebs von Geeks, die sich am Ende darueber freuen, wenn ihre Eintragungen trotz ihrer Komplexitaet noch von der einen oder anderen Anwendung als korrekt erkannt wird.

hurdygurdyman:

was aber z.B. das unbeabsichtigte “zerhacken” eines MP mit Editoren, welche davor nicht warnen, als eine Fehlerquelle noch nicht ausschließt.

Da denken wir doch mal kurz drueber nach und stellen erstaunt fest, dass die gewuenschte Alternative rein logisch unmoeglich ist:
Da man einem Mapper nicht vorschreiben kann, welchen Editor er nutzt, kann man auch nicht sicherstellen, dass er bei bestimmten Aenderungen gewarnt wird.
Im Prinzip kann man seine Aenderungen ja auch in einem ASCII-Editor, und die API kann ja nur ueberpruefen, ob die hochgeladene Aenderung syntaktisch korrekt ist, aber nicht ob der Mapper wusste, was er da tat.

Gruss
Torsten

Fabi2 · 2011-02-08T22:57:41.000Z

de_muur:

Fabi2:

sondern die möglichst gute und realitätsnahe Abbildung der Realität auf die Datenbank. Da braucht man nun mal auch komplexere Strukturen, das bei deren Einsatz der Benutzer möglichst gut unterstützt werden sollte, ist natürlich auch klar.

Nein, man braucht keine sonderlich komplexe Struklturen. Davon hat keiner was. Je einfacher die Strukturen gehalten werden, um so leichter kommen damit die Mapper zurecht und umso leichter ist dann auch die automatische Auswertung. Alles, was uebermaessig kompliziert eingetragen wird, ist reines Ausleben des Spieltriebs von Geeks, die sich am Ende darueber freuen, wenn ihre Eintragungen trotz ihrer Komplexitaet noch von der einen oder anderen Anwendung als korrekt erkannt wird.

Nein, das ist kein Spieltrieb, weil zum Teil gibt es Situationen wo man mit komplexeren Strukturen, z.B. Relationen weiter kommt, als mit einfachen Objekten/Tags, wo sich man entweder entscheiden muß, weil die Tags kollidieren, oder man sich notgedrungen Konstruktionen wie z.B. highway=service + service:kerb:left:height=0.10 ausdenken muß, was bei highway=residential dann residential:kerb:left:height=0.03 ist. Jemand anderes hat vielleicht nur kerb=lowered an den Weg getaggt, weil er das einfacher fand. Wirklich zielführend sind beide Varianten nicht, weil bei der einfachen kerb=lowered fehlen Informationen, und die andere kann man bei ausreichender Tagwertevielfalt nicht mehr pratikabel verarbeiten, was aber ja das ist, was du gerne machen möchtest. Weil den Rollirouter interessieren die linken Bürgersteifhöhen bestimmt ganz brennend. Die einzige halbwegs saubere Lösung ist dann hier z.B. der gefürchtete straßenbeleitende Fuß-/Radweg (, ja, die noch bessere Variante alles als Fläche zu taggen ist aus Aufwands- und GPS-Präzisionsgründen unpraktikabel).

Zusätzlich benutzt dann wie im Moment der Nächste service=, um wie ja der Name klar sagt, die Art der Dienstleistung anzugeben, weil was hat denn service= für sich allein genommen, mit Straßen zu tun? Ja, genau nichts! Die Verbindungen zwischen den Keys, stellt also nur der Mensch her. In OSM sollte also aus diesem Grund der Keyname für sich alleine alles Notwendige eindeutig genug aussagen, aber an der Nichtbeachtung dieser Tatsache kranken im Moment diverse Taggingvorschläge und etablierte Tags. Das gibt dann also langfristig eine lustige Tagsuppe aus verschiedenen Interpretertionen implizierter Bedeutung ausgehend von anderen Nachbartags.

Gut, wir haben ja die “eindeutigen” Tagkategorien, wie z.B. highway=* (Ah, das sind also alles Straßen, bis auf z.B. highway=traffic_lights, das ist amenity=, ach nee, das ist besser power=, weil ich ja elektrisch…) oder emergency=* (siehe z.B. die AED-Diskussion…). War schon lustig, wo sich auf der Mailingliste damals die Bude wegen der Liste falsch geschriebener Straßennamen gemeldet hat, die erst mal alle name=-Tags von highway= als Straßennamen extrahiert hatten und so 70000 Fehler gefunden hatten, am Ende waren es dann noch etwas über 1000 potentieller (nur automatische Syntaxprüfung) Fehler.

Prizipiell macht ein konkreter Tag ja nur eine 1:1-Zuordnung oder 1:n für einen Key, aber das hilft eben nicht, wenn man eigentlich 1:n für einen speziellen Key haben möchte, wo man sich ja im Moment oft mit Sachen wie cuisine=chinese;kebab;pizza;fish behilft. Der Nächste taggt das gleiche als cuisine=chinese;kebab;fish;pizza und der Übernächste als cuisine=pizza;fish;chinese;kebab. Viel Spaß bei der großflächigen Auswertung! Insbesondere auch, wenn z.B. bei spezialisierten Kliniken schon mal so 10 Werte für healthcare:speciality=* geben kann. (Naja, die Compuetrindustrie muß ja auch von was leben…)

So das reicht fürs erste erst mal, gibt natürlich auch noch eine genauer Erläuterung zum Kategorieproblem, aber das kommt ein andermal.