EventIDs are quite dynamic. If you have a series of nested events with IDs "3", "3.1" and "3.1.1", then add a single event in front of "3". The nested IDs will change to "4", "4.1" and "4.1.1". When you import events from a CSV file, you have to adjust the IDs between the file values and the current timeline. The EventIDs get remapped dynamically as they are imported, just as if you had manually created each event from the file one by one. The import process currently ignores the pre-existing ID numbers from the file, so there is no need to have any knowledge of any previous line in the file when processing a subsequent line. So if we have a CSV file with two nested events with IDs "2" and "2.1" and they happen to fall in sequence behind a pre-existing event "3" in our timeline (outside the import file), they need to get mapped to ID "4" and "4.1". In order to process EventID's in a way that would preserve the nested nature, we'd have to preserve the knowledge that we mapped EventID "2" to "4", so that when we got to "2.1", we would know that it had to be changed to "4.1". Preserving this state information during the import would complicate the process. You'd have to keep a map in memory of all the ID translations. Rather than complicate the import, I suspect Matt has opted to just ignore the EventID field, perhaps because child events are a more recent feature than CSV import?
Perhaps . . . but it would seem that the link between a parent event and it children events are (somewhere) absolute, so that regardless of what ID the parent has, the children always follow. It seems (in theory, anyway) that this absolute link could be established at CSV import time. But (as I know well, being a code developer) easier said than coded! This issue is important for building time lines of history, as is the case for my use of Aeon Timeline. My modifications to the timeline are almost NEVER made in Aeon; rather back in the CSV that contains all the data. When I make a change, I 'simply' import an upgraded CSV. I'm never importing a CSV into an existing timeline. I suspect this is one of the (important) difference between using Aeon as time-working-tool (as it were) and a data-display, organizing, and search tool.
If you look at the AT2 XML data, you'll see that events have an Id and a DisplayId. The absolute link you are looking for would be the "Parent" value for the child event, which refers to the "Id" and not the "DisplayId". Id appears to be a permanent auto-incrementing field, similar to what you'd find in a database table. DisplayId is dynamic and changes as events are inserted upstream in the timeline. Unfortunately, when you do a CSV export, it uses the "DisplayId" value rather than the "Id". The schema of the exported CSV is fairly vanilla and skips fields like "Parent". Additionally, there doesn't seem to be any way to map even the DisplayId/EventID back to the timeline when doing an import. The only reason I'm bringing up Export is that it gives us a window into what's going on with Import. The 3.1.1 notation in the EventID is the only clue of any parent/child relationship in the CSV, but as you point out, that's not what AT2 is using internally. You might want to put a feature request in the Wish List forum. In the mean time, if you're doing this p rogrammatically and you're never importing over old data, how about just cloning an empty AT2 data file for the template you want and writing to that directly?
Experimenting with this a bit more and it seems pretty trivial to add events by directly manipulating the XML file. There don't seem to be any counters or other checks that need to be updated other than making sure you keep incrementing the Id. In fact, I'm not sure why DisplayId is included in the XML. If you omit it or deliberately try to set a bogus value, AT2 just recalculates it on load. Perhaps it just exists as a hint to speed up loading very large timelines?
Hi, At the moment there is no way to import parent/child information from a csv file. This is due to fact that you would have to include a way to define how to map out the parent/child relationshjp (eg. by event id). However this is on our list of possible features to add in the future. Jess
Razyr: An excellent suggestion! Adding parent/child/children events to an empty history template does work. As you mentioned, one need only take care to increment the IDs and make sure the child iDs match the necessary parent ID. As it turns out, AT2 uses a Proleptic Gregorian Calendar by default, so the year/date/times have to be expressed in lapsed seconds with care if they're to show up in the timeline correctly. Though it is an indirect process, it allows a very large and complicated history to be maintained in Excel (say) and the results (eventually) placed in an AT2 timeline. So it also seem possible that changes made to the timeline in AT2 could be brought back to a primary database with code that parses the AT2 XML file.
Hi, Just letting you know, we have now implemented the ability to import parent/child information from a csv file and it should be available in the next update. Jess
Great news! Looking forward to this new capability.