Analyzing quad trees of routes

[mnjrr]

I have read several of the informative posts and tutorials on the forum about merging routes as I would like to attempt a merger of my own.

To begin the process, I am wondering what would be the most efficient approach to determine if two routes share the same world files. Would comparing their quad trees in the RGE and looking at the contents of the world files in the respective folders of the routes be effective? Is there a way to temporarily project the combined quad tree of two routes to determine the layout of the world files?

Thank you for your time.

Sincerely,
Walter Conklin

[OTTODAD]

I have read several of the informative posts and tutorials on the forum about merging routes as I would like to attempt a merger of my own.

To begin the process, I am wondering what would be the most efficient approach to determine if two routes share the same world files. Would comparing their quad trees in the RGE and looking at the contents of the world files in the respective folders of the routes be effective? Is there a way to temporarily project the combined quad tree of two routes to determine the layout of the world files?

The only way to merge two routes it to use TsUtils which comes with the Route Riter, but is not something MSTS newbies should attempt.

Do a SEARCH for Merge in the MSTS forums and you will find much on the subject.

O t t o

[mnjrr]

Hi Otto,

I appreciate the forewarning.

I am not a MSTS newbie. I have been a member of this forum under a different username since MSTS came out in 2001. I have experience with another route using TSUtils to change the latitude and longitude coordinates of a route to approximate the coordinates of the actual route, adding DEM to the virtual route, and moving all of the scenery objects and tracks using a tool created by Mike Simpson.

As I mentioned in my first post, I have read several of the threads on the subject about merging routes. I probably shouldn't have let the cat out of the bag that I am attempting an merger. The reason why I asked my questions is because none of the merging threads cover ways to effectively determine if two routes share the same world files and compare their quad trees. Perhaps ascertaining this information is already common knowledge.

Walter

[OTTODAD]

I have been here since day 1 of MSTS too, but when if comes to merging routes then you are a newbie !

I have assisted with the merger of the Port Ogden & Northern route with part of the Marias Pass and have created my popular GOLD-SPIKE route, which is a merger of the Whitefish-7-RR and the Marias Pass part of the Marias-Kootenai I helped to create.

Perhaps ascertaining this information is already common knowledge. Not as far as I am aware of.

O t t o

[mnjrr]

Hi Otto,

You have been very helpful in addressing my questions over the years and I appreciate that, though I could do without the newbie hazing.

What you quoted was actually a double entendre done by me intentionally. You write, "Not as far as I am aware of" Hence, the reason why I asked my questions after reading the threads about merging routes. The questions that I raise after reading mark the next logical step in the thought process.

Walter

[OTTODAD]

You have been very helpful in addressing my questions over the years and I appreciate that, though I could do without the newbie hazing.

Sorry, did not mean to ruffle your feathers, but you do know little about what is involved in merging routes and neither do most other MSTS users.

The PRR-East Region team could tell you much about what is involved, having learned from the many mistakes they have made, I got involved in correcting !

O t t o

[mnjrr]

Hi Otto,

OK, I admit I know little about merging routes. Hence, I read the threads (several with informative replies) by the PRR Track team. I can still have questions, though.

From reading the posts, I know that you and the PRR team have been involved over the years with merging routes but your reference to to these nobel undertakings within the context of me reading several threads about merging routes does not really help me with adressing the actual questions I raise. I think we are on different wavelengths as I am not questioning your expertise garnered from experience.

Sincerely,
Walter

[OTTODAD]

Perhaps this thread will give you some idea what is involved when merging routes, but it's only the tip of the iceberg:

https://www.trainsim.com/vbts/showthread.php?t=271097

To give you helpful advice one would need to know what routes you intend to merge, their compass co-ordinates, altitudes, what version of the Tsection.dat was used when creating either, etc, etc.

I have been working with Carl-Heinz then:



who has helped me solve a number of problems I had merging routes to create my GOLD-SPIKE one.

If you like can assist you off forum. Use the e-mail option in my messages ID header.

O t t o

[pvoxland]

I have not seen any way to overlay the RGE geometry display from two routes.

There are various shareware utilities that can compare folders for identical or similar contents. You would basically be trying to establish whether there are any identical world tile names in the "World" folder for each of the routes. The names are created by the Route Geometry Extractor, of course. Although the tile name always remains the same, the dates, sizes, and contents would certainly be different as a result of any editing on the tiles done by the route builder.

At best this would help you decide whether there were any common tiles or not.

