Nachbau des Mapnik-Stils mit CartoCSS für OSM.org

Nach und nach werden die Anfragen (bisher aus AU, GB, ES, PT und jeweils Umgebung) zum neuen Tile-Server geleitet, welcher CartoCSS verwendet:
http://lists.openstreetmap.org/pipermai … 10014.html
http://lists.openstreetmap.org/pipermai … 15003.html
http://lists.openstreetmap.org/pipermai … 11712.html
http://lists.openstreetmap.org/pipermai … 00601.html

Interessant ist auch, dass der neue Tile-Server zzt. auch Kacheln mit Zoom 19 ausliefert. 🙂

Video dazu:
http://vimeopro.com/openstreetmapus/sta … o/68093876

Gruß,
Mondschein

Seit gestern Mittag laufen nun alle Requests ueber den neuen Server. Ob das bereits dauerhaft so ist, oder nur kurzfristig zum Testen weis ich aber nicht.

Mir ist bloß aufgefallen, dass seit kurzem kein railway=level_crossing mehr gerendert wird.

jetzt gehts wieder

Bekommt ihr was unter dem Link http://bl.ocks.org/tmcw/raw/4271706/#15 … /-122.4376 angezeigt?

Eigentlich sollte da ja eine zweigeteilte Darstellung erscheinen (alt/neu) Bei mir wird aber nur alt geladen 😄

Pajopath wrote:

Bekommt ihr was unter dem Link http://bl.ocks.org/tmcw/raw/4271706/#15 … /-122.4376 angezeigt?
Eigentlich sollte da ja eine zweigeteilte Darstellung erscheinen (alt/neu) Bei mir wird aber nur alt geladen 😄

Bei mir ebenso. Manueller Aufruf einer Kachel ergibt einen 500er. Wenn das jetzt aber bei osm.org Standard ist sähe man eh keinen Unterschied, da die "alten" Kacheln die neuen wären 😉

amm wrote:

Seit gestern Mittag laufen nun alle Requests ueber den neuen Server. Ob das bereits dauerhaft so ist, oder nur kurzfristig zum Testen weis ich aber nicht.

Jetzt ist die Umstellung offiziell abgeschlossen:
http://lists.openstreetmap.org/pipermai … 67802.html

Gruß,
Mondschein

Pajopath wrote:

Bekommt ihr was unter dem Link http://bl.ocks.org/tmcw/raw/4271706/#15 … /-122.4376 angezeigt?

Falls trotzdem noch jemand Interesse daran hat die Renderings zu vergleichen: http://bl.ocks.org/tyrasd/raw/6164696/ ist eine aktualisierte Variante des Tools. (Als Referenz wird das Mapnik-Rendering vom Wikimedia "toolserver" verwendet).

Der Wikimedia toolserver ist moeglicherweise nicht der beste Vergleich. Der laeuft noch mit Mapnik 0.7 und einem entsprechend alten Kartenstiel. Insofern duerfte es dort auch so einige Unterschiede geben zu dem was man zuvor auf osm.org gesehen hat.

Da der auf der neuen Technik basierende Stil nun der offizielle ist, denke ich, wird man nun Sachen aendern und fixen, unabhaengig davon wie sie zuvor aussahen und ob sie korrekt oder nicht waren.

Gravitystorm, der den Konvertierung hauptsaechlich gemacht hat, wollte die beiden Kartenstile zunaechst so aehnlich wie moeglich halten, damit die Akzeptanz der technischen Umstellung auf Carto nicht von der Akzeptanz der kartographischen, stylistischen Entscheidungen abhaengt. Angesicht der Tatsache das, wie man an den Aenderungen auf osm.org sieht, selbst kleinere stylistische Aenderungen immer wieder fuer viel Wirbel in der Community sorgen, denke ich war die Entscheidung seh sinnvoll.

Für die Umstellung sicher die richtige Entscheidung. Trotzdem ist jetzt hoffentlich der Zeitpunkt gekommen, mal ein paar Dinge zu bearbeiten, die beim Mapnik-Stil schon länger im Argen liegen. Vor allem hoffe ich doch, dass man von den Franzosen das Rendern der Sportplatzmarkierungen übernimmt.

Man wird sehen muessen wie viel "Manpower" fuer Verbesserungen zur verfuegung steht. Aber der ganze Sinn hinter der Umstellung auf Carto war es Aenderungen einfacher zu machen womit sich hoffentlich wieder jemand findet der das Stylesheet oderdentlich maintained. Zunaechst wird wohl gravitystorm (der ersteller der OpenCycleMap) der Maintainer des Stiles werden, nachdem Steve Chilton der frueher die Hauptarbeit gemacht hat schon eine Weile nicht mehr aktiv zu sein scheint. Aber wenn jemand anderes, mit hilfe von pull requests, zeigt das er gute Arbeit in der Hinsicht erledigt kann es gut sein das die "Maintainer Position" an jemanden weiter gegeben wird.

