Event Tagging - Battlefields, Campaigns, Explorer routes

General
1

in resuming my work on Battlefield Mapping, i’m moving back into experiments in event tagging, e.g. how to track the movements of units across the battlefield.
this has relevance to other kinds of event mapping, e.g. routes traveled by explorers. i’m opening this up for discussion of how to provide a generalized scheme for motion that can be customized for specific applications.

2 Likes
2

the core structure i’m using for troop movements is nodes/ways representing physical locations, with minimal other tagging. for troops where there is available data (there is for Antietam) this consists of a directional way and an indication of whether the troops are in line or column formation (use right hand rule to indicate direction if in line.)
the actual unit identification is in a containing relation; this to abstract meta data from the physical. timestamped ways representing troop units can all be contained in one relation, for say a given regiment, which then shows the progress of that regiment over the battlefield.
to indicate increasingly larger units, one can create divisions to contain regiments, corps to contain divisions, and so forth.
this does bang its head against the OSM API limit on nested relations. this is a soft limit; you can upload an arbitrary number of levels but by default you can only get so many back. further API requests are need to get increasingly higher level relations.

3

quick try at a widget, just took my existing overlay widget and pointed it at the north end of the Antietam battlefield. needs lots of work, but at least a little proof of concept. http://www.averillpark.net/Events/Antietam/

4

Event support seems like a pretty obvious and desirable addition to any sort of historical geoplatform, so I’m psyched you’re taking a stab at this.

I’m not sure if OHM is the best platform for this, but it’s available and I see no reason not to at least try to see what we could do with it.

What event models comparables are we using to guide these efforts? In the 2000’s, HEML, backed by Prof. Robertson, gained some traction, but there hasn’t been much coverage since 2009ish. I haven’t been able to find any reasonable RDF event model standards, which is probably more a reflection of my Google-fu than the lack of said standard. I’ve also dropped Prof. Robertson a note to get his thoughts.

Given using OHM as the platform with its key-value limitations, as opposed to something with RDF support, I wonder if there’s a simpler approach to take regarding event structure than what is proposed and discussed in this thread.

For example, it seems like things could get complicated quickly if there’s a need for hierarchy of an event (e.g., something like War->Theater->Campaign->Battle->Maneuver-> Engagement for a war) as well as for actors (e.g., Nation->Armed Forces->entire chain of command->Individual Actors). There might be pretty complex relation hierarchies and intersections of event hierarchies and actor hierarchies.

Given the limitations of the OHM/OSM datamodel, and the apparent benefits of an RDF event store somewhere else, why not just focus on who, what (and I’m assuming where and when, given the geo-temporal premise of OHM!). So, we’d end up with something like:

Points / Ways / Areas:
event:actor=name or Wikidata Q code
event:name=name of event or Wikidata Q code

Examples:
feature: point
event:actor=Winston Churchill
event:name=travels through Africa
connected to points of where he was at certain dates

feature: way
event:name=Tour de France, 1903, Stage 1
ways showing the routes of the tour through history (not sure this is really an event, per se, but it could be similar to a battle movement)

feature:point, closed area
event:name=Attack on Pearl Harbor
boundary of all attacks for that event

feature: point, way, closed area
event:name=Hurricane Katrina
could be the path of the storm, the path of the eye of the hurricane, points, the overall width of the path, width of the storm at various points in time

Relations:
type=chronology - used for a sequence of a single thread of related events; e.g., all of the points on the path of a hurricane; all of the individual years of the Tour de France
type=event - used for a collection of event-related relations, points, ways, closed areas, etc.

I think there’s still room for a lot of complexity and richness in this approach, including for rendering, without getting too deep into causal or descriptive relationships better served by RDF. I also think it leaves an easier path for tying in external systems in the future.

5

i’m comtemplating how to meld this with what i’ve done already. i can imagine using chronology relations and tagging them with info about the military units they represent. do we have an objection to nesting chronology relations? this is because i’m using nested relations to represent units composed of smaller units, e.g. divisions in the civil war are composed of brigades. the reason for representing this is it enables some things in some nebulous animation project, e.g. track the brigades across the field, or perhaps track the division across the field.

6

I’m trying to visualize how this would play out; say, for example, mapping the Lewis and Clark expedition. So we might have:

event:start_date = 1804-5-17
event:end_date = 1804-5-17

event:name = Corps of Discovery reaches confluence with the Platte River
event:start_date = 1804-07-21
event:end_date = 1804-07-21

And these events and other related ones could be separate ordered items in a chronology relation. Between these two would be a travel event corresponding to the stretch of the Missouri River starting and ending on the above dates. Does this fit the data arrangement you have in mind?

I’m also wondering about tagging the events. Do they have their own geometry? Or should the key:value pairs be added to an existing location? (or mappers choice?) Using an existing node or way might entail event:1:* = ... entries if more than one event took place at a single location, but it might be preferable to replicating Missouri River geometry for one linear event. However, the Missouri River flows opposite to the expedition’s westbound route, so a separate way or some other indication of direction would still be required. I’m sure I can come up with other complications…

The idea of mapping historical events including expeditions, explorations, migrations, discoveries, etc. is a good one. But I would agree that we want to keep it simple and straightforward.

7

