Suggestion : Dated Attributes

Names are not the same through time, for example in our village “Ratho Byres” today was called “Rathaw Byres” on a 1747 map.
Sometimes this is due to a genuine gradual changing of name, sometimes it’s because people were spelling a place phonetically in different ways.
It would be very helpful to be able to put against any entity multiple names, giving for each times of attestation (point date or date range), so that the presenting system can choose a style of presentation. For example it might show all of them all the time with their dates, perhaps with one of them highlighted (the latest or the name for the time), or filter the name(s) according to the date the slider is on.
This may be useful for other attributes so it could be generally available. For example, you might have a building tagged as a building, with date, then as a ruin, putting the date it became a ruin, and a tag reconstructed (or equivalent), with its date range, and so on. Perhaps a stream was flowing for a period and then became a dry ditch. Maybe a wooden bridge changes to a stone bridge. It would save redrawing the entity (e.g. the building or river) to represent each date period.

Hi David!

I’ve been waiting to see if anyone else would weigh in here, as this is a pretty frequent question.

Right now, the only way we have for managing changing attributes for an entity is to create either:

  • A new relation to depict the change in the attributed, with an end_date for the prior relation with the old attribute and a start_date for the new relation with the changed attribute and no change to the underlying geometry / objects.
  • A duplicate object with the changed attribute, and associated name changes.

Each approach has its weaknesses. This is a definite hole in our data model, but I think we’ve been able to manage around it… so far.

In general, I’m a fan of the changing the attributes in relations, as I find overlapping objects more of a pain to deal with.

That said, I don’t know if we’ve had anyone build out data objects with too too many changing dimensions of attributes. E.g. a road that has its surface, official name, memorial name, directionality, lane width, change over time. You could see how this might result in > 8 versions of a single stretch of a single street.

Another approach is to use both: maybe a street relation contains 3 separate overlapping stretches of the same block segment with different names, and each of the overlapping stretches having different start and end dates.

Then, you have to think of how this will show up in an extract of our data, but my thinking hasn’t gotten that far.

The obvious sort of namespace modification for changing attributes - e.g. name:1950-1980=Army Boulevard seems straightforward, but introduces numerous other issues, one of which is that keys should only contain descriptive elements, not values, but the more important of which is that our software infrastructure doesn’t support this convention.

Hope that helps - we definitely need to get our lifecycle documentation up to date, for natural features, roads, buildings, amenities, etc.

You can start by reading most recent thread Roads – how to represent evolution?
We need to distinguish geometry, feature, and attribute. They can be viewed independently. The biggest difference of OSM with standard GIS is the lack of multiple data “layers” , files, and datasets.

  • way is best used for constructing the geometry physically, only drawing separately when the shapes changes. What it represents may change through time.
  • rel type=multipolygon can be used for the building= feature to describe it, with some limited additional physical attributes.
  • However, it’s best to separate as much “functional” attributes as possible. Addressing might be in another rel . ref= + network= should be kept to the route=road directly.

The important consideration, or actually a de facto balance of status quo, is the geometry does frequently change, eg roadway center line (not discussing the road’s RoW strip of land. or zoning, here) usually already shifts when it is widened. So it can often be ideal to draw separately regardless. Especially for your example, water flow constantly shifts.
The particular issue with roads is the functional classification is currently tied to the highway= feature. That causes a usability gap when the function changes without physical change.

1 Like

Separate objects for separate attributes is inevitable. In OSM, there is already turn =restriction , more advanced =connectivity for layout of lanes, and drawing separate parking=street_side areas. Transit, and non-motorized modes use =route .

1 Like

For now, one mitigating factor is that most of us aren’t mapping as many detailed attributes about a feature as we would in OSM. For example, when I map the same shop in OSM and OHM, I usually tag the opening hours, accepted payment methods, and so on only in OSM. When I map the same road in both projects, I reserve the lane count, turn lanes, and speed limit for OSM alone. All these things are technically valid to tag in OHM too, but it just seems like a distraction when mapping history.

Names end up being the most dynamic thing I typically tag; name changes are the main reason I have to draw redundant, overlapping buildings. But I would create an overlapping building=construction anyways for the period during which the building was under construction. Someone who needs to track a building’s owner over time might have to create several copies of a building – that might get extreme.

Similarly, when I started contributing to OHM, I immediately abandoned my long-held view in OSM that a building with only one shop inside should be dual-tagged with both building=* and shop=*. Instead, I’ve been placing unattached POIs within the building area. I had good reasons to disfavor this approach in OSM, but one has to be pragmatic when dealing with an extra degree of complexity in OHM.

I think eventually we’ll look back at this post and chuckle at how naïve and careless I was for omitting even minor details that show up in historical sources. The downside of being an early contributor is that, down the line, contributors who don’t remember the old days will chastise you for breaking rules and violating norms that didn’t exist yet. :sweat_smile:

If the shop= occupies the entire building= , =multipolygon can be used, as how building= attribute changes can be shown by it. That’s better than a random butch of points scattered inside, and Proposal:Node - OpenStreetMap Wiki (or a type=point as I prefer to call it according to OGC together with =mutlilinestring ) isn’t better.

Or perhaps a normal area coincident with and connected to the building, sort of in the manner of indoor tagging. Either approach would be less intuitive to inexperienced mappers who happen upon it while needing to make adjustments, but admittedly the point-in-building approach is somewhat crude.

To me, having the =multipolygon appear on the list of rel is more visible than coincident areas. It can potentially be made nested (by =chronology ; as *:source= is being done), and sortable (chronologically).

⌄ Relation (5)
  ⌄ Building (2) ↥
    Building [1990 - 2000] 
      outer ▼
    Building [2000 - ] 
      outer ▼
  ⌄ Shop (3) ↧
    Shop [2000-]
      outer ▼
    Shop [1995-2000] 
      outer ▼
    Shop [1990-1995] 
      outer ▼