OpenStreetMap Forum

Als ich das gerade mit Ubuntu 12.04 probiert habe, hat es geklappt. Das erste mal habe ich ein HTTP 500 Fehler von naturalearthdata bekommen, aber danach ging es.

Welche Version von Ubuntu verwendest du?

Nein, die Diskussion, das alles ausser JOSM nur ein Spielzeug ist bringt uns wirklich nicht weiter. ( Ich verwende in den meisten faellen P2 da das fuer das meiste ausreicht und imho einfacher ist mal schnell was zu verbessern als JOSM zu starten und damit zu hantieren. )

Was hingegen wirklich helfen wuerde, waere empirische Daten zu erheben wie die echte Neulige auf iD und P2 reagieren und welches ihnen lieber ist, intuitiver erscheint, und womit sie weniger Fehler machen. Man koennte das entweder in Labor versuchen machen, welches deutlich detailiertere Ergebnisse liefert, dafuer aber weniger umfangreich und wesentlich aufwendiger waere, oder man probiert aus iD fuer X prozenet der Neulige als default zu setzen und fuehrt dann eine statistische Auswertung durch, welcher Editor besser angenommen wird und ob welcher mehr Fehler provoziert.

Die Entwicklung von iD war zwar keine Auftragsarbeit und somit nicht eine Entscheidung der OSMF, aber die Erhebung von iD zum default editor auf osm.org ist sehr wohl eine "strategische Entscheidung" der OSMF (oder zumindestens sollte eine sein).

Insofern muss sich die OSMF bei dieser Entscheidung sehr genau ueberlegen auf welchen Browsern und Betriebsystemen es gut laeuft und wie viele User dadurch moeglicherweise "verprellt" werden. Wobei man es immer relativ zum jetztigen Status sehen muss, der auch nicht ideal ist. Allerdings (Uebertrieben gesprochen), die Notwendigkeit sich einen schnelleren Computer anzuschaffen, einen anderen Browser zu verwenden, und moeglicherweise das Betriebsystem zu wechsel, faellt auch nicht gerade unter "Einsteiger freundlich" welches sich iD auf die Fahne schreibt... ;-)

Nein, MapBox kann man das nicht (unbedingt) vorwerfen, aber die OSMF hat dann das Recht (und moeglicherweise auch die Pflicht), eben zu sagen das es noch nicht so weit ist iD zum default editor auf osm.org zu machen. Diese Entscheidung muss sehr behutsam gemacht werden.

