Verbesserungsvorschläge für ID Editor

Mit "JOSM" geht das eigentlich alles ...

Mit welchem Editor arbeitest du?
Beispiele (link) sind immer hilfreich.

EDIT:

http://wiki.openstreetmap.org/wiki/DE:JOSM/Guide

http://wiki.openstreetmap.org/wiki/DE:J … _Shortcuts

Hi, es ist der Browsereditor. Josm hab ich schon mal gestartet, aber da kann man nur Zahlen statt Beschreibungen wählen da tu ich mir als Anfänger schwer.

Zur Chronik: Bei Wikipedia kann man ja die Chronik aufrufen und sieht ziemlich schnell ob jemand Blödsinn gemacht hat. Desto leichter man sich einbringen kann, desto mehr Trolle schleichen sich ein. Deswegen wäre eine Versionskontrolle wichtig, aber bei OSM hab ich es nicht geschafft die vorhergehende Version zu betrachten.

Danke für die Links, der Browsereditor scheint nur für kleinere Änderungen geeignet zu sein. Was ich mich auch frage, was wenn man eine Straße einzeichnen will, die tausende Kilometer lang ist? Der Browsereditor müsste ja dann ziemlich viel scrollen, bzw Josm kann nur ein paar km runterladen und editieren. Evtl. könnte man da eine gpx laden und als Linie in eine Straße umwandeln?

Zum Anschauen eines Changesets gibt es http://overpass-api.de/achavi/?changeset=<cs-id>

Automat7 wrote:

Zur Chronik: Bei Wikipedia kann man ja die Chronik aufrufen und sieht ziemlich schnell ob jemand Blödsinn gemacht hat. Desto leichter man sich einbringen kann, desto mehr Trolle schleichen sich ein. Deswegen wäre eine Versionskontrolle wichtig, aber bei OSM hab ich es nicht geschafft die vorhergehende Version zu betrachten.

Wenn du die Objekt-ID deines bearbeiteten Objektes kennst, kannst du sie in eins der vielen history-Werkzeuge (z.B. http://osmlab.github.io/osm-deep-history/ , https://pewu.github.io/osm-history/#/ ) eingeben und kriegst tolle Visualisierungen der history.

In JOSM kannst du Ctrl+H drücken, und kriegst ein history-Fenster, in dem du mindestens die tag-Änderungen sehr gut vergleichen kannst.

Automat7 wrote:

Danke für die Links, der Browsereditor scheint nur für kleinere Änderungen geeignet zu sein. Was ich mich auch frage, was wenn man eine Straße einzeichnen will, die tausende Kilometer lang ist? Der Browsereditor müsste ja dann ziemlich viel scrollen, bzw Josm kann nur ein paar km runterladen und editieren. Evtl. könnte man da eine gpx laden und als Linie in eine Straße umwandeln?

Da wäre zuerst die Frage: ist das ein häufiger Anwendungsfall? Wie oft kommt es vor? Und gibts auf der Straße wirklich sonst nix - keine Abzweigungen? Keine Brücken/Tunnel?

Ich würde es im Sinne der Datenqualität für wesentlich besser halten, die Straße mittels Luftbild und GPX abzumalen, und dabei dann gleich die Topologie korrekt zu machen (d.h. abzweigungen, Brücken, ...).

OSM in Deutschland ist an der Stelle absichtlich "langsam". Wir wollen nicht, das 25 Leute jeder tausende KM lange Straßen hochladen, die mit nix verbunden sind, sondern wir wollen das 25000 Leute jeder mal einen KM Straße zeichnet, der dann aber auch korrekte Abzweigungen hat.

Die USA sind da anders, Stichwort "TIGER import", wenn du dazu was lesen willst.

Automat7 wrote:

Hi, es ist der Browsereditor. Josm hab ich schon mal gestartet, aber da kann man nur Zahlen statt Beschreibungen wählen da tu ich mir als Anfänger schwer.

Die Lernkurve ist am Anfang steil, aber danach geht alles leicht :-) JOSM hat andererseits auch eine Menge Vorlagen an Bord, die die Arbeit erleichtern. Vor allem aber empfehle ich JOSM deshalb gern Anfängern, weil es da sinnvolle Fehlermeldungen gibt, wenn du in guter Absicht eine Bearbeitung vornimmst, die andere Datenstrukturen (Routenrelationen oder so) zerstören würde.

Was ich mich auch frage, was wenn man eine Straße einzeichnen will, die tausende Kilometer lang ist? Der Browsereditor müsste ja dann ziemlich viel scrollen, bzw Josm kann nur ein paar km runterladen und editieren. Evtl. könnte man da eine gpx laden und als Linie in eine Straße umwandeln?

JOSM ist da sehr flexibel, z.B. kannst du alle Elemente entlang eines Ways oder einer Relation herunterladen. Auch die Möglichkeit, über die Overpass-API herunterzuladen, das ermöglicht richtig große Portionen auf einmal (ich hatte einmal halb Nordengland in der Datenebene, waren so 8 MB Download am Stück, aber dann wird das Arbeiten natürlich auch etwas zäh).

GPX direkt in Straße umwandeln: Erstens sind GPXe kaum jemals präzise genug dazu, das wird meist eine Krickellinie, die man erst mal angleichen sollte. Wurde das GPX mit "1 Punkt pro Sekunde" aufgezeichnet, hat man alle paar Meter einen Node, auch auf Geradeaus-Abschnitten – das ist Unfug. Deshalb braucht es immer Brain 1.0 zur Überarbeitung, GPXe sind Quellen, aber keine einbaufertigen Daten. Zweitens ist es bestimmt auch nicht sinnvoll, diese lange Straße als einen einzigen Way einzuzeichnen. Länger als ein, zwei Kilometer würde ich einen OSM-Way nicht werden lassen.

--ks

Mir ist noch was aufgefallen, und zwar bei Zugang: "Alle" ist irreführend, man denkt es schließt Motorfahrzeuge etc. mit ein. Es müsste also heißen: Jedermann!

Die Sache ist die, ich würde mir viel leichter tun wenn ich ein einfaches Tutorial lesen könnte (ein paar DinA4 Seiten) und danach um die 80% der Mappingfunktionen leicht anwenden könnte ohne mir dabei viel merken zu müssen. Ohne Englischkenntnisse und ohne viel Kenntnis hinter der Technik von OSM. So kämpft man mit den Menüs und muss manchmal raten und macht auch falsche Auswahlen, was ja nicht gerade zuträglich ist.

Ein weiterer Punkt, man sieht manchmal nicht ob Straßen mit einander verbunden sind. Wenn man z.B. einen Weg erneuert. Man müsste dann einen Hinweis bekommen, dass noch aufgelöste Knoten vorhanden sind.

Osm ist prima, und funktioniert schon echt super fürs GPS. Aber Feinschliff wäre erwünschenswert. Ich finde es ist wichtig, dass sich der User dazu angespornt fühlt möglichst eindeutige detailgetreue Angaben zu machen ohne viel Aufwand.

Also ich hab jetzt schon ein paar Änderungen gemacht, kann mir ein Veteran sagen ob ich das gut gemacht habe, oder ob ich vielleicht einfach nur getrollt habe? Beim Mappen ist mir aufgefallen, dass in einem Waldstück ziemlich viel eingetragen war, was gar nicht vorhanden war, sowie lose Punkte. So wie mir scheint könnten Trolle lang unentdeckt bleiben. Wenn sie aufgedeckt werden, wie einfach kann der Schaden wieder rückgängig gemacht werden?

Osm hat das Zeug alle proprietären Karten überflüssig zu machen und weit zu übertreffen, es braucht nur clevere zukunftssichere Investitionen. Wikipedia ist ein gutes Beispiel was möglich ist. Das dürfte so gut wie jeden Interessieren, den Mapper, den Wanderer, den Fernfahrer und viele andere.

Hm, es ist vielleicht auch sinnvoll sich über den korrekte Adressaten Deiner Vorschläge Gedanken zu machen.

Was den Browser ID angeht hat der ne Seite auf github soweit ich weis.

Und im Gegensatz zu Wikipedia gibts ganz viele verschiedenen Datenbankfrontends. Viel von dem was Du willst ist Technische nicht trivial.

Die Kartendatenbanken zu bearbeiten ohne Relationen vernünftig edidieren zu können ist sehr schwierig. Und viele Deiner Beispiel werden über Relationen gelöst. 1000 km länge Strassen sind nicht nur ein Pfad, sondern vermutlich mehrere hundert Und die Stückchen werden durch die Relation zu einer lången Strasse...

Man sollte hier den Titel dieses Beitrages ändern, in "Verbesserungsvörschläge ID" oder ähnlich, damit man weiß, worum es hier geht.

Gruß
--sv54

CS: http://www.openstreetmap.org/changeset/43829056 -> Editor ist iD -> http://wiki.openstreetmap.org/wiki/DE:ID

access=no
bicycle=yes
foot=yes
highway=track*
horse=yes
motor_vehicle=no
tracktype=grade3*
width=waldw attrib

• waren alte Werte (Chronik).
  

(Warum zeigt iD bei width keine m an?)
id lässt auch weitere Einträge zu (+) -> auswählen aus: http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A#H

Außer einen doppelten node (unverbundener Punkt) sind die Angaben nicht "falsch" - das access-Problem müsste iD problem sein. foot, bicycle und horse sind default auf yes - access=no nicht unbedingt notwendig - notwendig nur motor_vehicle=no.

Allerdings, wenn du mehr machen möchtest -JOSM !!! - der sagt dir auch "unverbundener Punkt" oder "doppelter Punkt" - oder sonstige Fehler ...

JOSM -> siehe oben

Automat7 wrote:

Mir ist noch was aufgefallen, und zwar bei Zugang: "Alle" ist irreführend, man denkt es schließt Motorfahrzeuge etc. mit ein. Es müsste also heißen: Jedermann!

Für welchen Wert? Also: Wo steht „Alle“? Ich gebe dir zu bedenken, dass kaum jemand hier im Forum mit iD arbeitet. Das Teil kennen wir alle kaum noch.

Automat7 wrote:

Die Sache ist die, ich würde mir viel leichter tun wenn ich ein einfaches Tutorial lesen könnte (ein paar DinA4 Seiten) und danach um die 80% der Mappingfunktionen leicht anwenden könnte ohne mir dabei viel merken zu müssen. Ohne Englischkenntnisse und ohne viel Kenntnis hinter der Technik von OSM. So kämpft man mit den Menüs und muss manchmal raten und macht auch falsche Auswahlen, was ja nicht gerade zuträglich ist.

Tutorial: Wie lang darf’s denn sein? Kannst mal in meins reinschauen und mir sagen, was es taugt. Adresse steht unten in der Sig.

Einfaches Editieren ohne viel Technik: Das wurde schon oft versucht, aber es beißt sich irnkwann mit der Detailliertheit unserer Informationen, die du ja andererseits auch lobst. OSM bildet halt nicht nur ab „Hier ist ein Trampelpfad“, sondern auch „Hier läuft der Europäische Fernwanderweg E1 lang“. Für letzteres braucht es eine Relation, die die vielen hundert Wegstücke, auf denen der E1 verläuft, entsprechend anordnet. Schon muss der Benutzer, der daran arbeitet, zumindest wissen, was Relationen sind, damit er nicht den Weg auftrennt und eine zusätzliche Kurve einbaut, die zwar an sich richtig ist, aber hinterher in der Relation an der falschen Stelle sitzt oder ganz fehlt.

