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 [Entry Object JSON Schema] | 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 70: | Line 70: | ||
| ====== ADF Structure ====== | ====== 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) | ||
| + | |||