Der groesste Vorteil von Carto duerft wohl sein, das es dafuer mit TileMill einen semi-wysiwyg Editor gibt, das das Bearbeiten des Styles deutlich erleichtern sollte. Somit wird es hoffentlich auch leichter fuer Drittanbieter den OSM-Style als Basis zu verwenden und dann zum Beispiel das Farbschema an ihre Beduerfnisse einfach anzupassen.

Insofern duerfte hoffentlich in der Tat der Zeitpunkt gekommen sein in dem man Sachen (nach fast einem Jahr Pause) wieder verbessert.

Schaetzungsweise ist die beste Stelle Verbesserungsvorschlaege einzureichen unter https://github.com/gravitystorm/openstreetmap-carto . Wobei "bitte rendert dieses oder jenes obscure tagging feature" erst einmal nicht sonderlich hoch auf der Prioritaetenliste stehen duerfte. Allerdings beherscht der neue Renderingserver nun auch Z19 (auch wenn das auf osm.org noch nicht aktiviert ist), womit wieder deutlich mehr Platz ist um spaeter einmal das rendern von POIs auszubauen, wenn die groesseren Probleme abgearbeitet sind.

amm wrote:

...
Der groesste Vorteil von Carto duerft wohl sein, dass es dafuer mit TileMill einen semi-wysiwyg Editor gibt, das das Bearbeiten des Styles deutlich erleichtern sollte. Somit wird es hoffentlich auch leichter fuer Drittanbieter den OSM-Style als Basis zu verwenden und dann zum Beispiel das Farbschema an ihre Beduerfnisse einfach anzupassen.

Insofern duerfte hoffentlich in der Tat der Zeitpunkt gekommen sein, in dem man Sachen (nach fast einem Jahr Pause) wieder verbessert.

... Allerdings beherscht der neue Renderingserver nun auch Z19 (auch wenn das auf osm.org noch nicht aktiviert ist), womit wieder deutlich mehr Platz ist um spaeter einmal das rendern von POIs auszubauen, wenn die groesseren Probleme abgearbeitet sind.

In Zukunft auch Z19 anbieten zu können, klingt sehr gut. Es gibt doch einige Bereiche, die in OSM mittlerweile sehr dicht erfasst sind. Dort würde man mit Z19 sicher einiges mehr zeigen/sehen können.

Ansonsten scheint mir die Umstellung auf Carto sehr gut gelungen. Ich konnte bisher keine Probleme finden. Erst mit dem Hinweis von tyr_asd auf http://bl.ocks.org/tyrasd/raw/6164696/ konnte ich einige kleine Unterschiede in der Farbgebung (trunk, primary, tertiary) erkennen. Ansonsten war der Wechsel osm.org mit Carto zu Mapnik-alt (vom Wikimedia-Server) in der Vergleichskarte nur gelegentlich an der Platzierung von Namen und einer leicht anderen Auswahl an POI zu erkennen. Das mag teilweise jedoch auch an unterschiedlichen Datenständen liegen (Beispiel Bonn-Endenich).

Edbert (EvanE)

amm wrote:

Der Wikimedia toolserver ist moeglicherweise nicht der beste Vergleich. Der laeuft noch mit Mapnik 0.7 und einem entsprechend alten Kartenstiel. Insofern duerfte es dort auch so einige Unterschiede geben zu dem was man zuvor auf osm.org gesehen hat.

Klar, aber eine andere Vergleichsgrundlage kenne ich nicht. Zumindest der Mapnik-Stil sollte aber auf dem Toolserver und dem alten OSM-Server der gleiche gewesen sein.

amm wrote:

Da der auf der neuen Technik basierende Stil nun der offizielle ist, denke ich, wird man nun Sachen aendern und fixen, unabhaengig davon wie sie zuvor aussahen und ob sie korrekt oder nicht waren.

Logisch, alles andere wäre Unsinn. Das Tool hilft dabei sich einen Eindruck vom Fortschritt zu verschaffen. 😎

amm wrote:

Gravitystorm, der den Konvertierung hauptsaechlich gemacht hat, wollte die beiden Kartenstile zunaechst so aehnlich wie moeglich halten, damit die Akzeptanz der technischen Umstellung auf Carto nicht von der Akzeptanz der kartographischen, stylistischen Entscheidungen abhaengt.

Das stimmt, aber mittlerweile sind wir schon bei Version 2.3.2 angelangt, und einige sichtbare Änderungen haben es auch schon in das Style geschafft. Z.B. die etwas dunklere Farbe der primary-roads oder größere Zeilenabstände.

In welchen Intervallen fließen denn die Änderungen am carto-Stil, die schon im github-master sind, in neue Renderings ein? Gibt es da Aussagen von Andy Allan zu?

