Template talk:Map

Improved Interface Proposal

In anticipation of a more flexible method to highlight features directly pulled from the base layer, I propose the following parameters to interface with that system:

• Universal parameters: {{Map|stroke=?|stroke-width=?|title=?|description=?}}, with stroke and stroke-width operating the same as the Kartographer implementations. title and description would overwrite any title and description further down the chain.
• By Wikidata: {{Map|id=?}}, where id reflects the article's wikidata. This can be defaulted from the page's wikidata item. If the article references a system, it can look for instances of Wikidata relationship P16 within that network.
• Individual Highways: {{Map|network=?|ref=?}}, equivalent to an Overpass query of rel["route"="road"]["network"="?"]["ref"="?"];. The ref can be either signed or unsigned.
• Highway system: {{Map|network=?|ref=?}}, equivalent to an Overpass query of rel["route"="road"]["network"="?"];. The parameter ref=? (this time the question mark isn't a placeholder) would distinguish between highways that are signed vs. unsigned, a stipulation I put in specifically to exclude NY's reference routes; the parameter unsigned_ref=? would include only reference routes. Members of the system would act as their own Features. The title parameter would stipulate a naming pattern; for example, something like title=New Jersey Route %ref% would return "New Jersey Route 33" where the OSM ref is 33. The description parameter could have a switch attached to individual elements for more information; for example, {324:"Unsigned",58:"Former"}, when attached to NJ's system, would describe NJ 324 as "Unsigned", and NJ 58 as "Former".
• Custom queries: {{Map|query=?|area=?}}, where query just plugs the parameter directly as an Overpass query, and area refines the search, separated by commas like addresses such that query=Kalamazoo, Michigan, USA filters by the USA, then Michigan, then Kalamazoo. These queries would be bound in a single Feature (see "Suffixed Paramaters" below to create more than one Feature).
• Queries by OSM id would be HEAVILY discouraged, but you could theoretically type in {{Map|way=?}} or {{Map|rel=?}}.
• Historic queries: {{Map|historic=yes}} or {{Map|historic=March 15, 1900;1970-01-01;now}} would automatically change the base map to an OHM base, and no OSM base may be specified. If the historic parameter is set to yes, then any queries that match across time would be included, otherwise only those that lie in those dates would come up. Underneath the map would be a slider that scrolls through time. If dates are specified in the historic parameter, then the first and last dates chronologically would be the start and end of the slider; otherwise, the end date would be the current date, and the start date would be determined from the first instance of the query. If only one date is specified, this would be presumed to be the end date. Any further dates specified along the timeline would be snap points for the slider, to highlight a fresh change to the relation (for example, the opening of a new bypass). Without further dates, any new instance of the query would be presumed to be a snap point (up to a point; if there's too many changes, no snapping will occur). The text showing the date shown ought to be editable to specify the state on a specific date.
• Suffixed Parameters would bind parameters together, much as they did in Kartographer, so that multiple "features" can be created.

Thoughts? (I realize this is a far-in-the-future thing to implement, but why not figure it out now?)

— Preceding unsigned comment added by BMACS1002 (talk • contribs) 01:07, 6 November 2023 (UTC)

Good stuff. I appreciate your brainstorming. A lot of this stuff is already quite doable; there's just a psychological hurdle to diving in and doing it.

I think it'll be good to have these querying capabilities as a failsafe, but we'll need to be careful about giving editors plenty of options before they end up relying on it. The Maps gadget has no backend, so instead of Kartographer's geoline service, we've been relying on Wikimedia Commons map data files. The Overpass API can provide on-demand results in principle, but we'd be relying on a public instance that can time out or get throttled rather unpredictably. I experience this all the time when flipping through Wikidata items due to the Overpass gadget I have enabled. We'd have to handle errors gracefully. To mitigate errors due to load, I think any Overpass API fallback should wait until the user explicitly asks for it to load by clicking some kind of interstitial overlay.

Regarding highway networks, d:Property:P16 is good for crawling up the hierarchy to the network that a route belongs to, but enumerating all the members of that network is less straightforward. It is possible to come up with a search API query for the members, thanks to WikibaseCirrusSearch, but it's a lot more straightforward to query the Wikidata Query Service instead.

As for OpenHistoricalMap, I think we should preserve the option to view the basemap without an overlay. For example, on Fort Washington Way#Construction, highlighting the route per se would detract from the message we're trying to convey (the complex ramp system). In that case, a swiping interface is ideal for comparing two points in time. However, if we want to compare more than two points in time, then this interface breaks down. Your jump point idea would be ideal for these cases. It reminds me of openhistoricalmap.org's "time slider" widget, which lets you scrub, step through, or animate within a date range on a user-defined interval. This interface is available as a Leaflet plugin, but we're using MapLibre GL JS. Anyways, I think your jump points would be more appropriate for this wiki, since the article should be opinionated about which dates to present to the user.

 – Minh Nguyễn ^💬 20:50, 5 November 2023 (EST)

I probably should've specified that all of my speculations anticipates a system that isn't MapLibre that can pull data directly from the information already present in the base layer, hence the requirement that the base layer in historic mode be an OHM base, or it dynamically changes the style specifications of the base layer. BMACS1002 08:19, 6 November 2023 (EST)

Oh, yes, MapLibre is imminently capable of the tile querying you’re referring to. The main limiting factor is that often we need to display a route overview at a very low zoom level, lower than a zoom level at which a general-purpose basemap would show all the routes. On the OpenStreetMap side, the OSM Americana project needs to move off of OpenMapTiles so we can start including routes at lower zoom levels, or we could spin up our own tileset specific to roads needed by AARW with extra effort. On the OpenHistoricalMap side, the tile schema currently doesn’t expose route relation details, but this is on the team’s radar. [1] Once that happens, it’ll be fairly straightforward to adapt the Americana style to OHM tiles. [2] – Minh Nguyễn ^💬 16:26, 7 November 2023 (EST)