Wenn ich mich nicht taeusche, war es geplant iD sofort zum Standard editor zu machen. Es stand sogar so im offiziellen OSMF blog am 7ten May: "From later today, new OpenStreetMap users with a modern browser will automatically use the new iD editor", wobei das wohl ein Versehen war und nicht so im Blog stehen sollte. Es gibt auch einen entsprechenden pull request von MapBox um iD zum default zu machen ( https://github.com/openstreetmap/openst … e/pull/262 ) in dem eigentlich nur woodpeck gegen das direkte mergen war.

Insgesamt hat iD denke ich viel Potential und viele Sachen sind schon recht gut geloest, insofern bin ich der Meinung das die Entscheidung iD als weitere Option auf osm.org anzubieten gerechtfertigt war. Ich hoffe mal das die ausstehenden Probleme auch demnaechst geloest werden koennen und somit iD tatsaechlich zum default Editor aufsteigen kann. Man muss schliesslich bedenken, das das Perfekte nicht zum Feind vom Guten wird und somit sich nichts verbessert.

Was genau funktioniert denn nicht? Welche URL gibt die HTTP 500 Fehler zurueck?

Aber wenn es seit 2 Tagen kontinuierlich nicht funktioniert, dann klingt das nach einem Bug der gefixt werden muss / sollte.

Zumindestens den Tileserver Teil kann man sehr leicht selbst einrichten und wenn man nur einen kleinen Teil der Welt, wie z.B. Australien rendern will, sind die benoetigten Serverresourcen auch recht moderat.

Es gibt dafuer eine Anleitung auf http://switch2osm.org/serving-tiles/bui … -packages/ mit der man auf einem Ubuntu Server mit wenigen Befehlen seinen eigenen Kachelserver einrichten kann.

Fuer die Frontend Anbindung gibt es ebenfalls sehr leicht verstaendliche Beispiele die man einfach Kopieren kann mit ein paar Anpassungen an die eigenen Gegebenheiten.

Wenn man die Tiles erst einmal hat, darf man damit machen was man will. Die offene Lizenz erlaubt nicht nur den privaten Gebrauch, sondern auch ausdruecklich den kommerziellen und jeden anderen Gebrauch auch.

Allerdings, kann jeder Serverbetreiber Beschraenkungen auferledgen wie viel man die Server verwenden kann. Er kann zum Beispiel das ganze hinter ein Passwort verstecken, oder entscheiden das man nach X Aufrufen nur noch eine Fehlermeldung bekommt. Die Beschraenkungen des OpenStreetMap tile servers ist wie oben erwaehnt in der tile usage policy beschrieben. Im Prinzip Begraentzt sie nur die Menge die man verwenden darf, nicht deren Verwendungszweck.

OpenStreetMap versucht das die gerenderten Kartendaten, so leicht zugaenglich sind wie moeglich. Allerdings hat OSM kein milliarden Budget um x beliebig viele Server zu betreiben, sondern nur ein sehr sehr begrenztes Budget. Insofern sind die Serverresourcen recht limitiert. Desshalb muss OSM Begrenzungen einfuehren um den Betrieb generell aufrecht zu erhalten. Dabei hat sich OSM entschieden das grossflaechige Herunterladen von Gebieten zu limitieren, da bei dieser Methode ein Grossteil der Daten nie angesehen werden (man laed ja einfach alles herunter damit man es hat falls man es doch mal benoetigt). Es ist also ein recht ineffiziente Art des Resourcenverbrauchs.

Dank einiger grosszuegiger Spenden von einigen Hosting betreibern hat OSM in letzter Zeit die Tileserverkapazitaet deutlich ausbauen koennen und somit das Problem etwas entschaerfen koennen. Somit ist das reine Ausliefern der Tiles derzeit weniger ein Problem. Allerdings wird das rendern der Tiles nachwievor von nur einem einzelnen (inzwischen aelterem) Server erledigt (die anderen sind reine caching Server) der inzwischen wieder an seine Grenzen zu stossen beginnt.

Die Art und Weise wie das System technisch funktioniert, bedingt aber wiederum das das grossflaechige Herunterladen (im Gegensatz zum gezielten Betrachten der relevanten Gebiete) besonders den einen rendering server belastet und somit leider limitiert werden muss.

Es gibt aber zum Glueck einige Alternativen wie man dennoch offline Karten bekommen kann. Unter anderem hat man immer die Moeglichkeit die Karten selbst aus den Rohdaten zu errechnen.

Werden die Relationen tatsaechlich zerstoert? Soweit ich weis hat iD einiges and Logik im Hintergrund um mit den Relationen sinnvoll umzugehen und je nach Typ und Editiervorgang automatisch das korrekte zu tun. Wenn das mit den standard Relationen wie routen, multipolygonen und Abbiegebeschraenkungen nicht funktioniert, dann muss das dringen gefixt werden. Falls ihr also konkrete Beispiele habt wo iD das falsche macht, bitte hier oder im issue tracker auf github berichten.

Gluecklich bin ich zwar auch nicht direckt darueber das Relationen komplett versteckt werden, da es wohl immer Faelle geben wird wo die automatik versagt. Allerdings muss man auch bedenken das Neueinsteiger auch haeufiger mal bereits jetzt Relationen kaputt machen, da sie sie nicht verstehen. Insofern ist die Frage nicht ob iD gelegentlich Relationen zerstoert, sonder ob dank der Automatik und der versteckten Komplexitaet weniger kaputt geht, oder eben doch mehr. Das wird man sehr vorsichtig beobachten muessen und gegebenenfalls nachbessern.

Als erfahrene Mapper ist es manchmal schwer sich in Neueinsteiger zu versetzen und wie diese an Probleme herangehen, bzw wie sie OSM verstehen. Vielleicht ist von den $500k noch etwas fuer richtige usability studies uebrig um diese Fragen mal systematisch zu erforschen.

Es wird gerade darueber diskutiert den Editor sehr bald als default editor zu nehmen (moeglicherweise noch Heute, nicht ganz klar) und P2 als solchen zu ersetzen. Insofern werden alle Neueinsteiger dann iD verwenden.

Insofern sollte man sich den vermutlich mal genauer anschauen... ;-) Bin ich aber bislang auch noch nicht dazu gekommen.

Der Pull request fing an bezueglich des Textes im "Add a Note"-Fenster, aber in dem Zusammenhang wurde in den spaeteren Kommentaren auch die Begrifflichkeit "Add a Note" bzw "Note" im allgemeinen in Frage gestellt und Tom hat eben seine Begruendung fuer die Verwendung des Begriffes gegeben.

Wie oben schon erwaent, wurde in der ersten Fassung die Begriffe "Report an issue" und "Bug" verwendet, wurde dann aber im Laufe bewusst in "Note" umgeandert. Zum Teil, weil "Bug" nicht gerade der benutzerfreundlichste Begriff ist und weil im Source ein generischer Begriff nuetzlicher ist, aber auch weil eben Bewusst das ganze expansiver gestalten wollte. Dies bestaetigt Tom auch noch einmal in einer englischen Diskussion zum Thema der Begrifflichkeiten[1].

[1] https://github.com/openstreetmap/openst … t-17236768

Der Vollstaendigkeitshalber, hier der Link zu der offiziellen Policy zu wie man weitere map layer zu osm.org hinzufuegt:

http://wiki.openstreetmap.org/wiki/Tile … Guidelines