Another similar strategy would be to use a program such as Envira's Magellan Explorer (shareware, but with a 30 day trial). With this you can open up a side by side panel in which you could list in alpha-numerical order the world tile names. Then, you could work you way down the sorted lists and spot whether there were any identical names. (Setting up two sorted side by side Window's Explorer window panes is effectively the same thing).

World tile names are numbingly hard to stare at for long, but each of these strategies would bring you to the same conclusion. And worse, those names are a little hard to make sense of even if in the end they map to latitude and longitude locations on a map.

Another visual method would be trying to print and compare the RGE maps for the two routes to see by inspection whether any geographical overlap occurs. The route tiles can be a little tiny even when you have zoomed in about as much as is allowed, so this could be pretty tedious.

--- Phil

[mestevet]

Walter,

These were your questions:

To begin the process, I am wondering what would be the most efficient approach to determine if two routes share the same world files. Would comparing their quad trees in the RGE and looking at the contents of the world files in the respective folders of the routes be effective?

You could do that, the tile names should be the same for tiles covering identical areas, so if you had a match, you'd know there was an overlap.

Is there a way to temporarily project the combined quad tree of two routes to determine the layout of the world files?

I'm not aware of this functionality in an addon program, or something like that. However, I do think you COULD do it, if you were smart about it...

I ran a little test to see if I could do it by taking a screenshot of the quad trees in the Route Geometry Creator, and then overlay them in Paint Shop Pro. It actually turned out to be easier than I expected.

What I did was go into the Route Geometry Creator and pull up the first route, load the quad tree - do all the zooming in that you need and expand the window to encompass the entire route (as best as possible). Then take a screenshot of the window with your favorite method, and save it. IMPORTANT, without changing anything in the Route Geometry Creator window, select and open the second route, and load it's quad tree. In my case, it came up and the viewing window was unaltered, and so I had to do nothing but take another screenshot, the view was the same! (thus all set up for overlaying in your favorite image editing program). If for some reason it didn't work out that way, I also tweaked the window to see how easy it would be to get back the original alignment just by using the rough lat/lon coordinates of the upper left hand corner of the window, and it wasn't hard to do at all.

After I had my two screenshots of the "neighbor" quad-trees (of different, but adjacent routes), I used Paint Shop Pro to bring up both screenshots, copied one into the other, and since they were already aligned by the method I mentioned above, they were lined up. I then used the layer properties to set the visibility of the "upper" layer to 50% so that the "lower" layer could be seen through it, and voila, I had an overlay of two quad-trees. Total time, including writing this up, was 15 minutes. See the images:

Route 1:


Route 2:


Route 2 overlayed on image of Route 1 using Paint Shop Pro layers:


Now, my routes don't overlap, that's clear from these images, but if you know yours do, and you want to make it more clear what tiles overlap, then do a little editing of one of the images, just "tint" it a bit, or maybe just paint in the quad tree boxes (which should be pretty easy in an image editor) and the overlapped tiles should be more obvious. Personally I can's see that taking more than a few additional minutes of work.

