hmkaiser

Hallo Ernst, ich habe jedem dass Passwort für HMK_XPNetwork geschickt, der mich wie auch immer darum gebeten hat, nicht aber zwingend an den Fluß eines Geldbetrags geknüpft. Wie einige von euch aus direkten Diskussionen wissen, hatte ich niemals Interesse, HMK_XPNetwork, inkl. der Vorgänger-Versionen, anders als Freeware für euch bereit zu stellen. Aufgrund einiger spezieller Ereignisse und Erfahrungen in diesem Jahr, war das so aber nicht mehr möglich, deshalb blieb nur der auch in meinen Augen nicht ganz glückliche Schritt "Donationware", um einen gewissen Schutz zu erreichen. Als ordentlicher Kaufmann werde ich natürlich jedem mit dem aktuellen, letzten Stand von HMK_XPNetwork versorgen, der darum bittet.

Liebe Freunde, ich muss euch leider mitteilen, dass ich das HMK_XPNetwork-Projekt ab sofort einstelle. Alle Projekt-Archive, die das HMK_XPNetwork-Projekt betreffen, sind aus meinem Google-Drive-Ordner entfernt. Ich möchte mich bei euch allen hier im Forum bedanken. Es hat mir immer viel Freude gemacht, in diesem kleinen, feinen Zirkel unterwegs zu sein. Meine Arbeit nicht nur in diesem Umfeld, habe ich stets unter dem Motto "Ehrenamtlich" verstanden, allerdings ist mir in Hinblick auf "HMK_XPNetwork" dieser Weg seit dem Frühjahr 2026 nicht mehr möglich. Vielen Dank!

Liebe Freunde, ich möchte mich bei euch, meinen verärgerten Usern entschuldigen, dass ich mein eigenes Süppchen koche und nicht akzeptiert habe, dass meine Arbeit jederzeit von jedem, wie auch immer, für eigene Zwecke verwendet werden darf. Ich hätte mich niemals dagegen verwehren dürfen, dass von mir entwickelte, neue Eigenschaften rund um das X-Plane-network nicht frei verfügbar, für eine externe Vermarktung offen stehen. Ich möchte mich dafür entschuldigen, dass ich "HMK_XPNetwork" als "Donationware" deklariert habe, also eine wie auch immer geartete, aber nicht nur monetäre "Donation" von euch verlangt habe. Es ist mir sehr unangenehm, dass ich die Integration, sprich das Kopieren meiner network-Entwicklungen in fremde, kommerzielle Angebote, als "nicht normale Aktivität" betrachtet habe. Ich bedauere außerdem, dass ich es gewagt habe, Arbeiten fremder Dritter an der Modellierung von Stromkabeln und Seilbahnen aus XP11-Zeiten in mein HMK_XPNetwork völlig unbedacht, ohne Notwendigkeit, aber textlich kenntlich gemacht, in meine Arbeit aufgenommen zu haben. Alles in allem habe ich aber profunden Beistand ...

Liebe Freunde, ich habe mir eben X-World Pro gekauft und installiert und muss feststellen, dass wesentliche Teile und Features aus meinem HMK_XPNetwork-Paket darin enthalten sind, ohne das es dazu eine Vereinbarung gibt, oder dies von mir in irgendeiner Form authorisiert worden wäre. X-Plane steht für ein sehr offenes System. Viele Dinge, gerade rund um das Scenery-Design sind für uns User völlig transparent sicht- und nachvollziehbar, damit auch einfach kopierbar. Ich habe seit über 2 Jahren nahezu täglich und mehrstündig an der Entwicklung meines Network-Projekts, vor allem Dank eurer tollen Rückmeldungen mit (meist) viel Freude gearbeitet, natürlich auch, weil ich immer wieder einen deutlichen Mehrwert für mich und meinen Simulator gesehen habe. Mir wird aber jetzt meine Arbeit einfach so weggenommen. Es macht daher keinen Sinn mehr, an Dingen weiterzuarbeiten, die bei nächster Gelegenheit anderswo auftauchen, dann auch noch zu Gunsten fremder Dritter verkauft werden. Es ist mehr als bedauerlich.

