Ideas to enhance Trucker Mudgeon's Slippy Map for ATS

ATS slippy map ideas.md

ATS slippy map ideas

These are some ideas of possible enhancements I've been having while using the amazing ATS Map by Trucker Mudgeon for a couple of months. Most of them I haven't considered much at all, some might even be bad ideas; I've just noted them down here so as to not forget about them.

This list is not meant to be a feature request. I'll probably work on implementing some of these ideas eventually, provided I find the time. If somebody else beats me to it, that works too. :) I'm also open to coordinating efforts. Feel free to get in touch, preferably on the SCS forum either in the Slippy Map thread or as PM.

nautofon

Spatial data

• Fix coastline for Eureka, Newport, Seattle, Port Townsend
• Additional detail layers:
  • Exit numbers for interstates etc.
  • Street names would be cool, but sadly the research effort might well be prohibitive
  • Road numbers that aren't already overlays (e.g. Montana secondary or Kansas highways)
  • POIs that aren't overlays, such as Texas historical markers
  • Lake outlines with names: Maybe get outlines from a suitable source (OSM: license might not allow it...) and adjust position such that it fits for ATS? See around Victoria, TX for a number of instances of such lakes.
• Add some form of terrain elevation into the map, such as IRL hillshading or perhaps some contour lines or at least pass elevations (there's some prior discussion of a possible way to obtain the necessary data from the game in the Kansas thread; you would drive all highways with a telemetry log enabled, bin all logged data and you get a DEM which you could probably use for contour lines)
• Try to get some green on the map—might heavily generalized IRL land cover data perhaps look acceptable?
• Try to improve positions of city names, maybe with building buffers?
• Try to use building buffers to improve the scenery town workflow

Cartography

• Fix oversized overlay icons (e.g. Colorado state highways)
• Add black border around white overlays (contrast between white U.S. highway shields and bright map background is insufficient)
• Consider changed representation for hidden content (e.g. hidden overlays could be 50% transparent)
• Try to fix issues with overlay render priority
  • e.g. company icons should perhaps have priority over gas stations; I-244 marker is sometimes visible at low zoom levels when I-44 isn't; etc. etc.
  • e.g. sleeping spot / gas station at a garage should never have priority over the garage icon itself (they're not available unless you happen to actually own that particular garage)
  • in general, it's okay to sometimes let icons overlap a little, even if UI layer toggles are unimplemented
• Render priority of roads: Show grade-separated crossings of two roads as bridges rather than intersections
• Consider replacing "red railways" with level crossing markers similar to OSM Carto
• Investigate options to further improve the road classification, e.g. by assembling strokes or through graph analysis
  • For example: Why is I-84 at Mountain Home, ID colored white rather than yellow?
• The buildings should be shown flat 2D by default (or axonometric at worst) while the map shows the default straight-down view; however, an alternative 3D view is probably still useful as such
• Consider changing the map projection back to LCC in order to not distort distances as much (Google itself finally stopped using Mercator in late 2023, but switched back to Mercator in early 2024 for some reason)
• Fix flash of blue

UI

• Layers you can toggle
  • Consider a non-spoiler view of some sort
  • A layer with company branch identification would be useful
• Try to add a scale bar (perhaps dual: top city scale, bottom rural scale; or top 1:1, bottom 1:20)
• Coordinate readout (game coords? long/lat?)
• Use the SDK to show the player's position (as per truckermudgeon)
• A marker you can drop, with a link you can share, so that others can see the exact place you're referring to. Something like markers on osm.org.
• Add a link to the GH repo. The GH readme should in turn link to the map (both the regular / map and /routes) as well as to the forum discussion. I think the forum discussion's first post should probably be edited to include a link to GH, too.

Toolchain

• Add an option to generator footprints for using geopackage-js to improve performance
• Add a YAML output option to generator

Mileage targets

The following is a preliminary plan to fix the mileage targets mess (for ats-towns scenery town data).

Relevant files (names subject to change):

• def.scs
• filters.json — whether or not a particular mileage target is a valid scenery town
• mileage-targets.csv — see ats-towns
• towns-extra.geojson — extra scenery towns not included in the mileage targets
• towns.geojson — output of resulting scenery towns (possibly separate files by state)

Conceptual workflow:

1. Read the original mileage-targets.sii from def.scs, produce mileage-targets.csv with the current columns
2. Use filters.json to add one additional "status" column; the filters should be regexes that apply to a particular data column (e.g., any row that includes digits in the "editor name" column is almost certainly invalid)
3. Apply mileage target filters ("status" column), create towns.geojson
4. Append entries in towns-extra.geojson to towns.geojson, warning for any suspected duplicates

Optionally, create a mileage-targets.geojson file matching mileage-targets.csv. This may be useful for manual verification. But the ats-towns scripts can already do this, which is possibly good enough.

A decision needs to be made on whether or not to use the result to re-assemble the existing files and directories in ats-towns (for backwards compatibility), or whether to replace the existing file and dir structure with something simpler that is exclusively geared towards the ATS slippy map (smaller maintenance burden).