Verbesserungsvorschläge für ID Editor

FvGordon · 2016-12-25T20:40:19.000Z

streckenkundler:

Ich muß mir das nochmal genau anschauen. Wenn ich aber diesen “verseuchten” Node ein klein wenig verschiebe, und dann ein Hochladeversuch starte, sollte zu mindestens für den betreffenden Punkt der Validator in Josm anspringen… tut er aber nicht… könnte eventuell bei Josm eine Fehlerroutine fehlen?

Wenn Du einen der beiden Knoten leicht verschiebst, liegt er nicht mehr über dem anderen - und somit liegt hier kein Fehler vom Typ “Doppelter Knoten” mehr vor. Durch das Verschieben eines Knotens bekommt der Weg / die Linie hier einen Knick oder eine Z-Form in eine Richtung, die er in Wirklichkeit nicht hat. Daher lieber, wie in #61 beschrieben verfahren.

Franz

streckenkundler · 2016-12-26T10:53:33.000Z

pyram:

Bei den Prüfergebnissen den/die Fehlerpunkte auswählen und auf “Reparieren” klicken.
Hochladen und fertig.

Danke. Ich hatte das “reparieren” bisher immer ignoriert… Muß da doch noch weiter rumspielen…

Sven

Automat7 · 2017-01-01T22:19:52.000Z

Hey das mit dem Strecken verbinden klappt!!! Man muss die Umschalttaste gedrückt halten und dann kann man ein weiteres Wegstück auswählen und dann auf Verbinden klicken. SUPER!! So wies aussieht hat sich der Editor etwas verändert, ich könnte mich aber täuschen und ich habe es anfangs einfach übersehen.

Jetzt habe ich schon ein bisschen mit dem Editor gearbeitet und ich muss sagen, der ist gut und brauchbar. Es macht Spaß damit zu mappen. Und man kann damit auch gute Qualität abliefern. Qualität ist wichtig! So viel Information wie nötig, ein zuviel würde ja die mobilen GPS Geräte verlangsamen bzw. den Speicher verbrauchen. Außerdem würde es unübersichtlich werden.

kreuzschnabel · 2017-01-01T23:13:17.000Z

Automat7:

So viel Information wie nötig, ein zuviel würde ja die mobilen GPS Geräte verlangsamen bzw. den Speicher verbrauchen. Außerdem würde es unübersichtlich werden.

Von dieser Denke solltest du dich mittelfristig lösen. Keine Karte setzt alle in der Datenbank vorliegenden Informationen um, sondern sucht sich aus, was sie braucht. Dazu kann sie auch beispielsweise Wegkurven vereinfachen, um Nodes zu sparen. Um Übersichtlichkeit müssen wir uns beim Zusammenstellen der Datenbank nicht kümmern, das macht die Kartenanwendung, wenn sie sich daraus bedient.

Da aber jede Anwendung andere Schwerpunkte setzt, soll jede selbst entscheiden können, was sie nimmt und was nicht. Von daher gibt es beim Erstellen der Datenbank (fast) kein „Zuviel“. Wo würdest du beispielsweise die Grenze ziehen?

Beispiel: Ein Autofahrer mag surface=* an highway=track überflüssig finden, aber für einen Inline-Skater kann es ein großer Unterschied sein, ob der Weg asphaltiert oder pflastergesteint ist, der hätte diese Angabe gern. Deshalb sollte sie in die Datenbank, und eine autoorientierte Anwendung nutzt sie halt nicht.

–ks

Automat7 · 2017-01-02T13:49:22.000Z

Hi ks, einsparen würde ich die Punkte/Vektoren zu viel bei Linien und Flächen, weil dies das ganze Material unnötig aufbläht. Das kostet Serverpower und Benutzerzeit.