Hallo Bernd, das ist natürlich eine gute Idee ... würde aber eine Reihe von Nachteilen produzieren. Mir ist wichtig, dass mein HMK_XPNetwork innerhalb einer Kachel unterbrechungsfrei bleibt. Nur auf diese Weise lässt sich durchgängiger, fließender Verkehr realisieren. Würde man eine "NoGo-Area" über einen Airport legen, würden betreffende OSM-Straßen, darauf verlaufender Traffic, aber auch die statischen Elemente und ggf. die Beleuchtung wären abgeschnitten. Stellt man sich dazu einen Parkplatz vor, der außerhalb eines Airports gerade zur Hälfte in die "NoGo"-Area hineinragt ... Ich hatte mir schon überlegt, OSM-"aeroway=aerodrome"-Flächen dazu heranzuziehen. Aber leider sind diese Flächen an bestimmten Punkten auch oft so grob abgefasst, dass "Rest"-Bereiche des öffentlichen Straßenverkehrs bereits innerhalb, anderseits nicht-öffentliche Service-Straßen teilweise noch außerhalb der OSM-Fläche angesiedelt sind. Stimmen dazu dann auch die zugewiesenen Eigenschaften eines einzelnen "highway" nicht, passt nichts mehr. Es macht aber einen sichtbaren Unterschied, ob der ein Airport-Terminal versorgende Highway Bestandteil von HMK_XPNetwork ist, oder nicht. Dazu kommt, dass ich mir über die OSM-Straßen auch das Beleuchtungsmodell für die Scenery erzeuge. Die sind gerade im unmittelbaren, äußeren Umfeld eines Airports (Parkplätze) besonders wichtig, oftmals leider auch vom gleichen Typ, wie die Straßen, die in OSM innerhalb einer "aeroway=aerodrome"-Fläche verwendet werden. Egal wie ich bisher das Blatt auch gewendet hatte: Eine eierlegende Wollmilchsau ist mir noch nicht auf die Füße gefallen, obwohl mich diese Dinge besonders nerven. Ich habe mittlerweile eine Reihe zusätzlicher Kriterien in meine Überleitungsregeln eingebaut, die mit dem nächsten Update eine weitere, deutliche Reduktion fehlgeleiteter Trecker, Fahrzeuge, Passanten, nicht nur innerhalb von OSM-"aeroway=aerodrome"-Arealen bringen wird. Und die werde ich anhand Deiner Beispiele auf Wirksamkeit überprüfen. Danke!

Meine letzte "Kachel-Auffrischung" habe ich rund um den Jahreswechsel 25/26 gemacht und da lief die OSM-Abfrage über Ortho4XP noch durch. Ortho4XP generiert beim Erzeugen einer Kachel eine "Overpass"-Abfrage, die dann an OSM zur Datenselektion übergeben wird. Vermutlich blocken die OSM-Macher Abfragen, die "von der Seite" kommen. Zur Zeit ja noch nicht, weil meine Auffrischungen erst in ein paar Monaten wieder dran sind. Allerdings sehe ich für mich keine Probleme, weil ich ja ohnehin an OSM arbeite, die Datenbank-Extrakte von Geofabrik und auch die Tools (Osmium) zur Offline-Bearbeitung von OSM-Extrakten verwende. In Hinblick auf die Geofabrik-Datensätze fehlt mir nur ein Script zur automatischen Erzeugung der jeweils von Ortho4XP benötigten 5 einzelnen Auszüge. Das würde ich mir schnell zusammenbraten, wenn es soweit ist. Allerdings bin ich ja in Linux zuhause. Für eine einzelne Kachel könnte man zur Not auch die Overpass-Abfrage in JOSM nutzen. Darin müssten dann der Reihe nach die 5 einzelnen Datenselektionen mit den unterschiedlichen Selektions-Kriterien ablaufen und unter dem Ortho4XP-konformen Namen/Format gespeichert werden. Ich mache das in dieser Weise für meine laufenden network-Test-Arbeiten.

Ein kleiner Nachteil ist, dass die angebotenen pre-baked OSM-Daten wohl erst einmal auf dem Stand vom 24.07.2026 stehen werden. Seit Jahren erzeuge ich mir meine "Kern-Kacheln" für Mittel- und Westeuropa meist rund um den Jahreswechsel neu, ausschließlich weil sich die OSM-Datenbasis stetig verbessert und mehr Details liefert. Insbesondere Gewässer, Uferlinien punkten in den O4XP-Kacheln, bzw. der gesamten XP-Landschaft stark, wenn anstelle z.B. einer vorher nur über 4 Eckpunkte erfassten, rechteckigen OSM-"natural=water"-Fläche, detaillierte Uferlinien zur Verarbeitung kommen.

Es ist da einiges in Bewegung, z.B. https://forums.x-plane.org/forums/topic/349696-is-this-the-end-of-ortho4xp/, wobei die einzelnen Projekte unterschiedliche Aspekte in den Fokus nehmen. Für mich war der Ansatz von @CheckCanopy erst einmal interessant, weil darin die aktuelle OSM-Verfügbarkeits-Klippe auf simpelste Weise geschliffen wird.