Geplant ist wohl das es zukuenftig "releases" [1] des Stylesheets gibt. Wie haeufig es neue releases geben wird haengt vermutlich davon ab wie viele und wie wichtig die Aenderungen sind. Da aber bei jeder Aenderung des Stylesheets nun automatisch ein komplettes Neurendern einsetzt (z0 - z12 als pre-rendering und der Rest on demand) und dies die rendering Server dann einige Tage "ueberlastet" wodurch die normalen Updates im generellen Neurendern untergehen und somit nicht die gewohnte Aktuallitaet erzielt werden kann, kann man vermutlich davon ausgehen das es nicht wegen jeder kleinen Aenderung geschieht. Es sollte aber haeufiger geschehen als zuletzt mit dem alten Style, der ja quasi gar nicht mehr aktualisiert wurde.

Direkte Aussagen von Andy sind mir dazu jedoch nicht bekannt. Das wird vermutlich wie das meiste einfach nach Gefuehl gemacht... ;-)

[1] https://github.com/gravitystorm/openstr … o/releases

Hi,

nachdem das ganze Rendering umgestellt wurde , scheint der /dirty-Trick nicht mehr zu funktionieren. Zumindest sehe ich keine Reaktion. Auch bei /status sehe ich nicht vernünftiges.
Kann das jemand bestätigen?

Weiterhin gibt es anscheinend noch keine Munin-Ausgabe der neuen Rendering-Queue oder die Statistik hängt: http://munin.openstreetmap.org/openstre … queue.html
Any Infos?

Gruss
walter

Ich habe gerade getestet und nicht ungewöhnliches festgestellt.

Die fehlende Statistik kann ich bestätigen.

sonst weiß ich aber auch nichts.

Die "fehlende" Statistik liegt daran das der Server gewaechselt wurde. Die Kacheln werden nun von Orm gerender und ausgeliefert. Dem entsprechend finden sich die Statistiken nun unter http://munin.openstreetmap.org/openstre … index.html . Yevaud wird gerade neu installiert und ebenfalls auf Carto umgestellt. Nach dem neu Import wird er dann als zweiter tile Server wieder zur Verfuegung stehen. Im Moment ist so weit ich weis geplant diese unabhaengig von einander zu Betreiben und manche Laender ueber den einen Server und andere Laender ueber den anderen Server laufen zu lassen.

