Eine Karte in jeder Sprache
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 31 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/15836 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
3
6
7
12
13
14
16
20
25
26
27
00:00
WEBDrahtloses vermaschtes NetzService (economics)SmartphoneOpen sourcePoint (geometry)Norm <Mathematik>Moment (mathematics)Web browserSearch engine (computing)Route of administrationOperatorGeometryObject (grammar)Run-time systemSmart cardGEOLOGComputer hardwareFocus (optics)Physical quantitySeries (mathematics)Local ringSoftwareMobile appAndroid (robot)Computer animation
05:07
MetadataMetadataRoute of administrationCarriagewayComputer animation
05:44
Route of administrationInterface (computing)GeodesicSVGSmart cardInformationGoogleMoment (mathematics)Electronic visual displayComputer programmingComputer animation
07:02
Computer wormSmart cardComputer animation
07:39
Smart card
08:35
World Wide WebVersion <Informatik>SoftwareComputer animation
09:40
Computer programmingComputer animation
10:07
Web browserSurfacePlatteSmart cardDatabaseComputer programmingRandHausdorff spaceServer (computing)RAMVolumenvisualisierungCoordinate systemAdaptive behaviorComputer animation
13:04
Moment (mathematics)VelocityIP addressServer (computing)Computer animation
14:08
Structural loadSoftwareRandSoftwareStatistikerServer (computing)Moment (mathematics)Process (computing)Structural loadPlatteCache (computing)VolumenvisualisierungGroßes SystemComputer animation
17:47
Computer fileComputer animation
19:11
Service (economics)Smart cardServer (computing)InformationComputer hardwareWeb browserClient (computing)CompilerImplementationGoogleDatabaseUniform resource locatorEuclidean vectorSet (mathematics)IntelCache (computing)Norm <Mathematik>Vector graphicsZusammenhang <Mathematik>CLOU <Programm>RandLecture/Conference
Transcript: German(auto-generated)
00:01
Spaß. Ja, hallo. Und zwar geht es hier um die mehrsprachigen Karten, die gerade im internationalen Bereich von Interesse sind, aber auch gerade hier in der Lokal in der Schweiz. Und vorab aber ein bisschen Info drum herum, weil als wir den Vortrag eingereicht
00:20
haben, sind wir eigentlich davon ausgegangen, dass das zu dem Zeitpunkt jetzt schon in der Wikipedia eingebunden ist und jeder das nutzt und tausend Fragen jetzt an uns kommen, wie man das taggt und sowas, wobei taggen könnte das ja so oder so, aber es fehlt halt eben noch ein bisschen so die Killer-Anwendung, dass jeder das auch auf der Karte sieht im Moment leider.
00:40
Als zu der mehrsprachigen Karte wird dann Jochen ein bisschen mehr sagen. Ich werde mal kurz andeuten, warum das im Moment in der Wikipedia nicht so auf dem Stand ist, wo wir es uns erwartet haben, aber auch mal ein paar Punkte ansprechen, die vielleicht interessant sind, was aktuelle Themen sind im Geo-Bereich.
01:03
Und zwar sieht es so aus, also um den Tool-Server ist es ein bisschen ruhig geworden, der ist ja 2009 gestartet worden und war dann durchaus eine Zeit lang sehr aktiv, mit verschiedenen Karten-Styles und jetzt ist sein Ende irgendwo nah, aber es geht eigentlich noch bis 2014,
01:21
werden die Dienste weiter betrieben, aber es wird jetzt nichts mehr in die Hardware investiert. Und es wird eine Aufteilung geben, also die Karten-Style, die bekannter sind, die Heikin-Bype-Knapp ist relativ populär, die wir rendern, aber auch den OSM-Default-Style oder so ein No-Label-Style,
01:40
der soll ins Produktivsystem und da greifen dann eben professionelle Operator darauf zu, sodass dann Freiwillige nicht unbedingt mehr darauf den Zugang haben. Und dafür soll es dann aber auch entsprechend die Labs geben, was der Tool-Server-Nachfolger ist, Labstool-Labs in der Kombination und da kann auch wieder jeder
02:01
einen Account bekommen und sobald da die OSM-Daten da sind, was ich hoffe, dass es bald passiert, kann man damit halt eben umspielen. Der Tool-Server, der nur wieder vom deutschen Verein betrieben wurde, da ist es nicht ganz ausgeschlossen, dass es da mal einen Nachfolger gibt, aber der muss halt eben leichter
02:20
zu warten sein, als es im Moment der Fall ist und wir werden erstmal die Erfahrung mit den Labs abwarten, wenn wir komplett glücklich sind, dann wird es da nicht unbedingt den Grund geben, was Neues zu machen. Aber jetzt zu den eigentlichen Geo-Geschichten. Und da habe ich mal fünf Themen rausgezogen, die aktuell so in der Diskussion
02:42
sind, was man gerne machen würde, was man gerade macht. Und die gehe ich jetzt mal der Reihe nach durch. Und das Interessante ist, früher war der Geo-Bereich immer so ein externer Hobby-Bereich, er war nicht direkt im Fokus der Foundation, das hat sich etwas geändert, also man kann jetzt wirklich die
03:01
englische Wikipedia nachschlagen, kriegt eine Nearby-Spezialseite, der Browser zieht sich seine Geolokalisation raus und man kriegt Objekte in der Umgebung angezeigt und das auch als App entsprechend auf dem Smartphone. Aber da fehlt es an vielen Features,
03:20
so dass ich da jetzt noch nicht andere Leute dadurch arbeitslos sehe. Aber dafür ist es für großen Trafik ausgelegt, Solar als Suchmaschine im Hintergrund, da tut sich auf jeden Fall einiges. Der nächste Punkt würde mich
03:40
interessieren und mich freuen, wenn der umgesetzt würde. Wenn wir Android haben, da haben wir auf der einen Seite schon offline Karten von OpenStreetMap, also so MapsForge und andere Anwendungen und auf der anderen Seite haben wir entsprechend offline Wikipedias und das wäre schön, wenn man die verbinden könnte soweit und das wäre
04:01
wahrscheinlich auch eine kleinere Übung, die man machen könnte. Der nächste Punkt ist ein sehr spannendes, schönes Thema, wir haben Tausende, man kann sagen 17 Millionen Bilder auf Commons und davon sind auch einige historische Landkarten und davon sollen es immer mehr werden und die wollen wir jetzt eben auch
04:22
recht professionell georeferenzieren, nutzen da die Software MapsFrapper und das ist eigentlich auch nicht so kompliziert. Wo es kompliziert wird, ist, dass es in das ganze Gebilde mit eingeflossen einfließen soll, was entsprechend die Commons
04:40
angeht, aber auch die Kooperation mit Museen und Bibliotheken, die die Karten bereitstellen und dann aber auch soweit, dass sie bis im JOSM verfügbar sein sollen, die historischen Karten und dann für OpenHistoricalMap zum Beispiel zur Verfügung stehen sollen, dass die Leute das also abzeichnen können, was auf diesen Karten
05:00
zu sehen ist. Also ich finde, das ist ein ganz spannendes Projekt und werden wir mal sehen, was daraus wird. Der vorletzte Punkt in meiner Liste ist, es ist ein richtig großes Projekt, nennt sich Wikidata und beeinflusst eben die komplette Wikipedia-Instrastruktur, dass auch zum Beispiel die ganzen Wikipedia-Koordinaten
05:22
jetzt an einen zentralen Platz wandern und automatisiert auslesbar sind. Aber durch die Verbindung zwischen Wikidata, Wikipedia und OpenStreetMap steht dann auch entsprechend genügend an Metadaten für OpenStreetMap- so zumindest meine Vorstellung.
05:49
Der letzte Punkt ist, dass wir auch in der Wikipedia so eine Kartenwerkstatt haben und die arbeitet momentan relativ lokal, sei es mit Inkscape, Kugis,
06:00
was auch immer. Und dann werden die fertigen Werke halt eben hochgeladen auf Commons. Das Problem bei dem Prozess ist aber, dass da sehr viele Informationen verloren gehen. Und wenn man dann Jahre später will ein anderer Nutzer wieder anfangen und die Karte updaten, dann besteht das Problem einfach, dass die ganzen Geodaten verschwunden sind. Die sind in dem SVG drin und nicht mehr nutzbar.
06:22
Und da schauen wir jetzt halt eben gerade, was wäre da eine geeignete Anwendung. Und da sehe ich durchaus auch dieses sharemap.org als sehr interessant an, weil man da einfach mal Karten per Hand auch Dinge einzeichnen kann. Es ist jetzt für den Nicht-Programmierer
06:41
ausgelegt. Und man hat aber durchaus auch die Möglichkeit, über die Overpass API hier in die Schnittstelle zu haben, wo man Elemente von OpenStreetMap einladen kann, die dann auch automatisiert aktualisiert werden können. Ja, das wären eigentlich die Punkte, die ich erstmal sagen wollte. Jetzt würde ich an Jochen übergeben, der zu mehr Sprachkarten was sagt.
07:02
Danke Tim. So, dann müssen wir kurz umschalten. So, mehrsprachigen Karten. Also, das Ziel des Projektes ist,
07:20
mehrsprachige Karten in die Wikipedia zu kriegen. Wenn man in der Wikipedia rechts oben auf den Knopf drückt, je nach Sprachvariante von der Wikipedia, kriegt man da verschiedene Karten. Und bei vielen ist da eine OSM-Karte dahinter. Also jetzt zum Beispiel bei der deutschen Wikipedia hier mal an dem Beispiel Rappers wie Jona gezeigt, wird eine OpenStreetMap-Karte eingeblendet.
07:42
wie wir das so kennen, von unseren OpenStreetMap-Karten, man guckt irgendwo in irgendein Bereich, in dem man etwas weiter in die Welt und man kann eigentlich nichts mehr erkennen. Wer kann jetzt hierauf sehen, wo da Seul oder Peking oder was weiß ich irgendwo ist?
08:01
Die Standard-OpenStreetMap-Karten benutzen den Nametag um die Labels zu zeichnen. Das ist immer der Name, wie er lokal verwendet wird, typischerweise. das hilft natürlich mir nichts, der ich all diese asiatischen Schriftarten nicht kenne und diese Sprachen
08:20
nicht kenne. Das heißt, wir wollen eine mehrsprachige Karte haben. Das wollen wir sowieso alle, aber die Wikipedia ganz besonders, weil die gibt es eben in 200 verschiedenen Sprachen oder sowas. Und das ist etwas blöd, wenn man zwar eine Wikipedia übersetzt hat in alle möglichen Sprachen, aber die Karten dazu dann nicht vernünftig benutzen kann. Es gibt derzeit nur einige Wikipedias,
08:40
für die man spezielle Kartenversionen gemacht haben, die deutschen, die russischen und ein paar andere. Aber wir wollen es in all diesen 200 verschiedenen Sprachweihen von der Wikipedia haben. Problem, es gibt sehr viele Sprachen. Es gibt noch mehr Kombinationen von Sprachen. Das kann ja sein, dass jemand sagt, naja gut, ich kann Deutsch und ich kann Französisch und ich kann Englisch oder sowas, aber
09:02
Chinesisch kann ich nicht. Das heißt, selbst wenn der Name von, sagen wir jetzt, Peking oder sowas, auf Deutsch nicht übersetzt wurde, aber eine französische Variante davon haben, dann würde ich die vielleicht lieber sehen als die chinesische Originalvariante, weil ich dann wenigstens noch ein bisschen was erkennen kann. Also deswegen geht es eigentlich nicht nur darum, dass man für jede Sprache eine Karte macht, sondern es geht darum,
09:22
dass man auch Kombinationen irgendwie haben kann. Und die bisherige Software, Standard, Teilserver, egal was man da verwendet, die skaliert halt nicht, weil ich für jede Sprache quasi eine Kopie von einem Style habe und quasi nochmal einen getrennten Teilserver aufsetzen muss, die alle nebeneinander sind und das funktioniert nicht.
09:40
Das war unsere Ausgangsbasis. Und dann haben Tim und ich uns beantragt letztes Jahr oder vorletztes Jahr war schon die Beantragung und dann letztes Jahr die Durchführung. Der Wikimedia Deutschland e.V., die haben so ein Projektbudget, wo sie sagen, wir haben ja einen Batzen Geld, da können sich Leute darauf bewerben,
10:02
die irgendwas voranbringen wollen im Wikipediaumfeld und kriegen ein bisschen Geld. Und da haben wir Geld rausgekriegt, um Softwareentwicklung zu bezahlen und dieses Projekt durchzuführen. Das Ganze sieht technisch relativ simpel aus. Wir haben die Hintergrundkarte, da ist alles drauf, was kein Label ist, sag ich jetzt mal. Dann haben wir
10:21
einen Vordergrund, die Label, die dann übersetzt werden können und das setzt man zusammen und dann haben wir wieder eine normale Karte. So weit nicht weiter schwierig, also Flächenlinien usw. im Hintergrund. Was ich machen muss, ist die Namen, die Refs, also was man braucht für die Highway Shields, also diese Autobahnsymbole usw. Hausnummern, all diese Sachen.
10:40
Hausnummern muss man zwar nicht übersetzen, aber sie müssen in diesen Layer rein, weil man sonst die falschen Sachen überdeckt. Also man nimmt quasi einen Standard-Style, teilt das auf und sagt, ok, das kommt da rein, das ist der erste Schritt. Und dann kann ich im Browser überlagern, könnte man theoretisch auch im Server machen, aber funktioniert im Browser ganz gut.
11:03
Also Hintergrundkacheln kann ich vendern wie gewohnt. Dann nimmt man irgendeinen Teilserver, spielt keine Rolle, das ist das, was sozusagen erprobte Technologie ist, die wir kennen. Ich render die Sachen, speicher die Kacheln einfach auf der Platte und muss halt gelegentlich neu vendern,
11:20
wenn sich die Daten ändern usw. Für die Sprachkacheln ist es etwas anders. Weil, wenn ich 200 Sprachen habe und vielleicht auch noch Kombinationen erlauben will, dann kann ich nicht diese Kacheln 200 mal auf der Platte speichern und dann muss ich die ja auch nicht mehr speichern, sondern ich muss sie ja auch expiren und neue Versionen rechnen, wenn sich die Daten geändert haben usw. Und das geht nicht,
11:40
das heißt, die Idee ist, das live zu machen, diese Kacheln live zu rendern, wenn der User sie anfragt und dann nicht ewig zu speichern. Das heißt, was man machen muss, die Anfrage für die Kachel kommt vom Browser rein. Der Browser sagt, ich möchte die und die Kachel mit der und der Koordinate möchte ich haben und mit der und der
12:01
Sprachkombination. Die Sprachkombination muss also in der URL übergeben werden. Dann muss ich die Mapnik-Konfiguration in dem Fall anpassen. Das heißt, da wo der Mapnik sagt, gib mir mal aus der Datenbank das Nametag, sagt man eben ne, ich hätte aber gerne das namendoppel.de Tag. Oder nametag.de und namen.in und dann nimmt er das erste, was er kriegt oder so.
12:22
Dann wird's live gerendert und ausgeliefert. Natürlich so ganz auf dem Kacheln können wir nicht verzichten. Was wir da drin haben, ist ein Memcached, der diese Kacheln kurzzeitig speichert. Aber der auch eben, der das nur im Ram macht und der, wenn die Kacheln nicht mehr angefordert wird, der merkt sich, welche Kacheln zuletzt angefordert werden
12:41
und wenn nicht mehr genug Platz da ist, dann schmeißt er die Sachen hinten raus. Das Rendern geht sehr, sehr schnell. Aber das, dieses Kurzzeit-Caching braucht man trotzdem noch, weil wir immer metateils auf einmal rechnen, also 8x8 kacheln. Das heißt, ich will diese 8x8 kacheln, die werden ja häufig zusammen angefordert. Will ich natürlich nicht irgendwie 64 mal den gleichen Bereich
13:01
rendern. Also damit kriegen wir nochmal eine gewisse Geschwindigkeit hin. Das Ganze gibt's im Moment im Testbetrieb an dieser Adresse. Ich hoffe, es funktioniert. Ich habe gerade nachgeguckt heute. Haben wir gerade nach Serverproblemen kürzlich wieder aufgesetzt. Da kann man das mal ausprobieren und da kann man
13:20
eben hier in dieses Feld auch eintippen, welche Sprachen man haben möchte. Hier, das ist also jetzt die Standardkarte. Wenn man einfach nur Name kriegt, dann sieht das so aus. Ich weiß nicht, wie gut so hinten rüberkommt. Nicht wahnsinnig gut. Man kann ein bisschen sehen. Also das ist jetzt deutscher Name und wenn kein deutscher vorhanden, dann der englische Name. Da kann man schon ein bisschen mehr erkennen jetzt als deutschsprachler.
13:41
Wenn ich jetzt russe bin, dann hätte ich aber gerne, dass die Karte so ausgilt. Dann kann ich sagen, irgendeine russische Sprache und was dieses Ding auch kann, ich kann sagen, ich möchte jetzt hier zum Beispiel den Nametag haben und dann in eckigen Klammern den deutschen Namen hinten dran, wenn's den einen gibt. Das Ganze ist nur Testbetrieb.
14:00
Ich garantiere für nichts, dass dieser Server irgendwie läuft oder dass er performant ist oder irgendwas. Das nur mal um zu zeigen, was geht. Wie gesagt, die Idee war, dass wir das in die Wikipedia reinkriegen. Und dass wir später auch andere Leute das in ihre Seiten einbringen können. Eine Sache, die wir bei dem ganzen Projekt
14:21
berücksichtigen mussten, ist die ganze Frage, wie viel Last erzeugt das, wenn wir diese Sachen live rendern? Funktioniert das überhaupt? Kriegen wir das mit der Performance hin? Wir haben da relativ viele Statistiken im Vorfeld gemacht, haben uns angeguckt, wie viele Requests haben wir denn eigentlich? Für welche Sprachen? Wie viele Teils müssten wir die Sachen angucken? Und das Ergebnis war, ja, wir können das live rendern. Das Einzige, was man letztlich
14:41
zu dem live rendern mehr braucht, als eine normale OSM2PGL-Datenbank, wie man sie so fürs Rendern verwendet, ist, da sind ein paar mehr Indizes drauf. Damit die Queries, die in den kleinen Zoom-Levelen, zum Beispiel eben die City Labels und so weiter,
15:01
dass diese Queries wesentlich schneller laufen, als sie das vielleicht normal tun würden, und dann kann man diese Sprachen, diese Sprachlabels live rendern. Und das müsste auch noch funktionieren, wenn da mehr Last drauf ist. Wie gesagt, wenn mehr Last drauf ist, funktioniert der Cache ja auch besser. Und wenn es gar nicht mehr funktioniert, dann kann man auch noch einen HTTP-Cache davor schalten, notfalls.
15:22
Jetzt, die Software. Hätte jetzt verschiedene Möglichkeiten gegeben, welche Software man meint. Es gibt ja verschiedene Teilserver-Software. Und ich habe vor einem Jahr, vor eineinhalb Jahren habe ich mir das angeguckt, okay, welche Software haben wir. Und im Wesentlichen, das, was die meisten Leute verwenden,
15:40
ist RenderD oder T-Rex. Die haben aber beide das Problem, dass sie nicht so richtig skalieren, dass sie insbesondere eigentlich nur dafür ausgerichtet sind, auf einem einzelnen Server zu laufen und nicht über mehrere Server verteilt werden können. Das ist die eine Sache. Und die andere Sache ist, die sind komplett darauf ausgelegt, die Kacheln
16:00
zwischenzuspeichern auf der Platte. Die haben da keine modulare Möglichkeit, zum Beispiel eben diesen Memcache-D einzubinden oder so. Es gibt noch eine andere Software, eine andere Teilserver-Software, nämlich die von MapQuest, die die speziell entwickelt haben für ihren eigenen Zweck. RenderMQ heißt sie, die ist
16:20
Open Source, ist auf GitHub drauf. Und ich habe dann mit dem Entwickler geredet und so weiter und habe gesagt, das ist eigentlich eine gute Basis, wenn man da nachher so ein großes System laufen haben will, wie auf der Wikipedia, was wirklich sehr weit skalieren muss, was man über mehrere Server laufen lassen möchte vielleicht. Und es hat eben auch schon diese modulare
16:40
Backend-Geschichte eingebaut gehabt, sodass es relativ einfach war, da dieses Memcache-D Backend anzuflanschen. Und haben uns damals entschieden, diesen Render MQ einzusetzen dafür, dass, wie man an der Demoseite sieht, funktioniert das System auch im Prinzip. Das System ist da, die Software ist da, das funktioniert. Wir haben schon gesehen,
17:00
an der Wikipedia hängt es im Moment so ein bisschen. Es läuft noch nicht auf Wikipediaservern. Das liegt halt an Wikipedia-internen Prozessen, Abstimmungsprozessen. Irgendwie, wer ist für was zuständig und die sind gerade dabei, wie Tim schon gesagt hat, da viel an der Server-Struktur, Zühl-Server und so weiter umzuändern und andere Leute sind
17:20
plötzlich für Dinge verantwortlich und so weiter. Deswegen sind wir da noch nicht weitergekommen, dass es in der Wikipedia wirklich läuft. Und wir haben auch so ein bisschen ein Problem, dass dieser MapQuest Render MQ nicht wirklich maintained ist. Der ist von MapQuest geschrieben worden, von MapQuest Mitarbeitern geschrieben worden, aber MapQuest ist im Moment, steckt da keine weiteren Ressourcen rein. Das heißt,
17:40
das Ding ist eigentlich unmaintained. Und das ist so ein bisschen schade eigentlich, weil es eine schöne Software ist. Ich weiß also nicht, ob es damit so weitergeht. Eigentlich muss ich dazu nicht viel sagen. Ja, es gibt verschiedene Tags für Namen und es gibt aber auch so Sachen wie eben Name, underscore, eins,
18:01
gibt es irgendwie 800.000, was weiß ich, was das wieder für ein Import ist, was das bedeutet. Sowas wird halt zum Beispiel jetzt nicht ausgewertet da. Das sind so diese Dinge wie da Tagging-Probleme, da müssen wir erklären, wie wir mit den Tags eigentlich umgehen. Und dann gibt es eben diese Sprachvarianten, kennt ihr alle, mit dem Doppelpunkt drin. Das sind meistens dann zwei Buchstaben
18:21
für Sprache, aber die Portugiesen, das brasilianische Portugiesisch zum Beispiel, müsste dann eigentlich so aussehen, da gibt es aber auch wieder verschiedene Varianten. Und dann ist die Frage, wenn man das kombiniert, Old Name, Int Name, mit Sprache und so weiter, wie das genau aussieht. Welches ist der Hauptname, wenn es kein Name ohne irgendwas
18:41
gibt, welcher dann, davon nimmt man dann, da gibt es also noch einige Fragen, die wir auch in der Community noch klären müssen. Was eigentlich ganz nett ist, was ich auch mal ausprobiert habe, was aber nicht live ist, ist Transliteration. Das funktioniert durchaus ganz gut, dass man automatisch zum Beispiel kyrillische Buchstaben in Lateinische umsetzt. Vom Chinesischen klappt das nicht so gut, aber gerade von kyrillisch
19:01
in Lateinisch geht es ganz gut. Man kann erkennen, was das wohl für ein Ort ist. Das ist schon mal besser, als gar nichts zu haben. Ich habe das mal in MepNic eingebaut, also mal schauen. Wie geht es weiter? Einbindige Wikipedia, wissen wir jetzt noch nicht, wie das weitergeht. Vielleicht ist ja auch eher was für osm.org, muss man sehen. Und
19:20
die Implementierung auf dem MapQuest RenderMQ ist die Frage, wer bereit ist, das weiter zu maintainen und so weiter, ob das der richtige Weg ist. Jetzt haben wir diese, gerade die ganz neue MepNic-Version, diese Vector-Kachel- Geschichtenmacht. Vielleicht wäre das auch eine Basis, auf dem man das besser einrichten könnte. Weiß ich auch nicht, wie es da weitergeht.
19:42
Hier gibt es diverse URLs mit weiteren Informationen und das war's. Danke schön.
20:01
So, Fragen. Alle sind schon zu müde, keiner hat mehr Fragen. Genau, dann komme ich zu Ihnen gelaufen, wenn Sie Fragen haben. Muss ich mir selbst Fragen stellen jetzt, oder?
20:22
Okay, der Peter möchte. Ich hatte ja selber schon ein paar Mal damit rumgespielt damals, mit diesen multilingualen Karten. Und ein Problem, das wir damals hatten, ist, dass es eben nicht reicht, einfach nur die Labels irgendwie so an sich zu malen, sondern eigentlich muss man auch
20:41
alles andere zumindest mit bedenken, um zu wissen, welches Label muss ich denn jetzt malen und welches nicht. Beispielsweise wenn auf der Hauptkarte ein Symbol gemalt wird, dann darf ich nicht, also was weiß ich, hier Bäckerei, dann darf ich ja nicht auf dem Label-Ding da drüber nochmal einen Text legen. Also das heißt, wenn da schon ein Symbol ist, darf der Text da nicht hin. Und diese
21:01
Verdrängung, ich erinnere mich, dass das damals ein relativ großes Problem war, weil man eigentlich fast den ganzen Style malen musste, aber zumindest berechnen musste, auch wenn man ihn dann nicht in das Bild malt. Hast du ähnliche Probleme gehabt und wie hast du sie gelöst? Nein, eigentlich habe ich die Probleme in der Form so nicht gesehen.
21:20
Also ein Problem war zum Beispiel die Hausnummern. Also die Hausnummern werden deswegen in den Label-Teils mit berechnet, obwohl sie nicht sprachabhängig sind und nicht in dem Hintergrund-Layer. Und ja, es gibt manchmal den Fall, dass es irgendwie komisch aussieht und dass irgendwas was anderes übermalt, aber es passiert eigentlich erstaunlich wenig.
21:42
Vielleicht liegt es auch daran, wer es für einen Stylemann eben hat und ist natürlich abhängig vom Zoom-Level wieder und so weiter. Also ich muss jetzt sagen, es ist erstaunlich wenig passiert und so wenig, dass wir gesagt haben, dass das tragbar ist, diese Lösung sozusagen.
22:01
Also ich sage mal, jede andere Lösung würde quasi so aussehen, dass man die Daten komplett jedes Mal rendern müsste irgendwie. Was nicht realistisch ist mit dem Setup, den wir hier haben. Wobei das eben auch ein Vorteil möglicherweise von diesem Vektorkachel-Ansatz ist. Also für die Leute, die das
22:21
jetzt nicht genau kennen, was MEPNIC da macht. Vektorkacheln heißt nicht in dem Fall, dass die Vektoren zum kleinen, zum Browser ausgeliefert werden. Die werden immer noch auf dem Server gerendert. Aber die Aufteilung der Daten in Kacheln wird schon vorher gemacht. Das heißt, man muss nicht mehr die Datenbank bemühen und sagen, gib mir mal
22:42
irgendwie aus all diesen verschiedenen Layern all diese Informationen, such mir die alle zusammen, sondern die liegen alle schon so vor, indem alle Daten, die ich für eine Kachel brauche, liegen quasi schon vor, gefiltert vor. Und dadurch kann ich dann natürlich schneller rendern irgendwann mal. Google macht es ja auch. Die können ja auch alle Kacheln
23:02
live rendern inzwischen und angepasst an genau das, was der User gerade braucht und so. Möglich ist das auf jeden Fall, wenn man genug Hardware hat. Und ich denke, ganz langfristig wird der Weg dahin gehen, dass man entweder sowieso im Client rendert oder, wenn man noch auf dem Server rendert, dass man eben keine Bitmap-Kacheln mehr
23:22
zwischenspeichert, sondern nur Vektorkacheln zwischenspeichert. Und dann verschwinden all diese Probleme, die man hat, dass sich Label überdecken mit irgendwelchen Icons oder sowas. Wie gesagt, also bei uns war das jetzt relativ wenig der Fall. Aber das hängt natürlich vom Style und so weiter.
23:41
Gibt es sonst noch Fragen? Ganz oben. Ein bisschen Sport kriegst du auch noch heute. Das ist doch auch was. Ihr verwendet sicherlich hauptsächlich das Namengut
24:01
als OSM selbst. Was passiert mit dem Namengut aus der Wikipedia? Das differiert ja mitunter. Wie verfordert ihr mit diesen Differenzen? Die Namen aus der Wikipedia werden überhaupt nicht verwendet für diese Karte. Also da gibt es keinen direkten Zusammenhang, sag ich jetzt mal, zwischen oder keine Vermischung der Daten an der
24:21
Stelle, sondern wir nehmen hier nur die OSM-Daten und render eine Karte und zeigen die dann in einer Wikipedia- Seite an. Was es aber gibt, ist die Bestrebung, also gibt es schon verschiedene Sachen, dass man Daten abgleicht zwischen der Wikipedia oder so was,
24:40
oder dass man eben die in der Wikipedia vorliegenden Übersetzungen benutzt und die in OSM importiert oder so was. Da haben wir auch wieder zusammen mit dem Wikidata-Projekt. Das Wikidata-Projekt versucht ja aus der Freitext-Wikipedia- Sache jetzt mal Daten rauszuziehen und zum Beispiel die Übersetzung
25:02
von irgendwelchen Begriffen in strukturierter Form zu sammeln und das ist natürlich schon möglich, dass man das vielleicht dann wieder mit OSM abgleicht. Da muss man natürlich irgendwo immer wieder aufpassen, wie man das genau macht und so. Ich weiß nicht, willst du da vielleicht noch was zu sagen?
25:27
Da wäre eben das aktuelle Problem, dass der Wikipedia-Artikelname der muss halt eben eindeutig sein und deswegen ist der für die Kartendarstellung ungeeignet. Da gibt es Beispiele, da lautet
25:40
der Artikelname halt eben Frauenkirche in Klammern Dresden und auf der Karte weiß man, man schaut sich gerade Dresden an, da braucht man diese Informationen in den Klammern nicht mehr. Bei Wikidata sollen deswegen auch Labels gesammelt werden und da wäre das entsprechend an die Kurzform, die man eigentlich auch für eine Karte nehmen könnte. Wir wollen diese Übersetzung aber wirklich auch in
26:02
OpenStreetMap drinne haben, weil dann auch die Nominetim drauf zugreifen kann und alle möglichen anderen Dienste. Das ist der Hintergrund. Gut, wenn es sonst keine weiteren Fragen gibt,
26:21
Sie können auch schon den Raum wechseln, falls Sie sich beeilen möchten. Ganz kurz, aber diese Geschichte, wenn ich irgendwie eine deutsche, wenn ich eine Karte zeichne mit deutschen Labels, dann habe ich immer das Problem, dass die politisch nicht so ganz korrekt ist,
26:41
weil ich dann plötzlich allen möglichen früher mal Nazi-besetzten Orten plötzlich diese politisch nicht ganz korrekte Namen aus der Vergangenheit zuordne. Hat einer von euch da oder habt ihr euch da mal im Rahmen von einem Projekt irgendwelche Gedanken gemacht, wie man mit akzeptabel, also ich meine, wenn ich an Milan, wenn ich an Milano
27:01
Milan dran schreibe, dann ist das kein Problem, aber es gibt eine ganze Menge Orte, wenn ich da den anführungszeichen deutschen Namen dran schreibe, dann ist das ein Problem. Ideen, wie man das lösen kann? Das ist auf jeden Fall ein Problem, aber das sollte man sich als Entwickler auch zurückziehen und sagen, das ist ein Community- Problem und da müssen Diskussionen laufen, wenn
27:21
das geht und man nutzt halt eben diese Definition und zeigt die an. Wie die genutzt wird, müssen andere entscheiden.
27:41
Also ich glaube, das ist ich sag mal Grund, jetzt hat er mich abgehört. Okay, also ich glaube, das ist grundsätzlich kein anderes Problem, als viele andere Probleme, die wir haben in der Community, wo wir uns einigen müssen,
28:00
welche Daten wir wie erfassen und wie interpretieren. Das mag zwar irgendwie manchmal etwas größer erscheinen, als andere Probleme das sind, aber wenn sich irgendwie die Radfahrer oder irgend sowas darüber streiten, wie sie ihre Radrouten erfassen und verschiedene Leute da verschiedene Schemata haben oder sowas, ist es letztlich genau das gleiche.
28:20
Wir müssen in der Community irgendwelche Gemeinsamkeiten finden, gemeinsame Ideen finden, wie bestimmte Sachen eingetragen werden. Nur dann kann auch das Projekt als Community funktionieren. Und ja, da ist noch etwas Arbeit zu tun, aber ich bin da eigentlich relativ optimistisch.
Recommendations
Series of 11 media
Series of 2 media