hmkaiser

Ich habe die geänderte Kachel +48+011.dsf in HMK_XPNetwork-Europe_1.1.zip integriert. Es dürfte sicherlich noch ähnliche Konstellation geben, die aber über die parallel geänderten Übernahme-Regeln mit dem nächsten Update ausgebügelt werden.

Hallo Philipp, HMK_XPNetwork-Europe ist wie hier beschieben, Donationware, d.h. ich bitte um einen Spendenbeitrag für meine Arbeit und versende dann das Passwort.

Hallo Jürgen, das kommt meist aus den OSM-Daten, denen immer wieder mal ein Tick Präzision fehlt. Hier kommt bei den klaren "Kanten" die Frage hinzu, an welcher Stelle ein Objekt seinen "Anker"-Punkt hat. Befindet sich dieser in Objekt-Mitte, fährt ein Kfz-Objekt mit der vorderen Hälfte bereits auf der Brücke, bevor sich das ganze Objekt in den Keller aufmachen kann. Diese Frage hat mich z.B. konkret bei der Erstellung meiner langen Sattelschlepper-LKW beschäftigt. Da habe ich den "Anker"-/Mittelpunkt nahe der Vorderachse platziert. Es hat aber alles Vor- und Nachteile, besonders sichtbar bei den extra langen Schiffsobjekten.

Hallo Jürgen, vielen Dank für diesen Hinweis! Und das ist schon ein spezielleres Thema: Ich verwende die Scenery SFD_EDDM_Munich und habe dazu auch das Mesh der Ortho-Kachel +48+011 mit dem von SFD mitgelieferten Patch "EDDM.patch" erzeugt. In dieser Kombination gibt es bei mir das von dir geschilderte Problem nicht. Hier zu sehen die Brücke Taxiway N2. Das zugrunde liegende Mesh ist jetzt so ausgebildet, dass die über OSM kommenden Autobahn-Fahrspuren des "Flughafen Nordrings" und der beleuchtete OSM-highway=path, in Bezug auf die jetzt passend ausgebildete Taxiway-Brücke, eine Etage tiefer, damit Autogen-Cars und statische Elemente "richtig" liegen. Ist das Mesh ohne "EDDM.patch" generiert, fehlt die passende Höhenabstufung. Außerdem kommt jetzt zum Tragen, dass im Gegensatz zu den OSM-Autobahnen, den unter beiden Brücken verlaufenden OSM-Fahrrad-/Gehweg-Abschnitten der Parameter layer=-1 fehlt. Folglich werden diese beiden Segmente nicht unter, sondern auf den Erdboden, hier also den Taxiway-Brücken gesetzt. Ich habe dieses zweite Problem abgefangen und zum Test dafür die HMK_XPNetwork-Kachel +48+011.dsf neu erzeugt. Personen, Radfahrer auf den EDDM-Taxiways sollten nach Austausch der Kachel verschwunden sein. Der Download dieser neu erzeugten Kachel ist als "+48+011.dsf.zip" wie immer möglich über https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto&hl=de

Ich habe eben die beiden HMK_XPNetwork-Libs aktualisiert und upgeloaded https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto&hl=de Es sind einige Fehler-Korrekturen enthalten, dazu habe ich die Fahrzeug-Abmischungen insbesondere auf den Autobahnen geändert. Speziell hier habe ich die Gesamtzahl fahrender Objekte reduziert, dabei den LKW-Anteil erhöht. Der bisher sehr "stetig" wirkende Fahrzeugfluss sieht jetzt "aufgelockerter" aus. Außerdem ist der Fährverkehr u.a. auf dem Bodensee erheblich reduziert. Wer möchte, kann die i.S. 5 Stück geänderten Dateien über die separat verfügbare HMK_XPN_Update.zip downloaden und direkt austauschen, man kann aber auch erneut die kompletten Libraries downloaden und jeweils in die bereits installierte Library entzippen, dabei alle vorhandenen Dateien überschreiben lassen. Der Einfachheit halber hefte ich HMK_XPN_Update.zip hier ebenfalls an. HMK_XPN_Update.zip