JOSM gibt dann zumindest eine Warnung aus („Durch diesen Vorgang wurde Relation xyz betroffen“).

Ein weiterer Punkt, man sieht manchmal nicht ob Straßen mit einander verbunden sind. Wenn man z.B. einen Weg erneuert. Man müsste dann einen Hinweis bekommen, dass noch aufgelöste Knoten vorhanden sind.

JOSM benutzen. Ich hab meinen so eingestellt, dass shared nodes andersfarbig dargestellt werden. Ich sehe sofort, wo was noch nicht verbunden ist.

Osm ist prima, und funktioniert schon echt super fürs GPS. Aber Feinschliff wäre erwünschenswert. Ich finde es ist wichtig, dass sich der User dazu angespornt fühlt möglichst eindeutige detailgetreue Angaben zu machen ohne viel Aufwand.

Zunächst mal wäre es gut, wenn du unterscheiden würdest zwischen

- dem Projekt OSM (der Geodatenbank, die wir zusammenstellen)
- einem bestimmten Editor dafür (dessen Nachteile sind nicht Nachteile von OSM!)
- bestimmten, daraus erzeugten Karten (Mapnik [die „Hauptkarte“ auf osm.org] ist auch nicht OSM, sondern ein daraus erzeugtes Produkt unter tausenden).

Dann redet es sich leichter, denn vieles, was du kritisierst, ist kein Problem von OSM, sondern eines von iD, und dann sind dessen Maintainer die richtige Adresse dafür.

Was einfaches Editieren angeht: Es gibt viele Ansätze dafür, aber die haben bislang oftmals auch ebenso viele Fehler produziert. Vor einem Jahr hat eine gutgemeinte Handy-App Sprechzeiten von Arztpraxen erfasst, indem es sie an die Straßen getaggt hat, weil der Anwender nicht genauer zielen konnte. Und der Anwender dachte natürlich: das wird so schon richtig sein. Hunderte von Bearbeitungen mussten leider zurückgesetzt werden, die Information war wieder weg – aber ein manuelles Überarbeiten hätte irrsinnig Zeit beansprucht. Ohne ein bisschen Wissen, was man da macht und wie das hinter den Kulissen abgeht, geht es offenbar nicht.

Osm hat das Zeug alle proprietären Karten überflüssig zu machen und weit zu übertreffen, es braucht nur clevere zukunftssichere Investitionen. Wikipedia ist ein gutes Beispiel was möglich ist.

Einen Text zu bearbeiten oder dort Bearbeitungen rückgängig zu machen ist andererseits auch ungleich einfacher als eine Geodatenbank, wo viele Strukturen zusammenarbeiten und voneinander abhängen.

Das dürfte so gut wie jeden Interessieren, den Mapper, den Wanderer, den Fernfahrer und viele andere.

Das ist hier jedem klar, deshalb arbeiten wir ja zusammen daran, dass OSM immer besser wird. Aber „ganz einfaches Bearbeiten“ und „detaillierte Karte, die auch Feinheiten abbildet“ beißt sich irnkwann. Das heute praktizierte Tagging kommt ja gerade davon, dass wir immer mehr Details erfassen. Beispiel: Fahrstreifen auf Fahrbahnen. Früher hat man da einen Way langgezogen und „highway=primary“ drangeschrieben, und das reichte zur Orientierung. Heute teilen wir diesen Way in Dutzende Teile auf, die alle ein paar Meter lang sind, weil wir zur Freude des Anwenders auch Tempolimits, Richtungsfahrstreifen (mit Richtungsangaben), Abbiegeverbote (für korrektes Routing) und ähnliches erfassen und dafür den einen Way alle paar Meter aufteilen müssen, wenn sich da nur ein Merkmal ändert. Abbiegeregelungen lassen sich nur über Relationen abbilden. Natürlich wird die Datenstruktur dabei immer komplexer, und natürlich muss man immer besser aufpassen, dass noch alles konsistent ist – das kann ein Editor nicht grenzenlos per Software sicherstellen, das braucht auch immer mehr Mitdenken des Bearbeiters.

--ks

Hallo - Er ist ein Anfänger, der nur das gemacht hat was "OSM" vorschlägt: "Bearbeiten" -> wer hat denn iD eingebunden?

Und mit iD kann man "Kleines" bearbeiten - allerdings sollte JOSM nutzen der nicht nur schnell einen Parkplatz oder eine Adresse eintragen möchte. Das Problem: es gibt auch keinen Guide für iD.

@Automat7: kannst auch gern eine PN senden - aber bitte weitermachen - Mapper vor Ort sind es nie zuviel.

geri-oc wrote:

Hallo - Er ist ein Anfänger, der nur das gemacht hat was "OSM" vorschlägt: "Bearbeiten"

Ist mir bewußt. Hab ich ihm irnkwas vorgeworfen? Hab ich ihn beschimpft? Ich verstehe deinen Einwurf nicht ganz.

wer hat denn iD eingebunden?

Weiß ich nicht, aber ich hätte noch eine Seite dazwischengeschaltet mit dem Hinweis, dass es noch deutlich größere und mächtigere Editoren gibt als diesen, aber dass man damit mal die ersten Schritte machen kann.

--ks

Ich habe auch nichts gesagt von beschimpfen.

Es geht nur darum, wie jemand, der noch nie etwas mit OSM zu tun hat, auf OSM "geholfen wird". Und iD ist das klägliche Beispiel an erster Stelle. Wenn es dort wenigsten ein Suchfeld geben würde, wo z.B. "Schranke" eingegeben wird und dort auf "barrier" weitergeleitet wird ...

Deshalb bin ich auch für als "Deutsche Startseite" ...

Hallo Automat7, was mich mal interessieren würde, wie bist du zu OSM gekommen, was war dein erster Berührungspunkt .. und ganz wichtig, hast du dich schon einmal mit der Startseite des Wikis beschäftigt?

Edit: Habe mir auch mal die Änderungssätze angeschaut, und diesen Weg und dessen Chronik fand ich irgendwie cool, lustig, was auch immer:

highway=track
tracktype=grade5
note=motor␣saw␣recommended

das war 2010, nun half wohl auch die Motorsäge nicht mehr und wurde folgerichtig gelöscht 😎

geri-oc wrote:

Es geht nur darum, wie jemand, der noch nie etwas mit OSM zu tun hat, auf OSM "geholfen wird". Und iD ist das klägliche Beispiel an erster Stelle.

Kläglich? 🙄 iD soll Interessierte motivieren über eine sehr niedrige Schwelle bei uns einzusteigen und ist damit sehr erfolgreich - 2016 hatte iD etwa 6x soviel Nutzer wie JOSM, https://wiki.openstreetmap.org/wiki/Editor_usage_stats

Hast du dir mal das Changelog für v.2 angesehen?
https://github.com/openstreetmap/iD/blo … ANGELOG.md

Wenn du iD kläglich findest, kannst du Verbesserungen hier vorschlagen: https://github.com/openstreetmap/iD/issues

geri-oc wrote:

Wenn es dort wenigsten ein Suchfeld geben würde, wo z.B. "Schranke" eingegeben wird und dort auf "barrier" weitergeleitet wird ...

Zugegeben, die deutschen iD-Übersetzer auf transifex haben teilweise wenig Detailwissen über OSM. Beim neuen Preset für tourism=apartment wurde z.B. Guest Apartment / Condo mit Ferienwohnung / Eigentumswohnung übersetzt. Ich habe die Eigentumswohnung gestern entsorgt, weiß aber nicht wie lange es dauert bis die Korrektur in iD auftaucht.

lift_gate wird mit den Begriffen Schranke oder Schlagbaum gefunden.

geri-oc wrote:

Deshalb bin ich auch für als "Deutsche Startseite" ...

Weshalb? Der "Bearbeiten"-Button auf openstreetmap.de führt auch nur zu openstreetmap.org...

Gruß
geow

edit1:typo
edit2:lift_gate... ergänzt

@Automat7 Ich würde vorschlagen, du änderst den Thread-Titel eindeutig z.B. in "Verbesserungsvorschläge iD-Editor"

Einfach anmelden und unter dem ersten Beitrag https://forum.openstreetmap.org/viewtop … 65#p618865 "Edit" anklicken, dann kannst du auch den Titel bearbeiten.

Danke
geow

geri-oc wrote:

Ich habe auch nichts gesagt von beschimpfen.

Es geht nur darum, wie jemand, der noch nie etwas mit OSM zu tun hat, auf OSM "geholfen wird". Und iD ist das klägliche Beispiel an erster Stelle. Wenn es dort wenigsten ein Suchfeld geben würde, wo z.B. "Schranke" eingegeben wird und dort auf "barrier" weitergeleitet wird ...
...

iD hat das seit ca. Tag null und weiter gibts natürlich auch mehrere EInführungen zu iD. Was tatsaächlich etwas ein Problem ist, sind schlaumeierische Übersetzungen, das Problem haben wir aber auch auf openstreetmap.org und anderswo (bei JOSm ist es teilweise dafür umgekehrt).

geow wrote:

Kläglich? 🙄 iD soll Interessierte motivieren über eine sehr niedrige Schwelle bei uns einzusteigen und ist damit sehr erfolgreich - 2016 hatte iD etwa 6x soviel Nutzer wie JOSM, https://wiki.openstreetmap.org/wiki/Editor_usage_stats

Mag sein, dafür wirft iD auch nahezu 100% aller Fehler in die DB.

Wenn du iD kläglich findest, kannst du Verbesserungen hier vorschlagen: https://github.com/openstreetmap/iD/issues

Ohne Dir besonders nahe treten zu wollen, aber der Vorschlag ist mindestens albern. Wenn nicht gar trollig. Der grösste Teil der hier von einem Neuling vorgetragenen Probleme steht teilweise seit Jahren in den Issues bei iD (oder hier im Forum oder anderen Diskussionskanälen). Passiert genau nix. Jetzt haben wie eine v2.0.1 mit über 200 issues. Hätte auch gern was von den Drogen.
iD muss m.E. in der Qualität nicht mal mit JOSM gleichziehen, es würde für den Anfang mal reichen, grundlegende Probleme zu beheben. (Beispiele siehe oben ... oO)

Zugegeben, die deutschen iD-Übersetzer auf transifex haben teilweise wenig Detailwissen über OSM.

Noch son schöner Hasspunkt. die Entwicklung findet auf github statt, wo viele Leute/Mapper verzweifeln, weil sie nicht damit klarkommen (ich hab auch sehr lang gebraucht und fühle mich da mittlerweile recht wohl) dann braucht man auch noch noch einen weiteren ACC bei Transifex. Ich kann nur jedem empfehlen: lohnt die Mühe nicht, macht nur schlechte Laune (also äquivalent zu den iD-issues auf github, sondern noch schlimmer). Nicht nur, dass genau wie bei github-issues Verbesserungen nicht im Code ankommen ist transifex noch 20 Ticken unstrukturierter.

Kurzfassung: Nix von dem was man bei Github an Verbesserungen abkippt kommt im Code an und bei tranisfex _gar_ nix.

geri-oc wrote:

Deshalb bin ich auch für als "Deutsche Startseite" ...

Weshalb? Der "Bearbeiten"-Button auf openstreetmap.de führt auch nur zu openstreetmap.org...

