Die Webseite (Joomla!) an sich wird von Apache geliefert, und der hat keine Probleme.
Die Karten allerdings von Jetty. Jetty ist ein in Java geschriebener Application Server, der Servlets verwendet.
Ab und zu schafft es ein Anwender der OSM Boundaries Map, einen Export zu generieren, bei dem der Server in die Kniee geht. Es war wochenlang Ruhe aber seit gestern passierte das immer wieder
Ah, ja, diese Erklärung macht mehr Sinn! Hm, dann wollen wir mal hoffen, dass der Übeltäter (allzu gieriger Boundaries-Map-Exporter) von seinen Untaten ablässt …
Im Moment funktioniert jedenfalls die aS-Karte wieder bestens, vielen Dank!
Und dabei zumindest früher auch fleißig komplett getaggte Adressen in AS-Konstrukte mit nur housenumber am Objekt und Straßenname an der Relation umgewandelt haben. Etwa 2% der Straßennamen in diesem Bereich wurden übrigens später korrigiert. Da die AS-Befürworter keine QS-tools entwickelt haben, hat keiner bemerkt, daß die Namen der Straßen nicht mehr mit den Namen in der Relation übereinstimmen.
Die ref tags wurden wohl alle von einem nicht mehr aktiven Mapper 461103 eingefügt, leider ohne jeglichen Kommentar.
Die tags sind aus meiner Sicht überflüssig. Wenn man die löscht findet JOSM z.Z. 1314 obsolete aS in Bielefeld.
Ja, das ist „lustig“ (um keinen weniger höflichen Ausdruck zu gebrauchen), über solche Änderungen bin ich auch schon gestolpert. Da dachte ich mir: Wenn sich der Mapper beschwert, dass ich seine schönen aS-Konstrukte lösche, dann werde ich ihn fragen, warum er damals die sauber erfassten addr:-Daten gelöscht hat …
Soviel also zu den oft beschworenen angeblichen Vorteilen der aS-Relationen in der Praxis (Redundanzvermeidung, leichtere Wartung … etc.): sie funktionieren also in der Realität nicht.
Ich würde mal sagen, das liegt eher an osmosis, als an planet.osm.org. Wird echt Zeit, dass dieses nicht mehr unterstützte Tool aus der OSM-Steinzeit durch etwas besseres ersetzt wird.
Nein, das war wirklich nicht das Problem. Damals hatte osmosis versucht, mit einem Windows Character-Set osc Files als UTF-8 zu interpretieren - genau dasselbe was mir der Stacktrace auf talk-ML von heute sagt.