In Wikipedia gäbe es jede Menge Artikel zu Stoffen. Jeans-Stoffe, Tweet-Stoffe,… Jetzt hat jemand ein Skript, dass alle Artikel die “Stoff” im Namen haben herunterlädt und in einem Dokument zusammen fasst und dieses dann der Öffentlichkeit zugänglich macht. Jetzt kommt jemand daher und legt einen Artikel chemische Stoffe an. Würde dieser jetzt erst groß diskutieren, ob dieser Name Komplikationen in irgendeiner (kaputten) Auswertung etc. hervorruft? Eher weniger. Denn wenn dies “Pflicht” wäre, würden kaum noch neue Objekte geschaffen, sondern primär und endlos darüber diskutiert werden, ob man das nun so oder so macht. Dann ist ein Crowdsourcing-Projekt schneller tot als man denkt.
Das würde aber nur zu Chaos führen. Nicht ohne Grund gibt es Regeln wie bestimmte Sachen zu mappen sind. Es gibt zwar noch gewisse künstlerische Freiheiten, aber bei einer Karte ist es schon wichtig, ein einheitliches und harmonisches Bild abzuliefern. Man muss sicher auch nicht jede Kleinigkeit mit den Renderer-Programmierern abstimmen. Aber wenn grundlegend Sachen geändert werden sollte man doch lieber vorher mal diskutieren. Bei den Stimmbezirken war die einzige kurzfristige Notlösung, sie wieder zu löschen. Das ist aber alles Mehraufwand.
Eigentlich ist OSM als Stadtplan schon fast perfekt. Was mich noch etwas stört sind die “Stolpersteine”, nicht die Steine an sich,
nur dass sie in der Karte so dominant erscheinen, als wären es große historische Momumente, die man beim
Stadtspaziergang unbedingt besuchen müsste. Stattdessen ist es ja nur ein kleiner Gedenkstein im Asphalt,
vor allem sind es sehr viele in einer City.
Das, wie auch Wahlkreise oder Stimmbezirke, wäre gut geeignet für ein Layer-Konzept. Dass also diese Elemente gar nicht
in die gerenderten Kacheln eingebrannt werden, sondern als Vektorelemente überlagert.
Das erspart Duplikate der Massen von Rasterbilddaten, die man sonst für jede Layer-Kombination zum Abruf vorhalten müsste.
Vektor-Overlays dagegen werden von der Viewer-Software selbst überlagert, also im Browser per Javascript
(wie auch die Stammtisch-Links auf openstreetmap.de) oder wie die Vektor-Layer in Google-Earth.
Ich denke so etwas sollte noch weiter ausgebaut werden. Die Vektor-Overlays müssten dann auch nicht in einer
Zentraldatenbank gepflegt werden, sondern könnten unabhängig gewartet werden, oder sogar lokal auf der eigenen
Festplatte, falls man mit Geodaten herumspielen will.
Kennst du das Template-Konzept von Wikipedia? Der Witz bei der Vorlage zu den Chemischen Stoffen ist ja gerade, dass nicht jeder seine eigene Infobox zusammenfrickelt, sondern dass eine einheitliche Infobox gibt, eine Vorlage zum Ausfüllen, wo dann das Rendering klar ist. http://de.wikipedia.org/wiki/Vorlage:Infobox_Chemikalie
In Zukunft werden noch mehr solcher Rodaten in Datenbanken abgelegt und einheitlich daraus präsentiert.
Ohne Koordination der Datenstrukturen und Layout geht das nicht.
Ich kann auch nicht erkennen, dass die Wikipedia überreguliert wäre.
Bei einer Karte ist das harmonische Zusammenspiel von Datenstrukturen und Präsentation noch wichtiger als bei einer Sammlung von Einzelartikeln.
Nehmen wir mal an, ich hätte ein Template “chemische Elemente” erstellt und die Elemente der ersten Hauptgruppe angelegt und mache eine Auswertung über alle Verwendungen dieses Templates und erstelle eine Übersicht über die Namen. Nun kommt jemand daher und erfasst auch die Elemente der zweiten Hauptgruppe mit “meinem” Template. Soll dieser jetzt erst diskutieren, ob das evtl. eine Nutzung der Daten kaputt macht oder soll er dieses Template einfach nutzen? Ich denke wir sind uns einig, dass dieser das Template nutzen sollte. Nun macht das aber die Auswertung von seinem Kollegen kaputt, der die erste Hauptgruppe angelegt hat und nur die Namen dieser Elemente in seiner Liste hätte.
Sollte jetzt das Template für die zweite Hauptgruppe wieder gelöscht werden oder ist es nicht eher an dem, der die Auswertung “verbockt” hat, eben jene anpassen? Wenn man sich fürs erste stark macht (so wie du es tust) sorgt das dafür, dass sich dann jeder ein eigenes Template überlegt und ein systematisches Auswerten unmöglich wird.
Die Wikipedia-Templates sind wohl nicht das passende Analogon. Ich wollte damit nur sagen, dass man Datenstruktur und Layout von Anfang an abstimmen sollte. Die Präsentation wird anhand des Templates automatisch generiert. Da können kleine Änderungen große Kollateralschäden verursachen. Wenn man schon weiß, dass bestimmte Datenfelder die Präsentation ruinieren, sollte man ruhig etwas Geduld haben, bis auch die Default-Renderer damit zurechtkommen. Ein Stadtplan betrifft gleich viele Leute, z.B. in einer Großstadt von 300 000 Einwohnern und hoffentlich vielen OpenStreetMap-Kartenfreunden. Es heißt schließlich OpenStreet"Map" und nicht OpenStreet"Database". Die Datenbank ist lediglich Mittel zum Zweck, eine Karte strukturiert speichern zu können.
Wir haben ein Feld für Namen, und wenn ein Objekt einen Namen hat gehört der da rein. (Misslungene) Wikipedia-Analogie: Man will die Namen der Wikipedia-Artikel aus ausgewählten (alle zum Erstellungszeitpunkt vorhandenen) Kategorien in einer Wortwolke anzeigen. Dazu stellt man alle Namen von Wikipedia-Artikeln dar und sortiert sie den Kategorien entsprechend. Es werden danach munter weitere Artikel und Kategorien angelegt. Nun fällt einem auf, dass man gar nicht alle Namen wollte (weil es inzwischen Artikel und Kategorien mit sehr langen Namen gibt, bei denen das stört). Also müssen die Artikel, bei denen das unerwünscht ist wohl ohne Namen auskommen oder der Name woanders gespeichert werden. Ist doch so, oder etwa nicht?
Nein, es geht um mehr als nur eine (oder mehrere) Karte(n)…
Da liegst du leider völlig daneben: In der OSM-Datenbank werden Objekte aller Art abgespeichert, mit denen man unter Anderem eine Karte erstellen kann. Es ist nicht der Sinn und Zweck von OSM nur Karten zu erstellen sondern auch ganz andere Anwendungen zu ermöglichen. Die Visualisierung einiger Daten in Kartenform ist natürlich eine wichtige und schöne Sache, aber nicht Alles.
das ist die Auffassung der OSMF. Als Eigentümerin der Daten ist diese Meinung nicht ganz unwichtig, aber:
Auch mein Eindruck ist, dass die Masse der (größtenteils schweigenden) Erfasser sich für den theoretischen Unterbau der “freien Daten” überhaupt nicht interessiert. Die wollen “ihre” Daten in “ihrer” Karte sehen. Fertig!
Und meine Idee davon, mit der Situation umzugehen, sieht nicht die Missionierung der Erfasser. sondern das Ändern der Organisation vor. Zum Beispiel. indem man die Erfasser mal fragt. Aber schon diese “Kleinigkeit” ist in der derzeitigen Organisationsform schwierig.
Also für mich ist OSM in erster Linie eine freie Karte mit hochwertiger Optik und einem einzigartigem Detailreichtum. Dank der vielen Mapper natürlich, der verteilten “Intelligenz”. Ich denke darum ist OSM auch so beliebt geworden. So ein Ziel, ein “Markenzeichen” sollte man besser im Auge behalten. Geodaten-Sammlungen gibt es viele, z.B. ähnliche Versuche wie OSM, aber mit sehr bescheidener Optik (z.B. für Garmin-Geräte). Für viele interessiert sich keiner.
Natürlich kann man mit den Kartendaten noch viel mehr anstellen und die Daten mit Zusatznutzen anreichern. Auch das ist eine wünschenswerte Eigenschaft von OSM. Z.b. könnte man sich einen Benzinpreisberater auf dem Smartphone vorstellen. Der routet auf OSM zur nächsten Tankstelle, berücksichtigt dabei aber auch den Weg und den Benzinpreis (ein wunderbarer Spielplatz für Optimierungsalgorithmen). Aber nun: wollen wir wirklich OSM zur Online-Datenbank der Benzinpreise ausbauen? Das sind auch ortsbezogene Daten, sicher auch wichtiger für Bürger als Stimmbezirke. Aber das würde eben eine hohe Dynamik in den Kartendaten verursachen, die Datenverarbeitung insgesamt verlangsamen. So etwas lässt sich eben wunderbar in externe Datenbanken im Rahmen unabhängiger Projekte pflegen. Ein Kartenprogramm kann diese Daten mit den OSM-Karten verheiraten, z.B. die Tankstellen-Benzinpreise als Vektordaten der Karte überlagern. Denn warum sollte weltweit man eine eigene Rasterdatenquelle für so einen Layer produzieren? Unnötige Redundanz. Oder eine historische Aufarbeitung der römischen Feldzüge. Sicher interessante Geodaten, aber muss man das ständig omnipräsent in den Zentraldaten mit berücksichtigen? Natürlich kann man viel ausblenden, aber wenn jemand mit JOSM editiert hat er das ganze Chaos auf seinem Schirm.
Nochmal ein Wikipedia-Vergleich: Wikipedia ist als Enzyklopädie groß geworden. Viele Autoren vergessen das. Regelmäßig müssen Autoren daran erinnert werden, dass Artikel z.B. keine wissenschaftliche Aufsätze sind. Im Artikel über Ethanol muss man nicht das Konsumverhalten Nordirischer Jugendlicher auf 10 Seiten Statistik aufarbeiten. Sicherlich interessant, aber nicht enzyklopädisch. Und für Artikel mit Lehrbuchcharakter musss man auf wikibooks.org verweisen, die dort besser aufgehoben sind. Natürlich kann man alle Daten wunderbar vernetzen.
Auch zwischen OSM und Wikipedia gibt es eine schöne Vernetzung im Smartphone. Bei OsmAnd kann man das als Reiseführer nehmen, sich auf der Karte die Wikipedia-Artikel-Locations einblenden lassen, oder eine Umkreissuche damti machen. Ein Klick und schon hat man eine Artikelkurzfassung. Aber muss deswegen gleich der Wikpedia-Artikel in die OSM? Andersherum lassen sich Koordinaten in Wikipedia schnell in OSM visualisieren. Ich denke es ist gut, wenn es solche freien Spitzenprojekte gibt, die aber nur deswegen so spitze sind, weil sie ein klares Ziel haben und darin sehr gut geworden sind.
Was spricht denn gegen eine Vernetzung mehrerer Datenbanken? Und eine Schnittstelle mit den man lokal Geodaten schnell mit OSM verbinden kann, z.B. wie ein Google Earth KML Vektor Overlay? Das entlastet das Hauptprojekt, bietet weniger Angriffsfläche für Vandalismus, senkt den Verwaltungsaufwand etc …
Magst Du Dich vielleicht mal ein wenig abregen? Man kann geteilter Meinung sein, ob die Stimmbezirke in OSM gehören, aber der Begriff des Vandalismus ist in dieser Diskussion so angebracht wie Pferdefleisch im Tomatenmark. Erstens ist abgesehen von einer Reihe kaputter Relationen (welche Dir nicht einmal aufgefallen sein dürften) kein Schaden entstanden; Deine gegenteilige Behauptung wird durch ständige Wiederholung nicht richtiger. Zweitens ist kein Vorsatz zu einer solchen Beschädigung erkennbar.
Wenn du einen Weg (er)findest, der Objekte (Nodes, Ways, Areas, POI, …) , die sich in verschiedenen Datenbanken befinden, stabil miteinander verknüpft, würde man dir wohlmöglich die Füsse küssen. Mach dir darüber mal Gedanken.
Und wenn diese “Kill-Kriterium” geklärt wäre - du bemerkst sicherlich meine Skepsis - hätten wir mehrere spezielle Datenbanken mit
unterschiedlichen Infrastukturen, Standorten, Administratoren, Kosten, Benutzerzugängen, …
Es sei denn, diese Datenbanken lägen alle auf den bewährten OSM-Servern. Dann könnte man aber gleich das Datenschema der OSM-Datenbasis erweitern.
Hier liegt wieder mal der Teufel im Detail. Ein pauschales “Irgendwo muß das Zeug schließlich hin” “Dann packen wir das halt in einen andere Datenbank” hilft hier leider nicht weiter.
Ich konstruiere hier mal ein fiktives Beispiel: DB der Straßennamen mit Erklärung der Herkunft des Namens (“Wonach ist die Adolfstraße in Kassel und die in Hannover benannt?”)
Das Problem ist, dass eine Straße in einer Stadt aus mehreren Teilstücken besteht (wenn wir mal von doppelten Straßennamen in einer Stadt absehen).
Also muß man entweder
an jedes Teilstück (Way) Verweise auf den Namensgeber taggen
in der Namens-DB einen Verweis auf die Teilstücke in OSM pflegen
eine associated_street-Relation in OSM aufbauen, die alle Teilstücke zu einem Objekt zusammenfasst, welche dann in der Namens-DB verwendet werden könnte.
Bei den beiden letzten Beispielen kommt noch dazu, dass die OSM-ID eines OSM-Objektes (hier: Way oder Relation) nicht stabil ist und associated_street als Sammelrelation per se unsicher ist.
Das ist noch ein relativ “harmloses” Beispiel. Bei anderen Konstrukten fällt mir noch nicht einmal eine fiktive Lösung ein. Immer dann, wenn OSM-Objekte mit “was anderem” verknüpft werden sollen, klemmt es fürchterlich.
So, jetzt bist du dran.
Gruss
walter
ps: nicht daß hier der Eindruck aufkommt, daß ich sowas nicht für sinnvoll halte - nur an der Realisierung wird es wohl scheitern
Du kannst auf der nächsten SotM einen Vortrag halten zum Thema “Referentielle Integrität bei lose gekoppelten verteilten Datenbanken”. Gespannte Zuhörer sind Dir gewiss.
.oO( “Nichts ist unmöglich oder zu schwierig für den, er es nicht selbst tun muss.” )
Tja, wenn man eine Karte drucken will und nur noch Stimmbezirke sieht, dann ist das schon gravierend. Gut, so ein kleiner Unfall kann mal beim Schrauben an der Rendersoftware passieren, aber wenn das 1 Monat so steht fragt man sich schon, ob es da ein Kommunikationsproblem in der Community gibt. Du hast wahrscheinlich gar nichts davon gemerkt, denn das Problem war regional beschränkt, da wo alle Stimmkreise eingetragen wurden. Natürlich ist das für die Datenbank kein Problem, aber was man von einer Karte sieht ist schließlich die Darstellung. Die Rohdaten helfen mir wenig beim Radfahren. Zumindest hat die Cyclemap die Einträge erst gar nicht dargestellt.
Einfach so wie es Google Earth mit KML-Overlays macht. Es spielt ja auch eine Rolle ob es eine ein- oder zweiseitige Beziehung ist. Die Wahlkreiskarte wird man sicherlich nicht als Grundlage für andere OSM-Einträge referenzieren müssen. Es ist einfach nur ein Polygon auf der Hauptkarte. Das geht auch einfacher. In Google-Earth könnte man die Wahlkreise schön optisch als Vektorzug oder transparente Fläche auf der Hauptkarte überlagern, ohne das die Datenquellen direkt miteinander verbunden werden. Werden die Wahlkreise nicht ohnehin schon als GIS Shapefile freigegeben?
Ich sag ja auch nicht, dass es um die Wahlkreise alleine geht. Die kann der Renderer noch unterdrücken (und es wäre schön wenn die Mapper noch etwas Geduld haben bis er es wirklich macht) und die Datenmassen in der Zentraldatenbank halten sich in Grenzen. Aber wo jetzt öffentliche Geodaten in Deutschland per Gesetzt freigegeben werden, muss man sich schon fragen, ob man die alle gleich in OSM abladen muss, oder ob man das mit anderen Datenbanken vernetzt. Wenn man halt den Schwerpunkt “Karte” verliert, endet man leicht im Datenchaos, das keiner mehr managen kann. Und wer soll das Worldfile noch auf seinem PC bearbeiten können, wenn die Datenmenge explodiert?
ab und zu merkt man doch, dass du erst relativ kurz dabei bist: Das Problem “Mapnik beschriftet benamte Linien IMMER mit Namen” ist uralt. Vor der Umstellung von Mapnik auf die neue Software war das unmöglich zu beseitigen und jetzt ist noch keiner dazu gekommen. Daher handelt es sich nicht um einen Unfall, der mal eben so nebenbei gefixt werden kann, sondern eher um eine offene Baustelle, die endlich mal geschlossen werden sollte.
Aus diesem Grunde bin ich eigentlich etwas unglücklich, daß “des lieben Friedens willen” die doch arg störenden Wahlkreise wieder rausgenommen wurden. Dadurch ist der Druck auf die Entwickler leider zurückgegangen. Ich hätte lieber in deren “Ecke” ähnliche Einträge gemacht, damit die endlich mal zu Potte kommen. Ging aber nicht mangels fehlender Daten.
Da erscheint der Bauernhof mit Wahlkreis bezeichnet.
Das es nur das Zentrum des Polygons ist weiss ich auch, aber rein optisch ist es eben falsch
(die gestrichelte Linie ist ein Feldweg)
Dort wird die Bahnstrecke mit “Stimmbezirk Godesberg Mitte” beschriftet.
Das sieht einfach blöd aus.
Zumindest heisst der Stadtwald jetzt wieder Kottenforst und ist nicht
mehr mit Stimmbezirken beschriftet (der betreffende Mapper hat als Workaround die Bezirke gelöscht).
Wenn das für eine öffentliche Karte irgendwie wichtig wäre, Ok, wären das halt Renderer-Bugs,
aber wer will denn überhaupt so etwas auf einer Karte sehen?
das ist doch keine Google Erfindung. Man braucht auch kein KML, die OSM-Datenbank reicht :), wie bereits erklärt.
Schau dir doch mal Leaflet oder Openlayers (für OSM) an.
Ja, klar, anfangs kam ich mit der Ergonomie der Mapping-Software nicht zurecht. Die eigenen NMEA-Logs waren da sehr unübersichtlich in ein Linienchaos eingebettet. Und jetzt ist die Karte schon so gut, dass man fast nichts mehr vermisst. Also bin ich eher Nutzer als Mapper. So gesehen ist mir auch egal ob die Render-Software oder die Datenbasis schuld ist. Für mich zählt das optische Ergebnis.