Das ist egtl. wieder eine ganz andere Geschichte. Das Problem hierbei ist, dass iD gegen den Willen der Community als "Standard"-web-editor durchgedrückt wurde. Potlatch ist klar die selbe Scheisse in grün, aber auf Kritik wurde zu keiner Zeit eingegangen. (Noob-)Webeditoren benötigen QA-Prüfungen, die gibt es aber nicht. Deswegen ist die DB auch voller Müll. Siehe Topic.

SimonPoole wrote:

"Suchfeld"

iD hat das seit ca. Tag null und weiter gibts natürlich auch mehrere EInführungen zu iD. ...

Es hat ein Suchfeld, was in den Daten sucht, ob eine "Schranke" im Gebiet ist. Aber eben nicht, wie etwas gemappt wird was unter den "Vorgaben" nicht enthalten ist. Da könnte man auch auf das WIKI verlinken und das diese Werte dann unter "+" eingetragen werden.

geow wrote:

Weshalb? Der "Bearbeiten"-Button auf openstreetmap.de führt auch nur zu openstreetmap.org...

Aber ich werde erst auf eine "Startseite" geführt, die mir verschiedenes "Wichtiges" kurz nennt und verlinkt:

SimonPoole wrote:

iD hat das seit ca. Tag null und weiter gibts natürlich auch mehrere EInführungen zu iD. Was tatsaächlich etwas ein Problem ist, sind schlaumeierische Übersetzungen, das Problem haben wir aber auch auf openstreetmap.org und anderswo (bei JOSm ist es teilweise dafür umgekehrt).

"Schlaumeierisch" ist vielleicht nicht immer richtig, aber bei Übersetzungen gilt in besonderem Maße "gut gemeint ist nicht immer gut gemacht". Es gibt da immer ein paar Leute, die denken, "irgendeine Übersetzung ist besser als gar keine, weil der arme nicht englisch sprechende Mensch ja sonst total auf dem Trockenen sitzt, also schreib ich mal irgendwas hin, was mir halbwegs passend erscheint", und diese Art von Eifer führt öfters zu Problemen - leider ist der Workflow irgendwie auch so, dass solche bescheuerten, ohne OSM-Kenntnisse gemachten Änderungen oft erst nach Wochen auffallen.

MKnight wrote:

... aber auf Kritik wurde zu keiner Zeit eingegangen. (Noob-)Webeditoren benötigen QA-Prüfungen, die gibt es aber nicht. Deswegen ist die DB auch voller Müll. Siehe Topic.

Danke, danke, danke, dass ich nicht der einzige bin, der das für sinnvoll hält.

woodpeck wrote:

leider ist der Workflow irgendwie auch so, dass solche bescheuerten, ohne OSM-Kenntnisse gemachten Änderungen oft erst nach Wochen auffallen.

Da hilft halt nur alle paar Wochen vorbeizuschauen. Mach ich wohl wieder öfters demnächst.
Bei der Übersetzung versuch ich mich am wiki zu orientieren, das hilft am ehesten weiter.

geri-oc wrote:

SimonPoole wrote:

"Suchfeld"

iD hat das seit ca. Tag null und weiter gibts natürlich auch mehrere EInführungen zu iD. ...

Es hat ein Suchfeld, was in den Daten sucht, ob eine "Schranke" im Gebiet ist. Aber eben nicht, wie etwas gemappt wird was unter den "Vorgaben" nicht enthalten ist. Da könnte man auch auf das WIKI verlinken und das diese Werte dann unter "+" eingetragen werden.

Hat es auch, aber ich meine die Suchfunktion, dass die Presets und Synonyme durchsucht:

und

Ansonsten ist es immer noch so, dass die Fehler mit den meisten Auswirkungen typischerweise immer noch mit JOSM gemacht werden.

Hi, Kreuzschnabel, dein Tutorial ist zu lang, ausführlich, unübersichtlich, aber für den ernsthaften Mapper sicherlich eine Fundgrube.
Ich meine das ganze so: Der Anfänger wird auf die Webseite klicken und dann zu diesem Webeditor kommen, dort ist zwar löblicherweise gleich beim Start ein Tutorial verlinkt, aber das hat mir nicht viel gebracht. Was wird ein Neuling wohl eintragen wollen? Wege, Kreuzungen und evtl. noch Kaufhäuser. Das wars, das wichtigste eben für den Ottonormalverbraucher. Und das sollte ihm OSM auch ermöglichen und zwar so, dass er nicht mehr als 15 Minuten aufwenden muss um mal gerade etwas abzuändern.
Ich beziehe mich hier nur auf www.openstreetmap.org der Hauptseite von OSM, was der Neuling auch als OSM identifiziert. Will er etwas ändern, wird er auf diese Seite gehen und dort auf Bearbeiten klicken.
"Feinheiten abbildet“ beißt sich irnkwan" schon klar, aber der Neuling hat an Feinheiten gar nicht so das Interesse, der will nur mal grobe Strukturen hinzufügen das wars. Evtl, könnte man einfach einen einfachen und einen erweiterten Modus benutzen. Und Relationen bleiben dann eben für den einfachen Modus gesperrt oder die Software schafft es irgendwie sie trotz Veränderung beizubehalten. Und evtl. könnte man gut und detailreich gemappte Bereiche einfach für Neulinge sperren? Die können ja immer noch einen Hinweis hinterlassen, oder evtl. nur eine richtige Bearbeitung, die jedoch nicht öffentlich eingetragen wird, sondern nur als Hinweis/Vorschlag.

@Gerioc der Wert "Alle" im Webeditor meint Jedermann! Ich hab es aber fälschlicherweise für den Ausschluss von den darunterliegenden Einträgen genommen. Ich hab die Wege falsch eingetragen, das sind öffentliche Wege wo jeder spazieren gehen darf. Wenn ich das auf no setze, dann darf da auch niemand mehr spazieren gehen, was totaler Blödsinn ist. Ich habe gedacht wenn ich Motorfahrzeuge auf no setze, dann muss ich "Alle" auch auf no setzen, weil die Motorfahrzeuge ja nicht mehr dabei sind.
Mit mehrere Wege auswählen meine ich: Es ist ein Waldweg, wenn ich auf den klicke, dann leuchtet immer nur ein kleines Stück Waldweg auf, wenn ich dann den Motorfahrzeugbetrieb verbieten möchte, dann muss ich mich durch die Teilstückchen des Waldweges klicken und muss jedes mal das Verbot erneut aussprechen. Das ist unsinnig für den Mapper.
"Er ist ein Anfänger," Absolut richtig! :-D
" wo z.B. "Schranke" eingegeben " Das hab ich erst später entdeckt, ganz oben links ist so ein Feld, ich gebe Schranke ein und er leitet mich auf Schlagbaum um. Über dem Feld müsste „Objekt suchen“ stehen, nicht einfach nur ein Lupenbild.

@Hartmann: „wie bist du zu OSM gekommen“ Zuerst als Google Map Alternative, weil ich freie Programme bevorzuge, dann als Wanderkarte, anschließend als Karte fürs GPS und dann wollte ich auch etwas ausbessern.
„und diesen Weg und dessen Chronik“ Wenn ich auf den Link klicke, was muss ich tun, damit mir der alte Weg angezeigt wird? Weil bei mir kommt nur ein Rahmen um das Gebiet, aber der gelöschte Weg ist nicht zu sehen

@geow: „Kläglich?“ Nicht ganz, aber es hat schon noch Potential auszubauen. (Für mich als frischen Einsteiger)
„Weshalb? Der "Bearbeiten"-Button auf openstreetmap.de führt auch nur zu openstreetmap.org...“ genau, außerdem wird der Surfer direkt die Karte ansteuern, und von dort direkt versuchen zu editieren.
„du änderst den Thread-Titel“ Wurde scheinbar schon für mich erledigt.

@Forum, als ich meinen Post absenden wollte, meint das Forum ich sei nicht angemeldet und nach dem Login waren meine Eingaben weg, zum Glück hab ich die in Libreoffice getippt und nicht im Webfenster.

ps. wenn man kostenlose Arbeitszeit verschenkt dann kostet das. OSM ist darauf angewiesen, dass es geschenkte Arbeitszeit möglichst effizient nutzt.

Hallo geow,

geow wrote:

Zugegeben, die deutschen iD-Übersetzer auf transifex haben teilweise wenig Detailwissen über OSM. Beim neuen Preset für tourism=apartment wurde z.B. Guest Apartment / Condo mit Ferienwohnung / Eigentumswohnung übersetzt. Ich habe die Eigentumswohnung gestern entsorgt, weiß aber nicht wie lange es dauert bis die Korrektur in iD auftaucht.

Das war derselbe Übersetzer, der sich schon einmal an dem ungepflegten Feldweg (die Alten erinnern sich bestimmt noch daran ;-)) versucht hat. Ich habe ihm eine PN geschrieben und ihn auf Deine Kritik hingewiesen.

Aber die anderen Übersetzungen anderer Zeichenketten sind auch mehr als komisch:

Barrier Features → Barrierefunktionen
Building Features → Gebäudefunktionen
Golf Features → Golfplatzfunktionen
das geht so weiter …
Drive-Through →Durchfahrtslokal
Leaf Cycle → Blätterzyklus

Im Webinterface von Transifex steht ja neuerdings sogar, in welcher Objektvorlage (und für welches Tag) die Übersetzung Anwendung findet.

Viele Grüße

Michael

Automat7 wrote:

Wenn ich auf den Link klicke, was muss ich tun, damit mir der alte Weg angezeigt wird? Weil bei mir kommt nur ein Rahmen um das Gebiet, aber der gelöschte Weg ist nicht zu sehen

In der Tat, das kann auch die Hauptkarte nicht, wenn es sich um etwas gelöschtes handelt. Die Hauptkarte kann nur die letzte Version eines Objektes anzeigen und die letzten Version ist eben das Löschen gewesen.

Hierzu nimmt man sich z.B. das oben schon erwähnte achavi. Das zeigt zumindest in diesem Änderungssatz dann mit rot alles an, was gelöscht wurde.

Nakaner wrote:

Aber die anderen Übersetzungen anderer Zeichenketten sind auch mehr als komisch

scheint ja fast so, dass man hier einen übersetzungsbot hat laufen lassen, weil man eventuell nicht wollte, das nicht übersetze Texte (also englisch) nicht erscheinen?! 🙄

Weil ich hier Kritik an (meinen) Übersetzungen lese:
Bitte beteiligt Euch an der Übersetzungsaufgabe in transifex.
Je mehr Personen dort mitwirken, desto besser wird das Ergebnis.

Ich mache schon seit einiger Zeit transifex-Übersetzungen für iD und mir sind einige Fehler unterlaufen.
Mein auffälligser Fehler war der falsch übersetzten "Feldweg", da habe ich noch nicht gewusst,
wie bei "Context" unter "Instructions" das zugrundeliegende Key=Value Pärchen angeführt wird.

Ich übersetze normalerweise zeitnahe, weil die Veröffentlichung einer neuen Version des iD-Editors nicht angekündigt wird
und ich möchte, dass möglichst alle Begriffe ins Deutsche übersetzt sind.
Nochmals meine Bitte: Beteiligt Euch an den transifex-Übersetzungen!

SimonPoole wrote:

Ansonsten ist es immer noch so, dass die Fehler mit den meisten Auswirkungen typischerweise immer noch mit JOSM gemacht werden.

Hast Du da eine Quelle dazu?

