Bei JOSM hat man die Fehlerprüfung, die einem davor warnt… Warum unsere polnischen Kollegen da “etwas” nachlässsig sind kann ich nur spekulieren.
Was mir noch fehlt, ist eine effiziente Funktion diese Fehler zu beseitigen.
Im Moment schneide ich die betreffende Linie am Punkt davor und danach, lösche den betreffenden Abschnitt mit dem “verseuchten” Punkt und füge die Linie wieder zusammen.
Wenn ich den betreffenden “Duplicate node” Punkt geringfügig verschiebe, kann ich in JOSM hochladen, ohne daß der Validator anspringt. andererseints kann ich aus dem betreffenden “Duplicate node” Punkt mit “g” beliebig viele neue Punkte prodizieren. Daher “verseuchter Punkt”.
Das habe ich gerade an meinem Punktbeispiel nochmal probiert, aber nicht hochgeladen.
Fehler in OSMI ancklicken und JOSM ferngesteuert aufrufen. Wenn viele Fehler im gleichen Gebiet vorliegen auch das Umfeld nachladen.
In JOSM Fehler mit “Prüfung” suchen.
Bei den Prüfergebnissen den/die Fehlerpunkte auswählen und auf “Reparieren” klicken.
Hochladen und fertig.
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?
Es geht z.B. um das Hinzufügen einer Haltestelle: Wenn sie zwischen den schon vorhandenen Haltestellen X und Y liegt, dann muss sie auch zwischen X und Y in die Relation eingefügt werden.
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.
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.
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.
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
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.
Wir haben keine Karte, sondern eine Datenbank. Die Karte(n(!)) holen sich aus der DB das was sie gern darstellen möchten.
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.
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.
Gute Idee.
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.
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.
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).
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.
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).
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
Das wäre was für den Urlaub oder Freizeit um die Planung zu vereinfachen und mehr Spontanität zu ermöglichen.
„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.