New Record format

[panterz]

In the future, we will need to support other geometries than points. Instead of trying to figure out our own polyline or polygon format it's better to follow the standards format and convert the internal record format from json to geojson.

[benismobile]

query: should we use name for the record name attribute. According to GeoJSON spec we should use "id"

"If a feature has a commonly used identifier, that identifier should be included as a member of the feature object with the name "id"."

[benismobile]

regarding the "dichotomous" editor issue (had to look up "dichotomous") do we have an example of how this would work. Would a graph / node syntax between fields be an option?

[panterz]

I paid attention to the examples where no id was there. I noticed that there is a reference to the id. Yes, we could replace name with id. I am not sure of how we could integrate the work with the geofencing. We could add the trackid to be part of the properties object of geojson.

As far as concerned the dichotomous editor(decision tree) I thought of making it by adding a new control on the Authoring Tool. For the November release (COBWEB release) I am going to add a feature on the AT to parse an existing json that I need to make from a list of questions I've got to a linked questions that will be loaded on the phone by making a new plugin that has to do with decision tree questions. That's for the near future. For the long run ideally, we would have an interactive interface where the user could construct these questions and link them with each other.

[benismobile]

So the "id" attribute is optional so its fine not to have one at all. However, my reading of the spec is that if you are going to use an identifier for the feature then you should use "id", rather than something else.

Happy with plan of adding other features within the properties. Would be good I think if we could find a way to make the fields array a child of an editor node (also should we change "editor" to "form"?). So perhaps have editor head with name and fields as children?

So with the dichotomous editor I guess the complexity should be in the editor (form) - can we adapt the existing html5 forms to handle this?

[panterz]

Basically, the idea of the dichotomous question is that we will have a new control added on the existing controls (text, textarea) and this will open a new window/get you on a new page where users will drag radio elements and will connect each answer with a new question if exists one. The result will be a json object that will connect answers with questions and then a plugin will be written on FTOpen that it would render the json object to a form and save the answer to the record.properties.fields object.

By changing the terminology from editor to form makes it a bit clearer to a new developer/user of what's that. I wouldn't recommend having this structure : [] as part of the properties because in the future if we decide to extend the properties object and add another item that will be : Array then how the PCAPI would know which of these two items is the editor(form)?

[benismobile]

not quite sure what "control" would look like in the editor / form? think it is important that structures like trees and pagination are encoded in the editor/form , not the record. The record would just reference elements in the editor/form as is currently the case.

So the structure I was thinking about was something like:

"properties": {
    "editor": {
        "name": "<editor>",
        "fields": [
            {
                "id": "<id>",
                "label": "<label>",
                "val": "<value>"
            }
        ]
    },
    "author": "benb",
    "group":"benb",
    "permissions":"rw",
    "geofences": [],
    "trackref": "#"
}

[gmh04]

I think the above structure creates too strong a relationship between the editor and record. To access a record field value you access a property called 'editor' (or myrecord.properties.editor.fields[0].val). We think about this relationship with the editor because we see records visualised in the authoring tool, but how are users going to use the records? Now if the answer is only through the authoring tool then fair enough, but if users wanted to use the records in some other bespoke way then I would go for:

"properties": {
    "fields": [
        {
            "id": "<id>",
            "label": "<label>",
            "val": "<value>"
        },
        ...
    ],
    "editor": <editor>, # or perhaps "form"
    ...
}

[benismobile]

well I'm certainly aiming for a format that is independent of any specific implementation such as authoring tool. But you ask the question yourself, how are users going to use records? There is a restricted view and more general answer to this. The restricted view is that the format we are developing is part of the PC API specification and so what users are going to do with records is implement or consume a PC-API isntance. A more general answer is to look at the kinds of thing the PC-API does and generalize requirements from this. Overall we are in business of designing a system for geo spatial data capture (as opposed to consumption of geo spatial data which is what most POI formats (gazeteers etc) focus on. Derive from that and we can expect users will want to do the following with with records.

1. organize, visualize and collate records spatially ( same as POIs - geoJSON handles this for us with its geometry property)
2. organize, visualize and collate records by creation date.
3. organize, visualize and collate records by author, owner or tool used to created records.
4. organize, visualize and collate records by asset types. (image, audio etc).
5. covert records into other common standard formats. (csv, kml etc)
6. use a tool such as authoring tool and FtGB to design forms thereby create records in this format.
7. design their own applications with forms to create records in this format.
8. categorize records into them into semantic types ( so a simple property/value format might say "species":"redwing") but users will surely require some way of relating this information to the context in which data was created. (i.e. we are doing a survey of butterflies). This is where link to editor is important as it is currently the only way to provide context to the property value (we could instead link to an ontology).

