Design challenge: how to render select features at select zoom levels during a selected time range

Style change requested

Describe what you want to see added or modified in the style. Is it something easy to explain like a color fill or rendering something not currently showing? Or is it a more complex need specific to historical mapping?

If you're asking for new symbology, especially for historical points of interest or areas that might not be part of modern maps, are there existing cartographic symbols or standards we can reference? The more info you can provide here the better!

I would like to be able to render historically important features at appropriate zoom levels, even if they aren't typically rendered at that level today.

For example, dirt roads that linked cities in the Incan Empire should probably be rendered at fairly low zoom levels & the most major railroads should be included in a national map of the US in 1850.

Here's a good example of selected trails that make sense to show at a low zoom level: https://dsl.richmond.edu/panorama/overlandtrails/#loc=5/-2.263/-2.900&date=1/1/1840

Or a very early railroad map (the map itself is a bit messy...):

Affected Tag or Tags

If you know what they are, let us know the specific tags we should target for style changes

I think we need to come up with some sort of time-specific scale rank tagging. For example, Astoria, Oregon makes the national map above (crazy, right?)

name=Astoria place=city scale_rank:1 = 5 scale_start:1 = 1840 scale_end:1 = 1920

But... this will require a processing step to create layers & I'm not sure we have time-specific logic in how we create our vector results... @gregallensworth

At first, I was thinking that @gregallensworth was unlikely to be involved here -- once things are in the vector tiles, the timeslider would operate them to simply show or hide them.

But then I started to wonder: Is this really a question of how data in OHM is tagged? Or is it more like having variant stylesheets with different hierarchies of importance for different centuries?

After writing this comment, I don't see a clear path forward here. Needs some serious thinking about what is feasible.

OHM Tagging Exercise

This is what Jeff starts to describe above, time-specific tagging.

Pros:

The data can be fine-tuned very closely to show when cities were major cities (even if they are minor now), when roads were major vs minor, when railroads or wagon trails were important, and then became less important
Geometry can be retained, along with all other attributes while only the prominence changes

Cons:

Feels like a boil-the-ocean approach where the level of effort for tagging becomes ever higher.
It's not clear why some fields get this treatment and others don't. Maybe they all do? Like road surfaces or other attributes that change, while names, geometry and hierarchy do not
Not actually clear how we would implement this. Can a GL style be made to look at different tags to style on depending on some other Javascript on the page? Sounds hard and potentially slow.
More data we need to cram into map tiles.

stylesheet variant

Another way to solve some of these issues would be to try to make some broad judgments at the stylesheet level -- like >1940, roads are more important than railroads, 1840-1940 RR more important than roads, <1840 trails and dirt tracks get more importance. And then we see about building Javascript that would load different styles based on timeslider selection. This also seems nontrivial!

Pros:

We don't need to change tagging and make mapping in OHM harder
We can more easily test outcomes by loading different style variants and seeing the results (vs waiting for data to be tagged)
We need to solve for a finite number of stylesheet variants, vs a potentially infinite overlap of tagged start- and end-dates for n tags on n entities.

Cons:

Assumes a monolithic idea of "history" that we can discretely block out times when X was more important than Y
Only solves categorical importance of things by type. Doens't solve the issue of a city going from minor to major back to minor.

This is a hard problem!!

Cons:

Can a GL style be made to look at different tags to style on depending on some other Javascript on the page? Sounds hard and potentially slow.

Yes, it technically can. Once the style is loaded into memory, portions can be rewritten and the map redrawn. That's the basis of the timeslider: it rewrites the filtering clauses relevant to start_date and end_date

However, two considerations:

I would consider this a second tool, acting in conjunction with the 'slider, perhaps querying the 'slider for the current year, but then doing its own thing. We do have the 'slider in its own repo with its own demo and so on, and it seems wise to carry on the "tradition" of keeping interactive components rather than a monolithic 'slider that works with literally 1 single map style in the world.
The rewriting is in theory the easier part, compared to inventing a tagging system that somehow communicated change over time and then forcing contributors to comply with that specification rigidly.

Wow one would tag a feature with date-sensitive sets of tags?