Du nicht, aber ich: Da habe ich völlig falsch formuliert: Nach dem Speichern der extern gelieferten OSM-Daten dürfen diese Daten vor Erzeugen einer neuen Kachel nicht per "Erase cached data" gelöscht werden. Der Schritt "Assemble Vector Data" muss aber zwingend ausgeführt werden. Wie bei den .hgt-Höhendaten diskutiert, verwendet Ortho4XP immer bereits gespeicherte, als im Cache befindliche Daten, statt diese Daten über das Netz nachzuladen. Sorry! Da kann ich leider keine Antwort geben, weil ich aktuell noch keine Kachel mit diesen "Pre-baked"-OSM-Daten erzeugt habe. Ich vermute, dass die Abfrage zur Selektion der "pre-baked"-OSM-Daten einfach nur präziser abgefasst ist. Ich gucke mir in den kommenden Tagen mal einen "pre-baked"-OSM-Satz per JOSM an. Mal sehen, ob ein Vergleich mit den von Ortho4XP gezogenen OSM-Daten etwas zeigt. Allerdings hocke ich gerade noch in größeren network-Untiefen.

Hallo Michael, das Problem ist bekannt und beschäftigt einige XPlaner u.a. hier https://forums.x-plane.org/forums/topic/347657-osm-server-rejections-galore-lately-stale-settings/ Insbesondere dank @CheckCanopy gibt es eine Lösung, an die von Ortho4XP benötigten OSM-Daten anderweitig zu gelangen. Dazu müssen die 5 einzeln benötigten OSM-Datensätze "..._airports.osm.bz2", "..._big_roads.osm.bz2", "..._coastline.osm.bz2", "..._small_roads.osm.bz2", "..._water.osm.bz2" vorab aus dem Internet gezogen und in den passenden Ortho4XP-Subverzeichnissen ".../OSM_data/xxx_yyyyy/" gespeichert werden. Das einzeln, oder per Batch über Ortho4XP angeschobene Erzeugen einer Kachel, erfolgt dann unter Auslassung(!) des ersten Schritts "Assemble Vector Data" von "Erase cached data - OSM data". Ortho4XP greift dann auf die vorab gespeicherten OSM-Datensätze zu, die restlichen Arbeitsschritte bleiben wie gehabt. Unter https://xpconnect.me/orthoforge-data.html stehen bereits aktuelle OSM-Datensätze als "Pre-baked OSM-Data-Tiles"für eine direkte Verwendung in Ortho4XP zur Verfügung.

Ich habe bisher außerhalb "Autobahnen" auf die Verwendung 4+x-spuriger Straßen-Modelle, bzw. 2+x-spuriger Einbahnstraßen-Modelle, in HMK_XPNetwork-Europe verzichtet. Diese Straßen weisen eine erhebliche Breite auf und produzieren tendenziell den Effekt "übereinander gestapelter Straßen". Aktuell arbeite ich an einer deutlichen Verschlankung dieser Straßen-Modelle und neu abgefassten Regeln, ab wann diese Straßen in der Überleitung zugewiesen werden. Im Bild mein aktueller Arbeitsstand am Beispiel der B 431, Osdorfer Landstraße, zwischen Iserbrook und Osdorf, Hamburg. Im unteren Bereich liefert OSM eine einzelne Straße mit 4 Fahrspuren, im oberen Bereich (Osdorf) sind es zwei einzelne Einbahn-Straßen mit 2 Fahrspuren, wobei sich im Verlauf der B 431 dieses Wechselspiel laufend wiederholt. Einige Straßen-Anbindungen sehen schon ganz gut aus, andere sind noch nicht so prickelnd. Alleine die Primary-Straßen bestehen aus 20 Varianten, dazu kommt die Interaktion mit allen anderen Straßen-Typen. Ich möchte aber nicht auf diese Varianten komplett verzichten, denn diese markanten "Pfade" sind - aus dem Cockpit betrachtet - schon markante Wegmarken.

