For simplicity, and an initial (for wip) or basic (for abstracting) level-of-detail, an existing place= point could be reused as a label to represent the approximate location at that time. This is similar to what’s done in boundary= , despite them being different concepts. Secondarily, this can be used as a sorta “spatial index” to help geocode nested rel if they don’t contain geometry directly, which is a common question and confusion in querying them, as recent as today. It helps with rendering directly as well. No need to always perform clustering, or draw artificial areas.
An event can be considered from the functional (the exploration itself), and physical (the on-the-ground trace, eg camps) aspects. The physical features can be related in the type=eventhttps://www.fortwiki.com/Category:Lewis_&_Clark_Camps
been out of discourse for a bit, but checking back in. i like the outline of exploration stuff and will think about how to factor it in.
at SOTM US right now; doing a lightning talk on this stuff after lunch. exploration won’t really be in it, but i have some new thinking about campaigns which are subtly different from battles.
Here’s a query for Mongol Empire-related events and related relations. This isn’t too complex, just modeling the entire sacking of a city as a single event node. (Sorry, cities.) The goal here is to show the progress of the Mongol Empire’s dominion as they laid waste across the planet. On the tail end of this, we should also end up with events for the subjugated kicking the Mongols out.
just made some revisions to the tagging for military related events; i had allowed it to rather out of date. more to come, as i need to codify the variants for campaign movements (which differ a little from battle movements.) OpenHistoricalMap/Tags/Events - OpenStreetMap Wiki
I came here to see how this might apply to this situation! I’ll probably take a stab at adding some cycling races. It would start with a lot of roadway mapping to have ways to include in the relation.
There’s nothing wrong with nesting relations, but that sounds like something other than a chronology to me. Chronology relations have always been a rather simple concept: grouping the copies of a feature as it changes over time. Conceptually, the fact that a division is composed of brigades is neither strictly geographic nor temporal information, so it’s better suited to a knowledge base such as Wikidata or FactGrid.
In Wikidata, a brigade can be part of (P361) a division and a division can have parts (P527) that are brigades. As long as you can think of some model for the lowest-level unit, all you need is a wikidata=* tag on it, and of course a chronology relation can track its movement over time. Wikidata currently has 104 items about military units in the American Civil War, probably many more that are undertagged. Brigades without Wikipedia articles are somewhat less likely to already have items, but WikiProject Military History may be able to assist in building out this coverage further.
If you want to model these relationships redundantly in OHM to simplify the task of rendering an animation, a collection relation would be closer to the semantics you’re looking for, but I think that just highlights the ill-fitting nature of any kind of org structure in OHM.