Bezueglich /diry: das sollte im Prinzip schon funktionieren. Da nach dem Stylechange wie oben erwaehnt der komplette Cache "invalidiert" wird und somit alles neu gerendert werden muss, ist der Server damit derzeit etwas ueberlastet und verwirft somit viele /dirty Anfragen ( http://munin.openstreetmap.org/openstre … essed.html die dropped Statistik ) Das gilt auch fuer das renderen von sich geaenderten Tiles, wodurch die automatische Aktualisierung der Tiles nicht so gut wie normalerweise funktioniert. Das duerfte sich in ca 1 - 2 Tagen wieder legen wenn der Server ausreichend Kacheln neu gerendert hat um mit der Menge an Anfragen wieder klar zu kommen.

Da das bei jedem Style-Update wieder geschehen wird, ueberlege ich mir gerade in mod_tile / renderd eine weitere Prioritaetsstuffe einzubauen um die Aktualitaet waerend der cache invalidation Phase nicht (oder weniger) zu gefaehrden.

Was ich mich schon lange frage: warum ist die Queue auf eine derart geringe Länge (1000) beschränkt? Wenn nicht gerade massenhaft Niedrigzoomkacheln gerendert werden müssen, trägt Mapnik diese Queue in zwei Minuten ab. Bei höherem Limit (zunächst etwa 10^5; bei positiven Ergebnissen auch mehr) würden weniger Anfragen (dirty) verworfen und stattdessen einfach später ausgeführt.

Der noch gueltige Hauptgrund duerfte sein das es als etwas "verkappte" Prioritisierung fungiert. Wenn der Renderer ueberlastet ist und X% der Anfragen verwirft hat jede Anfrage eine gewisse Wahrscheinlichkeit das just in dem Moment ein Platz in der Queue frei ist und diese somit dann gerendert wird. Sehr beliebte Kacheln senden viele Anfragen an den Renderer und sehen somit eine deutlich erhoehte Wahrscheinlichkeit das wenigstens eine der Anfragen in die Queue rein kommt. Damit werden die viel besuchten Tiles prioritisiert.

Historisch hat es noch einen Performance Grund. Bei jeder Anfrage muss die Queue durchsucht werden um Duplikate zu finden. Da die Queue urspruenglich als linear list umgesetzt war, war die Queue Laenge stark begrenzt. Das ist aber schon seit langem nicht mehr der Fall. Das Limit wurde aber nie angepasst.

Abgesehen davon ist es fraglich wie weit eine verlaengert Queue tatsaechlich etwas bringt. Zumindestens in Faellen wie jetzt, wo die Queue ueber Tage hinweg am Anschlag ist (inklusive waerend der Nacht) gibt es kein wirklich naehe liegendes "Spaeter" auf das man es verschieben kann. Mit der gestiegenen Performance (Orm schaft inzwischen ca 14 metatiles / s) wird die Queue zeitlich gesehen jedoch immer kuerzer. Die 1000 metatile queue ist inzwischen gerade einmal knapp ueber einer Minute. Insofern ist denke ich eine gewisse Erhoehung durch aus sinnvoll und moeglich.

amm wrote:

Abgesehen davon ist es fraglich wie weit eine verlaengert Queue tatsaechlich etwas bringt. Zumindestens in Faellen wie jetzt, wo die Queue ueber Tage hinweg am Anschlag ist (inklusive waerend der Nacht) gibt es kein wirklich naehe liegendes "Spaeter" auf das man es verschieben kann. Mit der gestiegenen Performance (Orm schaft inzwischen ca 14 metatiles / s) wird die Queue zeitlich gesehen jedoch immer kuerzer. Die 1000 metatile queue ist inzwischen gerade einmal knapp ueber einer Minute. Insofern ist denke ich eine gewisse Erhoehung durch aus sinnvoll und moeglich.

Für Situationen, wo der ganze Cache verworfen werden muss (insbesondere bei Änderungen des Styles), sollte man sich eventuell eine andere Strategie überlegen, wie von dir bereits angedeutet.

@Oli-Wan:
Ich würde die Cache-Größe nicht gleich um den Faktor 10 erhöhen. Eine Verdoppelung auf 2000 könnte man jedoch durchaus mal ausprobieren. Je nach dem, wie sich das in den verschiedenen Situationen (Normalbetrieb / Cache verworfen) auswirkt, kann man dann weiter erhöhen oder ggfs. auch wieder einen niedrigeren Wert einstellen.

Eine Queue-Größe von 2000 würde bei 14 Meta-Tiles/sek einen Backlog von knapp über 2 Minuten noch ohne Ausfälle bewältigen. Wenn man jedoch wie zur Zeit ca. 200 Metatiles pro Sekunde verwerfen muss, dann hilft eine Queue-Größe von 10000 wahrscheinlich auch nicht mehr viel.
Wenn in Zukunft das Verwerfen des Cache öfter notwendig wird, dann hilft wahrscheinlich nur eine Anpassung der Strategie. Dabei stellt sich natürlich die Frage, was wichtiger ist: angefragte Kacheln oder geänderte Kacheln.

Edbert (EvanE)

@amm: Danke für die Erläuterungen, damit wird einiges klarer.

Die behelfsmäßige Priorisierung würde mit einer längeren Queue genauso funktionieren, sobald diese gesättigt ist, nur daß die "erfolgreichen" Requests länger bis zur Ausführung warten müßten. Bis die Queue voll ist, werden zumindest alle noch eingestellt statt verworfen, und gewöhnliche Lastspitzen (also alles außer einer Style-Änderung) könnten besser abgefangen werden. Wobei ich mich frage, ob bei einer Style-Änderung überhaupt alles neu gerendert werden muß - dafür, daß bloß hier und da ein paar Objekte neu auftauchen oder sich einzelne Symbole ändern. Meist sind es ja Änderungen im Detail, die sich in den niedrigen Zoomstufen kaum auswirken. Es wird ja wohl nicht von heute auf morgen das Meer lila werden.

@EvanE: Ich habe nicht einen Faktor 10 vorgeschlagen, sondern einen Faktor 100. Das ist immer noch ein Aufkommen, das im Normalfall in zwei oder drei Stunden abgearbeitet ist. Einen Faktor 2 würde man vermutlich kaum sehen.

amm wrote:

Die Kacheln werden nun von Orm gerender und ausgeliefert.

Prima, dass man das auch mal erfährt 🙁 Im Wiki steht immer noch Yevaud als Renderer drin und da schaut man dann natürlich nach, wenn es mal klemmt.

Gruss
walter

Oli-Wan wrote:

@amm: Danke für die Erläuterungen, damit wird einiges klarer.
...

@EvanE: Ich habe nicht einen Faktor 10 vorgeschlagen, sondern einen Faktor 100. Das ist immer noch ein Aufkommen, das im Normalfall in zwei oder drei Stunden abgearbeitet ist. Einen Faktor 2 würde man vermutlich kaum sehen.

Sorry, da habe ich falsch gerechnet / unaufmerksam gelesen.
In dem Fall ersetze Faktor 2 durch Faktor 10. Das sollte für einen Test erst einmal genügen. Man weiß ja nie im voraus, ob nicht irgendwelchen unerwarteten Nebeneffekte auftreten.

Edbert (EvanE)

wambacher wrote:

amm wrote:

Die Kacheln werden nun von Orm gerender und ausgeliefert.

Prima, dass man das auch mal erfährt 🙁 Im Wiki steht immer noch Yevaud als Renderer drin und da schaut man dann natürlich nach, wenn es mal klemmt.

Auf welche Wiki Seite beziehst du dich? (Es gibt wahrscheinlich viele Seiten auf denen etwas falsches steht... 😉) Dann kann man sie vielleicht aendern.

Wobei die Information sich vermutlich in den naechsten Tagen schon wieder aendern werden. Yevaud ist halb durch mit dem re-import und wenn der fertig ist wird Yevaud dann schaetzungsweise auch wieder in den Dienst gestellt. Wie genau die Arbeitsteilung dann zwischen Orm und Yevaud aussehen wird weis ich nicht. Ich weis auch nicht ob das ueberhaupt schon entschieden ist. Wenn sich das System etwas mehr heraus kristalisiert hat, wird man schauen koennen ob man die Statistiken dafuer verbessern kann und die relevanten Information einfacher zugaenglich machen kann.

amm wrote:

Auf welche Wiki Seite beziehst du dich?

http://wiki.openstreetmap.org/wiki/Platform_Status
Direkt auf der Wiki-Hauptseite verlinkt.

Gruß,
Mondschein

Ah, der gute alte Platform Status. Den hatte ich ganz vergessen... Naja, ich habe den jetzt geaendert und werde versuchen dran zu denken den auch wieder weiter zu aendern wenn yevaud wieder ebenfalls verwendet wird.

Mondschein wrote:

amm wrote:

Auf welche Wiki Seite beziehst du dich?

http://wiki.openstreetmap.org/wiki/Platform_Status

Nicht ganz:
Platform_Status wurde inzwischen angepasst - ich meinte aber Servers - da hatte ich nachgesehen, weil ich dort den neuen Server suchte.

Danke für's Anpassen und Schwamm drüber.
Walter

ps: wenn ich die lokale IP wüßte, könnte ich es sogar ändern; aber amm wird das schon hinkriegen. 😉

amm wrote:

Wobei die Information sich vermutlich in den naechsten Tagen schon wieder aendern werden. Yevaud ist halb durch mit dem re-import und wenn der fertig ist wird Yevaud dann schaetzungsweise auch wieder in den Dienst gestellt. Wie genau die Arbeitsteilung dann zwischen Orm und Yevaud aussehen wird, weis ich nicht. Ich weis auch nicht, ob das ueberhaupt schon entschieden ist. Wenn sich das System etwas mehr heraus kristalisiert hat, wird man schauen koennen ob man die Statistiken dafuer verbessern kann und die relevanten Information einfacher zugaenglich machen kann.

Man hat generell zwei Optionen:
- Lastverteilung: Ein Render-Server für Europa/Asien/Afrika,
Ein Render-Server für Amerika, Ozeanien, Pazifik.
- Ausfallsicherheit: Beide Render-Server erzeugen die gleichen Daten.

Das sollte man sorgfältig abwägen.
Mit verteilten Tile-Servern hat man ja bereits Erfahrungen, auf denen man ggfs. aufbauen kann.

Edbert (EvanE)

EvanE wrote:

[
Man hat generell zwei Optionen:
- Lastverteilung: Ein Render-Server für Europa/Asien/Afrika,
Ein Render-Server für Amerika, Ozeanien, Pazifik.
- Ausfallsicherheit: Beide Render-Server erzeugen die gleichen Daten.

Ich würde Lastverteilung bevorzugen. Damit geht das Rendern neuer Seiten überall für alle schneller.
Ausfallsicherheit erscheint mir nicht ganz so wichtig, solange die vorgeschalteten Tile-Server überhaupt etwas ausliefern - und das tun sie ja.

Gruss
walter

...und im Ernstfall könnte man immer noch dem überlebenden Tile-Server sagen, er soll alle Cache-Server beliefern.

Im Moment ist wie gesagt geplant das einige der Frontend Caches auf den einen Rendering Server zugreifen und die anderen Frontend Caches auf den anderen Rendering Server.

Das heist wenn man z.B. in Deutschland sitzt bekommt man die Tiles von Server A gerendert, ob man nun einen Auschschnitt in Deutschland betrachtet oder einen in den USA oder Australien. Umgekehrt wenn man z.B. in den USA sitzt bekommt man alle seine Tiles von Server B gerendert. Insofern haben beide Server alle noetigen Daten und mehr oder weniger auch Tiles.

Da jedoch vermutlich Leute in Deutschland ueberwiegend Kartenausschnitte in Deutschland betrachten und die die in den USA sitzen ueberwiegend amerikanische Ausschnitte, und da die tiles on demand aktualisiert und neu gerendert werden, sollte das ganze auch eine deutlich Lastverteilung ergeben ohne das man die Ausfallsicherheit (uebermaessig) reduziert. Es kann beim "fail-over" dann jedoch fuer eine Zeit haeufiger zu veralteten Tiles kommen, da die Tiles in der anderen Region zwar weitestgehend vorhanden sein duerften, aber eben nicht so akutell gehalten werden und es dann zu einer Ueberlastung des on-the-fly updatens kommen kann.

etwas OT:

Dann könnte man ja leicht unterschiedliche Rendering-Rules implementieren: Die Amis sehen auf "ihrem" Renderer geblurte Military Areas und wir kriegen die volle Pracht 😉

Duck&Cover
Walter

amm wrote:

Im Moment ist wie gesagt geplant das einige der Frontend Caches auf den einen Rendering Server zugreifen und die anderen Frontend Caches auf den anderen Rendering Server.

Das heist wenn man z.B. in Deutschland sitzt bekommt man die Tiles von Server A gerendert, ob man nun einen Auschschnitt in Deutschland betrachtet oder einen in den USA oder Australien. Umgekehrt wenn man z.B. in den USA sitzt bekommt man alle seine Tiles von Server B gerendert. Insofern haben beide Server alle noetigen Daten und mehr oder weniger auch Tiles.

Da jedoch vermutlich Leute in Deutschland ueberwiegend Kartenausschnitte in Deutschland betrachten und die die in den USA sitzen ueberwiegend amerikanische Ausschnitte, und da die tiles on demand aktualisiert und neu gerendert werden, sollte das ganze auch eine deutlich Lastverteilung ergeben ohne das man die Ausfallsicherheit (uebermaessig) reduziert. ...

Ah ja gut.
So kann man eine Lastverteilung erreichen, ohne dass man die Ausfallsicherheit opfern muss.

Edbert (EvanE)

Nun sind sowohl Orm als auch Yevaud im Betrieb und rendern "froehlich" vor sich hin.

Inzwischen sind damit 12 Frontend Proxyserver verteilt in der Welt und 2 Rendering Backendserver in London im Betrieb um sicher zu stellen das die Standard OSM Kacheln so schnell, zuverlaessig und aktuell wie moeglich sind.

Die geographische Verteilung der Laender auf die einzelnen Proxies kann man unter http://dns.openstreetmap.org/tile.opens … p.org.html sehen und die Verteilung der Proxyserver auf die backend rendering server unter http://dns.openstreetmap.org/render.ope … p.org.html .

Dort sieht man das Deutschland derzeit von einem Proxyserver von Hetzner in Falkenstein versorgt wird, der wiederum seine Tiles von Yevaud bekommt.

Wobei sich die Konfiguration der Frontend und Backendserver jederzeit aendern koennen wenn sich das System selbst reconfiguriert um etwaige Ausfaelle oder Ueberlastungen auszugleichen.

WoW !

Die Sache sieht wirklich rund aus - wenn ich noch an OSM von 2009 denke (da bin ich eingestiegen) so liegen da Welten dazwischen.

Gratulation - und weiter so.

Gruss
walter

Jetzt gibt es auch Z19 auf osm.org.

Also ab ans micromapping... ;-)

amm wrote:

Jetzt gibt es auch Z19 auf osm.org.

Aktuell geht eher gar nichts mit Mapnik.

Christian

brogo wrote:

amm schrieb: Jetzt gibt es auch Z19 auf osm.org.
Aktuell geht eher gar nichts mit Mapnik.

Hallo Christian

Mittlerweile geht alles recht flott.
Bei Z19 dauert es mal 1-2 Sekunden bis die Kacheln gerendert sind. Aber das halte ich für durchaus schnell.

Mich würde in nächster Zeit interessieren, wie die Erfahrungen mit dem neuen Zoomlevel 19 sind.
- Wie groß ist die zusätzliche Belastung durch Z19
Rechenzeit (Erstellen) Speicherplatz (Tile-Server), ...
- Wieviele Gebiete (% der Landmasse) werden in Z19 angefragt.

Es gibt ja durchaus dünn gemappte Gebiete in denen Z15 im Prinzip ausreichen würde. Genauso gibt es Gebiete (z.B. Innenstädte), die massiv von Z19 profitieren.

Edbert (EvanE)

brogo wrote:

Aktuell geht eher gar nichts mit Mapnik.

Da war etwas beim GeoDNS falsch:
http://lists.openstreetmap.org/pipermai … 67844.html
Davon waren (oder sind?) nicht alle Nutzer betroffen.

Gruß,
Mondschein

Mondschein wrote:

brogo wrote:

Aktuell geht eher gar nichts mit Mapnik.

Da war etwas beim GeoDNS falsch:
http://lists.openstreetmap.org/pipermai … 67844.html
Davon waren (oder sind?) nicht alle Nutzer betroffen.

Gruß,
Mondschein

tja, dann war mein nächtliches Problem (*) wohl doch nicht "selbst gemacht". Ubuntu und mein Provider unschuldig 😉
Der rettende Reboot hat wohl nur den lokalen DNS-Cache geleert und dann ging es wieder. DNS kann manchmal wirklich "grausam" sein.

Gruss
walter

• ) http://forum.openstreetmap.org/viewtopi … 49#p354549
  

