Digital Nonvisual Maps

Hello,

I would like this topic to contain discussion related to standardizing nonvisual mapping techniques. If the discussion becomes too big, we can split the topic, but for now, there are quite a few similar requirements for nonvisual maps.

Here are some links from the presentations:

Digital Auditory Maps:

Audiom - The cross-sensory web map widget builder.

TEAM - An OSM viewer of data in a first-person view.

iSonic - A heatmap tool.

SAS Graphics Accelerator - Audio Graphics tool, allows the creation of heatmaps and maps with points (as well as other sonifications).

Grmapa - A grid-based presentation of OSM data.

Vibro Haptic Maps:

VEMI Lab - A company that makes Vibro haptic diagrams.

Commonalities Between the Above Maps

1. All features need a name property along with an attribute
2. All maps use an egocentric viewpoint rather than an allocentric viewpoint
3. All the maps use a type property, like “Restaurant” or “Metro”

Things to Consider for the Future

Web XR is here, and along with Web XR comes peripherals and multimodal displays. HaptX is an example of a tactile display that would bring a tactile 3D model map or raised line map viewer to the web.

Thanks for starting the conversation with this post, @brandon.biggs.

Your presentation was excellent, and really sets us up to establish what the goals of standardized Web maps should be. The considerations you raised in your position statement can and should be incorporated into the evolving Requirements and Use Cases for Web Maps.

I hope that this sets the stage for developing truly accessible standardized Web maps in the future.

To standardize adding semantic information to web maps, here is a GitHub issue that might be relevant.

@opyh Thank you! I would like to put forth a requirement that features have a name and geometry feature, but how will this work with Raster and tile maps? One option is that tile maps have a bounding box, but since tiles can have many features inside of them, a single name may not be enough, and a bounding box would not tell a user much, other than there’s a chunk of stuff here. Any ideas about how to make raster maps more meaningful than a blob of pixels?

The GIS function “identify” is a long-standing mapping pattern, and it is part of the WMS and WMTS standards as “GetFeatureInfo”. In MapML, we implement this as <link rel="query">, which allows the user to trigger a server-side query that can return MapML, HTML or I suppose anything else, but most useful if a supported media type. With HTML and MapML responses the markup is up to the service provider (usually oneself).

I’m not sure these properties give enough info to show the spatial relationships between features within a tile, especially larger tiles. If tiles are small, like a 1-3 meters, then it would be pretty safe to use properties associated with the tile to create the geometries. Otherwise, I guess we’re back to text descriptions generated through viewing properties. Essentially, what is needed is a raster to vector map converter for larger tiles (a whole PHD thesis on its own!). Please let me know if I’m missing something!