Eng.: I'm planning the route from Magdeburg HBF to Berlin Ostbahnhof. This route has an approximate length of 150 km and a continuous maximum speed of 160 km/h between Biederitz and Potsdam. This route is served by regional and long-distance trains, as well as freight trains to the edge of Berlin (the RE1 from Magdeburg HBF to Berlin Ostbahnhof takes about 120 minutes, the IC takes 80-110 minutes). There is also an S-Bahn line from Potsdam to Ostbahnhof, which is served by several lines (I don't yet know whether the S-Bahn can also be used). I am also planning several shunting tasks in Magdeburg and Berlin, as well as possibly some historic special trains on the route. Since I haven't made much progress yet and this is a pretty long route, I can't yet give a date for when the route will appear, nor can I say whether the route will ever be finished. I would be happy if I could get a few pictures of the route and the surrounding area so that I can recreate it as accurately as possible. Ger.: Ich plane die Strecke von Magdeburg HBF bis Berlin Ostbahnhof. Diese Route hat eine ungefähre Länge von 150 km und zwischen Biederitz und Potsdam eine durchgehende Höchstgeschwindigkeit von 160 km/h. Diese Strecke wird von Regional- und Fernzügen, sowie Güterzügen bis an den Rand von Berlin befahren (mit dem RE1 von Magdeburg HBF nach Berlin Ostbahnhof fährt man ca. 120 min, mit dem IC 80-110 min). Ab Potsdam führt ebenfalls eine S-Bahnstrecke bis Ostkreuz, die von mehreren Linien befahren wird (ob die S-Bahn auch befahren werden kann, weiß ich noch nicht). Ebenfalls plane ich mehrere Rangieraufgaben in Magdeburg und Berlin, sowie möglicherweise einige historische Sonderzüge auf der Strecke. Da ich bisher noch kaum Fortschritt gemacht habe und dies eine ziemlich lange Route ist, kann ich bisher weder ein Datum nennen, wann die Route erscheinen wird, noch kann ich sagen, ob die Route jemals fertig wird. Ich würde mich freuen, wenn ich ein paar Bilder von der Strecke, sowie der Umgebung erhalten könnte, damit ich diese so originalgetreu wie möglich nachbauen kann.
The RE1 from Magdeburg to Frankfurt (O), operated by the ODEG, is usually operated by four or six-car units of the BR 462, but since I have no idea how to create a train in the editor, I don't know yet whether I can actually operate the line with these vehicles. My only hope lies in this, that the Folezz version will be released at some point so that I only have to make small adjustments. However, if this is not possible, then this line will be operated with the old train schedule with BR 182 and 5 Dostos.
this is definetly what I recommend. since it's most likely (or, guessed) to release as an official DLC due to the silencing etc. it'd be a good choice to extend it by 2 coaches and change the livery. though, the model would need to be a little different too, as it's a bit of a different variant.
I still see this as a somewhat bigger problem because I don't have much experience with moddeling and I first have to see whether I can get the buildings, etc. to be the way they should be. Maybe I'll get help with this, or maybe someone who reads this thread can already help.
perhaps you could contact Folezz at some point whenever his projects got revealed or whatever, if you 2 could work on this together or something, so he could help you with the model and some other stuff of the unit? just an idea idk
yes, that sounds good, once I've made a little progress I'll try that. As a first part, I just want to build the route from Burg (Magdeburg) to Magdeburg HBF and perhaps publish it as a beta, where I would already need a train for the RE1
As I said before, I'm relatively unexperienced and would therefore need your advice. I'm currently working on the LIDAR data from Magdeburg to Burg, when processing it I followed exactly a tutorial, which worked up to a certain point, but then I encountered the problem with the warp, that there is a UTM border between Magdeburg and Burg, which is why I cannot reproject the area. Does anyone have any tips on how I can get around this problem as easily as possible?
Could you maybe treat everything as the same UTM? So everything is 32 or 33. Maybe you need to preprocess the "other" UTM so that the coordinates match the "right" UTM like a continuation of the "right" UTM. I think a simple offsetting of all coordinates might work. Though, I haven't worked with UTM 33 yet. EDIT: I just downloaded and merged and warped the DGM1 between Magdeburg and Burg to try and test whether what I'm saying is right. But for me it just works as the data that I found from Saxony-Anhalt is already all in UTM 32N. Maybe we have different sources. EDIT 2: When I imported UTM 32N data from Saxony-Anhalt and UTM 33N data from Brandenburg into QGIS, it displays it correctly. So no coordinate correction is needed. But I couldn't get it to merge because the "black" parts overwrote other parts of Brandenburg. There probably is a better way to merge this correctly. But if you settle for the UTM 33N system, which makes for sense for your route in my opinion, QGIS would automatically translate the UTM 32N tiles into the UTM 33N system. If you by any chance experienced the same stuff that I just said, you can also not merge at all (in contrary to what most tutorials say) but just process the tiles on their own and import them into the TSW Editor one by one. This is not only faster and consumes less RAM during processing, but in border regions you would probably not have to merge two regions of different systems but can just pick one of the tiles so the overwriting problem doesn't occur anymore. With this approach you would also probaly need extra postprocessing (fill_nodata or sth.) to get rid of walls. I hope this makes some kind of sense
Wenn ich sehe was du planst freue ich mich extrem da ich oft diese Strecken fahre (auch selber) und ich mich bei diesen Strecken zuhause fühle
I have now started working on the LIDAR data between Magdeburg and Burg and have only imported the data for Burg. As can be seen in the photos, the data itself is correct, as you can see both the tracks and the Elbe-Havel Canal, however, you can now also see these strange bumps on the edge of the rendered map, as well as a kind of perforation between the individual tiles. Does anyone know where the error could be? Screenshot 2024-07-06 112609 by Plague#5440 posted Jul 6, 2024 at 11:33 AM
It looks like the part of the landscape tiles that got the Lidar correctly applied is smaller than the actual tiles. Everything around has "no data" and was flattened to the highest elevation. You can verify this by selecting one of the landscape tiles in select mode. If the outline is bigger than the "correct" area, I think this is a reprojection issue. Usually the officially provided tiles are 1km x 1km or so and should cover a whole landscape tile. Did you reproject it to WGS 84 / Pseudo-Mercator (EPSG:3857)? Regarding the perforation: I don't know which tutorial you followed, that shouldn't happen but as it is only lightly visible you can easily fix it using the landscape tool.
Höchstwahrscheinlich ja, da ich erst Mal den Abschnitt bis Burg vollständig fertig machen möchte und erst danach der Rest kommt, aber ich kann noch nicht sagen, wann dieser Teil kommt
I followed Smqsher's tutorial and used WGS84 / Pseudo-Mercator for reprojection exactly as described. The only difference was that I used the current version of QGIS (3.38 Grenoble). Is this perhaps the problem that this version works differently?
Ja, vielleicht baue ich auch noch ein paar Züge zwischen Magdeburg Hbf und MD Neustadt ein oder den RE 13 bis Biederitz
I don't think it's the version. One thing that could cause the walls to appear is that when you reproject the data, you usually have some "no data" area in your tiles. This is displayed as black in QGIS. In order to get rid of this, you need to surround your Lidar with more Lidar even if it's not used on the map. You can only apply Lidar to a whole 1km x 1km tile. If there happens to be a black area in there, it will become a wall. I also don't know if the landscape tiles in TSW perfectly match the UTM 32N grid. So that could be another reason. On my own map I set the route origin to be exactly in the center of a UTM 32N tile so that I could rely on a UTM 32N tile fitting into a landscape tile. So if your reprojection is really right, I would say just add more Lidar around it and the walls will be gone. I couldn't find the tutorial you mentioned but I assume by your files that you processed the tiles one by one. The perforation you mentioned could maybe be fixed by using the QGIS tool "fill_nodata" on every tile at the end.
I used this site when testing data to help you in my last posts. https://data.geobasis-bb.de/geobasis/daten/dgm/ You need to find the right UTM 33N tile coordinates beforehand. I couldn't find an interactive site. You can probably find a GeoJSON and select the tiles you need in QGIS and then write a download script or something. There are probalby instructions on their site. I had to do the same for my Niedersachsen tiles.
I looked at the Geoportal Brandenburg website and I couldn't really find a GeoJSON which could make it a bit complicated. I case you don't know, a GeoJSON can contain information about the UTM tiles and their DGM download links which can make it easy to download the right tiles. The goal is to find the download links of all the tiles that you need. Since the file names are formatted in a specific way we actually only need to find the coordinates of the tiles. There are many ways to do that. I think the easiest but most tedious way is to find a map that shows the UTM 33N tiles and just download the tiles you need manually. You could use Ctrl+F to find the tiles on the website. Depending on the length of your route this might be more worth it than spending the time to learn the more complicated way. But your route is so long... A better but much more complicated way is to use QGIS to generate a UTM 33N grid and to select the tiles there. If you can manage to generate them as selectable features you can also draw a path and automatically select all tiles within a certain distance of the path. You can then export the selected tile names as a list and then rename everything to match the link format on the website. Then you can use a mass download tool like wget to download all tiles. But I can't explain every step in detail. I don't even know how to make a UTM grid in QGIS. I think there is a generate grid tool somewhere in there. But there are lots of tutorials and Stack Exchange answers. If you had a GeoJSON you wouldn't need to generate a UTM grid by yourself and could just import the tiles into QGIS. But if you still need help just ask me.
Es freut mich das man die Strecke, auf der Ich für die ODEG Fahre auch in denn TSW 4 Schaffen könnte.
Not much to show yet, since I haven't got a maps API key yet. Till now I only finished importing all Lidar data between Magdeburg and Genthin, but if you'd like I could also this
bei mir ist die letzte Nachricht vom ihm vom 20 august stimmt hab ausversehen mit april verwechselt Ups
Hey guys, after about one month of silence I have finally managed to get the API to work (more or less). I can now load the overlay into the editor, but it is shifted about 10 meters towards the north (as can be seen in the picture, the tracks are some meters further north, then they should be according to the terrain), which prevents me from setting the tracks etc. correctly. Does anyone have an idea what this could be and how to fix it?
A few people complained about this issue before. No idea how to actually fix nor what exactly is causing it. However, I have a few ideas. 1.) It might be that you did something wrong with the EPSG codes at the conversion. The output Lidar tiles need to have the EPSG code 3857 (Pseudo Mercator) and every source Lidar tile needs to have the EPSG code of the region your Lidar data is from at the beginning of the conversion. But here lies the problem specifically for this area/route as you and Lulon already mentioned before, because the EPSG border between the codes 25832 / UTM32 and 25833 / UTM 33 ) is there and especially for the area of the border problematic. I didn't create a route where parts of it have different EPSG codes yet and whether it works to use both or just one for the entire route. But this might be the cause why your Lidar is shifted, even if the actual merge, reprojection and conversion processess in QGIS actually worked well. How did you actually end up merging the zones by Lulon's advice? Did you use UTM32 or UTM33 for the entire route or did you set each source tile to its appropriate UTM/EPSG code? 2.) Could be that you shifted the complete landscape accidentally. I would try to the create the plugin another time, apply the Lidar data and see whether this solves the problem. However, I moreover believe it has something to do with the UTM border.
Hint: I found out when converting Lidar in QGIS, multiply the value for spots with no data with 10, I believe all the tutorials were using sth like -9999.0 so you'll use -99999.0 for me this worked way better, and from what I am seeing, it looks like as if you have only used one square km tile around the tracks, you gotta have at least 3 in every direction.
In the end I used 25833 / UTM 33 for the process. I already tried recreating the plugin and sadly it didn't work.
I would try to do the Lidar for each of the zones with its respective UTM/EPSG code separately then. The border area might needs further manual fixing by using the landscape tools, but in this way in theory for ca. 90% of the route the Lidar should be correctly aligned.
I tried it with my second route project Wippra - Klostermansfeld (https://forums.dovetailgames.com/th...ony-anhalt-nebenbahnen-sachsen-anhalts.85694/), where everything is in the exact same UTM-Zone and as it can be seen on my first post there, I got the exact same problem, its just way worse than here. After I saw that I compared the cordinates in the Editor with the cordinates on Google Earth and I found, that the Landscape is shifted and that it can't be an API-Problem
not really right now, since I still don't have an answer to the problem with the shifted lidar data. I know that it's probably my own fault because it was also on another experimental project that the lidar data was shifted in the editor