Zuerst muss man ja wissen wozu die Karte überhaupt gebraucht wird.
Mir bekannt sind Orientierung, Landschaftserkundung, LKW-Auto-Fahrrad-Wanderrouting, GPS Navigations und Handgeräte. Und evtl. zum Ausdrucken für Wanderkarten, Wegbeschreibungen, und natürlich das Aktualisieren durch den Mapper.
Die Geometrie ist da zweitrangig, ob die Linien jetzt absolut passgenau sind oder nicht spielt meistens keine Rolle, nur beim Autobahnrouting könnte das evtl. sehr wichtig sein. Dann würde ich auch nur markante Punkte mit in die Karte aufnehmen, zur Orientierung in weitem Gelände. Nicht jedes einzelne Häuschen und Schuppen. Eigentlich reicht es nur ein Wohngebiet einzuzeichnen und dann noch die wichtigsten Gebäude die für die Allgemeinheit von Interesse sind. Das würde nicht nur das Datenmaterial effizient halten, sondern auch dem Mapperneuling das Leben vereinfachen, der evtl. durch den Wust an Linien und Flächen die Übersicht verliert, vor allem in der Großstadt.
Super finde ich auch die POI Datenbank, da hat man in einer fremden Stadt gleich seine Anlaufstellen herausgefunden. Die Wegattribute würde ich auch auf jeden Fall beibehalten, das sind nicht viele Bytes die dabei draufgehen. Gerade weil das Kartenmaterial für viele unterschiedliche Aktivitäten gebraucht wird halte ich das für besonders wichtig. Die Steigung, die Breite, die Oberfläche, Geschwindigkeit, vielleicht sogar wie übersichtlich die Straße ist, z.B. fürs Auto oder Rennradfahren, evtl. wie attraktiv der Weg fürs Wandern ist.

Vielleicht gibt es ja mal ein OSM Navigationsgerät, dass anhand der Daten automatisierte Routen heraussucht, man gibt den Ort ein, und die Aktivität, wie viel Strecke man zurücklegen will, wie viel Höhenmeter und ob man an Sehenswürdigkeiten interessiert ist und das Gerät spuckt eine automatisierte Route aus Das wäre was für den Urlaub oder Freizeit um die Planung zu vereinfachen und mehr Spontanität zu ermöglichen.

Wenn dann irgendwann mal OSM nicht mehr ausreicht, könnte man die Welt 3D mappen. Jeder Baum jedes Haus und jeder Grashalm. Man könnte sich virtuell wie im Computerspiel darin bewegen. Kommt bestimmt in 100 Jahren

MKnight · 2017-01-02T14:36:41.000Z

Automat7:

Hi ks, einsparen würde ich die Punkte/Vektoren zu viel bei Linien und Flächen, weil dies das ganze Material unnötig aufbläht. Das kostet Serverpower und Benutzerzeit.

Serverpower kostet es, wenn unsinnig die History aufgebläht wird.
Benutzerzeit kostet es in der History gelöschte Objekte zu finden.

Wenn Du 2 Wege zusammenfügst, passiert folgendes:

Du hast einen neuen Weg mit der History eines der beiden Wege + Deine Bearbeitung
Du hast einen alten Weg mit der History

Ergebnis: Datenbank+CPU belastet für nix. Oder ganz konkret: Statt gespart hast Du was dazugepackt.

Zuerst muss man ja wissen wozu die Karte überhaupt gebraucht wird.

Wir haben keine Karte, sondern eine Datenbank. Die Karte(n(!)) holen sich aus der DB das was sie gern darstellen möchten.

Dann würde ich auch nur markante Punkte mit in die Karte aufnehmen, zur Orientierung in weitem Gelände.

Ja, mach das wie Du denkst, Hauptsache Du löschst nichts von den Dingen, die andere(!) wichtig finden, und Hauptsache Du generalisierst nix von dem wo andere(!) der Meinung waren, dass die Details in die DB sollen.

kreuzschnabel · 2017-01-02T15:16:15.000Z

Automat7:

Zuerst muss man ja wissen wozu die Karte überhaupt gebraucht wird.

Zuerst definiere bitte, was du mit „die Karte“ meinst

1.: OSM ist keine Karte (trotz des Namens), OSM ist eine Datenbank mit Geodaten.
2.: Aus den Geodaten in dieser Datenbank lassen sich Karten erzeugen.
3.: Weil die Karten, die aus der Datenbank erzeugt werden sollen, unterschiedlichen Zwecken und Zielgruppen dienen, legen sie unterschiedliche Schwerpunkte. Einem Autoatlas ist egal, wo Wiese und wo Acker ist, einer Wanderkarte weniger.
4.: Weil wir allen Karten, die sich in unserer Datenbank bedienen, gerecht werden möchten, erfassen wir in Schritt 1 so viele Details wie möglich. Welche dieser Details für die jeweilige Anwendung nicht relevant sind und vereinfacht oder weggelassen werden können, entscheidet die jeweilige Anwendung in Schritt 2, was sie aus der Datenbank übernimmt und was nicht.

