Adding OSM data to layers

General
1

Current situation
ORM’s recent addition of historical data is interesting, but it reminds us that OpenHistorical is still a young project that often leaves only two choices:

  • display historical content on a map that is 99.99% empty, and therefore unusable.
  • or display historical content on a current basemap, which isn’t very useful (the Pacific Electric Glendora line didn’t cross a sea of ​​residential areas but orange groves).

On the other hand, I’m noticing content additions that unnecessarily duplicate OSM, by which I mean the new Liège tramway in Belgium, which was put into service a long time ago in a galaxy… 2025, among others (remember that OSM, which only seeks to map the current situation, has existed for two decades).

OpenStreetMap
And then there’s OSM. It has a license compatible with the project, it’s collaborative, and it has hundreds of thousands, if not millions, of objects tagged with start dates.

We could import a massive amount of data without interfering with OHM’s own database and without having to make any changes to the way OSM’s tagging system works.

Given that this tag is very stable on OSM, and given the amount of data to be processed, updates could only be made every X weeks or months.

This would leave the problem of overlapping objects, one from OSM and the other from OHM sharing a common existence range.
This could be resolved by excluding from layers all objects from the OHM database that do not have an end_date and by recalling the old OHM motto that once appeared at the top of the project description: “This project’s goal is to create the world’s most universal, detailed, and out-of-date map.”

Conflict between dates
This however raises a problem that only affects a minority of cases where there is a conflict between the start_date and start_date: something.

Would it be technically possible for the software that creates the layers to read, compare values, and choose a specific one?
For example, a road has the following tags:

  • start_date=1850
  • start_date:oneway=1970
  • start_date:name=1999

Would it be possible, in this case, to tell the machine to read the data from the start_date and start_date:something tags and choose the most recent value from these tags? In this case, 1999.

*You can find an almost complete example of what a fusion of OSM-OHM data gives with the castle of Nantes in France.

1 Like
2

Thanks for laying out this proposal. I’d like to take a step back from the technical aspects to address some underlying nontechnical assumptions about the state of the project.

It’s more complicated than that. If we were to import a significant amount of data from OSM unconditionally, OHM would be legally compelled to relicense the entire database as ODbL. Among other things, this would diminish our ability to serve as the definitive source of certain aspects of history already substantially covered under more permissive licenses. On the other hand, OSM is more than welcome to import OHM (or at least the parts that are in the public domain). So a hypothetical future database mixing both datasets would most likely be called OSM, not OHM. At least that’s the legal situation.

A bigger challenge in my view is that OSM culturally does not value research as much as direct observation. Mappers have been trained to reflexively ask, “Can I observe this on the ground?” In the absence of observational data, mappers contort themselves into hypotheticals about what would be observed by someone essentially conducting archaeological research or oral history while ignoring published works. This difference in methodology is the biggest difference between OSM and OHM, not the superficial divide between past and present.

This is not a knock against OSM but rather a reflection of the different scope, intended audience, and use cases. What does it really mean to use historical GIS data? Historical GIS is not merely a simulation of a past environment. History is about so much more than seeing things laid out on a static map, especially when we look beyond transportation history. People, events, issues – clever mapmakers quickly run out of visual language to convey this information. We can deliver value beyond what we depict by facilitating access to rich historical accounts of the places we map. This should influence our conception of “completeness”, as in some sense our acceptance of history makes us inherently more complete than OSM.

Among historical GIS projects, OHM is quite unusual in the degree to which our website focuses on empirical uses of hard data. There are casual gestures to telling a fuller story about the data, such as the Wikipedia snippet or occasional image preview, but otherwise we’re suffering from an uncanny valley caused by the site’s resemblance to openstreetmap.org. Now that we have more of a consensus on how to cite sources, we need to center those sources and encourage readers to make use of them. Another long-term goal is to use linked data (such as wikidata=* and Wikidata items) to integrate OHM data with more compelling content that we can’t visualize on the map. As painful as it is to see a few oases of brilliantly researched mapping in a sea of blankness, I suspect this would do more justice to the data than than drowning it out in a forest of ahistorical data.

Regardless, your proposal highlights the need to make it easier to cross-reference OHM with OSM beyond the layer switcher we have on the homepage. Once OSM debuts their official vector tileset, which is currently in beta testing, we’ll be able to more selectively visualize the two datasets together and, through linked data, establish more explicit relationships between the datasets at the “data consumer” level.

1 Like
3

Yes, this is technically feasible. Recent work on coalescing redundant boundary lines points to how the tile generator could, in principle, cross-multiply an OHM element by each of the attribute-level dates to result in a series of coincident features that each represent a certain combination of attributes.

Unfortunately, the tile generator is only one piece of software that would need to accommodate such a change. We would need to also adapt or rearchitect most editors, geocoders, querying engines, and ultimately routing engines to accommodate this data model. This is essentially what doomed the original concept of key-level history that one still sees on occasion in OSM, relegated to a footnote. There’s definitely an elegance to this approach, but we would need significant resources to pull it off.

4

Would it be wrong for me to use such tags (start_date:oneway=1970) on highways instead of not tagging or mapping it at all? If nothing else, it would at least be preserved for future uses if OHM comes up with some other tagging scheme. Cause I don’t want to redraw an entire highway everytime it gets paved.

5

Sure, no matter what, there’s always the principle that it’s better to capture useful information, however non-machine-readably, then it would be to drop it on the floor and force someone else to rediscover it independently. Historical mappers are data hoarders, after all. :wink:

2 Likes
6

This is true if we import OSM data into our database and then create layers from this mixed database.

What if this data were never integrated into the database? By that, I mean having a temporary file from OSM stored apart from OHM own database that passes through Tegola to add its content to the layers.

Our database remains separate, and we have layers with content from both databases.

Wouldn’t we then simply have to include the phrase Map data © OpenStreetMap contributors found on renderers that create raster tiles from the OSM database, in addition to the usual OHM mention?

You can add it, but the tag won’t be displayed. You can solve this problem by using multilinestring relationships (a multipolygon for ways) instead of a regular ways, which you can then duplicate without having to copy and paste the geometry and change the tags.

Here’s an example for a street that has changed its name:

2 Likes
7

Tegola is a vector tile generator, so this would be a vector tileset of OSM data alongside the OHM tileset. The OpenStreetMap Foundation began developing an official vector tileset of OSM data last year. Like the official OHM tileset, it picks up the latest changesets within minutes. It uses Tilemaker instead of Tegola, but the resulting tiles are compatible with the same client-side renderers. This tileset soft-launched earlier this month; check out the demo.

The new OpenRailwayMap shows that a mashup of OSM and OHM data does help users easily cross-reference the past and present. I created a simple demonstration of something similar but based on OSM’s vector tileset instead of a legacy raster tileset. In principle, a mashup could show so much more of history beyond railways.

Integrating a mashup into the main site would help users orient themselves on the map without forcing them to flipping back to openstreetmap.org as often. But this would only be for visualization purposes, primarily for end users. It wouldn’t quite be a substitute for mapping things that extend into the present directly in OHM.