my notion is to follow the pattern of abstracting metadata from physical location data, so you’d be mapping physical locations with out saying what they are, then putting the event oriented data in the first level of relation - this is how my battlefield stuff is currently configured although i’m still playing. this allows you to not have to deal with event:1:… and so forth.

1 Like
8

you wouldn’t need to create travel event relations; you’d just use chronology relations to collect the points-in-time. and i would just use bare start_date & end_date; no need for an event: prefix for them in my view.

9

this is all subject to change/evolution/better ideas in my view.

10

the one place where i don’t currently abstract meta data is on ways representing unit locations; i directly specify whether the way represents troop deployment in line or in column. abstracting this would require an additional level of relation which i’m reluctant to add. but for a series of connected points, this is unnecessary.

1 Like
11

Whoops! Clearly, any stage of the Tour de France should be represented with a type=route relation and not a way. Duh!

Seems to me this is directionally correct, but I’m not sure about event=*_date tags - shouldn’t those be assigned to the geometry that is tagged by the event? I’m also realizing event:name=* might be a bit heavy. Maybe just event=*?

So, tagging a node for this event would just be:

event = Corps of Discovery reaches confluence with the Platte River
start_date = 1804-07-21
end_date = 1804-07-21

Absolutely! Without a geometry, in OHM what are you tagging? :wink:

This is interesting. My take is that separate nodes for separate events might make more sense than a common shared event time/place node and that event:[#] should be avoided in general.

Hmmm… so no event data on basic nodes, ways, or areas?

This is an example where I think putting event tags on non-relation features makes sense. For example, at a basic level, you could just have a node showing where some stayed for a few days like this, on a node at a game park:

event=Churchill on safari in Kenya
start_date=1907-12-02
end_date=1907-12-05

This way, the node itself carries some reflection of the data it represents.
These tags could also be on an area encompassing the game park or on a relation that has time-appropriate game park boundary area or a relation as a member.

All of these travel nodes, areas, and relations could be. connected with a way showing the path of the travel or a relation showing the sequence of the travel.

Of course, if users wanted to track Churchill’s movements at a finer level (and could do so with good sources), they could just expand the master travel relation with more specific nodes.

I think what I’m trying to avoid (for perhaps unnecessary or ill-founded feelings) are tagless nodes that belong to relations. Seems like that might create confusion when editing.

12

i’ve been pondering the issue with untagged nodes in relations. there are arguments both ways. on the one hand, we aren’t bothered by untagged nodes in ways. on the other hand, there is the issue of recognizing that during the course of editing, that a node is no longer contained in anything and keeping it from becoming debris.

1 Like
13

Separately, here’s a link to Wikidata:WikiProject_Events.

14

Just received an email from Lane Rasberry who has worked with WikiProject Events & he indicated it hadn’t received much support. I have a call with him next week to get his advice and guidance in this area.

He pointed out another project (with issues, but worth checking out) for reference: Histropedia Battles of World War I

15

a thing i’m looking at now is synthesis with RDF sources as a way of reducing the amount of semantic information i load onto relations. for example, rather than using relations to describe-order-of-battle information, having that be in an RDF source. it’d be nice to use wikidata ids to bind the info together, but not sure about viability. would want to consult with wikidata folks.

16

i might do something like grab up orderofbattle.org to serve up this kind of data.

1 Like
17

So, I had a good conversation today with Lane Rasberry, Wikimedian in Residence at UVa.

Some notes:

  • We agreed to work together on a 1-2 page guide for best practices / ways to stay out of trouble with event modeling
  • There are several groups active with event modeling in Wikidata, with not always overlapping needs

After our conversation and did a slightly deeper dive into Wikidata and event modeling and have the following notes:

Interesting examples:

I’m wondering if, at a minimum, we could do some small things, like creating time-based geometries in OHM and then pointing at those things with P276 or a newer, more appropriate property.

  • The path of a storm could be a series of points connected by a way where the points indicate point in time and could also contain storm intensity, width, etc., information
  • A battlefield area could be defined in OHM and referred to by Wikidata
  • A fire’s spread could be a chronology relation with a set of time-tagged areas

I also wonder if the resolution of organizational modeling will need to be improved for this to work well. For example, the 82nd Airborne Division has both been part of Conflict and Participated In events, but not all of the 82nd Airborne has necessarily participated in these events.

1 Like
18

good stuff here.
i’m going to be looking at OOB (Order Of Battle) as part of my work at Antietam. i could in theory represent it using relations, but my very brief experimentation with that was problematic. but yes, units in battle do not necessarily operate as units; in fact they are frequently dispersed. a Cavalry division in the American Civil War would frequently operate broken up into Regiments or even smaller units. i was not expecting a huge amount of help from wikidata unless they would consider extending things to represent OOB data. issue is that OOB can easily shift over time as units get moved about in the organizational structure.

19

not working on this directly at the moment, i decided now was the time to shift my work on embeddable historic map widgets from leaflet to maplibre. am making progress on that.

1 Like
20

Oh, Tropical cyclone track is something I know a little about, as someone who didn’t study meteorology or science. I don’t know the extent of what the Wiki projects do. In short, the wind or pressure field is defined on a circular/polar spider web grid, and can be parametrized by different methods.