Wiki Update: Trade maps updated

[tjoneslo]

After a few false starts, I've re-run the PyRoute trade generation process and updated the maps, data, and summary information.

Current statistics are 132 sectors, 50,616 world processed. This includes all of the latest data from Traveller Map (official and unofficial).

I also tried a new process of using a wiki bot process to upload the data, rather than manually cutting and pasting the new information. Most of the data went in without a hitch. There are still a few bugs to work out.

Any suggestions for improvement are welcomed.

 

[Garnfellow]

Based on a quick check of Magyar it appears that the revised trade routes tend to be larger -- I don't remember a major line, and there seem to be more main lines. Is that my poor memory, a fluke of this sector, or a trend across all the sectors? If it is a change, what is driving it?

 

[rancke]

I see you're still using the '<sector>/data' file name for these new economic data. I thought you were going to restore the use of /data to contain the extended UWPs and come up with another name for the economic stuff (like /econ, perhaps).


Hans

 

[tjoneslo]

Based on a quick check of Magyar it appears that the revised trade routes tend to be larger -- I don't remember a major line, and there seem to be more main lines. Is that my poor memory, a fluke of this sector, or a trend across all the sectors? If it is a change, what is driving it?

When I switched to using the newer PyRoute program, there was a jump in the number of major (BTN 12+, the dark blue) routes over the much older nroute.c generated routes. And there are a few BTN 13+ route (a violet color, see Old Expanses).

I never completely understood the core route finding algorithm in the nroute.c program. Which is part of the reason why I wrote my own version.

The process of adding the trade of overlaying routes was done differently. If a longer route between two worlds also travels between two smaller worlds, the route between them may be larger than you expect.

And the PyRoute program is more aggressive in its effort to reuse routes. That is, if one route calculation follows a route A -> B -> C ->D, other calculated routes will follow the same route. I've tweaked the setting for this aspect down a little. And I may change it again for the next run.

 

[tjoneslo]

I see you're still using the '<sector>/data' file name for these new economic data. I thought you were going to restore the use of /data to contain the extended UWPs and come up with another name for the economic stuff (like /econ, perhaps).

I am not going to move, upload new files, and update 132 sectors worth of data by hand. Now that I have a handle on using the wiki bot software and can do that by writing a little code rather than aggravating my carpel tunnel again, I'm going to do that.

Note: If you look at the infobox for the many of the sector pages (column on the right side) there is a direct link to the sector file, as well as one in the header of the data page.

 

[maksimsmelchak]

I am not going to move, upload new files, and update 132 sectors worth of data by hand. Now that I have a handle on using the wiki bot software and can do that by writing a little code rather than aggravating my carpel tunnel again, I'm going to do that.

Note: If you look at the infobox for the many of the sector pages (column on the right side) there is a direct link to the sector file, as well as one in the header of the data page.

Hi Thomas,

If you can use a hand with writing, entering, or otherwise creating this code, please let me know. I'll volunteer to assist you as you see fit.

Thank you.

Shalom,
Maksim-Smelchak.

 

[rancke]

I am not going to move, upload new files, and update 132 sectors worth of data by hand. Now that I have a handle on using the wiki bot software and can do that by writing a little code rather than aggravating my carpel tunnel again, I'm going to do that.

So you're going to keep '/data' for the new economic stuff. Very well. So noted. What do you suggest be used for the files containing the old extended UWPs?

Note: If you look at the infobox for the many of the sector pages (column on the right side) there is a direct link to the sector file, as well as one in the header of the data page.

What are you saying here?


Hans

 

[tjoneslo]

Note: If you look at the infobox for the many of the sector pages (column on the right side) there is a direct link to the sector file.

What are you saying here?

You want a way of looking at the extended UWP information for each sector correct?

If you look in the article for each sector (e.g. Spinward Marches), on the right side of the page, there is a set of links in a section with a green background. The last link is associated with the text:

This sector has sector data

If you click on the link, you will see the extended sector data for the sector. I'm unclear what more than that do you want.

 

[rancke]