Ich habe gerade eben ein paar Stichproben gemacht und da sieht es so aus, dass bei Ways die Quote etwa 50/50 ist (was mich überrascht), bei POIs bzw. Nodes allerdings 1/10 (josm/iD) Relationen hab ich nur halbherzig angeschaut, da sieht es so aus, dass Fehler jahrelang mitgeschleppt werden. Um da eindeutige Aussagen zu machen, müsste man teilweise die ganze History reverten um rauszufinden, wer Schuld is. Hinzu käme da, dass Relationen in aller Regel älter als iD sind, also schlecht zu vergleichen.

MKnight wrote:

SimonPoole wrote:

Ansonsten ist es immer noch so, dass die Fehler mit den meisten Auswirkungen typischerweise immer noch mit JOSM gemacht werden.

Hast Du da eine Quelle dazu?

Du kannst einfach das Forum nehmen und die Beiträge zu den globalen OSM Katastrophen anschauen, die letzte ist nur 2 Wochen her https://www.openstreetmap.org/changeset/43343413 , schon vergessen?

SimonPoole wrote:

Du kannst einfach das Forum nehmen und die Beiträge zu den globalen OSM Katastrophen anschauen, die letzte ist nur 2 Wochen her https://www.openstreetmap.org/changeset/43343413 , schon vergessen?

In dem Falle meinst Du "grösste" Auswirkungen, nicht "meiste" (quantitativ). Der Unterschied zwischen beiden ist übrigens zusätzlich der, dass die "Grössten" (meist) schnell bemerkt werden und die "Meisten" mühsam aus QA-Tolls rausgeklaubt werden müssen. Imho ist das qualitativ ein grosser 🙂 Unterschied.