Also, clearly, just having a pretty picture won't do you any good, you need to have tile and file numbers to move forward. Well, I'd take the overlap image and compare it to one of the routes (whichever you decide is your "base") and locate and mark down (pencil and paper were wonderful inventions! ) the tile names and numbers where they overlap, and you have your answer (of course if there's a lot of overlap, that could be a lot, but no one said it would be easy!).

On another note... I fail to understand why doing ANYTHING with MSTS requires some sort of master's certificate, heck this ain't rocket science (and being a degreed "rocket scientist" I have some knowledge in that area). If you want to try merging routes, by all means, give it a shot. Yeah, you might fail, but nothing ventured nothing gained. My recommendation would be to do a test run on backups, or better yet, extract a couple of very small, but overlapping "test" routes, and try your techniques out on those first to work out the bugs. If someone tells me that something is "better left for the experts", my immediate thought is, well who taught the experts?, and are these experts really any smarter than I am? I'm guessing the reason why no one can explicitly explain it to you is that they're not exactly sure how or why it worked... What good is being an "expert" if you're incapable of passing along that knowledge to others?

Steve

[muskokaandtahoe]

Speaking of quad trees... sure wish we had a utility that would shift everything except the tile boundaries a distance of n meters on both horizontal axis. If I could I'd push my route about 500-600m east and maybe the same distance south... would spread the contents of a pair really object-dense tiles over several tiles instead of having them packed into one each.

I supposes DEMEX would do that... but hey, it's too late for DEMEX....

[OTTODAD]

Speaking of quad trees... sure wish we had a utility that would shift everything except the tile boundaries a distance of n meters on both horizontal axis. If I could I'd push my route about 500-600m east and maybe the same distance south... would spread the contents of a pair really object-dense tiles over several tiles instead of having them packed into one each.

TsUtils can do that and had it move some routes like the INDI away from Demarcation Lines to prevent WHITE VOIDS.

After moving one route closer to one to be merged with, their altitudes have to match too and one can be adjusted with TsUtils to match the other.

In one of the to be merged routes or both, tracks not required can be deleted to make room for new ones to link both routes and after deleting tiles not required in the RGE the routes can then be merged with TsUtils, providing that both have been created with the same type of Tsection.dat, original or new one.

This shows you how I did that: https://www.trainsim.com/vbts/sho...d.php?t=271097 but there is a bit more to it, depending on the track layouts in the area where the routes overlap and what interactives exist in them which have to be removed first before deleting the tracks they are linked to, etc.

O t t o

[rpicardi1]

Merging routes is no easy task. What has worked is doing the following;

Merging rules are that the new route being merged will have no interactives such as platforms, mile markers, signals, car spawners, etc... No dynamic track.

1. Back up the route to accept the merge.
2. Note which World files where the new route will be connected to. Those are the replace at your own risk with the merge locations.
3. Using a utility such as Print Folder, print out a list of all the World files from the route that will be merged.
4. Load the Quad Tree for the route accepting the merge.
5. Using the printed list, go to the World file location where track will connect and mark that World file on the list.
6. Find the neighboring World tile location where the new ones will go, mark the list as ones to add, and record the Tile file to be added.

Note, the printout will sort out with the top of the list being the World file starting on the lower right corner of the Quad Tree, SE corner. The listing will go up, North, until all the World files for that vertical row are used and the next file shifts it back to the bottom and one vertical row West.

7. Add to the Quad Tree as needed marking all World files and their Tile files to add.
8. Save the Quad Tree when done.
9. Compile a list of World and Tile files to add and add those to the route.

Now, you can go into the RE and check the addition for white voids nearby. Note that the new track will appear as static objects. Leave them alone for now. Make notes of which World file locations that will have to be added to the Quad Tree later.

Now, the tricky part;

1. Note the exact location where the existing activated track ends.
2. Save a backup of the route with the new addition.
3. Save a copy of the world file with existing track to replace with the new one
4. Drop in the merging track world file.
5. Go to that location in the RE.
6. If the location loads without crashing, there are TDB lines with matching track, those tdb lines are aligned with the track, you can select that tdb activated track without getting selection errors or crashing, you are probably good to go. If any of the above is causing problems, You Must put the old World file back in and hand lay new track to connect to the track in the addition.
7. When satisfied that all existing track is good, you can start adding the new stuff to the tdb by selecting it to activate it. Save often.

Sure, it is slow but trying to merge two TDBs is a nightmare that can cause untold problems with track in both routes.

[Signalmaster]

If you manage to combine two route and subject them to a full DB rebuild, if areas of track are separated more than a tile or two from trackage where the starting point is, they be ignored during the rebuild.

While I was combining distant pieces of routes in New Jersey, one in the north and the other in the south, even though the terrain tiles were in place in between, the DB rebuild missed all the track in the south portion.

FWIW.
Hank

[charlie]

I have read several of the informative posts and tutorials on the forum about merging routes as I would like to attempt a merger of my own.

Here's one way to do this that will preserve (almost) all of the track interactives and carspawners in both routes. As a general guide:

http://hawkdawg.com/MSTS/tuts/chuck/merge.htm

I've never really talked about this project in the open before, but I've merged my Silverton Branch with the Rio Grande Southern.

Here's the way I went about it. First of all, I have registered versions of both Demex and Mosaic available, since it makes things easier, but there are workarounds for the methods I used.

Even if you don't register Mosaic, I would strongly recommend that you install the demo. You can't save any changes, but it's by far the best route visualization tool we have. By mousing about, you can easily explore both routes. You can see lat/long and more importantly world file coordinates (even though it says "tile") down on the status bar at the lower left. Once you have the world file coordinates, plug them into the converter in RouteRiter (Misc. Options tab) to get the root tile file name. As in "-12384" and "14170" convert to "-025620cc". Keep a list of what you discover, but more on the easy way below.

The Silverton was chosen as the "primary", and I already knew of a considerable overlap. Here's the easy way of determining the overlap and deciding what to do.

Silv_Markers.jpg is a Mosaic view of the area of interest on the primary route. The RGS will be coming in from the west on the tile even with the town. I decided that the four western tiles would be deleted from this primary route since I wanted to keep those tiles in the secondary route (having track/roads and such). The roughly placed markers you see were made by right-clicking in Mosaic to outline the keeper tiles in the places where the routes overlap.


A workaround for these markers if you haven't registered Mosaic. Stand on a blue tile boundary in the RE and you can see lat/long in the Camera window. Have the route MKR file open at the same time, scroll to the bottom and copy the last entry and paste it on the line below. Then copy lat/long from the Camera window into the new marker entry in the proper places, and there you have a new marker on the boundary. I placed markers along the boundaries about a km apart, but 2 km will do OK.

BTW, if you use the "manual" method to place the markers, the next time you open Mosaic as a visualization tool, you'll have them in view.

Having done that, it's time to prepare the primary route for the merge. Since the four tiles I planned to delete had absolutely no track or roads, I identified (in Mosaic) the world file names and simply deleted the "w" files and any "ws" files with the same root name. Now it's time to get rid of the surplus tiles. You can do this in the RGE of course, but registered Demex is by far easier, especially if you have the markers to look at. As a side note, I do almost nothing in the RGE anymore but for generating just one std tile at the start of generating a route. Demex does every other RGE function after that.

Markers_Demex.jpg is such a view of the little green dot markers (hard to see in this poor jpg) we just made. If you right-click on a tile you want to delete, you get the pop-up you see. Remove all tiles you planned. Then at "Route" on the menu bar, select "Save Quadtree" then "Refresh Route Tiles" then "Remove Flagged Tiles". After that you'll find some files in the TILES folder that have a new "unused" file extension. You can move them aside or delete them.


So the primary route is (maybe) ready for the merge, but first an important point. The route must be capable of passing the TSUtils Integrity Check (ICHK) to get to a merge, and now's the time. I had a pesky fictitious wye west of Durango that I needed to dump. The TSUtils CLRDB helped me get through that.

So on the the secondary route preparation, and this one will be much more valuable to you. To begin, open the primary route's MKR file, copy all of the new markers we made (should be at the bottom), and then paste them into the secondary route's MKR file. Unfortunately I don't have a version of the RGS before I trimmed it, but Markers_RGS.jpg shows our new markers and the hole I carved in the RGS as a result. The important thing is that the markers gave me a view of the area of overlap in the two routes, and the Mosaic view gave me the world file names. Keep a list of world and tile file names that need to be trimmed...


Here is the procedure I used to carve the hole. Work carefully.
1) Open the secondary route in the RE, navigate to a tile boundary on a tile that will eventually be deleted. Travel along the trackage and delete all (ALL) of the interactives that you can find. Do the same thing for such things as carspawners on roads. Do this everywhere on all tiles that will eventually be trimmed. Check and doublecheck.
2) After that, start on the track and roads. Delete all (ALL) that you can find, occasionally saving as you go. When you're done with this, you should have a healthy TDB/RDB that's totally independent of anything in the primary route. Time to find out about health in TSUtils.
3) Using your list of world files,simply delete the "w" files and any "ws" files with the same root name just as you did in the primary route. We need to avoid overlap there too.
4) After all of that, it's time to trim the tiles, either by RGE or Demex. If you use the RGE, you can have your Mosaic "viewer" open at the same time. With our new markers visible, the Mosaic view will surely help you count row and column so that you can select the proper tiles in the RGE to delete.

Probably by now you can see the value of the time spent making the markers at the first.

So now just do the merge. In RR, primary route is selected in left pane, secondary in right. Follow anything the TSUtils routine says after you click on merge.

Some things will not be merged, like REF files, forest.dat, carspawn.dat, etc. Those will remain as in the primary route, but can easily be manually merged. We can talk about those later if you need to. I think there can be problems with signals, and "professional" help would be required there (not me).

A word about Distant Mountains. They follow the same rules as std tiles in regard to overlap. In my case, the DM's in the RGS were in such poor condition that I simply deleted the DM quadtree files in the TD folder in the RGS route (files with an "L" in the name). After the merge, I edited the resulting DM quadtree to add the needed extra tiles and DEM'ed the DM's again.

The standard tile view:


regards,
charlie