Um deiner Idee eines übersichtlichen Stadtplans gerecht zu werden, kann eine Stadtorientierungskarte alle Wohngebäude weglassen – warum nicht? Aber eine topographische Karte möchte alle Gebäude abbilden, deshalb wäre der TK schlecht gedient, wenn wir, deine Idee vorausnehmend, die Wohngebäude gar nicht erst einzeichnen würden. Es gibt immer auch andere Anwender mit anderen Präferenzen und anderen Bedürfnissen. Beispielsweise sind amenity=hunting_stand auf Wanderkarten wertvolle Festpunkte.

Daher nochmals meine Bitte: Trag möglichst viel in die Datenbank ein. Alles, was sich nicht kurzfristig verändert. Hochsitze, Wegweiser, Sitzbänke, Mülleimer, Schuppen, Funkmasten, Freileitungen. Dann sind die von dir erfassten Daten nicht nur für die eine Karte gut, die dir gerade vorschwebt, sondern für viele andere auch noch.

Dann würde ich auch nur markante Punkte mit in die Karte aufnehmen, zur Orientierung in weitem Gelände.

Gute Idee.

Nicht jedes einzelne Häuschen und Schuppen.

Schlechte Idee. Die Information „Der Trampelpfad zweigt gleich hinter dem Schuppen da ab und geht dann rechts an der nächsten Scheune vorbei“ ist in einer Wanderkarte sehr hilfreich. Geht aber nur, wenn nicht nur der Pfad selbst, sondern auch diese Gebäude in der DB sind.

Eigentlich reicht es nur ein Wohngebiet einzuzeichnen und dann noch die wichtigsten Gebäude die für die Allgemeinheit von Interesse sind. Das würde nicht nur das Datenmaterial effizient halten, sondern auch dem Mapperneuling das Leben vereinfachen, der evtl. durch den Wust an Linien und Flächen die Übersicht verliert, vor allem in der Großstadt.

D’accord – Innenstädte sind in OSM schon äußerst komplex. Ich glaube aber nicht, dass wir das ändern, indem wir Gebäude weglassen. Das braucht ein neues Strukturkonzept, das z.B. Admin-Grenzen, Schienen, Straßen und Landcover auf unterschiedlichen Ebenen abbildet, die sich unabhängig voneinander bearbeiten lassen, statt wie jetzt alles in eine Ebene zu packen.

Mit Verlaub – Bestrebungen, durch Vorselektion von Daten einzelne Bytes einzusparen, sind heute komplett sinnlos. Speicherplatz ist kein Thema mehr, auf Handgeräten schon gar nicht – eine (gute!) 64-GB-Karte fürs Schlaufon bekommst du unter 30 Euro und kannst da ein Planetfile von OSM draufpacken. (Vielleicht kein Planetfile, aber die kompletten OSM-Daten von Europa sind aktuell heute als pbf gerade mal 18.1 GB groß.) Wenn wir mal neue Speicher- oder Serverhardware brauchen, weil der Plattensatz aus den Nähten platzt, dann legen wir zusammen und fertig – aber wir fangen bestimmt nicht an, nur noch ganz grob zu mappen, um Daten zu sparen. Wir möchten eine detaillierte Geodatenbank aufbauen, keine Sparkarte.

Wohlgemerkt: Eine Sparkarte (für speicherschwache Handys oder dünne Internetanbindungen) kann daraus natürlich jederzeit erzeugt werden! Aber das ist Schritt 2. Es gibt halt immer auch Anwender, die mehr Details haben möchten und brauchen, daher sollten die nicht in Schritt 1 schon weggelassen werden.

Nur ein Beispiel: Wenn ich mit meinem Hund in einer fremden Kleinstadt spazierengehe, er dort einen Haufen macht und ich dann mit der gefüllten Tüte dastehe, bin ich sehr dankbar, per Osmand gezielt den nächsten öffentlichen Mülleimer ansteuern zu können. (Anhand dieses Beispiels mache ich sogar Werbung für OSM bei meinen Freunden.) Wenn aber ein Automat7 einfach mal beschlossen hat, dass wir keine Mülleimer in der Datenbank brauchen, um Speicherplatz zu sparen, dann geht mir dieser Nutzen von OSM verloren.

Wenn dann irgendwann mal OSM nicht mehr ausreicht, könnte man die Welt 3D mappen. Jeder Baum jedes Haus und jeder Grashalm. Man könnte sich virtuell wie im Computerspiel darin bewegen. Kommt bestimmt in 100 Jahren

Wirf mal einen ganz vorsichtigen Blick auf http://demo.f4map.com/#lat=50.1094369&lon=8.6745726&zoom=17. Ja, das sind OSM-Daten.

–ks