Nachtrag: Es ist übrigens auch ein Unterschied, ob man auf die JOSM-fehlermeldungen scheisst, oder ob man in iD überhaupt nichts von Fehlern mitbekommt. (Ja ich weiss, passt schlecht zu Deinem Beispiel, weil das in JOSM auch (noch) nicht angemeckert wurde.

MKnight wrote:

Ja ich weiss, passt schlecht zu Deinem Beispiel, weil das in JOSM auch (noch) nicht angemeckert wurde.

Ein so großes Gebäude aus dem genannten changeset 43343413 wurde auch in der verwendeten version 10966 bereits sogar doppelt angemeckert: "zu großes gebäude" und "zu lange segmente".

Die "zu großes gebäude" warnung wurde später in die Kategorie "Fehler" hochgestuft.

ManfredBrandl wrote:

Ich mache schon seit einiger Zeit transifex-Übersetzungen für iD und mir sind einige Fehler unterlaufen.
Ich übersetze normalerweise zeitnahe, weil die Veröffentlichung einer neuen Version des iD-Editors nicht angekündigt wird
und ich möchte, dass möglichst alle Begriffe ins Deutsche übersetzt sind.

Manfred, danke für Rückmeldung und die PN. Schön, dass du bei Transifex und OSM zum Projekt beiträgst!

Bei den Lokalisierungen der Editoren wäre es vorteilhaft, möglichst nah an den Definitionen im Wiki bleiben, die ja auch in den Presets von JOSM und iD verlinkt werden. OSM-Tag-Definitionen sind oft nicht allzu "buchstäblich" zu nehmen und zu übersetzen. So ist z.B. highway=path ein Mehrzweck-Weg (vgl. bike path oder multi-use-path) und nicht nur ein Wanderweg. Jetzt aber bitte keine OT-Diskussionen zu duck tagging 😉

Also vor einer Übersetzung ins Wiki schauen
https://wiki.openstreetmap.org/wiki/Map_Features
https://wiki.openstreetmap.org/wiki/DE:Map_Features

oder eine Suchmaschine fragen: osm + wiki + key

Gruß
geow

PS: Manfred, weißt du wie lange es ungefähr dauert, bis Änderungen in Transifex im iD-Editor ankommen?

SimonPoole wrote:

Ansonsten ist es immer noch so, dass die Fehler mit den meisten Auswirkungen typischerweise immer noch mit JOSM gemacht werden.

Das wag ich auch stark zu bezweifeln.
Hab mich vorzugsweise aufs weltweite Forest-Fixen verlegt, und wenn irgendwo ein längerer outer-Waldrand gelöscht wurde und dann ein Jahr oder gar mehrere über zum Beispiel 200 qkm die ganzen inners invers angezeigt wurden, innen grün und außen weiß, dann steht da eher selten mal JOSM dabei. Viel öfter "iD" oder Potlatch.

Extrem beliebt seit iD-Einführung auch: fake inners in Flächen!
Diese Methode: beim Flächen-Malen führt man den way einfach nahtlos nach innen weiter zu einer Lichtung, fährt um die außenrum, trifft dann wieder auf die eben erzeugte "Nahtlinie" zum outer und fährt auf derselben wieder zurück, und dann wieder weiter ganz außenrum. Bis zur nächsten Lichtung. Oder gern auch mal innerhalb von Lichtung zu Lichtung hopsen, gibt da die verschachtelsten Konstruktionen. Die Nahtlinien erzeugen doppelte Segmente nur auf den Fehlercheck-Tools, aber im Editor und auf osm ist diese Nahtlinie komplett unsichtbar! Dadurch totale Verwirrung, wenn man mit der Maus auf die Aussenlinie clickt und alle inners leuchten plötzlich gleichzeitig mit auf, obwohl überhaupt nirgends mit angebunden - scheinbar. Hab vor einiger Zeit Gegenden gesehen, da ist diese inner-Erzeugung via iD offensichtlich die Standardmethode für Löcher in Flächen, massenhaft. Und jeder Neuling schaut sich die ortsüblichen Methoden natürlich erstmal von bereits vorhandenen Daten ab und macht es dann genauso. Toll, warum auch nicht, die Karten scheinen damit auch keinerlei Probleme zu haben.
War dann zum Schluss gekommen, das muss jetzt wohl wirklich eine neue offizielle Methode sein, und hab schleunigst die Flucht ergriffen. In so Gegenden sieht man mich so schnell nicht wieder, mit so Murks komm ich nicht klar. Falls diese Methode evt. doch nicht so toll sein sollte, müsste ein automatischer Mindest-Check beim Hochladen her, aber der muss sowieso dringendst für alle Edits her.

Die mal wo gelesene Behauptung, dass Checks zur Fehlervermeidung Newbies vertreiben würden, ist sowieso totaler Blödsinn. Wenn ICH von irgendwas keinen blanken Schimmer habe, und bei jedem Click eine Katastrophe befürchten muss, wahrscheinlich auch ruckzuck welche anrichte, DANN lass ich von sowas schleunigst wieder die Finger. Nicht umgekehrt. Würde sehr vermuten, das geht der Mehrheit so, aber zumindest Leuten mit einem Minimum an Qualitätsgewissen.

Und ein ganz neues iD-Problem, erst diesen Monat entdeckt:
Ein Mapper malt KEINE fake-inners, sondern erzeugt tatsächlich mit iD nun Relationen für Lichtungen in Wäldern. An sich sehr löblich. Klitzekleines Problem nur: für JEDE Zusatz-Lichtung wird eine NEUE, zusätzliche Relation erzeugt. Als Resultat gibts für einen Wald mit 5 inners dann 5 Relationen, die alle dasselbe outer und jede genau 1 inner haben. Als ich das kürzlich bemerkt hab und das in der Gegend immer der gleiche iD-Mapper war, hab ich ihn mal angeschrieben zwecks Hinweis. Er hat dann versucht, rauszukriegen wie das passiert und wie er das richtig machen könnte, aber nach ein paar Tagen gemeldet: Keine Chance. Er findet partout nicht raus, wie und was er anders machen muss. Und ich konnt es ihm auch nicht sagen mangels Ahnung. Zwar etwas rumgegoogelt nach iD+MP Anleitung, aber nix gefunden, und selber testen kann ich's nicht.

wycbtma wrote:

SimonPoole wrote:

Ansonsten ist es immer noch so, dass die Fehler mit den meisten Auswirkungen typischerweise immer noch mit JOSM gemacht werden.

Das wag ich auch stark zu bezweifeln.
Hab mich vorzugsweise aufs weltweite Forest-Fixen verlegt, und wenn irgendwo ein längerer outer-Waldrand gelöscht wurde und dann ein Jahr oder gar mehrere über zum Beispiel 200 qkm die ganzen inners invers angezeigt wurden, innen grün und außen weiß, dann steht da eher selten mal JOSM dabei. Viel öfter "iD" oder Potlatch.

Das geht schon seit langem nicht mehr in iD aus versehen (man muss zuerst explizit das Objekt aus der Relation herauslöschen).

Extrem beliebt seit iD-Einführung auch: fake inners in Flächen!
.....

Und was ist iD spezifisch an den zwei Fehlern? Nichts? Es sind, nicht sehr klassische, Anfängerfehler die auch locker mit JOSM gehen. Das einzige spezielle an iD in der Hinsicht ist, dass es versucht das die synthetischen Flächenobjekte immer gültige Flächen (sprich Polygone oder MPs) bleiben, dass ist manchmal etwas verwirrend, ist aber nicht "falsch".

SimonPoole wrote:

wycbtma wrote:

Extrem beliebt seit iD-Einführung auch: fake inners in Flächen!
.....

Und was ist iD spezifisch an den zwei Fehlern? Nichts? Es sind, nicht sehr klassische, Anfängerfehler die auch locker mit JOSM gehen.

Dein Eintreten für iD in Ehren, aber:

In JOSM lässt sich so was im Zeichenmodus gar nicht zeichnen, weil JOSM einen Way abschließt, sobald er zum ersten Mal auf sich selbst trifft (hier: am Ende der ersten Lichtung). Das heißt: ich biege vom Outer nach innen ab, klicke um die erste Lichtung herum bis an ihren Anfang (hier schließt JOSM den Way ab), fahre mit der Maus wieder dahin, wo ich den outer verlassen habe, und setze diesen fort – aber jetzt fängt JOSM ab dem „Abknickpunkt“ am outer einen neuen Way an. Mache ich zwei Inseln und schließe dann den outer, habe ich drei Ways. Ich muss jetzt also drei Ways mit dem Flächenmerkmal taggen (schon das fällt auf), und die Darstellung dürfte ganz und gar nicht die gewünschte sein (spätestens dann weiß auch der Anfänger, dass es so nicht geht).

Andererseits kann man natürlich in JOSM erst den outer zeichnen und dann die Nodes so schieben, dass sie die Insel ergeben. Aber dann gibt JOSM bei der Prüfung vorm Hochladen die eindeutige Warnung „Linien, die sich selbst überschneiden“ aus.

iD aber zeichnet solche Konstrukte im Flächenmodus ohne jede Widerrede, und in der Editorvorschau sieht das Ergebnis auch „richtig“ aus (Fläche mit Insel) – ich hab’s nicht hochgeladen.

Da müsste tatsächlich eine Erkennung mit Warnhinweis für solche Fälle rein (z.B. dann getriggert, wenn ein Way zwei benachbarte Punkte an unterschiedlichen Positionen enthält).

--ks

kreuzschnabel wrote:

SimonPoole wrote:

wycbtma wrote:

Extrem beliebt seit iD-Einführung auch: fake inners in Flächen!
.....

Und was ist iD spezifisch an den zwei Fehlern? Nichts? Es sind, nicht sehr klassische, Anfängerfehler die auch locker mit JOSM gehen.

Dein Eintreten für iD in Ehren, aber:

Das Objekt, dass man mit dem Flächentool so kreiert ist aber nicht direkt falsch nach OSM Datenmodel, habe aber mal trotzdem ein Issue erstellt https://github.com/openstreetmap/iD/issues/3610

So lange ich darauf achte keine Knoten miteinander oder wieder mit dem Weg zu verbinden geht das übrigens auch locker mit JOSM in einem Zug, ganz ohne Warnung (auch wenn das Polygon sich selber überlappt, also optisch "richtig" aussieht).

SimonPoole wrote:

So lange ich darauf achte keine Knoten miteinander oder wieder mit dem Weg zu verbinden geht das übrigens auch locker mit JOSM in einem Zug, ganz ohne Warnung (auch wenn das Polygon sich selber überlappt).

Mit jedem Editor kann man Mist machen, da sind wir uns wohl einig. Und wenn mit iD besonders viel Mist anfallen sollte (was ich jetzt nicht nachprüfe), dann liegt das natürlich nicht nur an diesem Editor an sich, sondern auch daran, dass davor überproportional viele unerfahrene Anwender sitzen – an der unterschiedlichen Userprofilen scheitert da die Vergleichbarkeit.

Aber gerade deshalb wäre es schön, wenn iD eher nur Grundfunktionalität böte, aber dafür narrensicher wäre und bei Geometriefehlern dieser Art konsequent warnte. Beispielsweise könnte er bei solchen Fake-Inseln eine Mitteilung ausgeben, dass so was bei OSM anders gemacht wird und der User bitte Außen- und Innenumrisse als separate Polygone anlegen möge. Daraus kann iD intern ein MP erzeugen, von dem der User gar nichts erfahren muss. JOSM macht das automatisch, wenn ich alle Polygone selektiere und Strg-B drücke: ein MP wird erzeugt, outer und inner vergeben, und evtl. Tags vom outer werden an die Relation umgehängt. Code dafür gibt’s also.

Alternative: Nur vorgebildete Leute dürfen überhaupt mitmappen. Aber das bekommst du in so einem Projekt heute wirklich nicht mehr durch.

--ks

kreuzschnabel wrote:

SimonPoole wrote:

So lange ich darauf achte keine Knoten miteinander oder wieder mit dem Weg zu verbinden geht das übrigens auch locker mit JOSM in einem Zug, ganz ohne Warnung (auch wenn das Polygon sich selber überlappt).

Mit jedem Editor kann man Mist machen, da sind wir uns wohl einig. Und wenn mit iD besonders viel Mist anfallen sollte (was ich jetzt nicht nachprüfe), dann liegt das natürlich nicht nur an diesem Editor an sich, sondern auch daran, dass davor überproportional viele unerfahrene Anwender sitzen – an der unterschiedlichen Userprofilen scheitert da die Vergleichbarkeit.

Aber gerade deshalb wäre es schön, wenn iD eher nur Grundfunktionalität böte, aber dafür narrensicher wäre und bei Geometriefehlern dieser Art konsequent warnte. ...

Das ist aber schlussendlich ein anderes Thema, es ist wirklich sehr schwierig ein OSM Editor "narrensicher" zu machen, nicht zuletzt weil so viel von der Semantik im Tagging steckt und man prinzipiell dies nicht vollständig erfassen kann (der Grund wieso JOSM ständig false positives bei unbekanntem Tagging auswirft). Oekonomisch ist dann auch noch die Frage wieviel mehr Geld man in so ein Tool reinstecken will und wann gut gut genug ist.

Automatisch erzeugte MPs, von denen der User "gar nichts erfahren muss", erzeugen dann vermutlich so Probleme wie oben auch beschrieben: pro inner eine eigene Relation.
Aber gut, wenn jetzt immerhin keine versehentlichen outer-Löschungen mehr möglich sind, ohne zumindest irgendeine Warnung oder Hinweis oder gar Upload-Blockade zu kriegen.

kreuzschnabel wrote:

Alternative: Nur vorgebildete Leute dürfen überhaupt mitmappen. Aber das bekommst du in so einem Projekt heute wirklich nicht mehr durch.

Will man das überhaupt "durchbekommen"? Ohne "Schwärme" funktionieren Schwarmprojekte nicht. Das sieht man bei Wikipedia - jede Menge Artikel wurden in der Anfangseuphorie angelegt, aber seit der "Professionalisierung" 2012/2013/2014... nicht mehr ernsthaft aktualisiert.
Im äußersten Nordosten wäre ich froh, wenn es Anfänger gäbe, die aus Vor-Ort-Betrachtung heraus wenigstens "highway=track" - ohne weitere Differenzierung! - durch die Wälder ziehen würden. Die wenigen "Berufsmapper" schaffen das nicht. So fehlt aber in manchen Wäldern über die Hälfte aller wander- und radfahrbaren Wege.

Auch wenn die Diskussion hier ein wenig abgeschweift ist in die alte Diskussion, ob ID oder JOSM besser sei, möchte ich auf das Ursprungsthema zurückkommen: Verbesserungsvorschläge ID

Ich fände gut, wenn man seine jeweils letzte Änderung rückgängig machen könnte. Es kommt immer wieder vor, dass man sich nach dem Klick auf "speichern" denkt - "ups, da habe ich gerade etwas falsch gemacht"

Ich habe festgestellt, das zum Beispiel Grenzsteine in memorial umgewandelt werden. Weiß jetzt nicht, ob es ein Bedienungsfehler ist.
Auch dürften nicht einfach Flächen über Flächen - z.B ein ein geschlossener way mit name=* - über eine landuse=meadow hochgeladen werden.

geri-oc wrote:

Ich habe festgestellt, das zum Beispiel Grenzsteine in memorial umgewandelt werden. Weiß jetzt nicht, ob es ein Bedienungsfehler ist.

Wie hast du das denn festgestellt? Bei der tag-Suche nach "Grenzstein" wird korrekt historic=boundary_stone vorgeschlagen.

Hallo Zusammen,

die iD - Entwickler sollten sich den Code noch mal anschauen. Diverse "Duplicate node in way" - Fehler werden meiner Meinung nach ausschließlich von iD produziert...

Sven

streckenkundler wrote:

Diverse "Duplicate node in way" - Fehler werden meiner Meinung nach ausschließlich von iD produziert...

Hmm, und wie begründest du deine Vermutung? Hast du mal nen Link zu einem entsprechenden Beispiel?

geow wrote:

geri-oc wrote:

Ich habe festgestellt, das zum Beispiel Grenzsteine in memorial umgewandelt werden. Weiß jetzt nicht, ob es ein Bedienungsfehler ist.

Wie hast du das denn festgestellt? Bei der tag-Suche nach "Grenzstein" wird korrekt historic=boundary_stone vorgeschlagen.

Ein neuer User hat mit iD Grenzsteine zu memorial umgewandelt. Deswegen kann es auch ein Auswahlfehler sein, er antwortet auf diese Frage aber nicht.

geow wrote:

streckenkundler wrote:

Diverse "Duplicate node in way" - Fehler werden meiner Meinung nach ausschließlich von iD produziert...

Hmm, und wie begründest du deine Vermutung? Hast du mal nen Link zu einem entsprechenden Beispiel?

der hier:

https://www.openstreetmap.org/node/4565 … 0/13.95069

OSMI: http://tools.geofabrik.de/osmi/?view=ge … ode_in_way

Soweit ich es beobachte waren das immer Edits von Usern, die überwiegend mit iD arbeiten.

Sven

streckenkundler wrote:

Hallo Zusammen,

die iD - Entwickler sollten sich den Code noch mal anschauen. Diverse "Duplicate node in way" - Fehler werden meiner Meinung nach ausschließlich von iD produziert...

Sven

Ist bei dem neuen User auch passiert - nahm an es ist ein Bedienfehler. Da der Validator das schnell löst, habe ich nicht bei den node darauf geachtet. Werde es beim nächsten Mal beobachten ...

geri-oc wrote:

Ein neuer User hat mit iD Grenzsteine zu memorial umgewandelt. Deswegen kann es auch ein Auswahlfehler sein, er antwortet auf diese Frage aber nicht.

Also an iD liegt's jedenfalls nicht, kannst du ja leicht selber ausprobieren. 😉

geow wrote:

streckenkundler wrote:

Diverse "Duplicate node in way" - Fehler werden meiner Meinung nach ausschließlich von iD produziert...

Hmm, und wie begründest du deine Vermutung?

Die Vermutung kann ich nur bestätigen. Praktisch alle "Doplicate node", bei denen ich nach der Quelle geschaut habe, wurden mit iD erzeugt. Jedenfalls kann ich mich eigentlich nicht an andere Editoren erinnern. Es scheint etwas Systematisches bei der Art der Benutzung zu sein, weil es immer von einzelnen Usern gleich massenhaft solche Fehler gibt - von Anderen iD-Vielnutzern gar keine. Ich tippe auf Doppelklick beim Zwischen-/Endpunkt-Setzen. Sehr häufig tritt der Fehler beim Zeichnen von Gebäuden auf oder beim Einfügen einer Brücke in einen Way.

Auch mit JOSM ist das anscheinend technisch möglich - aber dank Fehlermeldung innerhalb JOSM finden solche Daten in der Regel nicht den Weg in die Datenbank.

Mir ist aufgefallen, dass viele Wege und Flächen unsinnig detailreich gemappt sind. Das bringt niemanden was, sondern nur Datenmüll. Z.B. unwichtige Gebäude und Plantagen bzw. Wege mit tausend Punkten, wo auch einfach ein Dreieck oder eine gerade Linie reichen würde. Evtl. könnte man die Geometriefunktionen so einschränken, dass sie im technisch sinnvollen Rahmen bleiben?

Und eine äußert hilfreiche Funktion wäre eine Chancesethistory auf die man durch einfaches Klicken auf ein fehlerhaftes Objekt ansehen kann. Dort würde der verantwortliche User und alle seine Changesets angezeigt werden die man gleich mit kontrollieren kann. Dies könnte man dann validierten Mappern mitteilen und diese könnten dann diese Changesets wieder revertieren. Vermutlich gibt es die Funktion schon so ähnlich, aber auch ein unerfahrener User könnte so auf Trolle aufmerksam machen. Also so eine Art Trollalarm Button für Newbies :-) Was wird eigentlich mit identifizierten Trollen gemacht?

Ich glaube, wenn man so eine History möchte, sollte man sich langsam mit etwa JOSM anfreunden. Was die Geometrie angeht, denke ich, dass es weiterhin im Ermessen des Mappers liegen sollte, wieviele Punkte er zum Beispiel einer Kurve gibt. Was viele Punkte auf einer Geraden angeht, gibt es für JOSM ein passendes Plugin, wenn ich mich nicht falsch erinnere.

Unterm Strich würde zumindest ich es nicht für eine gute Idee halten, dem sowieso schon trägen und ressourcenfressenden JS-Editor noch mehr Funktionalität dranzuschrauben. Einerseits eben, weil’s technisch nicht ideal wäre, andererseits, weil‘s für die Hauptzielgruppe am besten so einfach und wenig komplex wie möglich gehalten werden sollte. Wer mehr will, für den steht andere Software zur Verfügung. Nur meine Ansicht ….

Automat7 wrote:

Mir ist aufgefallen, dass viele Wege und Flächen unsinnig detailreich gemappt sind. Das bringt niemanden was, sondern nur Datenmüll. Z.B. unwichtige Gebäude und Plantagen bzw.

Was wichtig oder unwichtig ist, bestimmt JEDER Mapper selbst. Ich finde, das sollte man neben "we map whats on the ground" als ergänzende Grundregel verbindlich einführen, damit nicht ständig dieser unselige Relevanzquatsch aufkommt. Wir sind - zum Glück - (noch) nicht Wikipedia.

