Grundlegende Probleme von OSM

Das finde ich nicht, ehrlich gesagt. Wenn du auf OSM.org gehst, solltest du sofort einen einsetzbaren, ansehnlichen Kartendienst haben. Die eigentliche Karte sollte da nicht noch hinter diversen Links versteckt werden.

Vielen Dank! Mir war nicht bewusst das OSM hier so offen umgeht, viele Firmen halten sich über ihrer Server (Infra)Struktur doch eher bedeckt.

Nun ja ein kurzes drüber schauen, es sind genug Clouddienste dabei, die all. Anforderungen sind auch nicht übermäßig.

Die Requirements die sie aufzählen wären alle mit quasi jedem Anbieter erfüllt, da wird es wohl am Geld scheitern…

Für die nicht Finanzprofis :-): rein von den Kosten ist selber kaufen natürlich immer billiger bei gleicher Abschreibung über den gleichen Zeitraum. Bei Firmen kann aber Mieten oder Leasen sinnvoll sein da man so die liquiden Mittel schont, die man zum Beispiel braucht um Mitarbeiter zu entlohnen, andere Firmen zu übernehmen, spekulativ Anzulegen, und schlicht in Sachen zu investieren, die nicht gemietet werden können etc, also alles Dinge bei denen man hofft einen grösseren ROI zu haben als was die Miete, resp Leasing mehr als ein Kauf kostet. Natürlich ist Miete und Leasing auch eine Option wenn man die liquiden Mittel einfach nicht hat.

Die OSMF macht im Augenblick nichts von alledem und über alles gesehen ist was man im Augenblick macht (auch in Hinblick auf Netzwerkkosten etc) die weitaus günstigste Lösung. Das muss natürlich nicht auf Ewig so bleiben und muss immer wieder angeschaut werden, aber ausser dass es nicht Hip ist, ist aktuell nichts daran auszusetzen.

Simon

+1. Der Ansatz ist schon mal sehr viel besser, weil er die Bandbreite des Projekts darstellt.

–ks

Öh. Ich bin raus…

stimmts leicht nicht?

Ich denke der Blog Artikel trifft die Probleme in vielen Punkten exakt auf den Kopf:

  • die falsche Erwartungshaltung Karte anstatt Datenbank
  • keine Standards für das Tagging
  • kein Fortschritt bei den APIs. Also ehrlich Null Weiterentwicklung seit 2009 und immer noch kein Datenmodell für Flächentypen ist schon beschämend
  • das Sagen hat letztendlich wer den Rootzugang auf den Servern hat

bye, Nop

Und das ist ein Fehler?

Und das ist ein wirkliches Problem anstatt nur ein Tick?

Es gab Updates 2012, 2013, 2016 und 2017 (das letztere ist glaube ich auf der API Seite nicht dokumentiert, und vermutlich wird es auch 2018 was geben). Das ist nicht direkt “null”, dass einzige das stimmt ist das die Versionsnummer nicht erhöht wurde (alle Änderungen waren Erweiterungen die rückwärts kompatibel waren).

Es ist ja nicht so, dass wir jetzt keine Flächen modellieren können, mindestens hatte es viele schön bunte Flächen auf der Karte als ich das letzte mal nachgeschaut habe. Niemand hat bis jetzt ein neues Modell vorgeschlagen hat, bei dem die Nettoverbesserung tatsächlich die Nachteile der Umstellung übertreffen würden, sobald jemand das macht geht es los.

Ich kann mich nicht ersinnen, dass die Systemadmins sich in der Neuzeit in irgendwas eingemischt hätten bei dem halbwegs ein Konsens bestand.

Simon

Für Auswerter ist das teilweise eine echte Katastrophe, dass er z. B. verstehen muss dass building=no gerade kein Gebäude ist, shop=vacant kein Shop und ein highway mit disused=yes eigentlich alles heißen kann. Alleine für building= gibt es über 1000 verschiedene Werte in der Datenbank, manche sind einfach völliger Quatsch. Und automatisch korrigieren kann man das nicht weil das ja dann ein mechanical edit wäre.