edit: seltsam -> grausam

Mondschein wrote:

Da war etwas beim GeoDNS falsch:
http://lists.openstreetmap.org/pipermai … 67844.html
Davon waren (oder sind?) nicht alle Nutzer betroffen.

Noch einige Details dazu:
http://lists.openstreetmap.org/pipermai … 67870.html

Gruß,
Mondschein

Irgendwie werden keine Brücken mehr bei highway=living_street gerendert. 🙁

Thomas8122 wrote:

Irgendwie werden keine Brücken mehr bei highway=living_street gerendert. 🙁

Wurde schon gemeldet:
https://github.com/gravitystorm/openstr … issues/190
Vielleicht sollte man dort noch erwähnen, dass das im alten Stil angezeigt wurde.

Gruß,
Mondschein

Ich hab aber keine Lust mich deshalb bei github anzumelden.

Thomas8122 wrote:

Ich hab aber keine Lust mich deshalb bei github anzumelden.

Wenn dir 10 Sekunden zu viel sind...
Außer Benutzername, Passwort und irgendeine E-Mail-Adresse (wird nicht überprüft, könnte also theoretisch auch eine ungültige sein, wie z.B. a@b) muss man dort nichts angeben.
Alternativ kann man auch eine Wegwerfadresse wie z.B. trash-mail.com verwenden, dort muss man keinerlei Daten angeben, auch keine andere E-Mail-Adresse.