Duplicate notes:
Könnte evt. in Zusammenhang mit den "fake inners" stehen, die bei ID so populär sind. Die doppelten Segmentlinien zwischen inner und outer sind ja unsichtbar, obwohl die inneren Nodes trotzdem mit dem outer verbunden bleiben, da übersieht man leicht mal was.

Tatsächlich ist mir sowas kürzlich mit Merkaartor passiert. Hab da an uralten Corine-Landuses rumeditiert und wollte zwei Flächen testweise mal halbautomatisch verschmelzen statt wie üblich alles einzeln von Hand umzustricken. Die gemeinsame Grenzlinie war aber nicht gerade gewesen, sondern verlief zickzack über mehrere Ecken, und mittendrin war glaub auch noch eine dritte Fläche als Lichtung gewesen. Ziemliches Durcheinander. Weiß auch nicht mehr, ob die ursprünglichen Nachbarflächen jeweils gemeinsame oder doppelte Nodes hatten, könnte auch eine Rolle spielen. Die fertig umgebauten Flächen sahen jedenfalls wieder normal aus. Erst bei der OSMI-Kontrolle am nächsten Tag gab es dann plötzlich mehrere Duplicate Notes mittendrin in der neuen Fläche: das waren die Überbleibsel von der zickzack-Naht, deren Nodes hingen noch ohne irgendwelche sichtbaren Verbindungslinien am outer! Nachdem OSMI das angezeigt hatte, konnt ich es dann auch im Editor erkennen, bei sehr genauem Hinsehen (Fazit: Flächen mit Zickzack-Naht automatisch zu verschmelzen ist eine ganz schlechte Idee ;-)

Kann man inzwischen mit dem ID ÖPV-Routen bearbeiten?

pyram wrote:

...

Die Vermutung kann ich nur bestätigen. Praktisch alle "Doplicate node", bei denen ich nach der Quelle geschaut habe, wurden mit iD erzeugt. ...

Die -wichtige- Frage ist natürlich mit welcher Version, wenn das aktuell oder auch noch mit 1.9.7 passierte, sollte das als Fehler gemeldet. IMHO wurde das vor ca. 2 Jahren behoben (ja, drum meldet man Fehler, auch JOSM vertauscht nicht mehr lat/lon).

MKnight wrote:

Automat7 wrote:

Mir ist aufgefallen, dass viele Wege und Flächen unsinnig detailreich gemappt sind. Das bringt niemanden was, sondern nur Datenmüll. Z.B. unwichtige Gebäude und Plantagen bzw.

Was wichtig oder unwichtig ist, bestimmt JEDER Mapper selbst. Ich finde, das sollte man neben "we map whats on the ground" als ergänzende Grundregel verbindlich einführen, damit nicht ständig dieser unselige Relevanzquatsch aufkommt. Wir sind - zum Glück - (noch) nicht Wikipedia.

Ja! Beispiel: Was (in "unserer" Region) wie ein unwichtiger kleiner Holzschuppen aussieht, kann mitunter ein historischer Speicher sein, der unter Baudenkmalschutz steht. Lieber Daten pflegen statt voreilig löschen!

SimonPoole wrote:

pyram wrote:

...

Die Vermutung kann ich nur bestätigen. Praktisch alle "Duplicate node", bei denen ich nach der Quelle geschaut habe, wurden mit iD erzeugt. ...

Die -wichtige- Frage ist natürlich mit welcher Version, wenn das aktuell oder auch noch mit 1.9.7 passierte, sollte das als Fehler gemeldet. IMHO wurde das vor ca. 2 Jahren behoben (ja, drum meldet man Fehler, auch JOSM vertauscht nicht mehr lat/lon).

mein Beispiel hier: https://forum.openstreetmap.org/viewtop … 09#p623809 war mit Version 2.0.1 und entstand vor wenigen Tagen. In dem Beispiel betrifft es einen simplen Feldweg.

pyram wrote:

Es scheint etwas Systematisches bei der Art der Benutzung zu sein, weil es immer von einzelnen Usern gleich massenhaft solche Fehler gibt - von Anderen iD-Vielnutzern gar keine.

Ja, so sehe ich das auch. Ich hab in meiner Nachbarschaft einen User, der ausschließlich iD nutzt. Es sind fast nie solche Fehler.

Daß aber nicht nur iD "Duplicate node" produziert, kann man sich in Polen anschauen...
http://tools.geofabrik.de/osmi/?view=ar … icate_node viele von JOSM, ich habe aber auch schon den OSM-Editor für ArcGis gesehen.

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.

Sven

Weide wrote:

Kann man inzwischen mit dem ID ÖPV-Routen bearbeiten?

Ja man kann. Kleinigkeiten eben nur.
Erstellen oder größere Änderungen kann ich nicht empfehlen. Da klickt man sich zu Tode.

Fehler hab ich bei kleinen Änderungen anschließend keine gefunden.

streckenkundler wrote:

Was mir noch fehlt, ist eine effiziente Funktion diese Fehler zu beseitigen.

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.

pyram wrote:

streckenkundler wrote:

Was mir noch fehlt, ist eine effiziente Funktion diese Fehler zu beseitigen.

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?

Sven

R0bst3r wrote:

Erstellen oder größere Änderungen kann ich nicht empfehlen. Da klickt man sich zu Tode.

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.

streckenkundler wrote:

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

pyram wrote:

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

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.

Automat7 wrote:

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

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 :-)

Automat7 wrote:

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.

Automat7 wrote:

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&l … 26&zoom=17. Ja, das sind OSM-Daten.

--ks

Automat7 wrote:

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

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

Automat7 wrote:

Vielen Dank, das war sehr ausführlich!

Du wirst also in Zukunft keine Wege mehr begradigen?

MKnight wrote:

Automat7 wrote:

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).

seichter wrote:

MKnight wrote:

Automat7 wrote:

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.

MKnight wrote:

seichter wrote:

MKnight wrote:

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

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 :-)

Automat7 wrote:

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

Also Problem entweder nicht verstanden oder beratungsresistent.

Automat7 wrote:

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

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.

Automat7 wrote:

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.

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 wrote:

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

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

MKnight wrote:

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

geow wrote:

Auf welchem Niveau wollen wir miteinander reden?

Von mir aus gerne auf diesem: https://forum.openstreetmap.org/viewtop … 11#p624711 ff.
Da kam nur leider keine erhellende Antwort(en).

MKnight wrote:

geow wrote:

Auf welchem Niveau wollen wir miteinander reden?

Von mir aus gerne auf diesem: https://forum.openstreetmap.org/viewtop … 11#p624711 ff.
Da kam nur leider keine erhellende Antwort(en).

Ich dachte eher an dieses Niveau - ein Beispiel wie man einem Newbie, der nahe liegende Fragen hat, konstruktiv unterstützen kann:
https://forum.openstreetmap.org/viewtop … 16#p624716

BTW, wusstest du, dass die Anzahl und Produktivität der deutschen OSM-Mapper abnimmt - über die Gründe kann man sicher trefflich spekulieren

Quelle: http://osmstats.neis-one.org/?item=coun … ry=Germany

edit: Quelle ergänzt

geow wrote:

wusstest du, dass die Anzahl und Produktivität der deutschen OSM-Mapper abnimmt - über die Gründe kann man sicher trefflich spekulieren

Ein Grund könnte sein, dass Deutschland ziemlich gesättigt ist mit Mapping. Das Wegenetz dürfte einigermaßen vollständig sein, was fehlt, sind Flächen und POIs. Und die sind nicht so attraktiv :-)

Im Vereinigten Königreich ist noch deutlich mehr zu tun, auch am Straßennetz, deshalb sieht man mich da auch öfters. Soweit ich mich halbwegs auskenne.

--ks

Intelligentes Trackloeschen etc waer auch nett. Da sind manchmal Dreiecke von Tracks, wo man einen der Dreiecksschenkel loeschen will. Das geht im online editor nicht .. selbst wenn dieser schenkel schoen isoliert anwaehlbar ist. JOSM loescht sowas ohne probleme.

Voonosm wrote:

Intelligentes Trackloeschen etc waer auch nett. Da sind manchmal Dreiecke von Tracks, wo man einen der Dreiecksschenkel loeschen will. Das geht im online editor nicht .. selbst wenn dieser schenkel schoen isoliert anwaehlbar ist. JOSM loescht sowas ohne probleme.

Kannst du der Gemeinde mal darlegen, was genau du mit „intelligentem Löschen“ meinst? Beziehungsweise mit diesen Dreiecken? Prinzipiell wird nur gelöscht, was fehlerhaft in der Datenbank ist (also entweder falsch gemappt wurde oder mittlerweile nicht mehr existiert), und die einzige Intelligenz, die dazu zwingend erforderlich ist, sitzt einen halben Meter vor dem Monitor und nicht in der Software.

--ks

kreuzschnabel wrote:

geow wrote:
wusstest du, dass die Anzahl und Produktivität der deutschen OSM-Mapper abnimmt - über die Gründe kann man sicher trefflich spekulieren
Ein Grund könnte sein, dass Deutschland ziemlich gesättigt ist mit Mapping. Das Wegenetz dürfte einigermaßen vollständig sein, was fehlt, sind Flächen und POIs. Und die sind nicht so attraktiv :-)

Ja, die Gründe sind sicher vielfältig und das wär vermutlich ein spannendes Thema für eine Bachelor- oder sogar Masterarbeit. Mir ist nur aufgefallen, dass viele vergleichbare Länder in Mitteleuropa stabile Mapperzahlen haben. In Länder, die sich aktiv um die Integration von Newbies kümmern, wie Belgien oder Spanien, ist der Trend sogar leicht steigend.

geow wrote:

kreuzschnabel wrote:

Das Wegenetz dürfte einigermaßen vollständig sein, was fehlt, sind Flächen und POIs. Und die sind nicht so attraktiv :-)

Mir ist nur aufgefallen, dass viele vergleichbare Länder in Mitteleuropa stabile Mapperzahlen haben.

Nicht alles was hinkt ist ein Vergleich. Ich hab mir ja verkniffen auf Deinen indirekten Anpiss zu reagieren aber hier zeigt sich deutlich, dass Du weder mit Statistik umgehen kannst, noch des sinnentnehmenden Lesens kundig bist. Und jetzt kommste mit "vergleichbar"? Merkste selbst?

P.s. Mir ist bewusst, dass das wieder auf mein Arschlochkonto geht, aber so einen insistierenden Quatsch möchte ich dann doch nicht unkommentiert stehen lassen.

Edit zur Güte: Wo nimmst Du denn die "stabilen Mapperzahlen" her?

Nachtrag 2:

geow wrote:

BTW, wusstest du, dass die Anzahl und Produktivität der deutschen OSM-Mapper abnimmt
http://up.picr.de/27913571bx.jpg

Ich kann diesen Statistiken nicht entnehmen, dass die Produktivität der deutschen Mapper abnimmt.

MKnight wrote:

Ich hab mir ja verkniffen auf Deinen indirekten Anpiss zu reagieren aber hier zeigt sich deutlich, dass Du weder mit Statistik umgehen kannst, noch des sinnentnehmenden Lesens kundig bist ...
P.s. Mir ist bewusst, dass das wieder auf mein Arschlochkonto geht, aber so einen insistierenden Quatsch möchte ich dann doch nicht unkommentiert stehen lassen.