Natürlich ist eine falsche Erwartungshaltung ein Fehler, denn sonst wäre sie nicht falsch :smiley: Die Frage ist, wer den Fehler macht.

Wenn das osm-carto-Mapnik-Erzeugnis auf osm.org für alles gehalten wird, was OSM zu bieten hat, dann kreiden wir den so Denkenden bislang einen Fehler an, weil sie nicht wissen, dass OSM eine Datenbank ist und kein Kartendienst.

Man kann es aber auch anders sehen: Es ist ein Fehler von OSM, die Erwartungen an etwas, das „map“ heißt, nur rudimentär zu erfüllen und sich dann dahinter zu verstecken, dass man ja nur eine Datenbank bieten wolle und kein Kartenprodukt. Der Besucher kann sich dann nämlich leicht vorkommen wie – blödes Beispiel, das mir gerade einfällt – ein Postkunde, der am Postschalter zwar eine Übersicht über Briefporto ausgehändigt bekommt, aber gleichzeitig erfährt, dass er die benötigten Briefmarken woanders kaufen muss.

Kaufmännisch ausgedrückt ist das ein Fehler im Sortiment, bei dem man sich nicht wundern muss, wenn sich die Kundschaft rar macht.

–ks

Das building “Problem” illustriert nett wieso es eben doch nur ein (Ordnungs-)Tick ist.

Aktuell hat es 271’ 741’ 512 Gebäudeobjekte in OSM mit etwas über 12’000 verschiedenen Werten. Davon kommen knapp 10’000 maximal 2 mal vor, sind also vermutlich Tippfehler.

Die häufigst gebrauchten 23 Werte decken 98% der Objekte ab, mit 100 ist man bei gut 99% (73 Werte sind im wiki dokumentiert) und da ist man noch lange nicht im nur Tippfehlerbereich, sprich die Werte enthalten noch nutzbare Information.

Wenn man jetzt die Daten effektiv nutzen will muss man, natürlich, einen für den jeweiligen Zweck sinnvolle Normalisierung durchführen (und das müsste man natürlich auch wenn jede der 12’000 Werte dokumentiert und sinnvoll wäre), das könnte z.B. sein 12’000 - 73 Werte einfach auf building=yes abzubilden (minus building=no). Wo ist da jetzt genau das Problem?

Simon

Das ist ein Fehler!

Hier wird zu elitär gedacht. Nicht jeder der zufällig über die OSM-Mapnik stolpert ist ein Computerfreak.
Als normaler Nutzer sehe ich dann eine Karte auf der gerade mal ein Routing angeboten wird. Rechts sind noch ein paar Layer. Wenn ich die an klicke hat die Karte andere Farben und ein paar andere Infos. Das war es dann aber auch schon.

Rechts könnten Gruppen angeboten werden, z.B. “Routing” und da dann einige verschiedene Router.
Als nächstes, ich nenne es mal “Outdoor”. Gerade bei Wanderwegen und Fahrradwegen haben wir bessere Karten.
Noch zwei andere Gruppen und ein großer Teil unserer Datenbank kann einfach abgerufen werden.

True!

Und wenn ich dann noch mutig bin und die Suche nach einem POI frage, und es werden nur Dinge irgendwo in der Welt gefunden dann hat man es das letzte mal besucht.

Es steckt ja auch MAP im Namen und es heißt nicht openstreetDATABASE.org

Am besten zeigt meiner Meinung nach die Firma Mapbox, was rein optisch und beim Thema Datenaufbereitung möglich ist.

z.B.: https://www.mapbox.com/products/ oder https://api.mapbox.com/styles/v1/mapbox/streets-v9.html?title=true&access_token=pk.eyJ1IjoibWFwYm94IiwiYSI6ImNpejY4M29iazA2Z2gycXA4N2pmbDZmangifQ.-g_vE53SD2WrJ6tFX7QHmA#6.57/51.435/10.699

Eine solche Karte, verbunden mit der angesprochenen Auswahl an zusätzlichen Layern, einer Adresseingabe, Anzeige von Öffnungszeiten/Website/… (alles Infos die ja schließlich in der DB stehen!) etc. würde auf der Startseite einen komplett anderen Eindruck machen und wäre bei der Nutzerfreundlichkeit mit Google Maps vergleichbar…

