1ec5
commented
2 years ago Agreed that mobile compatibility would be beneficial for making the cartographic work here accessible to a wider audience. However, I’m not sure that it would be worth pursuing direct compatibility with all of the specific applications you’ve listed above, which sit on opposite sides of the raster/vector divide and are incompatible with each other (since their custom file capabilities are application-specific by design). That said, we could still achieve a goal of compatibility with some mobile applications, even if they aren’t the ones you’ve listed.
This project made a fundamental early decision to rely on client-side-rendered vector tile technology, which brings with it a number of long-term potential benefits, such as reducing the overhead for iterative style changes and on-demand personalization. GL JS is a Web library, but the Mapbox Vector Tile format and style specification format are both highly portable. There have long been ports of GL JS to Android, iOS, and other native platforms. In principle, any Mapbox/MapLibre style should run just fine (or even better) in an application that uses those libraries.
Unfortunately, this project is implemented as a full-blown Web application rather than a portable style. The actual style starts out blank until JavaScript runtime styling code fills in all the details. This approach is probably overkill for many layers, such as road lines and POI icons, but so far it’s been necessary for route shields, this project’s marquee feature, because we need to composite images on demand at runtime using an API that has no declarative counterpart in the style specification.
68 tracks moving all this runtime styling code to a build step, so that you could take the compiled style JSON file and put it into any GL-powered application regardless of platform. This would also unblock server-side rendering via the mapbox-gl-native Node.js bindings or tileserver-gl. Server-side rendering would produce raster tiles that you could import into an application that isn’t powered by Mapbox/MapLibre GL or that only renders raster tiles. The experience wouldn’t be as nice, but you’d be able to continue using your application of choice.
In the meantime, if you need to use Americana on a mobile device, the only option for now would be to use a mobile Web browser to access it. The Web application should already be compatible with most Android and iOS devices, though not as many as a raster map would be.
michaelblyons
Provide user methods for integration in mobile apps like OsmAnd, Guru Maps, Alpine Maps, etc.
Guru Maps can use .gs.xml files like the ones at ms.gurumaps.app
Alpine Maps has a curated, but huge, list of map sources.
Neither of these support vector format afaik
Making the map easily usable in mobile apps would make it more accessible for the average person, boosting engagement with the project. The map is at a stage that it can be widely used and promoted.