By century? e.g. road_type becomes road_type_1100 road_type_1200 road_type_1300 road_type_1400 ... for every century?
- I am dubious that anybody will fill in 20 different fields just to cover the C.E. dates (there are roads from B.C.E. too)
- Grows exponentially with the number of tags, e.g. a building's number of floors, type of business, owner name, and so on.... per century?
- Doesn't address changes in shape/geometry over time.
- Significant bloat in feature tags, loading time, and so on. This means slower loading, tiles potentially being dropped for over-bloat, etc.
With some contrived tags "ending in a string of numbers and maybe a negative sign indicating a range"? e.g. road_type road_type_1820_1930 road_type_1931_1974 road_type_1975_onward
- Very fragile, one must adhere strictly to that protocol, including rewriting pre-existing tags if one wants to change the choronology. e.g. changing the 1930-1931 boundary, means editing 2 tags.
- Sensitive to any deviation e.g. overlaps, gaps.
- Simply a heck of a lot of work.
- Doesn't address changes in shape/geometry over time.
- Still tag bloat, though arguably less.

In my opinion, that's a boondoggle. It would be much more feasible to treat the different features as different features. The road in 1820 surely is not the same as the road in 1965, neither its path nor its attributes. It makes much more sense, even in this most obvious case, to have the road drawn over with its different attributes.

edit the feature and indicate that it ended in 1962
take a copy of the feature
edit the copy as starting in 1962, and alter attributes accordingly
... as well as its shape if applicable, which I imagine is a fair amount of the time

It would be much more feasible to treat the different features as different features.

1000% agree! This is the direction I was describing, where the road we discussed in Peru could be considered a highway hundreds of years ago, but now it's a minor dirt road. I wasn't thinking that these would be multiple separate features, but that's for sure the most straightforward and can work in our current approach to cartography and functionality.

What this doesn't address is the idea that we may want the map to be a "rail" map from 1830 - 1920, then a "highway" map from 1920 to present day. This sounds like it will need some more thinking.

It would be much more feasible to treat the different features as different features.

1000% agree!

A challenge with this approach is that while the features may appear to be different, they not not really have different geometries. Overlapping geometries for the same features can be very tricky to edit, as one might have subsegments not shared by the other concurrent geometries. This is particularly true for long routes like a nationwide trail. And, the idea of "significance" can be independent of any particular feature change. Astoria is a good example of that. A 100,000 person city might be relatively very large in 1800, but that same city, with 150,000 people in 2000 isn't very noteworthy.

There is some appetite for lifecycle tagging of some sort among the OHM community to handle things like name changes, surface changes, etc. over time without having to create separate relations to handle these changes (which is the way it's done now).

So, I guess that's a third way of handling this... creating a map-style specific relation with a scale_rank tag on the relation to call out its importance.

The nice thing about this approach is that, say for the Oregon Trail, you could just duplicate an existing Oregon Trail relation and add differing tags... the (ha, "the"... as if!) problem is that this wouldn't inherit any changes to the underlying OT relation. Another issue is how this would clutter search results.

I really like the idea of a stylesheet-based approach, but the problem there is that we wouldn't want all railroads to get prioritized above roads. The challenge here is how to call out just the important north-south arteries (if any...) on the East Coast, or the major east-west rail routes.

I'm also hoping we can all be open to thinking up approaches that might seem radical or tough within our current constraints, or that might require some rework, as this is indeed a tricky problem given environmental constraints and the general difficulty of modeling stuff like this... for example... should we put some sort of layer in between the browser and the tile server that pre-filters / processes this kind of stuff? [ducks thrown tomatoes]

Related issues:

94 -- the original issue where we had relations coming in at least temporarily, as shown in the issue comments
272
282, essentially the same question

Based on the screenshot from issue #94, here, it does appear that we can make it so that elements in the tiles have tags from a relation and geometry from members ways/nodes, though there may be limitations on that. HEre's the specific screenshot showing this:

Tim, Gregor and I discussed and we think that focusing on using relations as the way to manage changing attributes over time would be the best solution for all three issues above. We avoid duplicating geometry on the editing side, and then on the vtiles side, the existing system we have continues to work as designed.

This is going to be a question for @geohacker based on Issue 94 as to what would be involved in pulling in relations in a similar way for probably every layer in the vector tiles. If that's possible, then we map out how to get there. If not, we need to regroup.

That approach would help for a lot of these challenges, though it would not address the idea that railroads were more important than paved roads in the 19th century. For that, we think the best approach here would be "let a thousand stylesheets bloom" -- make purpose-built maps for railroads, footpaths, battlefields, etc, and make those available on the side panel.

OpenHistoricalMap / issues