Lieber MKnight, OpenStreetMap ist ein Gemeinschaftsprojekt, wir müssen kooperieren, wenn wir die beste Geodatenbank der Welt schaffen wollen. Beleidigungen, Beschimpfungen, Zynismus und Polemik sind extrem ungeeignet um gewünschte Ziel zu erreichen.

Respekt, Freundlichkeit und Höflichkeit erleichtern die Zusammenarbeit dagegen ungemein.

geow

PS: Deine fachlichen Beiträge für OSM sind unbestritten wertvoll und natürlich auch weiterhin willkommen.

Hallo Zusammen,

Ich finde dieses etwas andere Konzept mit den halbkreisartigen Funktionsmenü zur Bearbeitung von Objekten beim Standard-iD-Editor gar nicht so schlecht, speziell für einfache Aufgaben. Für Neustarter wird dieses Konzept u.U. eher angenommen und ist ggf. besser geeignet als die grössere Anzahl der Menü’s und Abkürzungsschnelltasten beim JSOM. Die Benutzung der Editor-Variante hängt vielleicht auch davon ab wer welchen Anwendungsfall gerade erledigen möchte:
a) für ein Gemeindemitglied welches gerne Qualitätssicherung betreibt, ist für einen bestimmten Arbeitsgang JOSM toll, wenn mal diesen bestimmten Arbeitsgang dann einfach durch Speziallfunktionen/-werkzeugen erledigen kann
b) für ein Gemeindemitglied welches mal zu Beginn den weißen Fleck am Heimatort eliminieren möchte, und dafür intuitive universelle Generalfunktionen benutzen möchte (und sich nicht erst mit dem „Kartenabschnitts-down-und-upload“ Konzept des JOSM’s kümmern möchte) freut sich über die reduzierte Menüauswahl, die der iD-Editor bietet

Nebenbei, gibt es zufällig eine treffendere Bezeichnung für dieses „halbkreisartige Funktionsmenü“ beim iD-Editor? (etwa Headsupdisplay?)
Ein Verhalten stört mich ab und zu an diesem Menü. Und zwar taucht es manchmal exakt über dem Koordinatenpunkt auf, den man im nächsten Arbeitsschritt markieren/bearbeiten möchte.
Also der gewünschte zu bearbeitende Koordinatenpunkt wird dann vom Menü verdeckt, und man muss z.B. die Fläche an einer weiter entfernten Position vom Punkt nochmals anklicken/markieren, um das Menü nachträglich an anderer xy-Position erscheinen zu lassen.

Also Beispiel, verschiedene Flächen (landuses) sind miteinander verklebt, z.B. 3 Flächen treffen sich dann einer gemeinsamen Koordinate. Also liegen dort 3 verklebte Punkte übereinander? Wenn man eine der 3 Flächen verschieben/editieren möchte, würde ich zunächst die 3 verklebten Punkte voneinander lösen. Dafür würde ich den Punkt markieren, um das Menü („Trenne diese Wege/Flächen“ Tastenkürzel: D. Also den Knopf mit dem Icon welches einen links und einen rechts gerichteten Pfeile darstellt) anzeigen zu lassen. Bevor man aber den verklebten Punkt markieren kann ,um das Menü zu sehen, ist es notwendig eine der 3 Flächen zu markieren, nämlich erst dann werden die einzelnen Punkte sichtbar. Wenn man nun die Aktion „Fläche markieren/auswählen“ an einer ungünstigen Stelle durchführt, poppt das halbkreisartigen Funktionsmenü genau über dem Punkt auf. Daher kann man nun den Punkt nicht durch den direkt nächsten Klick markieren, um das gewünschte Menü „Trenne diese Wege/Flächen“ zu sehen. Falls ungenau beschrieben, bitte gerne mal nachhaken.

Ist dieser Umstand zufällig auch schon mal jemand aufgefallen?
Falls ja, wie würden denn Eurer Meinung nach zu diesem Fall die eventuellen Verbesserungsvorschläge lauten?

Achso, mal ab vom Thema (OT):

geow wrote:

... Mir ist nur aufgefallen, dass viele vergleichbare Länder in Mitteleuropa stabile Mapperzahlen haben. In Länder, die sich aktiv um die Integration von Newbies kümmern, wie Belgien oder Spanien ...

Hallo geow, wie wird die Integration der Neustarter in Belgien und Spanien im Detail umgesetzt?

Viele Grüsse
AB

edit: ein überflüssiges "zu" entfernt.

geow wrote:

OpenStreetMap ist ein Gemeinschaftsprojekt, wir müssen kooperieren, wenn wir die beste Geodatenbank der Welt schaffen wollen. Beleidigungen, Beschimpfungen, Zynismus und Polemik sind extrem ungeeignet um gewünschte Ziel zu erreichen.

Full ack. (Bisschen untergegangen ist leider, dass Löschen oder "Geradebiegen" von ("Detail"-)Daten anderer auch "nich so prall" is, aber belassen wir es dabei)
Kooperation finde ich gut. Man könnte bspw. Detailmapper fragen, ob die das gut finden, dass ihre Eintragungen dedetailliert werden.

AB-inf-x-chg-AB wrote:

Hallo Zusammen,

Ich finde dieses etwas andere Konzept mit den halbkreisartigen Funktionsmenü zur Bearbeitung von Objekten beim Standard-iD-Editor gar nicht so schlecht, speziell für einfache Aufgaben. Für Neustarter wird dieses Konzept u.U. eher angenommen und ist ggf. besser geeignet als die grössere Anzahl der Menü’s und Abkürzungsschnelltasten beim JSOM.

Stimmt, aber:
in Josm muss man die "Schnelltasten" nur für die persönlichen Vorlieben lernen. In iD geht das So nicht.
Id hat, was hier noch nicht besprochen wurde neben den (besprochenen) Pseudovorteilen jede Menge Nachteile. Der Schlimmste: es gibt keine Validierung.
Auf Deutsch: Ich kann in iD jeden erdenklichen Müll in die DB kippen. das geht in Josm auch aber ich bekomme da halbwegs aussagekräftige Fehlermeldungen.
In Josm kann man das als Arschloch ignorieren, in iD merkt man garnich, was man für einen Scheissdreck hochlädt.

AB-inf-x-chg-AB wrote:

Hallo geow, wie wird die Integration der Neustarter in Belgien und Spanien im Detail umgesetzt?

Es gibt Portale um neue Mapper zu begrüßen:
https://welcome.osm.be/
http://bienvenida.openstreetmap.es

Viele weitere Details und Ideen zum Aufbau lokaler/regionaler Gruppen finden sich in einem Blogpost von Joost Schouppe
http://www.openstreetmap.org/user/joost … iary/39876

MKnight wrote:

in Josm muss man die "Schnelltasten" nur für die persönlichen Vorlieben lernen. In iD geht das So nicht.

Geht in iD natürlich auch: Tastaturkürzel sind seit vielen Jahren hier beschrieben: http://wiki.openstreetmap.org/wiki/DE:ID/Shortcuts

MKnight wrote:

...
Id hat, was hier noch nicht besprochen wurde neben den (besprochenen) Pseudovorteilen jede Menge Nachteile. Der Schlimmste: es gibt keine Validierung.
Auf Deutsch: Ich kann in iD jeden erdenklichen Müll in die DB kippen. das geht in Josm auch aber ich bekomme da halbwegs aussagekräftige Fehlermeldungen.
In Josm kann man das als Arschloch ignorieren, in iD merkt man garnich, was man für einen Scheissdreck hochlädt.

Das ist ein/dein Fehlschluss. Der Ansatz in JOSM, nachträgliche Validierung, ist nur eine von mehreren Wegen wie man Datenfehler verhindern kann, so kann man man z.B. Aktionen gar nicht erst zulassen die ungültige Daten produzieren oder unmittelbar wenn eine Aktion ausgeführt wird auf ein Problem aufmerksam machen.

geow wrote:

MKnight wrote:

in Josm muss man die "Schnelltasten" nur für die persönlichen Vorlieben lernen. In iD geht das So nicht.

Geht in iD natürlich auch: Tastaturkürzel sind seit vielen Jahren hier beschrieben: http://wiki.openstreetmap.org/wiki/DE:ID/Shortcuts

Ok, is mir noch nich untergekommen. (Mglw. da "Shortcuts" im Browser eh anders (mit Suche) belegt sind.) Nehme alles zurück und behaupte das Gegenteil. Moment: Shortcuts löschen/ändern ... jaja bin schon still.

Simompoole: mir ist klar, dass mit iD diverse Dinge nicht kaputtzumachen sind. Das liegt aber imho da nicht an QA sondern an fehlender Funktionalität.
Gegeben sei bspw. der Fall Strassen zu begradigen. Ich bezweifle, dass iD da bei unterschiedlichen Werten das aus QA/Fehlergründen unterbindet, sondern einfach aus Komplexiität (Faulheit auf deutsch). (Oder eben aus Mangel an QA-Prüfung, was ich aber bezweifle)

SimonPoole wrote:

...

Das ist ein/dein Fehlschluss. Der Ansatz in JOSM, nachträgliche Validierung, ist nur eine von mehreren Wegen wie man Datenfehler verhindern kann, so kann man man z.B. Aktionen gar nicht erst zulassen die ungültige Daten produzieren oder unmittelbar wenn eine Aktion ausgeführt wird auf ein Problem aufmerksam machen.

Zwei Wege übereinander ohne gemeinsamen node ...
Bach über Straße ...
Zwei Straßen übereinander ...

geri-oc wrote:

SimonPoole wrote:

...

Das ist ein/dein Fehlschluss. Der Ansatz in JOSM, nachträgliche Validierung, ist nur eine von mehreren Wegen wie man Datenfehler verhindern kann, so kann man man z.B. Aktionen gar nicht erst zulassen die ungültige Daten produzieren oder unmittelbar wenn eine Aktion ausgeführt wird auf ein Problem aufmerksam machen.

Zwei Wege übereinander ohne gemeinsamen node ...
Bach über Straße ...
Zwei Straßen übereinander ...

Wieso sollte man das nicht beim Einzeichnen abfangen können?

SimonPoole wrote:

geri-oc wrote:

SimonPoole wrote:

...

Das ist ein/dein Fehlschluss. Der Ansatz in JOSM, nachträgliche Validierung, ist nur eine von mehreren Wegen wie man Datenfehler verhindern kann, so kann man man z.B. Aktionen gar nicht erst zulassen die ungültige Daten produzieren oder unmittelbar wenn eine Aktion ausgeführt wird auf ein Problem aufmerksam machen.

Zwei Wege übereinander ohne gemeinsamen node ...
Bach über Straße ...
Zwei Straßen übereinander ...

Wieso sollte man das nicht beim Einzeichnen abfangen können?

Wird aber bei iD nicht gemacht und hochgeladen.
Eine Straße durchs Haus wird angemeckert - was ja richtig ist.

MKnight wrote:

..

Simompoole: mir ist klar, dass mit iD diverse Dinge nicht kaputtzumachen sind. Das liegt aber imho da nicht an QA sondern an fehlender Funktionalität.
Gegeben sei bspw. der Fall Strassen zu begradigen. Ich bezweifle, dass iD da bei unterschiedlichen Werten das aus QA/Fehlergründen unterbindet, sondern einfach aus Komplexiität (Faulheit auf deutsch). (Oder eben aus Mangel an QA-Prüfung, was ich aber bezweifle)