Man könnte vielleicht irgendwo in “zentraler” OSM-Infrastruktur einen Server hinstellen, der Vektor-Kacheln liefert und diesen verwenden, um all die in diesem Topic vorgeschlagenen “Layers” auf der Hauptseite anzuzeigen. Ich denke, das hätte doch einen schönen Wow-Effekt. Plus, man muss nicht mehr versuchen, wie momentan auf der Mapnik-Hauptkarte, alles erdenkliche auf einer Karte abzubilden.

StreetComplete benutzt bereits Vektorkacheln, und so ist der Kartenstil komplett dynamisch anpassbar. Beispiel: Diese Karte (default StreetComplete-Stil) und diese Karte verwenden beide die gleichen gleichen Kacheln.

Der ganze Kram den Mapzen gemacht hat, ist alles OpenSource. Es spricht eigentlich nichts dagegen, dies für OSM-zentralere Themen weiterzuverwenden oder gar weiterzuentwickeln.

Das kommt darauf an. Wenn ich mir neue kaufe, oder wenn ich meine Infrastruktir regelmäßig erneutere, dann sind sie genauso schnell wie gemietete. Und umgekehrt: well ich einen Server miete, diesen jahrelang halten, wird er auch irgendwan langsamer sein als das Schnellste, was man für Geld kaufen kann.

Das tat ich. Und stellte dabei fest, dass hier ein Zusammenhang konstruiert werden soll, der nicht zutrifft.

Wie du meinst, du vergisst das Risiko in deiner Rechnung. Sehr oft ist das Mieten die bessere wahl

regelmäßig neu, heißt regelmäßig viel geld

wenn du ihn mietest wird er nicht langsamer werden, da der anbieter seine hardware schneller ausstauscht um konkurenzfähig zu bleiben, (und auch schneller als wenn du sie als firma kaufst) wenn bekannt wird das bei Firma xyz die server langsam sind aber sie die selben preise verlangen wie alle anderen wird bald keiner mehr zu ihnen kommen.

Das Ganze Risiko mit Sicherheit, maintenance, defekten/Austausch, etc gebe ich auch ab, ich brauche als Firma keinen 24/7 Techniker Support bezahlen, keine Räöume mieten, keine Klimaanlage, keine Brandmelder, keine Backuplösung im Falle eines Ausfalles etc, mir bleiben nur die Administratoren/IT

Oder sagen wir, der nicht in der Zwangsläufigkeit zutrifft, wie es

zu suggerieren scheint.

Vom Risiko war in der ursprünglichen Gegenüberstellung keine Rede.

Wie auch immer, man hat sich dazu entschieden, es so zu tun, wie man es tat, und das vermutlich mit Grund.

Das gilt auch für den Vermieter, und der holt sich das Geld dafür von seinen Mietern.

Aber ich glaube, wir schweifen ab.

Das gehört logischerweise dazu, muss man hier jeden punkt extra benennen?

OFF Topic ende

Jetzt muss ich hier doch mal ein bisschen bremsen, oder das zumindest versuchen.

In diesem Thread haben jetzt schon einige sich gewünscht, dass die OSM-Webseite “konkurrenzfähig” wird, “Endbenutzerfreundlich”, eben eine echte Alternative zu Google Maps.

Man kann mit dem OSM-Werkzeugkasten sicherlich etwas bauen, was mit Google Maps vergleichbar ist, aber das ist 'ne Menge Arbeit - da gehört ja dann zum Beispiel auch sowas wie UMap dazu, und zumindest in Grenzen vom Benutzer definierbares Rendering der Vektorkacheln (Karten, bei denen Süden oben ist etc.), und natürlich: gute Luftbilder. Dem unbedarften Webseiten-Nutzer ist das Fehlen von Luftbildern heute genausowenig vermittelbar wie “wir sind eine Datenbank und keine Karte” - die Antwort ist “bla bla interessiert mich nicht ich will eine nützliche Webseite”. Das Beispiel Luftbilder zeigt, dass wir gegen die “großen” als Vollsortimenter nicht anstinken können. Luftbilder sind nun mal nicht unser Geschäft, Luftbilder sind (derzeit noch…) nichts, wo jeder einzelne Mapper irgendwas zum großen Ganzen beitragen kann, und es wäre absolut albern, jetzt Geld in die Hand zu nehmen, um Luftbildlizenzen zu kaufen, damit wir auch was zu bieten haben auf unserer Startseite, ich hoffe, dass wir uns wenigstens da alle einig sind?