Hallo Ludger, vielen Dank für den Hinweis! Da habe ich leider vergessen, meine Test-Parameter zurück zu drehen. Diese Routen haben es in sich, weil hier nur alle X-Stunden ein Objekt auftauchen sollte. Um zu gucken, ob das gewünschte Objekt überhaupt auftaucht, drehe ich dazu den Hahn voll auf. Das anschließende Fast-Zudrehen passiert dann per Schätz-Kelle. Muss alles ja auch nur für einen kurzen Überflug-Zeitraum passen. Ich bin ohnehin dabei, eine ganze Reihe kleinerer Korrekturen und Objekt-Feinabstimmungen, vor allem der Fahrzeugbelegung, zu machen. Das betrifft Teile der beiden Libs und lade das inkl. der Korrektur "Fähren Bodensee" kurzfristig hoch.

dazu noch dieser Screenshot "Blick vom Bodensee auf Friedrichshafen, mit beleuchteten Promenaden", außerdem ist mir ein Shot mit der auslaufenden "Skandi Bergen" auf die Füße gefallen: Einen mächtigen Bug hat dieses Schiff.

Hallo Jürgen, vielen Dank für das große Lob! Die Sache mit den "kleinen Straßen" ist natürlich auch dem Umstand geschuldet, dass XPlane aus den USA kommt, die im Standard mitgelieferten, breiteren Straßen-Bausteine da einfach besser passen, als hier in Old-Europe. Ich denke, dass ich mit den modifizierten, bzw. ergänzten Straßen-Typen einen brauchbaren Kompromiss gefunden habe. Langeoog hat mich übrigens wieder an alte "Zuweisungsbaustellen" geführt. So wie es aussieht, muss ich da mal wieder ein paar Dinge in den Libs ändern. HMK_XPNetwork-Europe bringt ja auch ein stark modifiziertes Modell für die Straßenbeleuchtung mit. Grundlage ist auch hier OSM, wobei ich in etlichen Situation aus fremden Parametern ableiten muss, ob eine Straßenbeleuchtung gesetzt werden muss, oder nicht. Da wäre ich stark an einem Feedback von euch interessiert, ob das Thema "Beleuchtung" gelungen ist, ihr eine Verbesserung gegenüber dem Standard erkennen könnt.

Klar, es gibt ja den EN-und DE-Flyer über https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto&hl=de Der gefällt mir noch nicht so richtig, weil es da aus OSM kommend noch ziemlich drunter und drüber geht. Außerdem ist das ein Thema mit der Fahrzeugdichte, ich habe einige kleine Kurse gesehen, auf denen sich relativ schnell Fahrzeuge "stapeln" können. HMK_XPNetwork-Europe_EN.pdf

Das ist eine andere Baustelle: XPlane erzeugt über das network-System automatisch "highway" -Einmündungen, -Kreuzungen. Hier sind es Einmündungen von abgesetzten "footway"- auf "residential"- Straßen, denen leider automatisch Texturen mitgegeben werden, die hier nicht mehr passen, weil die highways selbst nicht gerendert werden. Ich habe dieses, sehr umfangreiche System noch nicht vollständig durchblickt, habe also noch keine Lösung parat.