kreuzschnabel · 2017-01-02T15:36:33.000Z

Automat7:

Mir bekannt sind Orientierung, Landschaftserkundung, LKW-Auto-Fahrrad-Wanderrouting, GPS Navigations und Handgeräte. Und evtl. zum Ausdrucken für Wanderkarten, Wegbeschreibungen, und natürlich das Aktualisieren durch den Mapper.

Noch ein paar Beispiele für thematische Karten aus OSM-Daten.

–ks

Automat7 · 2017-01-02T18:45:56.000Z

Vielen Dank, das war sehr ausführlich! Die 3d Karte ist ja lustig, da bewegt sich sogar der Kran

MKnight · 2017-01-02T18:47:48.000Z

Automat7:

Vielen Dank, das war sehr ausführlich!

Du wirst also in Zukunft keine Wege mehr begradigen?

seichter · 2017-01-02T19:23:04.000Z

MKnight:

Automat7:

Vielen Dank, das war sehr ausführlich!

Du wirst also in Zukunft keine Wege mehr begradigen?

Darf er schon. Wenn auf einem schnurgeraden Weg jeden Meter ein node sitzt, darf man das schon begradigen/reduzieren. Nicht unbedingt wegen der Speicherplatzersparnis, aber wegen der Übersichtlichkeit und Wartbarkeit. Solche Objekte setzen nämlich im Exzess die Größe des Gebiets herunter, das geladen werden kann.
Nicht umsonst gibt es ja die dringende Empfehlung, keine GPS-Tracks direkt als way zu übernehmen
Datensparsamkeit: So viel wie nötig, so wenig wie möglich (wobei für “nötig” nicht der eigene persönliche Maßstab als alleiniges Kriterium angelegt werden sollte).

MKnight · 2017-01-02T19:46:36.000Z

seichter:

MKnight:

Automat7:

Vielen Dank, das war sehr ausführlich!

Du wirst also in Zukunft keine Wege mehr begradigen?

Darf er schon. Wenn auf einem schnurgeraden Weg jeden Meter ein node sitzt, darf man das schon begradigen/reduzieren.

Ich meinte keine schnurgeraden Wege, sondern “vereinfachte”. Ich hab vorhin ein paar Stichproben gezogen, da war nix dabei wo jetzt direkt die Welt untergeht, oder man ein Fass aufmachen muss, wo aber geografische (“detail”-)Daten verschwanden. (Nix GPS mit 1000 Nodes)
Das würde ich gern für die Zukunft ausschliessen, vor allem wo ja (bis auf Ausnahmen) reichlich gute Daten neu reinkommen.

kreuzschnabel · 2017-01-02T23:01:10.000Z

MKnight:

seichter:

MKnight:

Du wirst also in Zukunft keine Wege mehr begradigen?

Darf er schon. Wenn auf einem schnurgeraden Weg jeden Meter ein node sitzt, darf man das schon begradigen/reduzieren.

Ich meinte keine schnurgeraden Wege, sondern “vereinfachte”.

Ich kann ihn gut verstehen, genau das hab ich in meiner Anfangsphase (schäm, schäm) nämlich auch gemacht „was sollen die 12 Nodes in dieser Trackkurve, drei tun’s doch auch“ … Vor allem: Man spart gar keinen Speicherplatz damit. Die „gelöschten“ Nodes bleiben ja AFAIK physisch in der Datenbank bestehen, sie werden nur als inaktiv markiert.

Schnurgerade, aber krickelgemappte Ways werde ich allerdinx immer per Node-Exekution begradigen, das mache ich mit Begeisterung. Allerdings finde ich auch dann zwei kilometerweit auseinanderliegende Nodes zu weit – so etwa alle 250 m kann schon einer hin, damit nämlich bei einer folgenden Bearbeitung dieser Gegend dieser Way auch hinreichend wahrscheinlich mit angezeigt wird (wird er nämlich nicht, wenn zufällig keiner seiner Nodes innerhalb des heruntergeladenen Gebiets liegt, auch wenn der Way mittendurch geht, und dann könnte $MAPPERKOLLEGE denken, dieser Way sei noch gar nicht drin, und anfangen, ihn abzubingen).

–ks

Automat7 · 2017-01-03T13:28:43.000Z