The new XPNetwork for Europe is available.Perfect dynamics in the XPlane 12 Europe world based on a new, up-to-date and complete network of roads, railways and waterways. HMK_XPNetwork-Europe delivers a new level of realism for XP12-Europe: A detailed, continuous road network based on the OSM database, as of April 01, 2026, consisting of motorways, expressways, primary, secondary, tertiary and other roads, plus graphically redesigned road types for e.g. residential areas, or raceways. Realistic left- or right-hand traffic on the level of a 1° x 1° tile. Additional static elements such as parked vehicles, pedestrians, bushes, etc. Additional dynamic autogen car objects for Europe, varied driving speeds for dynamic autogen objects. Near-perfect realistic scenery lighting Train traffic, including additional dynamic autogen rail objects moving at varying speeds, as well as static elements such as stationary railcars, bushes, etc. Differentiated maritime, ferry, and inland waterway traffic using over 150 vessel objects. More Screenshots are available here https://drive.google.com/drive/folders/1cWiJBNag50H85KeYUbdIUbvIZFCi7qqV?dmr=1&ec=wgc-drive-hero-goto HMK_XPNetwork-Europe is donationware, so I ask for a donation of any kind before I will send the password to unzip the two main archives. All packages - such as the flyer containing additional information - are available for download here: https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto. The HMK_XPNetwork-Europe scenery system consists of more than 1,600 .dsf tiles along with the specifications and objects contained in the HMK_Network_Library. In addition, the HMK_XPN_LocalAdds_Library is optionally available for local variations, such as country-specific police vehicles. Installation information in the form of .txt files is included with every .zip archive. I have been working on this project for more than two years and am constantly active on the "German side" here: https://forum.aerosoft.com/index.php?/topic/184997-xpnetwork-europa/

Ein kleiner Blick ins Nähkästchen: OSM liefert in etlichen Fällen nicht die Informationen, die das Vorhandensein, oder auch Nicht-Vorhandensein einer bestimmten Eigenschaft eindeutig und konsistent über den gesamten Datenbestand aufzeigt. Das trifft z.B. auf das Thema "Straßenbeleuchtung" zu. Zwar gibt es dafür in der OSM-Welt einen Schlüssel, allerdings wird der nicht durchgängig verwendet. Damit das Bild in X-Plane trotzdem einigermaßen stimmig ist, muss ich über Umwege versuchen, Lücken zu füllen, wobei "Umwege" das Verwenden mehrerer andere Schlüssel meint, die mit dem eigentlichen Thema eigentlich gar nichts zu tun haben. In Hamburg (meine Testwiese), umschließt die Straße "Am Rosengarten" unmittelbar das Südwest-Ende von EDHI. Und die ist - das ist mir direkt ins Auge gefallen - leider zu großzügig mit einer Straßenbeleuchtung versehen worden. Dazu kommt (das fällt einem danach auf), dass die komplexe Kreuzung "An der alten Süderelbe"-"Nesseldeich"-"Am Rosengarten", aus mehreren unterschiedlichen Straßentypen besteht, die "unglücklich" zusammengesetzt sind. Ich habe schon einige Zeit gebastelt, um die Trefferquote für die Ergänzung von Eigenschaften zu verbessern, bzw. näher an die Realität zu rücken. Der Blick auf den aktuellen Projektstand zeigt, dass mit meinen aktuellen Test-Übernahme-Regeln die Straße "Am Rosengarten" frei von Lampen, Fußgängern und geparkten Fahrzeugen ist. Die Kreuzung sieht auch deutlich "schlanker" aus, wenn auch noch nicht perfekt. Jetzt kommt es darauf an, dass nicht nur im Detail, sondern im großen Bild die Dinge in die richtige Richtung gehen.

Eine Kleinigkeit habe ich übersehen: Autogen-Fahrzeuge zweier Fahrzeug-Mischungen haben sich im gestrigen Update der HMK_XPNetwork_Library nicht an örtliche 50 kmh-Geschwindigkeitsbegrenzungen auf einfachen Landstraßen-Abschnitten, außerhalb von Ortslagen gehalten. Es ist aber gut möglich, dass diese rüpelhafte Fahrweise überhaupt nicht auffällt, zumindest habe ich aus dem Cockpit-Fenster nichts bemerkt. Trotzdem ist das korrigiert, die aktualisierte Library neu hochgeladen.

Ich habe eben die aktualisierten Version der HMK_XPNetwork_Library und HMK_XPN_LocalAdds_Library zum Download unter https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto bereitgestellt. Die Schritte zur Installation, bzw. Durchführung des Updates bleiben gegenüber den Vorgänger-Versionen unverändert und sind in den enthaltenen Text-Dateien beschrieben. In den Vorschriften zur Generierung des networks sind Änderungen enthalten, die erst mit dem kommenden Update von HMK_XPNetwork-Europe greifen werden. Sichtbar sind aber eine Reihe von Anpassungen und Objekt-Ergänzungen, wie z.B. die Aufnahme von Motorrädern in die verschiedenen Autogen-Fahrzeug-Mischungen. In Hinblick auf die Einsortierung der von OSM gelieferten Straßen, haben sich noch einige Möglichkeiten ergeben, die - so meine Hoffnung - die Zuordnung in die X-Plane-Welt weiter verbessern. Ich werde das zeitnah ausprobieren. Die gerade hochgeladenen Libs sind dafür vorbereitet.