Die Begradigungsfunktion wird nur angeboten (expliziter Test) wenn der Weg nicht geschlossen und einigermassen gerade ist. Ähnliche Tests hats bei diversen anderen Operationen.

geri-oc wrote:

SimonPoole wrote:

geri-oc wrote:

Zwei Wege übereinander ohne gemeinsamen node ...
Bach über Straße ...
Zwei Straßen übereinander ...

Wieso sollte man das nicht beim Einzeichnen abfangen können?

Wird aber bei iD nicht gemacht und hochgeladen.
Eine Straße durchs Haus wird angemeckert - was ja richtig ist.

Und? Ich hab ja auch nicht behauptet das iD das macht. Es ging nur drum, dass die nachträgliche Validierung a la JOSM nicht der einziger oder bester Weg ist Fehler zu vermeiden.

Zur Vermeidung aufeinander folgende doppelte Knoten (bei gleicher Id) in Wegen ist etwas in Arbeit (https://github.com/openstreetmap/iD/pull/3676).

Wenn ein derartiger Knoten in einem QA-Tool auftaucht, sollte dieser durch Einfügen eines zusätzlichen Knotens in den Weg per Doppelklick und anschließendes Löschen des neu eingefügten Knotens auch mit iD zu beheben sein.

Der Fall, dass sich zwei verschiedene Nodes an gleicher Position befinden, scheint mir aber nicht grundsätzlich falsch zu sein und dürfte damit auch schlecht zu verhindern sein.

Derartige doppelte Knoten sollte man mit iD auseinandeziehen können. Falls gewünscht kann man sie anschließend wieder übereinanderschieben, um sie automatisch zu einem gemeinsamen Knoten zu vereinen.

AB-inf-x-chg-AB wrote:

Also der gewünschte zu bearbeitende Koordinatenpunkt wird dann vom Menü verdeckt, und man muss z.B. die Fläche an einer weiter entfernten Position vom Punkt nochmals anklicken/markieren, um das Menü nachträglich an anderer xy-Position erscheinen zu lassen.

Man kann mit der Leertaste das Menü aus- und einschalten. Das ringförmige Menü wird aber wohl ohnehin bald ersetzt (https://github.com/openstreetmap/iD/issues/3671).

AB-inf-x-chg-AB wrote:

Also Beispiel, verschiedene Flächen (landuses) sind miteinander verklebt, z.B. 3 Flächen treffen sich dann einer gemeinsamen Koordinate. Also liegen dort 3 verklebte Punkte übereinander?

Das ist nur ein gemeinsamer Node.

SimonPoole wrote:

Wieso sollte man das nicht beim Einzeichnen abfangen können?

Weil es ein Fehler wäre, dass zu tun. Es wurde ja nur ein innerer Widerspruch zwischen den Daten festgestellt. Welche der Angaben falsch ist, ist nicht feststellbar.

Es gibt kein Naturgesetz, dass eine Veränderung von einem widerspruchsfreien Zustand der Daten in einen anderen widerspruchsfreien Zustand der Daten ohne fehlerhafte Zwischenzustände möglich sein muss. Z.B. kann ein Node in PTv2-Relationen nicht mal mit der Rolle "stop" und mal mit der Rolle "platform" auftreten (dann würden Passagiere überfahren). Wenn er jetzt in drei Relationen mit "stop" auftaucht und "platform" ist richtig, dann muss man das ändern können und der Editor darf einen nicht daran hindern.

Weide

Weide wrote:

SimonPoole wrote:

Wieso sollte man das nicht beim Einzeichnen abfangen können?

Weil es ein Fehler wäre, dass zu tun. Es wurde ja nur ein innerer Widerspruch zwischen den Daten festgestellt. Welche der Angaben falsch ist, ist nicht feststellbar.

Es gibt kein Naturgesetz, dass eine Veränderung von einem widerspruchsfreien Zustand der Daten in einen anderen widerspruchsfreien Zustand der Daten ohne fehlerhafte Zwischenzustände möglich sein muss. Z.B. kann ein Node in PTv2-Relationen nicht mal mit der Rolle "stop" und mal mit der Rolle "platform" auftreten (dann würden Passagiere überfahren). Wenn er jetzt in drei Relationen mit "stop" auftaucht und "platform" ist richtig, dann muss man das ändern können und der Editor darf einen nicht daran hindern.

Weide

Du hast natürlich Recht, aber man muss ja den Zwischenzustand nicht verhindern, sondern man kann eine entsprechende Warnung oder andere Massnahme ergreifen um den User auf ein potentielles Problem aufmerksam zu machen. Z.B. könnte man einen Kreuungspunkt ohne verbundenen Knoten highlighten oder was anderes Sinnvolles.

SimonPoole wrote:

Es ging nur drum, dass die nachträgliche Validierung a la JOSM nicht der einziger oder bester Weg ist Fehler zu vermeiden.

Daß diese Validierung in Josm automatisch erst direkt vor dem Upload erfolgt - und auf Wunsch auch früher und vollständiger - erscheint mir allerdings als die bessere Lösung. Ich erstelle z.B. öfters mal Hilfskonstrukte, die ich vor dem Upload wieder lösche. Wenn mir dann ein Live-Validator jedesmal auf die Finger hauen würde, wäre ich stark genervt.

Und Live-Warnungen kommen von Josm auch (z.b. wenn z.B. Member einer Relation gelöscht werden sollen).

Die Validierung in iD ist immer noch erschreckend schwach:

$␣more␣iD/modules/validations/index.js
export␣{␣validationDeprecatedTag␣}␣from␣'./deprecated_tag';
export␣{␣validationManyDeletions␣}␣from␣'./many_deletions';
export␣{␣validationMissingTag␣}␣from␣'./missing_tag';
export␣{␣validationTagSuggestsArea␣}␣from␣'./tag_suggests_area';

Inzwischen 4 (vier!) Validationsmodule der simpelsten Art, das bringt es natürlich ;(

Gruss
walter

Mehr ist in Arbeit - nachdem kürzlich ein Newbie 30 Minuten nach der Registrierung (versehentlich) den Michigan Lake zerschossen hat. 🙄 Hoffentlich wird da jetzt nicht überzogen.

https://github.com/openstreetmap/iD/issues/3681

slhh wrote:

AB-inf-x-chg-AB wrote:

Also der gewünschte zu bearbeitende Koordinatenpunkt wird dann vom Menü verdeckt, und man muss z.B. die Fläche an einer weiter entfernten Position vom Punkt nochmals anklicken/markieren, um das Menü nachträglich an anderer xy-Position erscheinen zu lassen.

Man kann mit der Leertaste das Menü aus- und einschalten. Das ringförmige Menü wird aber wohl ohnehin bald ersetzt (https://github.com/openstreetmap/iD/issues/3671).

Danke für den Tipp, dies hilft etwas bei diesen Fall :-)

Hallo,

Es gab heute ein ziemlich großes Update für den Editor. Es wurde zwar vor allem das Aussehen verändert, aber ich hab auch schon ein paar kleine neue Funktionen gefunden, z.B. kann man jetzt Objekte spiegeln. Weiß jemand, wo man einen vollen Changelog finden kann?

doktorpixel14 wrote:

Weiß jemand, wo man einen vollen Changelog finden kann?

https://github.com/openstreetmap/iD/blo … ANGELOG.md

irgendwie scheint der ID mir nicht mehr hochgeladene Tracks anzuzeigen :-(

Ich bin aktuell praktisch lahm gelegt beim mapen, hatte heute Morgen beim Joggen einen Track aufgezeichnet, sogar einige Waypoints gesetzt um z.B. Sitzbänke einzuzeichnen und habe den Track hochgeladen und sehe ihn aber nicht, wenn ich ihn versuche in der Karte anzeigen zu lassen. sonst wurde ein solche Track dann als pinke Linie, Waypoints als pinke Kreise angezeigt. Wenn jemand helfen kann - herzlich gerne!

@Galbinus
Hast du bei den Hintergrundeinstellungen OpenSteetMap GPS traces aktiviert? Damit werden bei mir zumindest Tracks angezeigt, wobei ich aber nicht geprüft habe, aus welcher Quelle die stammen.

Galbinus wrote:

und habe den Track hochgeladen und sehe ihn aber nicht, wenn ich ihn versuche in der Karte anzeigen zu lassen. sonst wurde ein solche Track dann als pinke Linie, Waypoints als pinke Kreise angezeigt.

Genau wie in JOSM gibt es auch in iD zwei Möglichkeiten GPS-Daten zu verwenden: (a) lokal von deinem Computer oder (b) aus der OSM-GPS-Datenbank.

iD Hilfe wrote:

Um einen GPS-Track fürs Mapping zu verwenden, ziehe ihn einfach in den Karteneditor. Wenn er erkannt wurde, wird der Track als hell-lila Linie auf der Karte dargestellt. Klicke auf das „Kartendaten“-Menu rechts, um die neue Ebene mit dem Track zu aktivieren/deaktivieren oder zoome zum Gebiet des Tracks.

Das funktioniert wie bisher auch in v2.10 einwandfrei, überprüfe evtl. die GPX-Datei, falls es nicht klappt.

iD Hilfe wrote:

Der GPX-Track wird nicht automatisch direkt zu OpenStreetMap hochgeladen.... Möchtest du den GPX-Track jedem zugänglich machen, kannst du ihn nach OpenStreetMap hochladen.

Das läuft über deine Profilseite mit http://www.openstreetmap.org/trace/create
Wenn du den Track nach osm.org hochgeladen hast, musst du vermutlich einige Zeit warten, bis das Layer aktualisiert wurde. Außerdem werden in diesem Layer m.W. nur GPS-Spuren angezeigt, die nicht als "private" gekennzeichnet sind.

Hm - das mit dem reinziehen verstehe ich nicht. Aber das wäre dann genau das, was ich bräuchte.

Daran, das mein Track fehlerhaft sein könnte, kann es nicht liegen, da es mit meinen zu früheren Zeiten hochgeladenen Tracks, die ich früher anzeigen lassen konnte, nun auch nicht mehr geht.

Bleibt noch der unterschied privat oder öffentlich. Alle meine bisherigen Tracks waren privat. Jetzt habe ich den Track von gestern nochmal als öffentlichen Track hochgeladen. Den kann ich jetzt sehen, wenn ich auswähle, dass GPS-Traces angezeigt werden sollen. Allerdings sehe ich dann alle Tracks, die irgendjemand zu irgendeinem Zeitpunkt mal öffentlich hochgeladen hat. Da ist es schwierig, den eigenen zu identifizieren,

Galbinus wrote:

Hm - das mit dem reinziehen verstehe ich nicht. Aber das wäre dann genau das, was ich bräuchte.

Mit der linken Maustaste die gpx-Datei im Explorer anfassen, auf die Oberfläche des iD-Editor ziehen und loslassen, auf neudeutsch auch drag & drop genannt. https://de.wikipedia.org/wiki/Drag_and_ … rop-de.svg

Oder der andere Weg: in iD im rechten Menu "Kartendaten" lokale Datei -> eine Datei laden -> gpx-Datei im Explorer auswählen.

geow wrote:

Mit der linken Maustaste die gpx-Datei im Explorer anfassen, auf die Oberfläche des iD-Editor ziehen und loslassen

Irgendwas habe ich wohl gestern bei den ersten Versuchen falsch gemacht, obwohl ich eigentlich weiß, was drag&drop ist. Jetzt bekomme ich es hin. Vielen Dank. Damit kann ich jetzt jedenfalls gut arbeiten.