Participants
@Names hereKelly Nelson Jim Wisner, Jeremy W Wilson Stuart Rhea (Deactivated) Andres Ferreyra Ruttencutter, Chris Charlie Guo (Unlicensed) Corey Lacey Bryce Hemme Jim Wilson Michael Figura Zac Oler
Meeting Logistics
Expand | ||
---|---|---|
| ||
ADAPT Serialization Meet Up - 26 Aug - 1pm Chicago (2pm New York) Fri, Aug 26, 2022 1:00 PM - 3:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. You can also dial in using your phone. Access Code: 330-169-053 More phone numbers: |
Agenda and Minutes
Expand | ||
---|---|---|
| ||
Antitrust Reminder
|
Main Topics
Use
Status | ||||
---|---|---|---|---|
|
Main goals for serialization of ADAPT
Topic Leader:
The desired outcome is that we have agreement on the purpose, scope and overall goals for serializing ADAPT.
Pre-meeting notes and references:
Is the serialization effort specific to the standard version of ADAPT begin done in SCORE or would it apply to existing .net toolkit as well?
Minutes
Still too much room for interpretation within ADAPT. Still requires a lot of one off interpretation per OEM.
Kelly’s three principles seems general agreement to these principles
Should be open format and semantics, if it cant be translated keep it out. Everything in ADAPT should be open and readable by anyone authorized to have the data
Data has to be flexible. Cannot mandate what must be serialized, ie spatial data can be a point or polygon
Should be as human readable as possible. Balance file size, some form of zipped GeoJSON maybe. If we go to Protobuff or some binary path we should consider developing some tools for industry to use to make data more accessible/human readable
Is possible to have both GeoJSON and Protobuff combination - yes
ADAPT standard effort will deliver a schema (JSON)
Maybe enhance SCORE to deliver a Proto schema as well as JSON?
Tool exists to convert JSON to Proto already that could facilitate this
Human readable = drop into QGis easily to trouble shoot issues in the data
QGis plugin may be difficult to manage due to open source license QGis is under
What are we serializing?
All of ADAPT?
Requiring standard names? DDI’s, other things that may not be in an “approved” industry vocabulary list
We need to STRONGLY encourage folks to use WG00-mediated controlled vocabularies, BUT give them an option to use proprietary ones.
Need to do a better job of making sure people know when Agrisemantics Subcommittee meets
Key deliverables for Serialization project
Topic Leader:
The desired outcome is that the main deliverables required for serialization of ADAPT are identified and agreed to in order to scope a project/charter a working group
Pre-meeting notes and references:
Minutes:
Can serialize subsets of model “it is chunk-able”
File sizes are reasonable
Minutes:
Main use cases
Organizations to store data internally (persistent data storage)
Status colour Red title Not in scope Sharing data sets between systems
Trend in industry seems to be OEM’s store data and share somewhat “processed” data
ie three combines in a field, but share yield map without any DDOP, or machine identifiers, all data merged
Is that ok, do we need the “original” data generated by each machine and the implement geometry etc. that comes with it
Some concerns over being able to fix/understand data that has been lumped/processed together
One file, side car files ok?
ie Summary vs logged data in ADAPT
Strictly time-series logged data
Spacial representations
I need to transfer data to someone else efficiently and they need to be able to understand it
Status colour Green title Primary Use Case
Technical solution
Proto buff, …
Ideally will be determined by requirements, ie human readability
Conduct some experiments to make informed decision on file size, human readability
Corteva/Granular open sourced Geostream, a compressed geojson format https://github.com/granular-oss/geostream
Proceed as an AgGateway working group
Topic Leader: Ben Craker
The desired outcome is that the group agrees to how the serialization effort will be managed
Pre-meeting notes and references:
Preference is to run as a normal AgGateway working group, this provides the clear charter, tools, and process for creating a digital resource
Also would be under AgGateway’s antitrust and IP policies making it clear how any contributions (code, or general knowledge) would be handled
Can still utilize GitHub repo or confluence pages or other tools, whatever makes sense to achieve the deliverables laid out in topic 2.
Only limitation is would be limited to AgGateway members
Minutes:
To build off what ADAPT currently is as an open source project, it may hinder participation/adoption if working group is limited to AgGateway members
Working group could produce serialization and contribute to/as open source project
Question if Europe is aware since most have been off the last ~month to voice opinion either way
Project Leadership
Topic Leader: Ben Craker
The desired outcome is that the group agrees to who will be the chair/vice chair of the working group
Pre-meeting notes and references:
Minutes:
Chair: Bryce Hemme
Vice-Chair: Stuart Rhea (Deactivated)
Meeting time and cadence
Topic Leader:
The desired outcome is that the group agrees on the time, dates, duration, and location for subsequent meetings assuming there is consensus to move forward with the project
Pre-meeting notes and references:
Meet weekly, bi weekly, for an hour, two hours, schedule a couple day face-to-face?
Minutes:
Meet virtually to get started, in-person during/around annual conf.
9-12 Monday 14 Nov Clear Water Beach, FL AgGateway Annual Conf.
Tuesdays at 1:30 central for one hour starting Sept 6
Closing Topics
Expand | ||
---|---|---|
| ||
Matters arising
Tasks assigned during meeting
Meeting schedule
Adjournment
|