This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
access:journal-file-proposal [2018/06/21 16:16] mjallison [Table] |
access:journal-file-proposal [2018/06/26 22:22] (current) mjallison [Area Block (.area)] |
||
---|---|---|---|
Line 54: | Line 54: | ||
The JSON object for all entries will minimally look like: | The JSON object for all entries will minimally look like: | ||
- | { | + | { |
- | latitude: number, // LLA | + | "latitude": number, // LLA |
- | longitude: number, // LLA | + | "longitude": number, // LLA |
- | altitude: number, // LLA | + | "altitude": number, // LLA |
- | note: string // A comment about the entry. | + | "note": "string" // A comment about the entry. |
- | } | + | } |
The location contained within the entry's JSON is referred to as the //reference point//. This point will be | The location contained within the entry's JSON is referred to as the //reference point//. This point will be | ||
Line 68: | Line 68: | ||
+ | |||
+ | ====== ADF Structure ====== | ||
+ | The ADF structure will support all of the currently defined Journal entry types. It should be noted that the | ||
+ | the Photo Note entry type will not create ADF files in the server. The definition exists to support an ADF journal export use case. | ||
+ | |||
+ | All Journal entry's are stored under first //Construction Model// of the ADF. If a brand new ADF is bring created the //Construction Model// is the same name as the enclosing project. | ||
+ | |||
+ | The path to the Journal entry's are as follows: | ||
+ | |||
+ | /CM/JournalData/Photos/ | ||
+ | /CM/JournalData/Areas/ | ||
+ | /CM/JournalData/Note/ | ||
+ | /CM/JournalData/Tracks/ | ||
+ | |||
+ | Each section has a JSON descriptor, with corresponding data files. For instance, Photos, might look like: | ||
+ | |||
+ | /CM/JournalData/Photos/photos.json | ||
+ | /CM/JournalData/Photos/Photo1.jpg | ||
+ | /CM/JournalData/Photos/Photo2.jpg | ||
+ | |||
+ | Because notes can be entirely contained in the JSON, the notes structure looks like: | ||
+ | |||
+ | /CM/JournalData/Photos/notes.json | ||
+ | |||
+ | Tracks will look like | ||
+ | |||
+ | /CM/JournalData/UserTracks/usertracks.json | ||
+ | /CM/JournalData/UserTracks/track1.track | ||
+ | /CM/JournalData/UserTracks/tracl2.track | ||
+ | |||
+ | Areas will look like | ||
+ | |||
+ | /CM/JournalData/Areas/areas.json | ||
+ | /CM/JournalData/Areas/Measure1.area | ||
+ | /CM/JournalData/Areas/Measure2.area | ||
+ | |||
+ | While the structure is defined to support multiple data instances, the server may only create single ADF file per entry. | ||
+ | |||
+ | ===== ADF JSON ===== | ||
+ | Each entry type has a json descriptor which describes the rest of the data. Examples of the JSON for each type are: | ||
+ | |||
+ | photos.jpg: | ||
+ | { "photos" : [ | ||
+ | { "latitude": nnn.nn, | ||
+ | "longitude": mmm.mmm, | ||
+ | "altitude": aaa.aa, | ||
+ | "time": tttttttttttt, /* Std mSec time */ | ||
+ | "customer": "custid", /* Access customer ID string */ | ||
+ | "user": "user@example.com" /* Access user ID string */ | ||
+ | "comment": "text", | ||
+ | "file": "Photo1.jpg" | ||
+ | }, | ||
+ | { "latitude": nnn.nn, | ||
+ | "longitude": mmm.mmm, | ||
+ | "altitude": aaa.aa, | ||
+ | "time": tttttttttttt, /* Std mSec time */ | ||
+ | "customer": "custid", /* Access customer ID string */ | ||
+ | "user": "user@example.com", /* Access user ID string */ | ||
+ | "comment": "text", | ||
+ | "file": "Photo2.jpg" | ||
+ | } | ||
+ | ] } | ||
+ | | ||
+ | Notes: | ||
+ | { "notes" : [ | ||
+ | { "latitude": nnn.nn, | ||
+ | "longitude": mmm.mmm, | ||
+ | "altitude": aaa.aa, | ||
+ | "time": tttttttttttt, /* Std mSec time */ | ||
+ | "customer": "custid", /* Access customer ID string */ | ||
+ | "user": "user@example.com", /* Access user ID string */ | ||
+ | "comment": "Text of note 1" | ||
+ | }, | ||
+ | { "latitude": nnn.nn, | ||
+ | "longitude": mmm.mmm, | ||
+ | "altitude": aaa.aa, | ||
+ | "time": tttttttttttt, /* Std mSec time */ | ||
+ | "customer": "custid", /* Access customer ID string */ | ||
+ | "user": "user@example.com", /* Access user ID string */ | ||
+ | "comment": "Text of note 2" | ||
+ | } | ||
+ | ] } | ||
+ | |||
+ | Tracks: | ||
+ | { "notes" : [ | ||
+ | { "latitude": nnn.nn, | ||
+ | "longitude": mmm.mmm, | ||
+ | "altitude": aaa.aa, | ||
+ | "time": tttttttttttt, /* Std mSec time */ | ||
+ | "customer": "custid", /* Access customer ID string */ | ||
+ | "user": "user@example.com", /* Access user ID string */ | ||
+ | "comment": "comment", | ||
+ | "file": "Track1.trk" | ||
+ | }, | ||
+ | { "latitude": nnn.nn, | ||
+ | "longitude": mmm.mmm, | ||
+ | "altitude": aaa.aa, | ||
+ | "time": tttttttttttt, /* Std mSec time */ | ||
+ | "customer": "custid", /* Access customer ID string */ | ||
+ | "user": "user@example.com", /* Access user ID string */ | ||
+ | "comment": "COmment about track 2" | ||
+ | "file": "Track2.trk" | ||
+ | } | ||
+ | ] } | ||
+ | |||
+ | Areas: | ||
+ | Tracks: | ||
+ | { "notes" : [ | ||
+ | { "latitude": nnn.nn, | ||
+ | "longitude": mmm.mmm, | ||
+ | "altitude": aaa.aa, | ||
+ | "time": tttttttttttt, /* Std mSec time */ | ||
+ | "customer": "custid", /* Access customer ID string */ | ||
+ | "user": "user@example.com", /* Access user ID string */ | ||
+ | "comment": "An area", | ||
+ | "file": "Area1.trk" | ||
+ | }, | ||
+ | { "latitude": nnn.nn, | ||
+ | "longitude": mmm.mmm, | ||
+ | "altitude": aaa.aa, | ||
+ | "time": tttttttttttt, /* Std mSec time */ | ||
+ | "customer": "custid", /* Access customer ID string */ | ||
+ | "user": "user@example.com", /* Access user ID string */ | ||
+ | "comment": "Measure 2 name" | ||
+ | "file": "Measure2.trk" | ||
+ | } | ||
+ | ] } | ||
+ | |||
+ | ===== ADF Block Types ===== | ||
+ | Photos and Notes have defined data storage types, but Tracks and Areas do not. This section details two new binary | ||
+ | ADF block types. | ||
+ | |||
+ | ===== User Track Block (.track) ===== | ||
+ | The Track block is a zipfile entry, which is a series of track points. A track is defined to have a | ||
+ | starting point (the very first point) and an end point (the very last point). | ||
+ | |||
+ | Block Header: | ||
+ | * Block Code 2001 : Int32 | ||
+ | * Block Size : Int32 = 40 for this definition | ||
+ | * Number of points : Int32 | ||
+ | |||
+ | The series of points are as follows: | ||
+ | * latitude - Double 64 (degrees) | ||
+ | * longitude - Double 64 (degrees) | ||
+ | * altitude - Double 64 (meters above MSL) | ||
+ | * time - Int64 (std mSec time) | ||
+ | * compass - Double 64 (0..359.9999) | ||
+ | |||
+ | ===== Area Block (.area) ===== | ||
+ | The Area block is a zipfile entry, which is a series of points. A area is defined to be a closed | ||
+ | region, e.g. the last point connects to the first point. There is no duplicated points to "close" | ||
+ | the area, and it is expected that applications perform whatever operations needed to represent it | ||
+ | as such. It is considered an error to close an area by duplicating a point for the first and last | ||
+ | in this block. | ||
+ | |||
+ | Block Header: | ||
+ | * Block Code 2002 : Int32 | ||
+ | * Block Size : Int32 = 24 bytes for this definition | ||
+ | * Number of points : Int32 | ||
+ | * | ||
+ | The series of points are as follows: | ||
+ | * latitude - Double 64 (degrees) | ||
+ | * longitude - Double 64 (degrees) | ||
+ | * altitude - Double 64 (meters above MSL) | ||