Ich schließe mich hier ks und seichter an. Allerdings ist es schon ein Softwarefehler wenn die Nodes nicht mit heruntergeladen werden, die das zu bearbeitende Gebiet betreffen. Das ist ja fast schon unverzeihlich, weil das ja extrem irritiert und ein Bearbeiten unmöglich macht. Der ID Editor ist aber wirklich fein jetzt wo ich damit schon das ein oder andre gemacht habe, und da passiert sowas ja nicht. Man kann damit auch einfach einen Weg anklicken und dann auf begradigen klicken

MKnight · 2017-01-03T14:13:56.000Z

Automat7:

Man kann damit auch einfach einen Weg anklicken und dann auf begradigen klicken

Also Problem entweder nicht verstanden oder beratungsresistent.

kreuzschnabel · 2017-01-03T14:16:20.000Z

Automat7:

Ich schließe mich hier ks und seichter an. Allerdings ist es schon ein Softwarefehler wenn die Nodes nicht mit heruntergeladen werden, die das zu bearbeitende Gebiet betreffen.

Nodes werden natürlich heruntergeladen. Aber ein Way, der das heruntergeladene Gebiet zwar durchquert, dessen Nodes aber so weit auseinanderliegen, dass halt keiner mitgekommen ist, ist im Editor dann erst mal nicht vorhanden. Deshalb bekommen auch schnurgerade Ways alle paar hundert Meter einen willkürlichen Node von mir (natürlich nicht bei Ways, deren Nodes semantische Bedeutung haben, z.B. Freileitungen, da sind die Nodes die Maste).

–ks

Automat7 · 2017-01-03T14:34:50.000Z

ks, das hab ich schon verstanden, eine Landstraße die nur 2 Nodes hat, würde nicht in Josm angezeigt. Das Programm müsste erkennen, dass da eine Landstraße durchgeht und diese 2 Nodes auch noch laden, obwohl sie kilometerweit außerhalb des heruntergeladenen Gebietes liegen.
MK tritt wohl jeden Morgen auf eine Tarantel? Ich kann ihn auch etwas verstehen, Gemeinschaftsprojekte müssen etwas verspielt bleiben, sonst werden sie zu trocken. Wikipedia z.B., da haben oft Leute Macht über Seiten und sorgen dafür, dass nur “Lexikon-relevante” Inhalte drin bleiben. Erfahrungswissen wird dann sofort wieder entfernt oder ein andres Beispiel: Mathematische Themen werden mit einer hoch professionellen Hochsprache verfasst die nur noch ein Universitätsprofessoren verstehen kann, aber ein Schüler kann im Artikel nichts verwertbares mehr finden, weil alles herausgelöscht wird was er verstehen könnte.

MKnight · 2017-01-03T15:23:32.000Z

Automat7:

MK tritt wohl jeden Morgen auf eine Tarantel?

Also doch letzteres, ich hatte gehofft, Du hast das Problem nicht verstanden.

Ich kann ihn auch etwas verstehen, Gemeinschaftsprojekte müssen etwas verspielt bleiben, sonst werden sie zu trocken. [wikipediakeulenunsinn]

Unfug. Du hast Details kaputtgemacht, wurdest freundlich darauf hingewiesen, warum das nur in wenigen Ausnahmefällen zielführend ist und jetzt machst Du dich darüber lustig.
Die Wikipediakeule könntest Du auspacken, wenn Deine CS bereits gestern revertiert worden wären.

Da Du keine direkten Antworten gibst, gehe ich davon aus, dass Du in Zukunft weiterhin Daten zerstören möchtest. Wenn das Deine Art von Spiel ist, dann bist Du hier falsch.

Automat7 · 2017-01-03T15:41:00.000Z

Hi MK, du bist von Anfang an etwas forsch deshalb die Tarantel, Menschen wollen in aller Regel respektvoll behandelt werden und nicht wie Idioten. Ich habe gewiss nicht absichtlich irgendetwas kaputt gemacht und ich weiß auch nicht was ich kaputt gemacht haben soll. Wenn du mir da etwas mitteilen willst, musst du das schon beim Namen nennen.

MKnight:

Wir sind - zum Glück - (noch) nicht Wikipedia.

Hierauf wollte ich mich beziehen, weil da scheine ich mit dir einer Meinung zu sein.

geow · 2017-01-03T19:22:21.000Z

MKnight:

Da Du keine direkten Antworten gibst, gehe ich davon aus, dass Du in Zukunft weiterhin Daten zerstören möchtest. Wenn das Deine Art von Spiel ist, dann bist Du hier falsch.

@MKnight
Auf welchem Niveau wollen wir miteinander reden?
Wir hatten das Thema ja erst kürzlich: https://forum.openstreetmap.org/viewtopic.php?id=56000