Ah, but that's the beauty of my scheme to "banish" the Non-industrial indicator to the italics font in the world names! That way I don't have to assign a color stripe to Non-industrial trade codes! Helps to limit the opportunities of the dreaded "triple color stripes" in the same world icon circle you see.
The Rich trade classification is not the only one that differs between CT and T5; other differences between CT and T5 can be found in the Industrial, Non-industrial, Water world, Desert world, and Barren world trade classifications.
What would be needed is for Joshua to add a new option to the SEC data API for selecting trade classification rules — perhaps something like tradeclass=SecondSurvey (for T5 trade classification rules, which would be the default for /data/ URLs) and tradeclass=Legacy (for CT trade classification rules, which would be the default for /api/ URLs).
I wouldn’t be surprised if the name Elixabeth were originally an “off-by-one” typographical error for Elizabeth, since X is a neighbor of Z on a QWERTY keyboard layout.Also had to fix the Government codes and “ownership” attribution for Elixabeth and Talchek so they reported as being colonies (code: 6) of Forine as published in LBB S3. Travellermap has an incorrect attribution of “ownership” for Elixabeth pointing to Dallia (O:1335) instead of Forine (O:1533) as stipulated repeatedly in the Travellerwiki page for Elixabeth. A transposition typo, I'm sure.
I agree.
I "steal" time in snippets so I'm not trying to do everything everywhere all at once in a single sitting.
It’s a shame that the Poster API doesn’t also provide an option for .svg output; updating a SVG image can be done in a text editor (its internal format is not unlike HTML, and it uses CSS for styling). I’d made a .svg of the Gemini subsector of the Solomani Rim as an experiment a few years back, and used cursor hovering to display certain information (e.g. if the cursor is hovered over the world in the center of a hex, it displays the world’s hydrographic information and trade classifications; if it’s hovered over the starport letter in a hex, it displays the UWP of the world; &c.). I’d made my own style (though still using Univers, Optima, and MICR typeface clones) rather than making an homage to one of the Traveller Map styles. It wasn’t nearly as trade-oriented as the style that you’re developing.
I keep thinking that a trade-oriented sector map makes a pretty darn decent "lowest common denominator" that provides such a (useful) wealth of information at a glance for the widest possible range of uses, including casual travellers (among others).
Whoops — mea culpa! The Rendering APIs do provide an option for .svg output: the accept=image/svg+xml option can be used with all of the Tile, Poster, and Jump Map APIs. If the SVG elements are well organized within the .svg files when this option is specified, then it should be much easier to modify the styles of mainworld names in .svg images than in their analogous .png images.
Attached is a .png of the style that I’d used for the Gemini subsector. My design goal was more oriented to a navigator’s perspective. The world colors relate to the world’s hydrographic percentage (the darker the blue/green, the higher the percentage), with the “backslash” overlay on some worlds representing “no dipping for unrefined fuel” (because the hydrographic percentage was too low); the nasty off-chartreuse (e.g. Hanumān) representing a world with fluid oceans; and a light tan (e.g. Parsifal) representing a desert world. Asteroid belts (e.g. Castor) are represented by a dot pattern in a “world” shape.
I’ll have to try downloading a subsector as a .svg image using the Poster API to see what the .svg image’s internal organization is like.
As a test, I’d downloaded the Aramis subsector of the Spinward Marches as a .svg image using this URL, with a milieu of M1105, a style of print, and an accept of image/svg+xml. The internal organization of the .svg image is unfortunately decentralized; the styles are explicitly applied to each text element rather than centralized by class types in a CSS section. For example, here is the text element for the world named Towers in hex 3103:
Document the steps for me so that I and anyone else can replicate what you're doing, in addition to being able to "dig into" the encoding so as to be able to make these kinds of custom edits and changes via coding as opposed to image editing like I'm doing right now.
Yeah ... that formulation is something that I (personally) find difficult to read/discern details in. The step changes are "too subtle" to be readily apparent (darker blue/green scaling) and I have to actively WORK to make sense of other bits of information buried in that format of presentation.
) then just simply knowing if wilderness refueling is available becomes rather wholly inadequate to the task of plotting the Best Route™ between Here and There (which ought to be the Navigator's job).Well, the advantage would be that an edited .svg file could be published and replicated by others more easily (just copy/paste into the APIs).
), but this italics in world names effort is really making me "see" an entirely new dimension of DEPTH in the "texture of subsectors" simply because the world names don't just look all the same everywhere.He did, he gave you the URL necessary to download the SVG file.
curl "https://travellermap.com/api/poster?sector=Spinward%20Marches&subsector=Aramis&milieu=M1105&style=print&accept=image/svg+xml" > subsector.xmlI haven’t read through the Traveller Map API page in detail, so there might be options there that would simplify what I saw in the Aramis subsector page that I’d looked at. That being stated,
No doubt; as I’d noted before, that Gemini subsector image was an experiment regarding the viability of using SVG, not an example of ideal design. Fortunately, I don’t try to eke out a living as a designer.