so 8 above is the hardest requirement to solve I think - if we lose link between generated data and the context in which it was created we have a problem. ( we don't know what other species were considered). We also need link to editor for 4 and 5.

So another way of thinking about this is whether is desirable to have a record without a link to an editor - i.e. editor is optional. Well we need to link to or embed within the record information that would assist a user in requirements 4,5 and 8 above first? What I found when looking at this before is that I ended up inventing something quite similar to HTML5 forms (i.e. this property is an image, this property is a text field, this property came from a list of options). But I'm not precious about this so open to suggestions. Or perhaps people disagree with scope of requirements above.

[panterz]

From requirements aspect I'd like to introduce some new terms/concepts that overlap with records grouping. In COBWEB, geocat is building a new module in GEONETWORK called community module where there are different types of users (project coordinator-PC, simple user) and projects, surveys and sessions. The idea is that:

• The PC is creating a new project where it can create multiple surveys (editors in the AT) and can link them to a group of simple users by sending an invitation to them.
• Then the user need to download the items of this survey which might be (backdrop images, vectors, existing points and the survey).
• The PC might have the option to decide when he/she prepares the form if the records should be published, so we might need to add a new control on the AT for this kind of work.
• Then there is also the concept of the session which is actually an instance of the survey. There are going to be cases where the PC might organize different sessions of the surveys in different times or/and places. So you might have to use the same survey (form) in different cases where you might need different layers (backdrop images, vectors etc), check image below.

Considering all these above it might be wise to change the folder structure of the how things are going to be saved:

<project name>
 |_records
 |_editors
 |_tiles
 |_help

or better like htis:

<project>
       |_records
               |_record1/
                       |_record.json
                       |_image1.jpg
       |_editors
               |_edtitor1/
                       |_test.edtr
                       |_session1.json
                       |_session2.json
                       |_warning.txt
                       |_instructions.html
                       |_image1.jpg
       |_layers
               |_session1
                       |_tile1.db
                       |_tile2.db
                       |_polygon.json

[panterz]

Some commits for this issue are under this: cobweb-eu/fieldtrip-cobweb#3

[panterz]

On COBWEB for valdation purposes we might need some extra sensor data on as part of the properties of the geojson such as:

"properties": {
    "editor": "<editor>",
     "fields": [
            {
                "id": "<id>",
                "label": "<label>",
                "val": "<value>"
            }
     ],
    "pos_sat": "",
    "pos_acc": "",
    "pos_tech": "",
    "dev_os": "",
    "cam_hoz": "",
    "cam_vert": "",
    "timestamp": "",
    "comp_bar": "",
     "tilt": "",
     "temp": "",
     "press": ""
}

where:

id -----> Record ID pos_sat -----> Number of satelites pos_acc -----> Size of halo pos_tech -----> Type of technology (WI-FI, GPS, Cell tower) dev_os -----> Device/OS type cam_hoz -----> Horizontal field of view angle can wrap these as camera geometry cam_vert -----> Vertical field of view angle comp_bar -----> Compass tilt ------> Tiltt temp -------> Temperature sensor press -------> Barometer

[benismobile]

I'd suggest taking a look at some existing standards describing sensors and observations. Otherwise just going to be slammed for re-inventing the wheel. Could be there is a place for JSON encoding, although i think the OGC IoT used JSON already. Some of properties above seem a bit specific to a particular application or device spec. Perhaps better simply to record device model or link to linked data set describing model capabilities. Don't forget my own discussion paper on sensed web !:) http://www.perey.com/ARStandards/%5BButchart%5DSensed_World_Web_AR_Standards.pdf

On Tue, Sep 2, 2014 at 2:51 PM, Panos Terzis notifications@github.com wrote:

On COBWEB for valdation purposes we might need some extra sensor data on as part of the properties of the geojson such as:

"properties": { "editor": { "name": "", "fields": [ { "id": "", "label": "", "val": "" } ] }, "pos_sat": "", "pos_acc": "", "pos_tech": "", "dev_os": "", "cam_hoz": "", "cam_vert": "", "timestamp": "", "comp_bar": "", "tilt": "", "temp": "", "press": "" }

where:

id -----> Record ID pos_sat -----> Number of satelites pos_acc -----> Size of halo pos_tech -----> Type of technology (WI-FI, GPS, Cell tower) dev_os -----> Device/OS type cam_hoz -----> Horizontal field of view angle can wrap these as camera geometry cam_vert -----> Vertical field of view angle comp_bar -----> Compass tilt ------> Tiltt temp -------> Temperature sensor press -------> Barometer

— Reply to this email directly or view it on GitHub https://github.com/edina/fieldtrip-gb/issues/26#issuecomment-54153825.

[panterz]

I am a bit confused now, so how would you suggest to capture the data above?

[benismobile]

Kind of depends if its just one off or a scheme you think will be used for lots of different purposes. Seems to me something like pressure measurement could be a complex observation to capture, but maybe I'm anticipating uses that won't arise. On 2 Sep 2014 17:27, "Panos Terzis" notifications@github.com wrote:

I am a bit confused now, so how would you suggest to capture the data above?

— Reply to this email directly or view it on GitHub https://github.com/edina/fieldtrip-gb/issues/26#issuecomment-54178727.

[benismobile]

if helpful? - here's a few links to stuff I've come across:

MPEG-V http://wg11.sc29.org/mpeg-v/?page_id=519

SWEET proejct http://sweet.jpl.nasa.gov/ontology/property.owl

OGC Sensor Things Data Model http://ogc-iot.github.io/ogc-iot-api/datamodel.html

OGC Sensor ML https://portal.opengeospatial.org/files/?artifact_id=55939

On Tue, Sep 2, 2014 at 5:56 PM, Benjamin Butchart b.butchart@gmail.com wrote:

Kind of depends if its just one off or a scheme you think will be used for lots of different purposes. Seems to me something like pressure measurement could be a complex observation to capture, but maybe I'm anticipating uses that won't arise. On 2 Sep 2014 17:27, "Panos Terzis" notifications@github.com wrote:

I am a bit confused now, so how would you suggest to capture the data above?

— Reply to this email directly or view it on GitHub https://github.com/edina/fieldtrip-gb/issues/26#issuecomment-54178727.