ISO 11783-10 ISOXML Tag Extensions
February 26, 2013
Table of Contents
Index of Tables .......................................................................................................................... 3
Purpose ..................................................................................................................................... 3
Scope ........................................................................................................................................ 4
Authors ...................................................................................................................................... 4
About the SPADE project ........................................................................................................... 4
Data Planning ............................................................................................................................ 5
Create Plan ................................................................................................................................ 6
Create Recommendation ........................................................................................................... 7
Create Work Order ..................................................................................................................... 7
Get Work Record ....................................................................................................................... 8
Historical Data Transfer ............................................................................................................. 9
Appendix A New Tag Proposals ...............................................................................................21
ISO11783_TaskPlanning ..........................................................................................................21
AAU - ApprovalAuthority ...........................................................................................................23
AAR - ApprovalAuthorityReference ...........................................................................................23
LIC - License .............................................................................................................................25
LIR - LicenseReference ............................................................................................................38
MSG - Message ........................................................................................................................38
HTY - History ............................................................................................................................34
DDT - DueDate .........................................................................................................................29
WST - WorkSet .........................................................................................................................42
WOR - Work .............................................................................................................................50
CRU - CropUse .........................................................................................................................28
CUR - CropUseReference ........................................................................................................29
ORQ - ObjectRequest ...............................................................................................................42
DRQ - DataRequest ..................................................................................................................30
HDT - HistoricalData .................................................................................................................34
DTA - HistoricalDataset.............................................................................................................30
LYR - HistoricalLayer ................................................................................................................38
STN - HistoricalSection .............................................................................................................45
ATR - Attribute ..........................................................................................................................26
SUM - Summary .......................................................................................................................49
PPT - Property ..........................................................................................................................44
REF - Reference .......................................................................................................................45
ADR - Address ..........................................................................................................................25
PER - Person ............................................................................................................................44
SSN - Season ...........................................................................................................................45
BTC - Batch ..............................................................................................................................26
LOT - Lot...................................................................................................................................38
CPY - Company ........................................................................................................................27
STS - StatusUpdate ..................................................................................................................48
Appendix B Proposed extensions to existing ISOXML tags ......................................................53
PFD - Partfield ..........................................................................................................................53
CTP - CropType ........................................................................................................................53
TSK - Task ................................................................................................................................54
ASP - AllocationStamp ..............................................................................................................54
TIM - Time .................................................................................. Error! Bookmark not defined.
PAN - ProductAllocation............................................................................................................54
CTR - Customer ........................................................................................................................55
DVC - Device ............................................................................................................................55
WKR - Worker ...........................................................................................................................55
PDT - Product ...........................................................................................................................56
CVT - CropVariety.....................................................................................................................56
PGP - ProductGroup ................................................................... Error! Bookmark not defined.
DLV - DataLogValue .................................................................................................................56
CLD - ColourLegend .................................................................................................................57
CRG - ColourRange ..................................................................................................................57
PLN - Polygon ...........................................................................................................................57
LSG - Linestring ........................................................................................................................58
PNT - Point ...............................................................................................................................58
Appendix C Examples? .............................................................. Error! Bookmark not defined.
Appendix D Guidelines for representation of ISO11783-10 ISOXML in JSON ..........................58
Files ..........................................................................................................................................58
XML Elements...........................................................................................................................59
Data Types ...............................................................................................................................59
Binary Attached Files ................................................................................................................60
TimeLog Binary Files ................................................................................................................60
Grid Binary Files .......................................................................................................................61
ZZZ - TAGTEMPLATE ................................................................ Error! Bookmark not defined.
Index of Tables
Table 1 – Supported Spatial Types ........................................................................................12
Table 2 - Raster Grid.................................................................................................................16
Table 3 - Raster Grid Z .............................................................................................................16
Table 4 - Raster Grid Cell .........................................................................................................16
Table 5 - Raster Grid Cell Z ......................................................................................................17
Table 6 - Spatial Data Type None ............................................................................................17
Table 7 - Spatial Data Type None Z ..........................................................................................17
Table 8 - Binary File Header .....................................................................................................17
Table 9 – Binary Record Structure ............................................................................................17
Table 10 - Spatial Data Structure ..............................................................................................18
Table 11 - Layer Data Structure ................................................................................................18
Table 12 - Section Data Structure .............................................................................................18
Table 13 - Attribute Data Structure ............................................................................................19
Table 14 - Data Object ..............................................................................................................19
Table 15 - Record Object ..........................................................................................................19
Table 16 - Layer Object.............................................................................................................19
Table 17 - Section Object ..........................................................................................................20
Purpose
The purpose of this document is to describe an electronic messaging system used in agriculture
to assist in the planning and execution of farming operations between producers, suppliers, and
service providers.
Scope
The scope of this project is limited to the data requirements related to the field operation of
planting. While the recommended changes are intended to be generic and usable by any field
operation, it is acknowledged that data requirements for non-planting operations may be
missing.
Authors
This document is a collaborative effort by members of AgGateway participating in the SPADE
project. The group consists of representatives from a large number of companies participating in
or related to precision agriculture.
About the SPADE project
Project Description and Value Proposition