Aber schauen wir auf die Sachen, die möglich sind - es wird zu leicht vergessen, dass all diese coolen Features erstmal Entwicklungsaufwand bedeuten, danach Installations- und Wartungsaufwand, und natürlich auch Hardware-Ressourcen fressen. Den Entwicklungsaufwand muss man mit etwas Glück nicht bezahlen, das machen noch Hobbyisten. Bei der Wartung wird es schon schwieriger - wir haben ein freiwilliges Sysadmin-Team in OSM, aber die haben schon ganz schön viel zu tun (Liste von Servern hier https://munin.openstreetmap.org/)). Wir betreiben nicht nur die zentrale Datenbank und Webseite dreimal (zur Sicherheit), sondern auch Wiki, Email, das Forum, help.openstreetmap.org, einen User-Rechner, das CiviCRM zur Mitgliederverwaltung, Tile-Server und Proxies auf der ganzen Welt, Nominatim… (übrigens, wenn jemand fit in Linux, Sysadmin und Englisch ist, die suchen auch immer Nachwuchs…). Langer Rede kurzer Sinn, irgendwann kommt der Punkt, wo wir bezahlte Sysadmins einstellen müssen, wenn das so weiter geht. Und mit Hardware- und Hostingkosten genauso.

Immer weitere Forderungen nach immer mehr End-User-Features auf unseren Seiten bedeuten also mehr Kosten. Das ist im Grunde kein Beinbruch, OpenStreetMap ist ja eine bekannte “Marke”, wenn uns ein bisschen Mühe geben, können wir bestimmt Förderungen von diversen Stellen bekommen. Notfalls stellen wir einen Fundrasing-Manager ein und zahlen dessen Gehalt dann aus den Einnahmen :wink: - was ich sagen will, das führt alles in die Richtung einer “dicken” OSMF, die massiv Gelder einsammelt und die Manager und Sysadmins und Programmierer bezahlt, und Fundraiser, um mehr Geld einzusammeln. Das aber wiederum führt zu größerer Abhängigkeit von Drittinteressen (die, die uns das Geld geben, wollen damit ja auch was erreichen). Bevor wir’s uns versehen, müssen wir auf unserer Webseite Marketing-Phrasen dreschen und der Welt ständig erzählen, was wir für tolle Sachen machen, damit der Geldhahn weiter offen bleibt, usw. usf.

Umgekehrt überlassen wir Firmen wie Mapbox oder maps.me (oder Mapquest, falls sich noch jemand erinnert) das Feld, wenn wir selbst keine eierlegende Wollmilchsau-Webseite anbieten. Wer weiss, vielleicht hat Google irgendwann auch einen OSM-Layer. Nachteil: Wir kriegen nicht so viel von dem Prestige. Vorteil: Wir können weiter das machen, was für uns wichtig ist, und wir können eine kleine Organisation bleiben, ohne Verwaltungswasserkopf.

Vielleicht male ich das zu drastisch, und es gibt vernünftige Mittelwege, aber für mich hängt die Forderung nach immer mehr Services für die Endbenutzer schon irgendwie auch damit zusammen, ob die OSMF eine kleine Organisation im Hintergrund bleibt oder sich zu einer Wikimedia-Foundation aufbläht.

Denkt mal drüber nach, was für eine OSMF ihr wollt, bevor großartige Forderungen gestellt werden.

Trivial ist das auch nicht, aber es ist ziemlich sicher, dass das zentrale Rendering irgendwann auf Vektorkacheln umgestellt wird, vorallem wegen der Beschriftungen. Da aber Vektorkachel nicht gleich Vektorkachel ist, ist völlig unklar, welche anderen Styles dann auch funktionieren würden und wo noch wieviel Aufwand reingesteckt werden muss.

Bye
Frederik