You want a way of looking at the extended UWP information for each sector correct?

If you look in the article for each sector (e.g. Spinward Marches), on the right side of the page, there is a set of links in a section with a green background. The last link is associated with the text:



If you click on the link, you will see the extended sector data for the sector. I'm unclear what more than that do you want.

I guess the original issue has been lost in time. It's been quite a while since I raised it. I had been doing subsector extracts of the sector data in my usual haphazard, non-systematic way every time I worked with a subsector and needed to look at the UWPs. Only about a dozen all told, IIRC. Since the sector UWPs were in '<sector>/data' files, I put my subsector UWPs in '<subsector>/data' files, as I think you'll agree was pretty reasonable.

Example: Rhylanor subsector data.

When you decided to put the new economic data in '<sector>/data' files, I objected and suggested you retain the '/data' files for the old data and use e.g. '/econ' files for the new data. Which I think was not unreasonable. As I recall it, you said you would, but that for some reason which I've forgotten you would wait for something or other to be done first before doing so. At which point I turned my attention to other matters.

Now that you informed me that you will not, after all, be going back to the old arrangement, I intend to move the dozen '<subsector>/data' files to some other file name, and would like to choose something that won't be preempted for some other purpose down the road. Hence my asking for a suggestion.

Does that sound reasonable?

Incidentally, the files you refer to do not contain the old 80-character extended UWPs we know and love and find so useful with Galactic. It's some sort of extended extended UWPs.


Hans

 

[tjoneslo]

There are three suggestions here, so I'm going to repeat them back to make sure we're clear.

1) The "extended" data files from the T5 Second Survey contain a number of new/extra fields and the wiki should provide the data in a "Legacy" format, something closer to: https://travellermap.com/api/sec?sector=Spin&type=Legacy

2) I promised that I would move the generated economic data from it current /data page to new /economics page, and return the extended UWP data to the /data page. Which I have not done for reasons.

3) You think it would be interesting to have a subsector/data page (with extended but not T5SS UWP data) and a subsector/economics page, both updated either from the sector data or at the same time as the sector data.

There are two outstanding questions I have about implementing this:

I have two choices for formatting both the UWP data and the economic data. The first is to use the older style, a pre-formatted text layout with a fixed width font. It look something like this:

Hex  Name                 UWP       Remarks                                  {Ix}   (Ex)    [Cx]   N     B  Z PBG W  A    Stellar       
---- -------------------- --------- ---------------------------------------- ------ ------- ------ ----- -- - --- -- ---- --------------
0101 Zeycude              C430698-9 De Na Ni Po                              { -1 } (C53-1) [6559] -     -  - 613 8  ZhCo K9 V          
0102 Reno                 C4207B9-A De He Na Po Pi                           { 1 }  (C6A+2) [886B] -     -  - 603 12 ZhCo G8 V M1 V

The second option is to use a Wiki formatted table as shown in the current /data pages. The advantage of this latter is the columns can be sorted (for quick analysis), the layout looks better (at least to me), and I can hide some query extraction/formatting codes to make the subsector layout processing easier. You can also do a select/copy/paste and the columns come out as tab-delimeted for easy insertion into spreadsheets or text files for other analysis.

Second, since you are expressing the preference not to use the T5SS extended UWP format, do you have a preference for which of the <N> other sector formats are selected, or should I pick one.

 

[maksimsmelchak]

The second option is to use a Wiki formatted table as shown in the current /data pages. The advantage of this latter is the columns can be sorted (for quick analysis), the layout looks better (at least to me), and I can hide some query extraction/formatting codes to make the subsector layout processing easier. You can also do a select/copy/paste and the columns come out as tab-delimeted for easy insertion into spreadsheets or text files for other analysis.

I greatly prefer nested tables. They are easier to read and they can be sorted making vastly easier to find things.

Second, since you are expressing the preference not to use the T5SS extended UWP format, do you have a preference for which of the <N> other sector formats are selected, or should I pick one.

*** What are the standard accepted formats for T5SS extended UWPs? ***

Shalom,
Maksim-Smelchak.