Genau das treibt mich auch an einem vergleichsweise weniger bedeutenden Schauplatz wie Spiekeroog an, weil das, was OSM liefert, in vielen Belangen für mich uneindeutig ist: Viele Straßen auf den Ostfriesischen Inseln sind als "residential", also normale Straße innerhalb eines beliebigen Wohngebiets deklariert. Tatsächlich aber ist auf den meisten Inseln kein Fahrzeug-Verkehr zugelassen. Das würde in meinem Verständnis eigentlich bedeuten, dass diese Straßen z.B. als "pedestrian", oder "motor_vehicle=no", also Fußgänger-Straßen in OSM deklariert sein müssten. Die OSM-Community sieht das aber anders, also bleibt nur der Versuch, anderweitig damit umzugehen. Noch besser ist das Beispiel der "railway=narrow_gauge"-Eisenbahn auf Spiekeroog. Da fahren nur von Pferden gezogene Wagen, in 98% aller Fälle auf solchen OSM-Railways aber "richtige" Züge. Leider konnte ich OSM nicht austricksen und musste per Hand die Daten in Kachel +53+007 korrigieren. Die hand-korrigigierte Fassung habe ich eben hochgeladen. Zum Austausch +53+007.dsf in das Verzeichnis HMK_XPNetwork-Europe_1.1/Earth nav data/+50+000/ entzippen, die vorhandene Datei dabei überschreiben lassen. Parallel setzte ich diese Datei in dass Gesamt-Archiv und lade "HMK_XPNetwork-Europe_1.1" neu hoch.

Die .bat zur automatisierten Erstellung der benötigten Symlink-Verzeichnisse befindet sich in ../HMK_XPNetwork_Library/.

Hallo Mike, vielen Dank für deine Rückmeldung und natürlich besonders auch für deine Spende! Wahrscheinlich werden noch einige Macken in HMK_XPNetwork schlummern. Mittlerweile ist schon ein ziemlich großer Blumenstrauß an Prozeduren, Scripten, Regeln für die Überleitung der OSM-Daten in Richtung XPlane-network entstanden. Habe gerade einmal kurz gezählt: Allein für die konkrete Umsetzung der vorab schon auf meinem Rechner umfangreich bearbeiteten OSM-Daten, sind mittlerweile rund 500 Regeln nötig. Die müssen in penibel abgestimmter Reihenfolge abgearbeitet werden, damit sichergestellt ist, dass die aus OSM kommenden Inputs auch die richtige Straßenklasse in XPlane finden. Allein da kann es schon schwierig werden, Fehler zu erkennen. Dann kommen noch die anderen Dinge und natürlich OSM selbst. Der heutige Abend ist jedenfalls für die Ostfriesischen Inseln reserviert, verbunden mit der Frage, wie ich OSM austricksen und von mir manipulierte Daten so einschleusen kann, dass OSM, besser hier JOSM, nichts davon merkt.

Ich habe gestern den Längengradstreifen +011 neu erstellt, weil da bei Erzeugung der betreffenden Kacheln u.a. rund um LOWI einiges durcheinander geraten ist. Dieser Streifen betrifft auch deinen Heimatbereich Königssee. Die Kachel +50+011 mit Erstellungsdatum 26.04.26 zeigt auch bei mir die von dir beschriebenen Fehler, mit der neuen Kacheln vom 04.05.26 sieht es rund um Pennewitz wieder normal aus. Verwendest du noch die Version vom 26.04.?

Auf Langeoog sind mir eben ein paar Straßensegmente aufgefallen, die definitiv in HMK_XPNetwork falsch klassifiziert sind und deshalb Autogen-Verkehr zulassen. Ich habe Ende vergangenen Jahres jede einzelne Straße auf den Ostfriesischen Inseln per Hand korrigiert und modifiziere darüber die aktuellen OSM-Daten. Ich muss gucken, was da jetzt nicht geklappt hat. Edit: Das ist, wie ich gerade feststellen musste, richtig blöd, weil mittlerweile einige Straßen auf den Ostfriesischen Inseln in OSM modifiziert wurden und diese neuen Edits dann meine älteren Korrektursätze aushebeln. Ich muss sehen, wie ich das umgehen kann. Vor jedem Update die betreffenden Straßen auf reinen Fußgänger-Betrieb umzuswitchen, macht auch keinen Spaß. In jedem Fall mache ich die betroffenen Insel-Längengrad-Streifen +006 und +007 kurzfristig neu und aktualisiere dann HMK_XPNetwork-Europe_1.1.