Historical Base Map Widget

[danrademacher]

In a recent conversation with @jeffreyameyer, we discussed developing a new widget that would highlight historic maps used to map elements in the viewport and then allow users to add those historic maps as overlays on the main OHM map.

This is an initial overview issue to list out assumptions and approaches.

Assumptions

1. Users digitize map elements from WMS or TMS layers in iD or JOSM.
2. Those files/tiles are published on the web at unauthenticated URLs
3. User would supply the URL and a NAME for the map tied to an element
4. Those tags would be added to Vector Tiles
5. Our widget would poll all the tiles in the GL layer, get the unique combinations of URL+NAME
6. Our widget would allow users to select one or more of those NAME+URL combos and we would add that to Leaflet as a layer on top of the vector tiles. Note this would be in Leaflet and not in Mapbox GL, since we are embedding GL as a layer inside Leaflet and Leaflet handles raster layers more easily than GL.
7. Likely we need transparency sliders for these maps to allow users to compare vector and with raster data.

Note that for 3 we might want to match the capabilities for WMS and TMS links in iD:

Challenges

1. This assumes one element in OHM is tied to one map. I wonder how often a single feature might be a composite sourced from multiple maps?
2. We know for sure that many elements might be tied to one map, so there's some tedious repetition of data entry.
3. It's also likely that users will reference the same map with different names, and perhaps even have different endpoiints for multiple digital versions of the same physical historical map.

Design and Development

We could proceed with implementing this feature in the following way:

1. Get a set of sample TMS and WMS layers we can use
2. Make a prototype of a widget based on those examples as a static list
3. Refine design and behavior of that prototype
4. Update vector tiles to include the relevant key:value pairs
5. Refactor the widget to extract the list fo available layers from the maptiles in the viewport. At this point, we would want to assess performance and see whether we are constantly update on map move or only on some other user action.

@jeffreyameyer can you review and comment on this issue for accuracy to what you're imagining? And check our assumptions!

[rwelty1889]

i will use multiple sources where necessary. this can come up for example when trying to nail down start_date and end_date. there are other situations.

[danrademacher]

For multiple maps on a single element, let's just do map:1 and name:1, map:2, name:2...

[jeffreyameyer]

Not sure if I follow how that might work if we needed additional info... e.g. map:1=url to map source map:1:date=date of map map:1:name=name, if one map:1:warped=link to warped map (diff from 1???)

[danrademacher]

@jeffreyameyer it would be super helpful to get a couple of specific examples of actual georectified, tiled maps that we imagine as the source for this feature, so that would help us then see what fields we need at a minimum for the thing to work at all, and what are nice to have.

[jeffreyameyer]

Sure! (apologies, as we're sort of prototyping in real time here...

Check out: https://www.openhistoricalmap.org/way/198291609 - set the time slider to 1856 & most of those elements should match the tags below.

I'll try to clean up another area to match, probably London.

[jeffreyameyer]

[jeffreyameyer]

I'll take your thoughts, @danrademacher & put some more thoughts on 'em!

Challenges

1. This assumes one element in OHM is tied to one map. I wonder how often a single feature might be a composite sourced from multiple maps?

I think this will happen a lot, as this is where the old triple-sourcing will come in handy. I think we should be encouraging people to limit this to the oldest sources possible and to just 3. Now, 3 sources for every building in a city could yield... a lot of maps. Would that be a bad thing? London's Regent Park zoo should provide a nice use case.

2. We know for sure that many elements might be tied to one map, so there's some tedious repetition of data entry.

That's indeed what I'm encountering. I'm wondering what the answer for this might be without creating some sort of onerous infrastructure? The good news is that JOSM offers some auto-fill help on this front. (which can replicate errors quickly!)

3. It's also likely that users will reference the same map with different names, and perhaps even have different endpoiints for multiple digital versions of the same physical historical map.

Yes, but I think that's ok... AND... this very issue (universal indexing of old maps somehow)... might be solved somewhere else. Or, we could have a recommended priority of sourcing based on likelihood of a source being around (e.g. universities, LoC, etc.)

[jeffreyameyer]

Following up on 2) from above - how to avoid tagging every item on a way with source info:

a) As it may be helpful to source just a few items from a map, it seems there might be no way around requiring support for individual map tagging on individual ways.

b) That said, I thought about using relations to identify all of the items from a map. Problem with that is that relations have many restrictions on them that will generate a lot of errors for users (I ignore these, but it's a little at your own peril; see: https://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Touching_inner_rings).

@rwelty1889 @geohacker @batpad - any thoughts here?