The SPADE Project involves the trading/sharing of agricultural data between farmers and
the companies with the goal of promoting efficient operations. This data sharing requires the
use of a common language among companies and equipment manufacturers.
The SPADE Project Team intends to adopt existing standards and if a gap exists, develop
standards for the automatic exchange of ag-related data between customers, businesses,
and other stakeholders. These standards will promote a seamless, scalable and sustainable
producer operation by lowering the barrier for adoption of precision ag products. Agriculture
companies will benefit by removing interoperability issues, thereby lowering development
costs.
Background
The next generation of agricultural managers is asking how the industry can enable seamless
data exchange between machines and Farm Management Information Systems (FMIS). The
costs for exchanging data are high due to the lack of common implementation guidelines, data
transfer protocols, message standards, and standard reference data. Producers report that it is
difficult or nearly impossible to move data from one system to another. To do so almost always
requires data reentry, manual data transformation, and/or specialists to manage data.
The value chain from manufacturing through distribution supports many data-management,
analysis, and decision-support functions for the producer. Having systems that utilize eBusiness
standards and guidelines will help move the industry toward interoperability. This will improve
the efficiency and productivity of the producers and their trusted advisors.
In June 2011, the Precision Ag Council’s Field Operations working group in AgGateway
identified several industry needs and selected seeding as the example use case to identify
applicable standards and analyze gaps within the standards that may be impeding data
exchange. Next, the team demonstrated a proof of concept regarding message contents for
data exchange between software/hardware systems building on the ISO11783 data standards
and distributed databases. The successful results of this proof-of-concept were presented to the
Precision Ag Council at AgGateway’s Annual Conference in November 2011. This charter
outlines a project to move from conceptual demonstration to production. Near project
completion, the project team will outline use cases for progressing with other operations
(seeding, spraying, fertilizing, etc) and consider opportunities for promoting more widespread
adoption.
Data Planning
The data planning process occurs through a series of messages between actors. The
messages contain information about who is sending the message, what work is being proposed,
and who authorizes the work to be done.
Work
Work is planned in three separate phases. Each phase is agreed upon by all actors before the
next phase of planning begins. While every step of each phase is supported through this
system, it is understood that some of these steps may be done informally, through other means,
and in a variety of orders.
Plan
The first phase of work is the plan phase. A plan is typically drafted at a high level, which may
include intended crop, crop season, seed and other products, and estimated rates for the
products needed for planting. It is a discussion support tool between producers and providers
that may include the entire farm or may just be a specific field/unit. A plan may or may not be
spatially specific.
Recommendation
A recommendation is the second phase of work. A recommendation is a suggestion for work to
be done based on a plan. Recommendations are typically created by a provider for a producer
and contain more detailed information than a plan.
Work Order
A work order is the final phase of work planning. A work order contains specific information
about what will be done, where, and with what resources.
Work Flow
Some notes here describing what the expected work flow between actors is, and probably what
actors are involved. Include some example scenarios and show xml (maybe in another
appendix?) that solves those. In this we should include the lifecycle diagram from WG1 and all
of the diagrams we made for the use cases
Create Plan
Create Recommendation
Create Work Order
Get Work Record
Historical Data Transfer
Purpose
Historical Data Transfer is intended to allow the transfer of data between FMIS systems that
otherwise has no explicit definition in ISO11783-10 ISOXML. This generally consists of
processed task data and data manufactured in the FMIS. It would not include things like
boundaries, guidance, and prescriptions as those already have explicit definitions better suited
to transferring that data.
Design
Historical data consists of collections of values related spatially and temporally. This can be as
simple as a single operation in a field or a complex multi-operation job in which a wide variety of
values are collected. Values are represented as either attributes or properties, depending on the
usage of the value. An attribute is a value that changes over time and a property is a value that
is constant. Both attributes and properties can represent the same types of data such as
planting rate. Each collection of related attributes and properties is grouped into a dataset.
A dataset is organized by a collection of layers. A layer is a group of values that relate by
operation (planting, fertilizing, etc.) and product. So, for example, if a grower were to go to a
field and plant two varieties plus spread fertilizer all simultaneously, there would be at least 3
layers needed to describe that set of operations. Two of the layers would need to be for planting
data, one for each of the varieties, and the third layer would be for the fertilizer. Each layer can
further be organized by sections and sub-sections (sections within sections), each containing
their own collections of values. Layer division is not restricted to only operation and product
bounds. Some values, such as fuel usage, are not part of a particular operation or associated
with a specific product. Additionally it would be wrong to copy the values to the operational
layers because that would lead to a misrepresentation of the data. In these cases it is useful to
group these types of values into one or more additional layers.
Two different layers may contain values for the same types of data, for example the planting
rate in the two planting layers, but a single layer can only contain the value once at the given
level. Consider the split planter example with 2 layers, one for each product being planted. Both
layers contain a value for the planting rate for the product associated with the layer. The layers
can also have sections (and possibly sub-sections) that also have a planting rate that
represents the rate for that section (or sub-section). A single layer could not however have two
planting rate values at the same level because the meaning for the two values would be
ambiguous.
A dataset’s contents are expressed as a collection of records. Each record contains a single
spatial object (point, line, polygon, etc.) and 0 or more values associated with that object.
Values in records are considered attribute values and the possible value types are defined by
the layer, section, and sub-section structure that makes up the dataset. For each record, every
layer declares that it either is or is not a part of that record. If it is not a part of that record then
the spatial object for that record is not associated with the layer and the layer cannot report any
attribute values. If the layer is part of the record then it can also define the values for its
attributes. The layer does not have to define values for every attribute in each record. If the
attribute value did not change from the previous record the layer participated in then the value
can be omitted. In this case the value from the previous record is carried through to the current
record. The first record that a layer participates in then will always have a value for every
attribute to initialize the set of known good values.
Tag Definitions
Historical data transfer is facilitated through the use of a collection of proposed tags
accompanied by a collection of records, either binary or textual, that contains the spatial and
attribute information about the data. The tags and their relationships are shown in the diagram
below.
Historical Data (HDT)
Historical Dataset (DTA)
Historical Layer (LYR)
Historical Section (STN)
Record Collection
Attribute
Property
Historica lData (HDT): An HDT is a collection of datasets that belong to a unique combination
of Customer (CTR), Farm (FRM), Partfield (PFD). Each of these items is optional so the data is
free to be expressed in whatever way it is actually linked to coding data.
Historical Dataset (DTA): A DTA is a collection of data that was recorded simultaneously. For
example if a grower were to spread fertilizer while planting, the dataset would contain all of the
collected values for both the planting and fertilizing operations.
Historical Layer (LYR): Each LYR is a collection of related values used in an operation. Each
layer is also limited to a single product. For example if there is some split planter data with two
varieties, each variety will be a separate LYR.
Historical Section (STN): An STN describes section level values for a particular layer. The
STN can have its own collection of attributes that describe the values recorded for that section
for each record. STNs can also be nested to allow for sub-section and row level value
descriptions.
Attribute (ATR): An attribute is a value in the data that changes over intervals. Examples of
attributes include the actual rate that seed is being planted, the work state (on/off) of a section,
etc.
Property (PPT): A property is a value in the data that does not change, or is considered
constant for the duration of the dataset. Examples of properties include X/Y/Z GPS offsets,
equipment dimensions, etc.
Properties and Attributes are interchangeable depending on how they need to be used. Working
Width for example may be a property for harvest datasets where the operating width is constant,
or an attribute for planting datasets when the operating width can change from record to record.
Any value that is constant for the every record in the dataset should be recorded as a property,
and any value that needs to change from one record to the next should be recorded as an
attribute.
Record Collection Representation
The collection of records that make up the dataset can be expressed as either a binary file or a
JSON object. In either case, each record consists of two parts, the spatial information and the
attribute values. The attribute values are organized by the layer and section structure defined in
the tags. Only values for attributes declared in the corresponding layer and section tags can
exist in the record collection. Additionally, if an attribute is declared on a layer or section then
that attribute must, at a minimum, record a value in the first record of the record collection. This
organization is shown in the diagram below.
Record Collection
Collection Header
Version
Flags
Record (1 or more)
Record Marker
Timestamp (optional)
Spatial Data
Layer (1 or more)
Is Valid
Attribute Value (0 or more)
Section (0 or more)
Attribute Value (0 or more)
Section (0 or more)
Attribute Value (0 or more)
Spatial Data
Spatial data is represented by a subset of the spatial types defined in ISO 13249-3:2011. In
addition to this subset, three new spatial types are defined to support data that is standard to
our industry. All spatial coordinates are expressed in WGS84. See table 1 for a summary of
supported spatial types.
Spatial Type
Point
LineString
Polygon
MultiLineString
MultiPolygon
Point Z
LineString Z
Polygon Z
MultiLineString Z
MultiPolygon Z
Raster Grid
Raster Grid Cell
None
Raster Grid Z
Raster Grid Cell Z
None Z
Spatial Type Code
1
2
3
5
6
1001
1002
1003
1005
1006
8950
8951
8952
9950
9951
9952
Is Part of WKB Standard?
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
Comment
Z is elevation in meters
Z is elevation in meters
Z is elevation in meters
Z is elevation in meters
Z is elevation in meters
Z is elevation in meters
Z is elevation in meters
Z is elevation in meters
Table 1 – Supported Spatial Types
Raster Grid Data
Data that is stored in raster (grid) structures are supported by using the two spatial types Raster
Grid and Raster Grid Cell. The first record in the raster dataset will contain a Raster Grid object
that specifies how the grid is constructed. Only one Raster Grid object can exist in a dataset.
Subsequent records contain Raster Grid Cell objects that reference a specific cell in the grid
using an index.
A raster grid is a grid of uniformly sized cells that starts at an origin defined as the southwestern most corner and extends north and east. The extent of a raster grid is defined by the
number of rows/columns and the height/width of each cell. Each cell in the grid can be identified
by a calculated index with the first cell being index 0. Likewise, the first, southern-most, row in
the grid is row 0 and the first, western-most, column is column 0.
Mathematically the index is as follows:
Index = row * NumberOfRows + column
91
92
93
94
95
96
97
98
99
80
81
82
83
84
85
86
87
88
89
70
71
72
73
74
75
76
77
78
79
60
61
62
63
64
65
66
67
68
69
50
51
52
53
54
55
56
57
58
59
40
41
42
43
44
45
46
47
48
49
30
31
32
33
34
35
36
37
38
39
20
21
22
23
24
25
26
27
28
29
10
11
12
13
14
15
16
17
18
19
0
1
2
3
4 Row
50
6
7
8
9
Column 0
90
The extents of a cell can be calculated using the cell index and some values from the grid. The
cell width and height have to be converted from meters to lat/lon (unproject below):
South = floor(Index / NumberOfColumns) * unproject(CellHeight) + MinimumLatitude
North = (floor(Index / NumberOfColumns) + 1) * unproject(CellHeight) + MinimumLatitude
West = (Index % NumberOfColumns) * unproject(CellWidth) + MinimumLongitude
East = (Index % NumberOfColumns + 1) * unproject(CellHeight) + MinimumLongitude
Not all cells in the grid need a corresponding Raster Grid Cell object. In many cases, the data
being transferred does not fully expand to every cell. If a cell does not contain any data, it can
simply be omitted as a record and the data reader will know not to include that cell in the
resulting dataset. The Raster Grid object has a property that indicates the cell index associated
with the first record, which can be something other than 0. This is illustrated in the example
below.
90
91
92
93
94
95
96
97
98
99
80
81
82
83
84
85
86
87
88
89
70
71
72
73
74
75
76
77
78
79
60
61
62
63
64
65
66
67
68
69
50
51
52
53
54
55
56
57
58
59
40
41
42
43
44
45
46
47
48
49
30
31
32
33
34
35
36
37
38
39
20
21
22
23
24
25
26
27
28
29
10
11
12
13
14
15
16
17
18
19
0
1
2
3
4
5
6
7
8
9
In this example, there is a single polygon in red that needs to be rasterized. The 10x10 grid
covers the extents of the polygon but only the cells that intersect the polygon will contain any
data. Rasterizing the polygon will result in the image below.
90
91
92
93
94
95
96
97
98
99
80
81
82
83
84
85
86
87
88
89
70
71
72
73
74
75
76
77
78
79
60
61
62
63
64
65
66
67
68
69
50
51
52
53
54
55
56
57
58
59
40
41
42
43
44
45
46
47
48
49
30
31
32
33
34
35
36
37
38
39
20
21
22
23
24
25
26
27
28
29
10
11
12
13
14
15
16
17
18
19
0
1
2
3
4
5
6
7
8
9
When generating records for a dataset containing this polygon, only cells highlighted in red
would be records and have cell objects in the dataset. The first record would have the grid
definition for 10 rows and 10 columns, and the first cell index would be 2 in this case. Cells not
highlighted in red, 99 for instance, would not have associated records at all.
Spatial Data Type None
The historical data transfer specification allows for the transfer of record data not related to any
geo-spatial object.
WKT Representation of New Types
The following BNF grammar is an extension of the ISO 13249-3:2011 well-known text grammar.
<corner point> ::=
<x> <y>
<cell width> ::=
<number>
<cell height> ::=
<number>
<cell size> ::=
<cell width> <cell height>
<cell index> ::=
<exact numeric literal>
<number of rows> ::=
<exact numeric literal>
<number of columns> ::=
<exact numeric literal>
<cell count> ::=
<number of columns> <number of rows>
<raster grid text> ::=
<left paren> <corner point> <cell size> <cell count> <cell index> [ <z> ] <right paren>
<raster grid tagged text> ::=
RASTERGRID [Z] <raster grid text>
<raster grid cell text> ::=
<left paren> <cell index> [ <z> ] <right paren>
<raster grid cell tagged text> ::=
RASTERGRIDCELL <raster grid cell text>
<none text> ::=
<left paren> [ <z> ] <right paren>
<none tagged text> ::=
NONE [Z] <none text>
Examples
Geometry Type
Raster Grid
Raster Grid Z
Text Literal Representation
RASTERGRID ( 10 10 1 1 20 20 0 )
RASTERGRID Z ( 10 10 1 1 20 20 0 1200 )
Raster Grid Cell
Raster Grid Cell Z
RASTERGRIDCELL ( 3 )
RASTERGRIDCELL Z ( 3 1200 )
None
None Z
NONE ( )
NONE Z ( 1200 )
Comment
A Raster Grid
A Raster Grid with
Elevation
A Raster Grid Cell
A Raster Grid Cell with
Elevation
An empty spatial object
An empty spatial object
with Elevation
Binary Representation
All binary data is stored in little endian format. Because the endianness of the file is specified as
little endian, the byte order byte of the WKB representation is omitted and the NDR encoding is
assumed. It is possible to use a standard WKB decoder with this representation by loading the
first byte of an array with the NDR byte order value and copying the remaining type and data
bytes into the array starting with the second byte. The binary structures of the new spatial types
and record collection structures are described in the tables that follow.
Binary Representation of New Spatial Types
Table 2 - Raster Grid
Value
MinimumLatitude
MinimumLongitude
CellWidth
Binary data type
double
double
double
Length in bytes
8
8
8
CellHeight
NumberOfColumns
NumberOfRows
FirstCellIndex
double
Unsigned 32-bit integer
Unsigned 32-bit integer
Unsigned 32-bit integer
8
4
4
4
Comment
min. -180.0 .. max. 180.0
min. -90.0 .. max. 90.0
WGS84 (not mm to avoid
projection)
Index of cell for the first
record.
Table 3 - Raster Grid Z
Value
MinimumLatitude
MinimumLongitude
CellWidth
CellHeight
NumberOfColumns
NumberOfRows
FirstCellIndex
Binary data type
double
double
double
double
Unsigned 32-bit integer
Unsigned 32-bit integer
Unsigned 32-bit integer
Length in bytes
8
8
8
8
4
4
4
double
8
Binary data type
Length in bytes
Elevation
Comment
min. -180.0 .. max. 180.0
min. -90.0 .. max. 90.0
Index of cell for the first
record.
Elevation of cell indexed
by the grid. Elevation is in
meters.
Table 4 - Raster Grid Cell
Value
Comment
Index
Unsigned 32-bit integer
4
Table 5 - Raster Grid Cell Z
Value
Index
Elevation
Binary data type
Unsigned 32-bit integer
double
Length in bytes
4
8
Comment
Elevation is in meters.
Table 6 - Spatial Data Type None
If the type is None, then the spatial data section of the record will be 0 bytes in length.
Table 7 - Spatial Data Type None Z
Value
Elevation
Binary data type
double
Length in bytes
8
Comment
Elevation is in meters.
Record Collection Structures
Table 8 - Binary File Header
Value
Version
Binary data type
unsigned byte
Length in bytes
1
Bitfield
4
Unsigned 32-bit
integer
Binary Record
Structure
4
Flags
Record
Count
Record
Data n
Comment
First release will be value 1
Bit flags:
1: Timestamp included in record [1=yes, 0=no]
2-32: Undefined
The total number of records in this file
variable
The list of records for this file
Table 9 – Binary Record Structure
Value
Record Marker
Time
Binary data type
unsigned 16-bit
integer
Unsigned 32-bit
integer
Length in bytes
2
4
Comment
The value for the record marker
is 0x2E07
Milliseconds since midnight
Only exists in the file if the flag
is set in the header.
Date
Unsigned 16-bit
integer
2
The values are in UTC
Days since 1980-01-01
Only exists in the file if the flag
is set in the header.
Spatial data
Number of Layers
Spatial Data
Structure
Unsigned 16-bit
variable
2
The values are in UTC
A single Spatial Data Structure
The number of Layer Data
Layer Data n
integer
Layer Data Structure
Structures to follow
A list of layers that contain data
for this record
variable
Table 10 - Spatial Data Structure
Value
Spatial data length
Spatial data type
Spatial data
Binary data type
Unsigned 32-bit
integer
Unsigned 32-bit
integer
variable
Length in bytes
4
4
Comment
The size of this structure
One of the values from the
Spatial Data Type table.
The bytes are interpreted based
on the value of the data type.
These bytes do not include a
byte order byte, nor do they
include the type again.
variable
Table 11 - Layer Data Structure
Layer ID
Value
Binary data type
16-bit integer
2
Length in bytes
Layer Record Is Valid
Number of Attributes
byte
Unsigned 16-bit integer
1
2
Attribute Data n
Attribute Data Structure
6
Number of Sections
Unsigned 16-bit integer
2
Section Data n
Section Data Structure
variable
Comment
Numeric portion of
HistoricalDataLayer
element ID
The number of attribute
data structures for this
layer
A list of Attribute Data
structures that contain the
attribute values for this
layer
The number of section
data structures for this
layer
A list of Section Data
Structures that contain the
section data for this layer
Table 12 - Section Data Structure
Section ID
Value
Binary data type
16-bit integer
2
Length in bytes
Number of Attributes
Unsigned 16-bit integer
2
Attribute Value n
Attribute Data Structure
6
Number of Sections
Unsigned 16-bit integer
2
Section Data n
Section Data Structure
variable
Comment
Numeric portion of
HistoricalDataSection
element ID
The number of attribute
data structures for this
section
A list of attribute data
structures that contain the
attribute values for this
section
The number of section
data structures for this
section
A list of Section Data
Structures that contain the
section data for this
section
Table 13 - Attribute Data Structure
DDI
Value
Binary data type
Unsigned 32-bit integer
4
Length in bytes
Value
32-bit integer
4
Comment
Index of the attribute in the
array
Value according to DDI
JSON Representation
The file portion of the historical data transfer can be represented using JSON following the
guidelines for representing ISOXML as JSON. The data can exist in its own file or as a part of a
JSON document. In either case, the data object will be added as a property of the root object
with a name equal to the Filename property (D) of the corresponding Historical Data (DTA)
element.
Table 14 - Data Object
Name
Version
Records
Data Type
number
array [ Record Object ]
Comment
version of the specification
Data Type
string
string
array [ Layer Object ]
Comment
Example:
{ “Version”: 1, “Records”: […] }
Table 15 - Record Object
Name
Datetime
SpatialObject
Layers
WKT Representation (ISO 13249-3)
Example:
{ “Datetime”: “2013-01-31T16:55:03Z”, “SpatialObject”: “(POINT Z, (-94.344200 41.186549
1290.706000))”, “Layers”: […] }
Table 16 - Layer Object
Name
Id
Attributes
Data Type
number
null or array [ [number, number] ]
Sections
null or array [ Section Object ]
Example:
{ “Id”: 1, “Attributes”: [[12, 12130]], “Sections”: […] }
Comment
Same value as the Id
null if no attribute values, otherwise a
two dimensional array of number
pairs with the first number being the
DDI and the second being the value
Table 17 - Section Object
Name
Id
Attributes
Data Type
number
null or array [ [number, number] ]
Sections
null or array [ Section Object ]
Comment
null if no attribute values, otherwise a
two dimensional array of number
pairs with the first number being the
DDI and the second being the value
There can be at most two levels of
sections.
Example:
{ “Id”: 1, “Attributes”: [[12, 11980]], “Sections”: null }
Examples (work in progress)
Scenario: Two different seeds are planted using a 12 row split planter with a controller for the
first 6 rows and another for the second 6 rows. Each controller reports the rate for its 6 sections,
and each section individually is reporting the down force. The work state can be changed at the
controller level and at the row level. The working width for the planter is constant, and is known
for each half as well as each row.
The number in brackets is the DDI as defined in the data dictionary, ISO11783-11.
Appendix A
New Tag Proposals
Insert tag map diagram here...
ISO11783_TaskPlanning
Description:
The XML element ISO11783_TaskPlanning is the root XML element for a TASKPLAN XML file.
It contains information about the construct of the XML File, such as version and origin. The
author of the XML file should fill in the attribute values with information about the software
creating the XML file.
Includes XML elements:
- ApprovalAuthority
- AttachedFile
- ColourLegend
- CropType
- Customer
- DataRequest
- Device
- ExternalFileReference
- Farm
- HistoricalData
- History
- License
- Message
- ObjectRequest
- Partfield
- Person
- Product
- ValuePresentation
- Worker
- WorkSet
Attributes:
Attribute
XML
Use
Types
Length
/range
Comment
List element release number
(major), used to specify the
version of the SPADE
Extensions standard that this
task planning file meets:
VersionMajor
A
r
xs:NMTOKEN
0 to 1
0 = The draft version of the
standard
VersionMinor
B
r
xs:NMTOKEN
0 to 99
ManagementSoftwareManufacturer
C
r
xs:string
32
ManagementSoftwareVersion
D
r
xs:string
32
ApprovalAuthority
AAU
o
xs:element
AttachedFile
AFE
o
xs:element
ColourLegend
CLD
o
xs:element
CropType
CTP
o
xs:element
Customer
CTR
o
xs:element
DataRequest
DRQ
o
xs:element
Device
DVC
o
xs:element
ExternalFileReference
XFR
o
xs:element
Farm
FRM
o
xs:element
HistoricalData
HDT
o
xs:element
History
HTY
o
xs:element
License
LIC
o
xs:element
Message
MSG
o
xs:element
ObjectRequest
ORQ
o
xs:element
1 = The first published version
of the standard
List element version number
(minor), used to refer to
revisions of the XML schema
that this task planning file
complies to.
Name of management software
manufacturer
Version of management
software
Includes a list of XML element
ApprovalAuthority
Includes a list of XML element
AttachedFile
Includes a list of XML element
ColourLegend
Includes a list of XML element
CropType
Includes a list of XML element
Customer
Includes a list of XML
elementDataRequest
Includes a list of XML element
Device
Includes a list of XML element
ExternalFileReference
Includes a list of XML element
Farm
Includes a list of XML element
HistoricalData
Includes a list of XML element
History
Includes a list of XML element
License
Includes a list of XML element
Message
Includes a list of XML element
Partfield
PFD
o
xs:element
Person
PER
o
xs:element
Product
PDT
o
xs:element
ValuePresentation
VPN
o
xs:element
Worker
WKR
o
xs:element
WorkSet
WST
o
xs:element
ObjectRequest
Includes a list of XML element
Partfield
Includes a list of XML element
Person
Includes a list of XML element
Product
Includes a list of XML element
ValuePresentation
Includes a list of XML element
Worker
Includes a list of XML element
WorkSet
Examples:
<ISO11783_TaskPlanning A="0" B=”0” C=”Generic FMIS” D=”1.0.0.1”>
…
</ISO11783_TaskPlanning>
AAR - ApprovalAuthorityReference
Description:
A reference to an ApprovalAuthority element.
Included by XML elements:
- WorkSet
References XML elements:
- ApprovalAuthority
Includes XML elements:
Attributes:
Attribute
ApprovalAuthorityIdRef
XML
A
Use
r
Types
xs:IDREF
Length/range
min. .. max. 14
Comment
Reference to XML element
ApprovalAuthority.
Format: (AAU|AAU-)([0-9])+
Examples:
<AAU A="AAU1">
<PER A="PER1" B="My Farm Manager">
<ADR A="123 Main St" C="42071" D="Murray" E="KY" F="USA" G="+1-270-555-4369"/>
</PER>
</AAU>
<AAR A=”AAU1”>
</AAR>
AAU - ApprovalAuthority
Description:
The ApprovalAuthority element describes a person/organization that is licensed or has
permission to approve a request for work to be done. Examples of an ApprovalAuthority might
be a service provider who wants to verify that an execution window for work fits the schedule or
a licensed independent entity that validates the legality of the requested work.
Included by XML elements:
References XML elements:
Includes XML elements:
- LicenseReference
- Address
- Person
Attributes:
Attribute
ApprovalAuthorityId
XML
A
Use
r
Types
xs:ID
Length/range
min. .. max. 14
Comment
Unique identifier for approval
entity.
Format: (AAU|AAU-)([0-9])+
LicenseReference
o
xs:element
Address
o
xs:element
Person
o
xs:element
Records generated on MICS
have negative IDs
Includes a list of XML
element LicenseReference
Includes a single XML
element Address
Includes a list of XML
elements Person that
represent the contacts for
this authority.
Examples:
<AAU A="AAU1">
<PER A="PER1" B="My Farm Manager">
<ADR A="123 Main St" C="42071" D="Murray" E="KY" F="USA" G="+1-270-555-4369"/>
</PER>
</AAU>
ADR - Address
Description:
A series of properties that defines an address.
Included in XML elements:
- ApprovalAuthority
- Person
References XML elements:
Includes XML elements:
Attributes:
Attribute
Street
POBox
PostalCode
City
State
Country
Phone
Mobile
Fax
EMail
XML
A
B
C
D
E
F
G
H
I
J
Use
o
o
o
o
o
o
o
o
o
o
Types
xs:string
xs:string
xs:string
xs:string
xs:string
xs:string
xs:string
xs:string
xs:string
xs:string
Length/range
Comment
Street
PO box
Postal code
City
State or county
Country
Telephone number
Mobile phone number
Fax number
E-mail
Examples:
<LIC A="LIC2" B="PDA123456789" C="Pennsylvania Department of Agriculture">
<TSP A="2013-01-01T23:59:59-05:00" B="2013-12-31T23:59:59-05:00"/>
</LIC>
<AAU A="AAU1">
<PER A="PER1" B="Jenny"/>
<ADR A="456 1st Street" C="16823" D="Bellefonte" E="PA" F="USA" G="+1-555-867-5309"/>
<LIR A="LIC2"></LIR>
</AAU>
ATR - Attribute
Description:
An attribute is used to indicate what values are available in a set of data. The attribute can have
a set value if the Value property is defined. The Attribute can reference a ValuePresentation and
assign a Designator to help process proprietary DDIs.
Included in XML elements:
- HistoricalLayer
- HistoricalSection
References XML elements:
- ValuePresentation
Includes XML elements:
Attributes:
Attribute
XML
A
Use
r
Types
xs:hexBinary
Value
Designator
B
C
o
o
xs:long
xs:string
ValuePresentationIdRef
D
o
xs:IDREF
DDI
Length/range
0x0000 .. 0xFFFF
Comment
The variable as specified in
ISO11783-11
The value of the DDI
Human readable name of the
attribute.
Reference to XML element
ValuePresentation
Format: (VPN|VPN-)([0-9])+
Examples:
<ATR A="0054" C=”Yield Volume/Area”/>
BTC - Batch
Description:
The batch number of a product.
Included in XML elements:
- ProductAllocation
References XML elements:
Includes XML elements:
Attributes:
Attribute
Designator
XML
A
Use
r
Types
xs:string
Length/range
Comment
The batch number
Use
r
Types
xs:ID
Length/range
min. 4 .. max. 14
Comment
Unique identifier for
company.
Examples:
<BTC A="A34B426">
</BTC>
CPY - Company
Description:
A company or organization.
Included in XML elements:
References XML elements:
- Person
- Customer
- Worker
- Product
- Variety
Includes XML elements:
Attributes:
Attribute
ComapnyID
XML
A
Format: (CPY|CPY-)([0-9])+
Designator
WebAddress
TaxID
Address
B
C
D
r
o
o
xs:string
xs:string
xs:string
xs:element
Records generated on MICS
have negative IDs
The name of the company
The URL of the company
The Tax ID of the company
A single XML element
Address
Examples:
<CPY A="CPY1" B=”Some Company” C=”http://www.somecompany.com”>
<ADR A="456 1st Street" C="16823" D="Bellefonte" E="PA" F="USA" G="+1-555-867-5309"/>
</CPY>
CRU - CropUse
Description:
The CropUse element describes a use of a crop. A crop use is documented as either an intent
or an actual. Where the crop use is located defines the meaning for that reference. When the
crop use is linked to a partfield, then that crop use is an intended crop use for operation
planning. When the crop use is linked to a task, then that crop use is an actual crop use that
was used during harvest. The intended and actual crop uses can differ during a farming
operation.
The CropUseCode value list should be stored in a DDI and initialized with the values from the
NRCS.
Included in XML elements:
- ISO11783_TaskPlanning
References XML elements:
Includes XML elements:
Attributes:
Attribute
CropUseId
XML
A
Use
r
Types
xs:ID
Length/range
Comment
Unique identifier for CropUse
Format: (CRU|CRU-)([0-9])+
Designator
B
o
xs:string
Examples:
<CRU A="CRU1" B="Silage"/>
<CRU A="CRU2" B="Grain"/>
When referenced from a Partfield, a CropUse is intended.
<CRU A="CRU1" B="Silage"/>
<PFD A="PFD1" C="My Corn Field" J="CRU1">
When referenced from a Task, a CropUse is actual.
Records generated on MICS
have negative IDs
Human readable crop use
name.
<CRU A="CRU1" B="Silage"/>
<TSK A="TSK-1" G="1" K="CRU1">
CUR - CropUseReference
Description:
A reference to a CropUse element.
Included in XML elements:
- CropType
References XML elements:
- CropUse
Includes XML elements:
Attributes:
Attribute
CropUseIdRef
XML
A
Use
r
Types
xs:IDREF
Length/range
Comment
Reference to XML element
CropUse.
Format: (CRU|CRU-)([0-9])+
Examples:
A CropType can contain multiple CropUse references to indicate the list of possible uses for a
given CropType.
<CRU A="CRU1" B="Silage"/>
<CRU A="CRU2" B="Grain"/>
<CTP A="CTP1" B="Corn">
<CUR A="CRU1"/>
<CUR A="CRU2"/>
</CTP>
DDT - DueDate
Description:
The DueDate element describes a point or span of time in which some action is valid. DueDates
can be one of two types; execution or return. An execution DueDate would indicate the period of
time for which it is valid to execute the action in question. A return DueDate would indicate the
period of time for which a response to an offer or a request is acceptable.
Included in XML Elements:
- Message
- WorkSet
References XML Elements:
Includes XML Elements:
- AllocationStamp
Attributes:
Attribute
DueDateType
XML
A
Use
r
Types
xs:NMTOKEN
Notes
AllocationStamp
B
o
r
xs:string
xs:element
Length/range
1..2
Comment
The type of due date
1 = execution
2 = return
Unbounded note field
A single AllocationStamp
element
Examples:
A DueDate for a WorkSet.
<WST A="WST1" B="3">
<WOR A="WOR1" B="CTR1" C="FRM1" D="PFD1" E="Corn">
<TSK A="TSK1" B="Corn Seeding" C="CTR1" D="FRM1" E="PFD1" G="1">
<DLT A="DFFF" B="31"/>
<OTP A="CPC1" B="OTQ1"></OTP>
<TZN A="0" B="28000 seeds/ac">
<PDV A="0011" B="6919" C="PDT2"/>
</TZN>
</TSK>
<DDT A="1">
<ASP A="2013-04-15T00:00:00-06:00" B="2013-05-15T23:59:59-06:00" D="1"/>
</DDT>
</WOR>
</WST>
DTA - HistoricalDataset
Description:
A HistoricalDataset object is a collection of attributes, properties, object references, values, and
geospatial objects that are related to one another spatially and/or temporally, and that reference
a common set of coding data objects used in the production of the data. A HistoricalDataset
object can be a complete or partial set of data, and can either contain the actual data or merely
indicate that the data is available.
Included in XML elements:
- HistoricalData
References XML elements:
Includes XML elements:
- WorkerAllocation
- HistoricalLayer
- AllocationStamp
- Property
- Device Allocation
- Polygon
Attributes:
Attribute
HistoricalDatasetId
XML
A
Use
r
Types
xs:ID
Length/range
min. 4 .. max. 14
Comment
Unique identifier for
HistoricalDataset
Format: (DTA|DTA-)([0-9])+
DataInclusionPurpose
B
r
xs:NMTOKEN
1 .. 2
FileType
C
o
xs:NMTOKEN
1 .. 2
Filename
D
o
xs:string
8
DatasetId
E
o
xs:string
Completeness
F
o
xs:NMTOKEN
WorkerAllocation
o
xs:element
HistoricalLayer
r
xs:element
AllocationStamp
o
xs:element
Property
o
xs:element
Records generated on MICS
have negative IDs
1 = indication
2 = actual
1 = binary (extension .bin)
2 = json (extension .json)
3 = shape (extension .shp,
.shx, .dbf)
Unique name of
HistoricalDataset file
Format: DTA[0-9][0-9] [09][0-9] [0-9]
A system specific string used
to identify the dataset.
Multiple partials that share
the same DatasetId should
be merged together.
1 = complete
2 = partial
A single XML element of
type WorkerAllocation
A list of XML elements
HistoricalLayer
A single XML element
AllocationStamp that
indicates the time this
dataset spans
A list of XML elements
Property
Polygon
o
xs:element
DeviceAllocation
o
xs:element
A single XML element
Polygon that is the bounding
region for this data
A single XML element of
type DeviceAllocation.
Examples:
<PFD A="PFD1"/>
<CTP A=”CTP1” B=”Wheat”>
<CVT A=”CVT1” B=”Wheat Variety A” C=”PDT1”/>
<CVT A=”CVT2” B=”Wheat Variety B” C=”PDT2”/>
</CTP>
<PGP A=”PGP1” B=”Wheat Group” C=”2”/>
<PDT A=”PDT1” B=”Wheat Variety A” C=”PGP1”>
<PDT A=”PDT2” B=”Wheat Variety B” C=”PGP1”>
<HDT A="HDT1" B="2012 Wheat Harvest" D=”PFD1”>
<DTA A=”HDT1” B=”2” C=”1” D=”DTA00001” F=”1”>
<LYR>
<ATR A=”0063” C=”Moisture”/>
<ATR A=”0053” C=”Volume per Area Yield”/>
<PAN A=”PDT1”/>
<SUM>
<ASP A=”2012-07-01T00:00:01-06:00” B=”2012-07-06T23:59:5906:00”/>
<ATR A=”0059” B=”11276” C=”Yield Total Volume”>
<ATR A=”0106” B=”1350” C=”Average Crop Moisture”
</SUM>
</LYR>
<LYR>
<ATR A=”0063” C=”Moisture”/>
<ATR A=”0053” C=”Volume per Area Yield”/>
<PAN A=”PDT2”/>
<SUM>
<ASP A=”2012-07-01T00:00:01-06:00” B=”2012-07-06T23:59:5906:00”/>
<ATR A=”0059” B=”16209” C=”Yield Total Volume”>
<ATR A=”0106” B=”1310” C=”Average Crop Moisture”
</SUM>
</LYR>
</DTA>
</HDT>
DRQ - DataRequest
Description:
A request for data. The request can be as broad or narrow as needed by using one or more of
the coding data reference attributes, by specifying an AllocationStamp for the data, and/or by
specifying the attributes being requested. The DataRequestType of inquiry is used to get a list
of available data. Actual will give the processed data as it exists in the FMIS. Actual Raw will (if
appropriate) give the raw file(s). The raw files will be returned as one or more AttachedFile
elements.
Included in XML elements:
- ISO11783_TaskPlanning
References XML elements:
Includes XML elements:
- AllocationStamp
- Attribute
Attributes:
Attribute
DataRequestId
XML
A
Use
r
Types
xs:ID
Length/range
min. 4 .. max. 14
Comment
Unique identifier for
DataRequest
Format: (DRQ|DRQ-)([0-9])+
DataRequestType
B
r
xs:NMTOKEN
1 .. 3
CustomerIdRef
C
o
xs:IDREF
min. 4 .. max. 14
Records generated on MICS
have negative IDs
1 = inquiry
2 = actual
3 = actual raw
Reference to XML element
Customer.
Format: (CTR|CTR-)([0-9])+
FarmIdRef
D
o
xs:IDREF
min. 4 .. max. 14
Reference to XML element
Farm.
Format: (FRM|FRM-)([0-9])+
PartfieldIdRef
E
o
xs:IDREF
min. 4 .. max. 14
Reference to XML element
Partfield.
Format: (PFD|PFD-)([0-9])+
ProductIdRef
F
o
xs:IDREF
min. 4 .. max. 14
Reference to XML element
Product.
Format: (PDT|PDT-)([0-9])+
CropTypeIdRef
G
o
xs:IDREF
min. 4 .. max. 14
Reference to XML element
CropType.
Format: (CTP|CTP-)([0-9])+
CropVarietyIdRef
H
o
xs:IDREF
min. 4 .. max. 14
Reference to XML element
CropVariety.
Format: (CVT|CVT-)([0-9])+
AllocationStamp
o
xs:element
Attribute
o
xs:element
A list of XML elements
AllocationStamp
A list of XML elements
Attribute
Examples:
<PFD A="PFD1"/>
<CTP A=”CTP1”>
<CVT A=”CVT1”/>
</CTP>
<DRQ A="DRQ1" B=”1” E=”PFD1” H=”CVT1”>
<ASP A=”2014-07-14T00:01:00-06:00” B=”2014-07-14T23:59:59-06:00”/>
</DRQ>
HDT - HistoricalData
Description:
The historical data block describes data that has been collected or generated in the past. It is
not data that has more specific definitions, such as guidance. Historical data shall not be used
to describe planned data.
HistoricalData elements shall either contain HistoricalData, raw file data, or both.
Included in XML elements:
- ISO11783_TaskPlanning
References XML elements:
Includes XML elements:
- HistoricalDataset
Attributes:
Attribute
HistoricalDataId
XML
A
Use
r
Types
xs:ID
Length/range
min. 4 .. max. 14
Comment
Unique identifier for
HistoricalData
Format: (HDT|HDT-)([0-9])+
Designator
B
o
xs:string
32
CustomerIdRef
C
o
xs:IDREF
min. 4 .. max. 14
Records generated on MICS
have negative IDs
Designator of the historical
data.
Reference to XML element
Customer.
Format: (CTR|CTR-)([0-9])+
FarmIDRef
D
o
xs:IDREF
min. 4 .. max. 14
Reference to XML element
Farm.
Format: (FRM|FRM-)([0-9])+
PartfieldIdRef
E
o
xs:IDREF
min. 4 .. max. 14
Reference to XML element
Partfield.
Format: (PFD|PFD-)([0-9])+
HistoricalDataset
o
xs:element
AttachedFiles
o
xs:element
A list of XML elements
HistoricalDataset.
A list of XML elements
AttachedFile. These will
indicate the raw data files
when that information is
requested.
Examples:
<PFD A="PFD1"/>
<CTP A=”CTP1” B=”Wheat”>
<CVT A=”CVT1” B=”Wheat Variety A” C=”PDT1”/>
<CVT A=”CVT2” B=”Wheat Variety B” C=”PDT2”/>
</CTP>
<PGP A=”PGP1” B=”Wheat Group” C=”2”/>
<PDT A=”PDT1” B=”Wheat Variety A” C=”PGP1”>
<PDT A=”PDT2” B=”Wheat Variety B” C=”PGP1”>
<HDT A="HDT1" B="2012 Wheat Harvest" D=”PFD1”>
<DTA A=”HDT1” B=”2” C=”1” D=”DTA00001” F=”1”>
<LYR>
<ATR A=”0063” C=”Moisture”/>
<ATR A=”0053” C=”Volume per Area Yield”/>
<PAN A=”PDT1”/>
<SUM>
<ASP A=”2012-07-01T00:00:01-06:00” B=”2012-07-06T23:59:5906:00”/>
<ATR A=”0059” B=”11276” C=”Yield Total Volume”>
<ATR A=”0106” B=”1350” C=”Average Crop Moisture”
</SUM>
</LYR>
<LYR>
<ATR A=”0063” C=”Moisture”/>
<ATR A=”0053” C=”Volume per Area Yield”/>
<PAN A=”PDT2”/>
<SUM>
<ASP A=”2012-07-01T00:00:01-06:00” B=”2012-07-06T23:59:5906:00”/>
<ATR A=”0059” B=”16209” C=”Yield Total Volume”>
<ATR A=”0106” B=”1310” C=”Average Crop Moisture”
</SUM>
</LYR>
</DTA>
</HDT>
HTY - History
Description:
The History element describes the history of messages during the lifetime of this document. The
document may pass between many entities during its lifetime and an audit trail of actions taken
is required. When a new action is to be taken, or a new message is to be sent that is built off
this document, the message element at the root of the document should be moved into the
history element to continue the audit trial. There is only one history element allowed in a given
document.
Included in XML elements:
References XML elements:
Includes XML elements:
- Message
Attributes:
Attribute
Message
XML
Use
r
Types
xs:element
Length/range
Comment
List of Message elements
that existed over the life of
this document
Examples:
A message history during the process of creating a plan between two FMIS.
<HTY>
<MSG A="MSG1" B="1" C="1" E="Grower FMIS" F="12.5" O="I need to make crop plans for my 3 fields. I
want to plant corn in my corn field and beans in my two beans fields.">
<ASP A="2012-12-5T16:53:12-06:00" D="10"/>
</MSG>
<MSG A="MSG2" B="1" C="2" E="Agronomist FMIS" F="3.20121206">
<ASP A="2012-12-06T10:35:12-05:00" D="10"/>
</MSG>
</HTY>
LIC - License
Description:
The License element describes a license. The license can be for a variety of purposes. Some
examples include a license allowing a grower to apply a specific product, or an entity that is
certified to approve some kind of work.
Included by XML elements:
References XML elements:
Includes XML elements:
- Address
- Reference
- AllocationStamp
Attributes:
Attribute
LicenseId
XML
A
Use
r
Types
xs:ID
Length/range
min. .. max. 14
Comment
Unique identifier for
approval entity.
Format: (LIC|LIC-)([0-9])+
LicenseNumber
IssuingOrganization
B
C
r
r
xs:string
xs:string
IssuingOrganizationContact
o
xs:element
LicensedObjects
o
xs:element
Expiration
o
xs:element
max. 64
max. 64
Records generated on
MICS have negative IDs
The license number
The organization/agency
for which this license is
issued from/valid for
A single XML element of
type Address that is the
contact information for the
issuing organization
A list of XML elements
Reference that indicate the
objects for which this
license is valid.
A XML element
AllocationStamp that is the
expiration of the license.
Examples:
A license that allows a customer to purchase/plant a variety of beans between March 1, 2013
and November 11, 2013:
<CTP A="CTP1" B="Beans">
<CVT A="CVT1" B="My beans variety">
</CTP>
<LIC A="LIC1" B="ABC123XYZ" C="Awesome Seed Company">
<REF A="CVT1"/>
<TSP A="2013-03-01T10:00:00-06:00" B="2013-11-30T23:00:00-06:00">
</LIC>
<CTR A="CTR1" B="Bob">
<LIR A="LIC1">
</CTR>
LIR - LicenseReference
Description:
The License Reference element describes a reference to a License object.
Included by XML elements:
- ApprovalAuthority
References XML elements:
- License
Attributes:
Attribute
LicenseIdRef
XML
A
Use
r
Types
xs:IDREF
Length/range
min.4 .. max. 14
Comment
Reference to XML element
License.
Format: (LIC|LIC-)([0-9])+
Examples:
<CTP A="CTP1" B="Beans">
<CVT A="CVT1" B="My beans variety">
</CTP>
<LIC A="LIC1" B="ABC123XYZ" C="Awesome Seed Company">
<REF A="CVT1"/>
<TSP A="2013-03-01T10:00:00-06:00" B="2013-11-30T23:00:00-06:00">
</LIC>
<CTR A="CTR1" B="Bob">
<LIR A="LIC1">
</CTR>
LOT - Lot
Description:
The lot number of a product.
Included in XML elements:
- ProductAllocation
References XML elements:
Includes XML elements:
Attributes:
Attribute
Designator
XML
A
Use
r
Types
xs:string
Length/range
Comment
The lot number.
Examples:
<LOT A="ABC123">
LYR - HistoricalLayer
Description:
A HistoricalLayer is a collection of data related to either the use of a single product or to no
product at all. For example, in a split planter scenario where half of the planter is some product
A and the other half is some product B, you would have at least two LYRs in your DTA. A LYR
with no product might be used to represent a collection of data for a tillage operation, or for
vehicle metrics data such as engine RPMs.
Included in XML elements:
- HistoricalDataset
References XML elements:
Includes XML elements:
- Time
- ProductAllocation
- HistoricalSection
- Summary
- OperTechPractice
Attributes:
Attribute
HistoricalLayerId
XML
A
Use
r
Types
xs:ID
Length/range
Comment
Unique identifier for
HistoricalLayer
Format: (LYR|LYR-)([0-9])+
LayerGroupId
B
o
xs:long
Attribute
r
xs:element
Property
o
xs:element
ProductAllocation
o
xs:element
HistoricalSection
o
xs:element
Summary
o
xs:element
OperTechPractice
o
xs:element
Records generated on MICS
have negative IDs
An ID that indicates a sibling
relationship between one or
more HistoricalLayers
A list of XML elements
Attribute
A list of XML elements
Property
A single XML element
ProductAllocation
A list of XML elements
HistoricalSection
A single XML element of
type Summary that is the
summary of data for this
layer.
A single XML element of
type OperTechPractice
Examples:
<PFD A="PFD1"/>
<CTP A=”CTP1” B=”Wheat”>
<CVT A=”CVT1” B=”Wheat Variety A” C=”PDT1”/>
<CVT A=”CVT2” B=”Wheat Variety B” C=”PDT2”/>
</CTP>
<PGP A=”PGP1” B=”Wheat Group” C=”2”/>
<PDT A=”PDT1” B=”Wheat Variety A” C=”PGP1”>
<PDT A=”PDT2” B=”Wheat Variety B” C=”PGP1”>
<HDT A="HDT1" B="2012 Wheat Harvest" D=”PFD1”>
<DTA A=”HDT1” B=”2” C=”1” D=”DTA00001” F=”1”>
<LYR>
<ATR A=”0063” C=”Moisture”/>
<ATR A=”0053” C=”Volume per Area Yield”/>
<PAN A=”PDT1”/>
<SUM>
<ASP A=”2012-07-01T00:00:01-06:00” B=”2012-07-06T23:59:5906:00”/>
<ATR A=”0059” B=”11276” C=”Yield Total Volume”>
<ATR A=”0106” B=”1350” C=”Average Crop Moisture”
</SUM>
</LYR>
<LYR>
<ATR A=”0063” C=”Moisture”/>
<ATR A=”0053” C=”Volume per Area Yield”/>
<PAN A=”PDT2”/>
<SUM>
<ASP A=”2012-07-01T00:00:01-06:00” B=”2012-07-06T23:59:5906:00”/>
<ATR A=”0059” B=”16209” C=”Yield Total Volume”>
<ATR A=”0106” B=”1310” C=”Average Crop Moisture”
</SUM>
</LYR>
</DTA>
</HDT>
MSG - Message
Description:
The Message element describes specifics about an instance of a message. The specifics
include the message type, intent, any related due dates, and approvals for the message. When
the message is inside the HTY tag, then the element indicates results in the past. Only one
message element is allowed in the root of the document. The root document message element
describes the purpose of the current message.
Included by XML elements:
- MessageHistory
References XML elements:
- ApprovalAuthority
Includes XML elements:
- AllocationStamp
- DueDate
- Person
- StatusUpdate
Attributes:
Attribute
MessageId
XML
A
Use
r
Types
xs:ID
Length/range
min. .. max. 14
Comment
Unique identifier for
Message
Format: (MSG|MSG-)([09])+
Records generated on
MICS have negative IDs
MessageType
B
r
xs:NMTOKEN
1..n?
MessageIntent
C
r
xs:NMTOKEN
1..n?
Message type
specification:
1 = Plan
2 = Recommendation
3 = WorkOrder
Message intent
specification:
1 = Request
2 = Send
ApprovalAuthorityIdRef
D
o
xs:IDREF
min. .. max. 14
3 = Edit
4 = Accept
5 = Approve
6 = Acknowledge
7 = Status
Reference to XML element
ApprovalAuthority.
Format: (AAU|AAU-)([09])+
OriginatingSystemDesignator
E
r
xs:string
OriginatingSystemVersion
F
r
xs:string
Notes
Person
G
o
o
xs:string
xs:element
AllocationStamp
r
xs:element
1
DueDate
o
xs:element
0..n
StatusUpdate
o
xs:element
Designator of the
software/system used to
create the message
Version string of the
software/system used to
create the message.
Unbounded note field
A single XML element of
type Person that
represents the person
responsible for the
generation of this
message.
A single XML element of
type AllocationStamp that
represents the time this
message was
constructed/sent.
List of due dates for this
message
A list of XML elements of
type StatusUpdate that
represent any updates on
work status at the time of
this message.
Examples:
A message requesting a plan.
<MSG A="MSG1" B="1" C="1" E="My FMIS" F="12.5" O="I need to make crop plans for my 3 fields. I want
to plant corn in my corn field and beans in my two beans fields.">
<ASP A="2012-12-5T16:53:12-06:00" D="10"/>
</MSG>
ORQ - ObjectRequest
Description:
A request for one or more objects of some type. This would be used to ask questions of the
target system such as what farms belong to a grower, what workers have been defined, or what
devices exist. A parent object can be specified to limit the results to only objects related to some
known object in a hierarchy. Only coding data objects can be requested.
Included in XML elements:
- ISO11783_TaskPlanning
References XML elements:
- All coding data objects
Includes XML elements:
Attributes:
Attribute
ObjectRequestId
XML
A
Use
r
Types
xs:ID
Length/range
min. 4 .. max. 14
Comment
Unique identifier for
ObjectRequest
Format: (ORQ|ORQ-)([0-9])+
ObjectType
B
r
xs:string
3
ObjectParent
C
o
xs:IDREF
min. 4 .. max. 14
Records generated on MICS
have negative IDs
The 3 letter XML tag name
representing the coding data
object type being requested.
A reference to an XML
element of any coding data
type where the same type
can also be referenced, or is
the parent of by hierarchy,
the object type being
requested.
Examples:
You can do this:
<ORQ A="ORQ1" B="PFD" C="CTR1">
A customer can be referenced from a PFD, so this is valid.
<ORQ A="ORQ1" B="CVT" C="CTP1">
A crop variety is a child element of a crop type, so this is valid.
You cannot do this:
<ORQ A="ORQ1" B="PFD" C="WKR1">
A worker cannot be referenced from a PFD and is not a parent element of a PFD so this is
invalid.
PER - Person
Description:
An element that represents a person that is not a customer or a worker. The person is
referenced from the approval authority and the message. In the message, a person is the
individual who is responsible for generating it. A person in an approval authority would be a
contact for that authority.
Included in XML elements:
References XML elements:
Includes XML elements:
Attributes:
Attribute
PersonId
XML
A
Use
r
Types
xs:ID
Length/range
min. 4 .. max. 14
Comment
Unique identifier for person.
Format: (PER|PER-)([0-9])+
Designator
Company
B
C
r
o
xs:string
xs:IDREF
Address
o
xs:element
LicenseReference
o
xs:element
min. 4 .. max. 14
Records generated on MICS
have negative IDs
The name of the person
Reference to XML element
Company
Format: (CPY:CPY-)[0-9]+
A single XML element
representing the address for
the person
A list of XML elements of
type LicenseReference
Examples:
Person with an Address.
<PER A="PER1" B="Jenny">
<ADR A="456 1st Street" C="16823" D="Bellefonte" E="PA" F="USA" G="+1-555-867-5309"/>
</PER>
PPT - Property
Description:
A property is a static value that describes some aspect of an object and that does not change
within the scope of the document the object exists in. An X offset on a HistoricalSection is an
example of a property.
Included in XML elements:
- HistoricalSection
- HistoricalLayer
- HistoricalDataset
References XML elements:
Includes XML elements:
Attributes:
Attribute
XML
A
Use
r
Types
xs:hexBinary
Value
Designator
B
C
r
o
xs:long
xs:string
ValuePresentationIdRef
D
o
xs:IDREF
DDI
Length/range
0x0000 .. 0xFFFF
Comment
The variable as specified in
ISO11783-11
The value of the property
Human readable name of the
property
Reference to XML element
ValuePresentation
Format: (VPN|VPN-)([0-9])+
Examples:
<PPT A="0086" B=”1500” C=”X Offset”/>
REF - Reference
Description:
A Reference tag creates a link between the parent tag and any identifiable object.
Included in XML elements:
References XML elements:
Includes XML elements:
Attributes:
Attribute
ObjectReferenceId
XML
A
Use
r
Types
xs:REFID
Length/range
min. 4 .. max. 14
Examples:
A Reference tag that refers to some Product with the ID PDT-1
<REF A="PDT-1">
Comment
A reference to any
identifiable object.
A Reference tag that refers to some Partfield with the ID PFD-2
<REF A="PFD-2">
SSN - Season
Description:
A season is a named period of time in which a crop is produced. Multiple seasons can exist in a
single year, and a season can span multiple years.
Included in XML elements:
- ISO11783_TaskPlanning
References XML elements:
Includes XML elements:
Attributes:
Attribute
SeasonId
XML
A
Use
r
Types
xs:ID
Length/range
Comment
Unique identifier for season.
Format: (SSN|SSN-)([0-9])+
Designator
AllocationStamp
B
r
r
xs:string
xs:element
Records generated on MICS
have negative IDs
The name of the season
A single XML element of
type AllocationStamp that
represents the span of time
for which this season is valid.
Examples:
A season used in defining a WorkSet.
<SSN A="SSN1" B="2013">
<TSP A="2013-01-01T23:59:59-05:00" B="2013-12-31T23:59:59-05:00"/>
</SSN>
<WST A="WST1" B="1" E=”SSN1”>
<WOR A="WOR3" B="CTR1" C="FRM1" D="PFD3" E="Beans 2">
<TSK A="TSK1" B="Corn Seeding" C="CTR1" D="FRM1" E="PFD3">
<OTP A="CPC1" B="OTQ1"></OTP>
<TZN A="0" B="16000 seeds/ac">
<PDV A="0011" B="3954" C="PDT2"/>
</TZN>
</TSK>
</WOR>
<TSP A="2012-12-06T10:35:12-05:00"/>
</WST>
STN - HistoricalSection
Description:
A section of data in a HistoricalLayer. Sections may themselves contain sections to a maximum
of 2 levels. For example a planter may have a full swath broken up into 4 sections and each of
those 4 sections could themselves have 6 rows which would be represented by sections.
Included in XML elements:
References XML elements:
Includes XML elements:
- Attribute
- Property
- HistoricalSection
Attributes:
Attribute
SectionId
XML
A
Use
r
Types
xs:long
Attribute
r
xs:element
Property
o
xs:element
HistoricalSection
o
xs:element
Examples:
<STN A=”1”>
<ATR A=”0002” C=”Spraying Rate, Section 1”/>
<PPT A=”0087” B=”-1500” C=”Y Offset”/>
<PPT A=”0043” B=”1500” C=”Width”/>
</STN>
<STN A=”2”>
<ATR A=”0002” C=”Spraying Rate, Section 2”/>
<PPT A=”0087” B=”0” C=”Y Offset”/>
<PPT A=”0043” B=”1500” C=”Width”/>
</STN>
Length/range
0 .. 65534
Comment
A value 0-65534 that is
unique within the collection
of sections in the parent
element.
A list of XML elements
Attribute
A list of XML elements
Property
A list of XML elements of
type HistoricalSection
STS - StatusUpdate
Description:
The status of any item within a WorkSet. Updates can be provided on the WorkSet, Work, or
even Task level through the WorkReferenceID attribute. In the case of an update being provided
for an entire WorkSet the status of each Work and Task item is assumed to be defined as being
the same at the time as defined in the AllocationStamp.
Included in XML elements:
- Message
References XML elements:
Includes XML elements:
Attributes:
Attribute
XML
A
Use
r
Types
xs:NMTOKEN
Length/range
1..7
WorkReferenceID
B
r
xs:IDREF
min. 4 .. max. 14
Comment
C
o
xs:string
r
xs:element
Status
AllocationStamp
Comment
1=Planned
2=Scheduled
3=In Progress
4=Paused
5=Partially Completed
6=Completed
7=Cancelled
Reference to XML element
Company
Format: (STS:STS-)[0-9]+
Additional information related
to the status update.
A single XML element of
type AllocationStamp that is
the time stamp for this status
update.
Examples:
StatusUpdate for a Work Order.
<MSG A="MSG15" B="3" C="7" D="AAU1" E="Service Provider FMIS" F="3.20130227" O="Status
Update">
<ASP A="2013-02-27T15:15:00-05:00" D="10"/>
<STS A="1" B="WOR1" C="2013-03-05T23:59:59-05:00" C="Waiting on weather forecasts.">
<ASP A="2013-02-27T15:15:00-05:00" D="10"/>
</STS>
</MSG>
SUM - Summary
Description:
A list of attribute totals to be used as a summary of data.
Included in XML elements:
- HistoricalLayer
References XML elements:
Includes XML elements:
- AllocationStamp
- Attribute
Attributes:
Attribute
AllocationStamp
Attribute
XML
Use
r
Types
xs:element
r
xs:element
Length/range
Comment
Single AllocationStamp XML
element that contains both
the start and end date
List of attributes and their
corresponding values
Examples:
<PFD A="PFD1"/>
<CTP A=”CTP1” B=”Wheat”>
<CVT A=”CVT1” B=”Wheat Variety A” C=”PDT1”/>
<CVT A=”CVT2” B=”Wheat Variety B” C=”PDT2”/>
</CTP>
<PGP A=”PGP1” B=”Wheat Group” C=”2”/>
<PDT A=”PDT1” B=”Wheat Variety A” C=”PGP1”>
<PDT A=”PDT2” B=”Wheat Variety B” C=”PGP1”>
<HDT A="HDT1" B="2012 Wheat Harvest" D=”PFD1”>
<DTA A=”HDT1” B=”2” C=”1” D=”DTA00001” F=”1”>
<LYR>
<ATR A=”0063” C=”Moisture”/>
<ATR A=”0053” C=”Volume per Area Yield”/>
<PAN A=”PDT1”/>
<SUM>
<ASP A=”2012-07-01T00:00:01-06:00” B=”2012-07-06T23:59:5906:00”/>
<ATR A=”0059” B=”11276” C=”Yield Total Volume”>
<ATR A=”0106” B=”1350” C=”Average Crop Moisture”
</SUM>
</LYR>
<LYR>
<ATR A=”0063” C=”Moisture”/>
<ATR A=”0053” C=”Volume per Area Yield”/>
<PAN A=”PDT2”/>
<SUM>
<ASP A=”2012-07-01T00:00:01-06:00” B=”2012-07-06T23:59:5906:00”/>
<ATR A=”0059” B=”16209” C=”Yield Total Volume”>
<ATR A=”0106” B=”1310” C=”Average Crop Moisture”
</SUM>
</LYR>
</DTA>
</HDT>
WOR - Work
Description:
A specific collection of things to do related to either part or all of a work set.
Included in XML elements:
- WorkSet
References XML elements:
- Customer
- Farm
- Partfield
Includes XML elements:
- Task
- DueDate
- GuidanceAllocation
Attributes:
Attribute
WorkID
XML
A
Use
r
Types
xs:ID
Length/range
min. 4 .. max. 14
Comment
Unique identifier for
WorkOrder
Format: (WOR|WOR-)([09])+
Records generated on MICS
have negative IDs
CustomerRefId
B
o
xs:IDREF
min. 4 .. max. 14
FarmRefId
C
o
xs:IDREF
min. 4 .. max. 14
Reference to XML element
Customer.
Format: (CTR|CTR-)([0-9])+
Reference to XML element
Farm.
PartfieldRefId
D
o
xs:IDREF
Notes
Task
E
o
o
xs:string
xs:element
o
xs:element
DueDate
min. 4 .. max. 14
Format: (FRM|FRM-)([0-9])+
Reference to XML element
Partfield.
Format: (PFD|PFD-)([0-9])+
Unbounded note field
A list of tasks for prescription
transfer.
A list of due dates
Examples:
A Work item for planting corn.
<WOR A="WOR3" B="CTR1" C="FRM1" D="PFD3" E="Beans 2">
<TSK A="TSK1" B="Corn Seeding" C="CTR1" D="FRM1" E="PFD3">
<OTP A="CPC1" B="OTQ1"></OTP>
<TZN A="0" B="16000 seeds/ac">
<PDV A="0011" B="3954" C="PDT2"/>
</TZN>
</TSK>
</WOR>
WST - WorkSet
Description:
A work set is a collection of work to be done. A work set exists in one of three phases; Plan,
Recommendation, or Work Order. A work set may have descended from another work set. In
this case, the parent work set can be referenced.
Included in XML elements:
- ISO11783_TaskPlanning
References XML elements:
- WorkSet
Includes XML elements:
- Work
- ApprovalAuthorityReference
Attributes:
Attribute
WorkSetId
XML
A
Use
r
Types
xs:ID
Length/range
Comment
Unique identifier for WorkSet
Format: (WST|WST-)([0-9])+
Phase
B
r
xs:NMTOKEN
1 .. 3
ParentWorkSetRefId
C
o
xs:IDREF
min. 4 .. max. 14
Notes
SeasonIdRef
D
E
o
o
xs:string
xs:IDREF
Designator
F
o
xs:string
Work
r
xs:element
DueDate
CreationDate
o
o
xs:element
xs:element
ModifiedDate
o
xs:element
Season
o
xs:element
ApprovalAuthorityReference
o
xs:element
min. 4 .. max. 14
Records generated on MICS
have negative IDs
1 = Plan
2 = Recommendation
3 = WorkOrder
Reference to XML element
WorkSet.
Format: (WST|WST-)([0-9])+
Unbounded note field
Reference to XML element
Season
Format: (SSN|SSN-)([0-9])+
The designator of the
WorkSet
A list of work to be done for
this work set
A list of due dates
A single XML element of
type AllocationStamp that is
the time in which this work
set was created.
A single XML element of
type AllocationStamp that is
the latest time in which the
work set was edited.
The crop season for this
work set.
A list of XML elements of
type
ApprovalAuthorityReference
that indicate the authorities
that authorized this set of
work.
Examples:
A Recommendation WorkSet with a single Work item.
<SSN A="SSN1" B="2013">
<ASP A="2013-03-01T23:59:59-05:00" B="2013-12-31T23:59:59-05:00" D="4"/>
</SSN>
<WST A="WST1" B="3" E=”SSN1”>
<WOR A="WOR1" B="CTR1" C="FRM1" D="PFD1" E="Corn">
<TSK A="TSK1" B="Corn Seeding" C="CTR1" D="FRM1" E="PFD1" G="1">
<DLT A="DFFF" B="31"/>
<OTP A="CPC1" B="OTQ1"></OTP>
<TZN A="0" B="28000 seeds/ac">
<PDV A="0011" B="6919" C="PDT2"/>
</TZN>
</TSK>
<DDT A="1">
<ASP A="2013-04-15T00:00:00-06:00" B="2013-05-15T23:59:59-06:00" D="1"/>
</DDT>
</WOR>
<ASP A="2013-01-15T10:35:12-06:00" D="1"/>
</WST>
Appendix B
Proposed extensions to existing ISOXML tags
PFD - Partfield
Modification:
Add an attribute (J) to PFD to indicate the intended crop use for the crop/variety referenced by
G and H.
Attribute
IntendedCropUseIdRef
XML
J
Use
o
Types
xs:IDREF
Length/range
min. 4 .. max. 14
Comment
Reference to XML element
CropUse
Format: (CRU|CRU-)([0-9)+
CTP - CropType
Modification:
Add an element list of type CropUseReference that indicates the uses available for this crop
type. These could be used in the MICS as a picklist for the user when documenting tasks.
Add standard moisture and crop density attributes to crop type.
Attribute
StandardMoisture
CropDensity
CropUseReference
XML
D
E
Use
o
o
o
Types
xs:decimal
xs:decimal
xs:element
Length/range
0.0 ... 100.0
> 0.0
Comment
The standard moisture in %
The density in kg/m3
A list of XML elements of
type CropUseReference
TSK - Task
Modification:
Add an attribute (K) to TSK to indicate the actual crop use of the crop/variety referenced by the
PFD referenced by the TSK.
Attribute
ActualCropUseIdRef
XML
K
Use
o
Types
xs:IDREF
Length/range
min. 4 .. max. 14
Comment
Reference to XML element
CropUse
Format: (CRU|CRU-)([0-9)+
ASP - AllocationStamp
Modification:
There is a need to indicate time as just an end with no beginning. These would be used in cases
of deadlines where some event cannot occur beyond some point in time. For example a work
order cannot be approved beyond a specific date. To accomplish this, the start time would need
to be optional.
There is also a need to track when a work set is created and when it was last edited. To do this,
additional types of Created and Modifed need to be added to the type list.
Start
Attribute
XML
A
Use
o
Types
xs:datetime
Length/range
Max. 25
Stop
B
o
xs:datetime
Max. 25
Type
D
r
xs:NMTOKEN
1, 4, 10, 11
Comment
Time of start. Format: yyyymm-ddThh:mm:ss[Z|[+|]hh:mm|null]
Time of end. Format: yyyymm-ddThh:mm:ss[Z|[+|]hh:mm|null]
Type of the AllocationStamp,
posisble values:
1=Planned
4=Effective
10=Created
11=Modified
PAN - ProductAllocation
Modification:
Add a list of batches and lots used with the allocation.
Attribute
Batch
Lot
XML
Use
o
Types
xs:element
o
xs:element
Length/range
Comment
A list of XML elements of
type Batch
A list of XML elements of
type Lot
CTR - Customer
Modification:
Add attributes to a customer to track tax information, the company they are associated with, and
their position in that company. Also add a license references to track licenses related to this
customer.
Attribute
TaxId
Company
XML
N
O
Use
o
o
Types
xs:string
xs:IDREF
Position
LicenseReference
P
o
o
xs:string
xs:element
Length/range
Comment
The tax number
Reference to XML element
Company
Format: (CPY:CPY-)[0-9]+
The position in that company
A list of XML elements of
type LicenseReference
DVC - Device
Modification:
Add an attribute (H) to a device to indicate the Model of the device. Currently there is a
designator which some companies (not all) are using as a Model. FMIS systems would like to
use the designator as a user defined name (eg. "My Planter") and calling out a specific Model
attribute would make it clear for hardware manufacturers where to put the model information.
Attribute
Model
XML
H
Use
o
Types
xs:string
Length/range
max. 32
Comment
The model of the device
WKR - Worker
Modification:
Add a company name the worker belongs to and a list of license references to indicate any
licenses associated with this worker.
Attribute
Company
LicenseReference
XML
N
Use
o
Types
xs:IDREF
o
xs:element
Length/range
Comment
Reference to XML element
Company
Format: (CPY:CPY-)[0-9]+
A list of XML elements of
type LicenseReference
PDT - Product
Modification:
Add an attribute to product that links to the manufacturer of the product.
Attribute
Company
XML
H
Use
o
Types
xs:IDREF
Length/range
Comment
Reference to XML element
Company
Format: (CPY:CPY-)[0-9]+
CVT - CropVariety
Modification:
Add an attribute to crop variety that links to the manufacturer of the variety.
Attribute
CompanyIdRef
XML
D
Use
o
Types
xs:IDREF
Length/range
Comment
Reference to XML element
Company
Format: (CPY:CPY-)[0-9]+
DLV - DataLogValue
Modification:
Add an attribute to data log value that indicates that this DLV contains values that extend
another DET. This is useful to inject additional information regarding a DET into the log stream
without requiring changes to an ECU. An example of this would be a TC that wants to record the
source of a setpoint value being sent to the ECU. It may also be useful in other situations where
a sensor value (for example vegetation index) on some device is being used to influence the
values on another device (continuing the example, the spraying rate).
Attribute
TargetDeviceElementIdRef
XML
G
Use
o
Types
xs:IDREF
Length/range
Comment
A reference to XML element
DeviceElement
Format: (DET|DET-)([0-9])+
CLD - ColourLegend
Modification:
Add an optional ARGB 32-bit integer value to allow a larger variety of colors displayable by an
FMIS to be used when showing the data. The FMIS will still be required to fill out an appropriate
palette color value that most closely matched the ARGB value for compatibility with systems
that only support the palette colors.
Attribute
DefaultARGBColour
XML
C
Use
o
Types
xs:unsignedLong
Length/range
32
Comment
4 byte ARGB representation
of the color. Least
significant byte is B.
CRG - ColourRange
Modification:
Add an optional ARGB 32-bit integer value to allow a larger variety of colors displayable by an
FMIS to be used when showing the data. The FMIS will still be required to fill out an appropriate
palette color value that most closely matched the ARGB value for compatibility with systems
that only support the palette colors.
Attribute
ARGBColour
XML
D
Use
o
Types
xs:unsignedLong
Length/range
32
Comment
4 byte ARGB representation
of the color. Least significant
byte is B.
PLN - Polygon
Modification:
Add an optional ARGB 32-bit integer value to allow a larger variety of colors displayable by an
FMIS to be used when showing the data. The FMIS will still be required to fill out an appropriate
palette color value that most closely matched the ARGB value for compatibility with systems
that only support the palette colors.
Attribute
ARGBColour
XML
F
Use
o
Types
xs:unsignedLong
Length/range
32
Comment
4 byte ARGB representation
of the color. Least significant
byte is B.
LSG - Linestring
Modification:
Add an optional ARGB 32-bit integer value to allow a larger variety of colors displayable by an
FMIS to be used when showing the data. The FMIS will still be required to fill out an appropriate
palette color value that most closely matched the ARGB value for compatibility with systems
that only support the palette colors.
Attribute
ARGBColor
XML
G
Use
o
Types
xs:unsignedLong
Length/range
32
Comment
4 byte ARGB representation
of the color. Least significant
byte is B.
PNT - Point
Modification:
Add an optional ARGB 32-bit integer value to allow a larger variety of colors displayable by an
FMIS to be used when showing the data. The FMIS will still be required to fill out an appropriate
palette color value that most closely matched the ARGB value for compatibility with systems
that only support the palette colors.
Attribute
ARGBColor
XML
L
Use
o
Types
xs:unsignedLong
Length/range
32
Comment
4 byte ARGB representation
of the color. Least significant
byte is B.
Appendix C
Guidelines for representation of ISO11783-10 ISOXML in JSON
Files
The document will contain a single, nameless, root object. On that root object will
live any external file as a property of that object with the property name being the
same as the expected file name. So a basic TASKDATA.XML file in JSON would
look like:
{TASKDATA: {...}}
where the file name is a property of the root object. If other files are needed, they
are appended as properties to the root object in the same way. A
TASKDATA.XML file with a single logged TLG will look similar to:
{TASKDATA: { ...}, TLG00001:{...}}
XML Elements
Each XML element will be an object in JSON. The object will have properties
named the same as the XML element attributes (A, B, C, etc.). These properties
will have the same values and constraints as documented in the specification.
Attributes that are optional may be omitted from the JSON, or given the value
null. For example, a Partfield object may look like:
{"A":"PFD1","C":"My Field", D:5000}
If the XML element contains child elements, a properties with the XML element
tag names will be added to the JSON object. When the element contains a list of
child elements, a JSON array is used. For example, a Partfield with a Polygon:
{"A":"PFD1","C":"My Field","D":5000,"PLN":[{...}]}
When the element contains at most a single instance of a child element then a
single object is used. For example, an AllocationStamp:
{"A":"2013-01-31T16:55:03Z","PTN":{...}}
Data Types
The data types for the XML attribute values map to JSON values in the following
ways:
XML Attribute Data Type
xs:ID
xs:IDREF
xs:string
xs:datetime
xs:NMTOKEN
xs:decimal
xs:unsignedLong
xs:unsignedShort
JSON Data Type
string
string
string
string
number
number
number
number
Example
"CTR1"
"CTR1"
"My Name"
"2013-01-31T16:55:03Z"
1
25.00135
123456789
65536
xs:unsignedByte
xs:long
xs:hexBinary
number
number
string
256
-123456789
"0A2B"
Binary Attached Files
If files attached using AttachedFile (AFE) elements require the file to be
expressed in binary, then the contents of the file are base64 encoded and
inserted as text as a normal file.
TimeLog Binary Files
TimeLog binary files are an array of record objects. A record object contains up to 3 properties;
TIM, PTN, and DLV. The TIM property contains the value of the start time (as a string
representation of xs:datetime) of the record and covers the two parts of TIM,A in the binary file
record. The PTN property contains an object that has the logged properties for the PTN object
as described in the corresponding TimeLog object with the exception of the H and I properties,
which are combined into a UTC string property as noted below. The DLV property contains a 2dimensional array of (index, value) pairs that would normally exist in the binary file record.
Value
XML
Reference
TimeStart
TIM,A
PositionNorth
PositionEast
PositionUp
PositionStatus
PDOP
PTN,A
PTN,B
PTN,C
PTN,D
PTN,E
HDOP
PTN,F
NumberOfSatellites
GpsUtcTime/Date
PTN,G
PTN,H, PTN,I
DLV
-
A brief time log file example:
{[
{
"TIM":"2013-01-31T16:55:03Z",
Binary Data
Type
unsigned 32bit integer
followed by an
unsigned 16bit integer
32-bit integer
32-bit integer
32-bit integer
byte
unsigned 16bit integer
unsigned 16bit integer
byte
unsigned 32bit integer
followed by
unsigned 16bit integer
byte followed
by 2D array of
[byte, 32-bit
integer]
JSON
Property
Name
"TIM"
JSON Data
Type
Example
string
"TIM":"2013-0131T16:55:03Z"
"A"
"B"
"C"
"D"
"E"
number
number
number
number
number
"PTN":{"A":42.7812343}
"PTN":{"B":121.5439872}
"PTN":{"C":30.04}
"PTN":{"D":5}
"PTN":{"E":0.5}
"F"
number
"PTN":{"F":0.5}
"G"
"UTC"
number
string
"PTN":{"G":7}
"PTN":{"UTC":"2013-0131T16:55:03Z"}
"DLV"
2D array of
[number,
number]
"DLV":[[0, 7213],[1, 90548]]
"PTN":{"A":42.7812343, "B":121.5439872, "D":5, "UTC":"2013-01-31T16:55:03Z "},
"DLV":[[0, 7213],[1, 90548]]
}, ...
]}
Grid Binary Files
Grid binary files are expressed as a 2 dimensional array. The layout is the same as the binary
version where the contents of the cells are represented as an array, with each cell containing an
array of PDV values.
{[[1, 2], [1, 2], [1, 2], [1, 2]...]}