Gruß,
Mondschein

Mondschein wrote:

... und irgendeine E-Mail-Adresse (wird nicht überprüft, könnte also theoretisch auch eine ungültige sein ...

Das muß man aber wissen, damit die Hemmschwelle sinkt. Das ganze Theater mit Mail angeben, Mail lesen, Bestätigung schicken ist doch arg lästig.

Gruss
walter

Na wenn das so ist...

Mondschein wrote:

Thomas8122 wrote:

Ich hab aber keine Lust mich deshalb bei github anzumelden.

Wenn dir 10 Sekunden zu viel sind...
Außer Benutzername, Passwort und irgendeine E-Mail-Adresse [...]

Mir würde es da weniger um die 10 Sekunden gehen, auch das mit dem Verteilen von Emailadressen ist für mich kein Problem. Ich habe aber keine Lust überall dabei sein zu müssen, nur um *einmalig* etwas jemandem mitteilen zu können (Datenbank mit nunmehr 52 Zugangsdaten/Accounts - das ist genug). Wer von mir erwartet, dass ich erst einen Account anlegen muss damit ich Feedback geben kann, der will mein Feedback nicht. Wer Interesse an Kommunikation hat sorgt für bessere Möglichkeiten.

Ne...du willst eine Veränderung 😉

Joachim Moskalewski wrote:

Wer von mir erwartet, dass ich erst einen Account anlegen muss damit ich Feedback geben kann, der will mein Feedback nicht.

Das könnte man auch von der anderen Seite sehen:
Wer sich keinen Account zulegen möchte um sein Feedback zu geben, damit andere etwas verbessern, ...

Sowohl du, als auch die Leute, welche sich um den Stil kümmern, sind Freiwillige und bekommen dafür keinen einzigen Cent.

Jahrelang gab es beim Stil keine Weiterentwicklung.
Jetzt haben sich Freiwillige gefunden, die das endlich übernehmen und wenn es für diese einfacher ist, Github zu verwenden, dann habe ich nichts dagegen, sondern bin froh, dass sich endlich etwas bewegt.

Gruß,
Mondschein

Du könntest auch einfach an einen von denen eine PN schreiben 😉

Mondschein wrote:

Joachim Moskalewski wrote:

Wer von mir erwartet, dass ich erst einen Account anlegen muss damit ich Feedback geben kann, der will mein Feedback nicht.

Das könnte man auch von der anderen Seite sehen:
Wer sich keinen Account zulegen möchte um sein Feedback zu geben, damit andere etwas verbessern, ...

Das sind typische Phrasen kommend von EDV Seite. Nur:

Nützt diese Betrachtung irgend was? Ändert diese irgend etwas am Umstand? Kommt damit auch nur eine Seite auch nur einen einzigen Schritt weiter?

Mondschein wrote:

Jetzt haben sich Freiwillige gefunden, die das endlich übernehmen und wenn es für diese einfacher ist, Github zu verwenden, dann habe ich nichts dagegen, sondern bin froh, dass sich endlich etwas bewegt.

Das ist okay, doch meine Aussage war und ist schlicht diese: Sie wollen nicht wirklich Feedback. (Auch ich habe bis vor kurzem Open Source Software zur Verfügung gestellt. Um Feedback zu erhalten habe ich dafür gesorgt, dass Anwender an meine Mailadresse kommen, und auf der entsprechenden Webseite ein Kontaktformular war - und niemand einen Account benötigt. Letzteres ist für mich ein Nogo.)

Joachim Moskalewski wrote:

Letzteres ist für mich ein Nogo.

Das mag so sein, andere dürfen es aber auch anders sehen. 😉

Ich handle das ja ähnlich wie du. Allerdings nur, weil ich weiß, dass das Feedback eher gering ist und ich der einzige bin, der mit dem Feedback arbeiten muss. Bei größeren Projekten halte ich diesen Weg aber für komplett unmöglich, weil der Verwaltungsaufwand zu groß wird.

Andersrum hängt die Wahl des Feedback-Systems auch sehr stark davon ab, wie ich das Feedback haben möchte. Beispielweise nutzt mkgmap eine Mailingliste, auf der die Devs recht viel mit den (Power-) Usern diskutieren. Mir als Nutzer gefällt das System. Anderen Nutzer finden eine Mailingliste komplett unpassend, weil sie gar nicht mit umfangreich mit den Devs diskutieren wollen, um denen zu sagen, dass der Wald grün besser aussehen würde...

Seit neuestem werden keine Straßennamen bei highway=living_street mehr angezeigt 🙁 . Ist wahrscheinlich nur konsequent da ja auch keine Brücken angezeigt werden. Als nächstes sind sie dann ganz verschwunden 🙄

Thomas8122 wrote:

Seit neuestem werden keine Straßennamen bei highway=living_street mehr angezeigt 🙁 . Ist wahrscheinlich nur konsequent da ja auch keine Brücken angezeigt werden. Als nächstes sind sie dann ganz verschwunden 🙄

soll das der Versuch einer Fehlermeldung sein oder willst du einfach nur motzen?

wambacher wrote:

soll das der Versuch einer Fehlermeldung sein oder willst du einfach nur motzen?

Ja und ja

So ein Style-Update scheint wohl immer ganz böse für den Server zu sein. Kann daher nicht schauen, wie es aussieht, da ich nur alte Tiles bekomme.
http://munin.openstreetmap.org/openstre … ml#renderd

Thomas8122 wrote:

Seit neuestem werden keine Straßennamen bei highway=living_street mehr angezeigt 🙁 . Ist wahrscheinlich nur konsequent da ja auch keine Brücken angezeigt werden. Als nächstes sind sie dann ganz verschwunden 🙄

Mit der Regel "wir beschriften alles, was ein Strich ist" war ja niemand wirklich zufrieden. Dummerweise war die für die Mehrheit aller -- auch gewünschter -- Beschriftungen verantwortlich weswegen sich lange Zeit auch keiner rangewagt hat angesichts der zu erwartenden Kritik. Die wird jetzt nach und nach ausgebaut (für Flächen auch)und dabei wird das eine oder andere Label vorübergehend oder dauerhaft auf der Strecke bleiben...

Grüße, Max

maxbe wrote:

Die wird jetzt nach und nach ausgebaut (für Flächen auch) und dabei wird das eine oder andere Label vorübergehend oder dauerhaft auf der Strecke bleiben...

Oh, das sind ja mal erfreuliche Nachrichten 🙂

Gruss
walter

Thomas8122 wrote:

Seit neuestem werden keine Straßennamen bei highway=living_street mehr angezeigt 🙁 . Ist wahrscheinlich nur konsequent da ja auch keine Brücken angezeigt werden. Als nächstes sind sie dann ganz verschwunden 🙄

Jetzt ist die Beschriftung wieder da. Danke

Thomas8122 wrote:

Thomas8122 wrote:

Seit neuestem werden keine Straßennamen bei highway=living_street mehr angezeigt 🙁 . ...

Jetzt ist die Beschriftung wieder da. Danke

Wie irgendwo im Forum oder auf talk bzw. talk-de erwähnt wurde, sind die catch-all Regeln insbesondere für Namen aus dem Mapnik-Standard-Stil entfernt worden. Regeln für Namen, die gerendert werden sollen, werden nun nach und nach ergänzt.

Solche größeren Änderungen erzeugen oft erst einmal Verluste, die man dann anschließend durch zusätzliche Regeln wieder um die gewünschten Dinge ergänzt. Die Situation, dass grundsätzlich alle Namen gerendert werden, war schließlich auch nicht ideal und hat zu manchen Irritationen geführt.

Seien wir also froh, dass der Mapnik-Standard-Stil offensichtlich aktiv weiter entwickelt wird (auch wenn das zwischendurch mal Ungereimtheiten ergibt).

Edbert (EvanE)

Ich habs grad anhand von zwei Fehlermeldungen gemerkt. Place-names, zumindest von hamlets, werden nur als Punkt und nicht von Polygonen gerendert. Gibts da auf github schon ein issue? Ich steig dort nicht durch.

Gruß Thomas

Thomas8122 wrote:

Place-names, zumindest von hamlets, werden nur als Punkt und nicht von Polygonen gerendert. Gibts da auf github schon ein issue?

Ja, gibt es. (betrifft alle place=*)

Ein anderer Fehler, der erst seit Kurzem besteht: highway=tertiary_link wird wie highway=secondary(_link) gerendert. Könnte das jemand weiterleiten, dazu scheint es noch kein Ticket zu geben?

rayquaza wrote:

Thomas8122 wrote:

Place-names, zumindest von hamlets, werden nur als Punkt und nicht von Polygonen gerendert. Gibts da auf github schon ein issue?

Ja, gibt es. (betrifft alle place=*)

Sogar schon als Nummer 103
Wurde aber auch erst drauf hingewiesen, als ich vor 2 Tagen einen issue dazu geschrieben habe.

rayquaza wrote:

Ein anderer Fehler, der erst seit Kurzem besteht: highway=tertiary_link wird wie highway=secondary(_link) gerendert. Könnte das jemand weiterleiten, dazu scheint es noch kein Ticket zu geben?

Ja, den Fehler hab ich auch schon bemerkt und den issue dazu hab ich beim durchschauen gefunden, aber die Nummer weiß ich nicht.