Reorder Widget Capabilities

[nchan0154]

I've worked on a potential order for the widget capability list that I think makes more sense. They fall roughly into the groups below, which we will not include in the report, but I just wanted to show what kind of thought process I had. The ones earlier on the list are more commonly found in widgets, and the later ones are some of the more 'advanced' functionality that we rarely see in the wild. Thoughts welcome! @AmeliaBR

Showing a particular place on the map:

• Generate a default map for a given area
• Select map view from latitude and longitude point
• Select map view from street address or place name

Expected user interface behaviors:

• Zoom the map independently from the rest of the page
• Pan the map display
• Load additional map tiles when they pan into view
• Wrap/duplicate data tiles when panning around the globe
• Maintain reasonable scale of labels and lines when zooming
• Dynamically load different resolution map tile on zoom
• Hide or show (and maybe dynamically load) vector features and labels on zoom

Display features that are beyond the basic capability of showing an area:

• Show pinpoint locations or custom markers on the map
• Draw polygons or polylines as stylable, interactive vector graphics (separate from the image tiles)
• Support hyperlinks from markers or vector features
• Display a basic map without JavaScript.
• Display map data attribution and links

Styling:

• Apply custom styling to map markers and vector features
• Apply custom styling to map controls
• Toggle whether default controls are displayed

Modifying the display of the map beyond whatever initial standard is set:

• Display a map using tile data from an author-specified web map service
• Display map tiles defined in various common coordinate systems
• Reproject map tile data into a new projection or globe view

Related to exporting, data formats

• Save the location or export to other application

[cmhodgson]

I feel like there are some capabilities that you haven't considered:

• the base map my not be tiled, it could be a single image rendered on the fly (WMS) or pre-loaded (panning an oversize image), or even vectors
• overlay layers don't just have to be vectors, they can also be transparent tiles, or images
• to me, "show pinpoint locations on the map" is just a specialization of showing a vector feature layer

I really think there needs to be a definition of a map as a collection of layers, layers which can be various types, eg. tile, image, vector, which are arranged in a stack using z-order, with the lowest layer being the "base layer", and other layers being overlays... this level of abstraction prevents you from duplicating the requirements for the "map" (ie. base layer) and the "features" (ie. overlays), as they are all just layers, and therefore should be able to do all the things that layers do (turn on and off, change style, pan/zoom together, etc).

Maybe I'm too biased by my experience with existing web map tools, but they all work this way for a reason, you need to be able to group "things shown on the map" together in order to manage them because there are typically to many "things on the map" to manage them individually. Thus, the layer concept.

[AmeliaBR]

All good points, @cmhodgson. One benefit of using a more structured organization for the capabilities list is that it is easier to see the gaps in the list! To clarify: the current list was really just me brainstorming when I started the draft, it was never meant to be exhaustive.

Re, "show pinpoint locations on the map", I think drawing a marker is sufficiently different from a polyline/polygon to talk about them as different capabilities. How you add the feature to the map & how you style it are different, and some web map tools may support one but not the other. But more discussion can happen on the pages for those specific capabilities: #56 is for markers, looks like we still need to open a discussion issue for the polyline/polygon capability. I'll try to go through this week & fill in the missing discussion pages.

Re the definitions of maps vs layers, I'll copy that over to #31, about needing a proper glossary.

[AmeliaBR]

@nchan0154 I think you've covered the main categories. My one suggestion would be to move up the "Modifying the display of the map beyond whatever initial standard is set" points to be the second category. For the libraries that don't come with a default set of map tiles, being able to specify map tiles is very important! Similarly, I'd group "Display a basic map without JavaScript" in the basic map display section instead of with features and annotations.

One option would be to group those with the basic "display a map" and then have the points about choosing a map location separately, grouped with the "export location" item.

Thinking this through, I think it might be worth inserting actual headings into the report for these categories. It'll make it easier to navigate, and as I mentioned above, it makes it easier for us to see what we're missing. I don't want to nest headings too deep, though, so maybe we can just split up the h3 section into categories:

4. Map Viewer Widgets
   1. Use Cases for Website Authors or Developers
   2. Use Cases for Website Visitors (end users)
   3. Capabilities: Image map rendering
   4. Capabilities: Vector map features
   5. Capabilities: Interpreting locations & map positions
   6. Capabilities: User navigation (pan & zoom)
   7. Capabilities: Custom styling

[nchan0154]

@cmhodgson Sorry if it wasn't clear, this section is specifically pertaining to map widgets/embeds (an example of which are the Google Maps embeds that sites often use for location viewers), which are discussed differently from the more robust APIs. Thus, this list may seem a little simplistic compared to the more deeper discussion planned for the Client Side API capabilities list. If you have any suggestion for tools that fit within the 'widget' definition that do what you suggested, particularly the WMS/single image rendered-on-the-fly, I would be very happy to test them!

@AmeliaBR So far I have not tested any tools that kind fit into our widget definition that don't come with a default set of tiles as I mainly stuck to the ones with URL based config, but if you have any suggestions for what other tools belong in this category, I would be happy to add to the list.

I agree that clear headings would help organization a lot! Below is how I'd group the list according to the headings you've set, feel free to copy/edit this list however, I'm not 100% sure I'm interpreting these correctly. 😂

Capabilities: Image map rendering

• Generate a default map for a given area
• Display a map using a single custom image as a map layer
• Display a map using tile data from an author-specified web map service
• Display a basic map without JavaScript.

Capabilities: Vector map features

• Show pinpoint locations or custom markers on the map
• Draw polygons or polylines as stylable, interactive vector graphics (separate from the image tiles)
• Support hyperlinks from markers or vector features
• Display map data attribution and links

Capabilities: Interpreting locations & map positions

• Select map view from latitude and longitude point
• Select map view from street address or place name
• Display map tiles defined in various common coordinate systems
• Reproject map tile data into a new projection or globe view

Capabilities: User navigation (pan & zoom)

• Zoom the map independently from the rest of the page
• Pan the map display
• Load additional map tiles when they pan into view
• Wrap/duplicate data tiles when panning around the globe
• Maintain reasonable scale of labels and lines when zooming
• Dynamically load different resolution map tile on zoom
• Hide or show (and maybe dynamically load) vector features and labels on zoom

Capabilities: Custom styling

• Apply custom styling to map markers and vector features
• Apply custom styling to map controls
• Toggle whether default controls are displayed
• Modifying the display of the map beyond whatever initial standard is set:

[AmeliaBR]

Thanks Nic, looks like we're on the same page. But I'd still move up the capability for custom map tiles, to the first category on image map rendering.

I have not tested any tools that kind fit into our widget definition that don't come with a default set of tiles

As I said on our call, I'd like to include the API-based tools in the widget comparison, so we can talk about the default UI of things like Leaflet and OpenLayers. And yes, I also said we should focus on the simplest versions of those, the features that can be declared in initial configuration calls, which can be conceptually replaced by elements and attribute. Which means I wouldn't be talking about extensive customization of map sources.

But some of the APIs have something close to declarative options for specifying a map tile server, e.g., in Leaflet a standard map tile server can be added as a custom layer with a base URL and a few options. That's something that could be represented as attributes on a <layer> element of some sort. The code for OpenLayers is a little more verbose, but still mostly contained in an initial JS configuration object. Even services that provide their own map layers can integrate with standard tile servers, e.g., here's the WMS demo for TomTom (the demo uses their own WMS interface, but emphasizes that it could work with any compatible service).

BTW, based on Chris's comments, we probably want to split this capability in two: Capable of displaying a single custom image as a map layer (where you can specify the image for the entire layer with a single URL), vs Capable of displaying a map tile set (assuming the tile server follows some sort of standard structure).

[nchan0154]

@AmeliaBR Thank you, this clarifies things for me! I will submit a PR soon with the reordered list (edited my past comment with the order updated and to reflect the split you just mentioned).

[AmeliaBR]

Closed by #93