Add asset URL to GeoJSON export in Authoring Tool

[ianholmes]

Digimap Roam supports the import of datasets in GeoJSON format. However the GeoJSON that is exported from FtGB Authoring Tool does not comply with this standard and as a result the data is not displayed in Roam correctly. I believe images are the problem.

Please modify the Authoring Tool so that the GeoJSON exported from FtGB complies with the GeoJSON standard so that data captured in FtGB can be easily visualised in Digimap Roam.

[panterz]

Did you try to copy paste the result here: http://geojsonlint.com/

[panterz]

So a few comments on this: First of all I tried to do the same workflow by using a geojson that I created from another app (http://geojson.io/) and still I get the same behaviour on roam:

1. the point disappears when I click on it
2. cannot see the properties.

I put the same file on geojsonlint and seems to be OK. The same happens with the geojson that comes from FTGB.

My next move was to check the geojson that is produced from ROAM:

{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "properties": {
                "internal": false,
                "marker": true,
                "pointRadius": 12,
                "fontSize": "24px",
                "fontFamily": "Arial",
                "fontColor": "#000000",
                "fontWeight": "bold",
                "textBold": true,
                "textItalics": false,
                "textUnderlined": false,
                "strokeColor": "#000000",
                "strokeOpacity": 1,
                "strokeStyle": "solid",
                "strokeWidth": 2,
                "strokeLinecap": "round",
                "labelHaloColor": "#FFFFFF",
                "labelHaloWidth": 4,
                "labelAlign": "lb",
                "alignment": 8,
                "labelXOffset": 6,
                "labelYOffset": 12,
                "fillColor": "#FF6666",
                "fillOpacity": 1,
                "symbol": "markers.medium.balloon",
                "fcode": 1
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    322585.0462855,
                    666633.4146985
                ]
            },
            "id": "OpenLayers_Feature_Vector_766"
        },
        {
            "type": "Feature",
            "properties": {
                "internal": false,
                "marker": true,
                "pointRadius": 12,
                "fontSize": "24px",
                "fontFamily": "Arial",
                "fontColor": "#000000",
                "fontWeight": "bold",
                "textBold": true,
                "textItalics": false,
                "textUnderlined": false,
                "strokeColor": "#000000",
                "strokeOpacity": 1,
                "strokeStyle": "solid",
                "strokeWidth": 2,
                "strokeLinecap": "round",
                "labelHaloColor": "#FFFFFF",
                "labelHaloWidth": 4,
                "labelAlign": "lb",
                "alignment": 8,
                "labelXOffset": 6,
                "labelYOffset": 12,
                "fillColor": "#FF6666",
                "fillOpacity": 1,
                "symbol": "markers.medium.balloon",
                "fcode": 2
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    323645.0462855,
                    666173.4146985
                ]
            },
            "id": "OpenLayers_Feature_Vector_775"
        }
    ],
    "crs": {
        "type": "name",
        "properties": {
            "name": "EPSG:27700"
        }
    }
}

As you can see it's exporting the OL styling as part of the properties (marker, pointRadius, symbol etc) which means that any geojson that doesn't have these attributes won't be rendered as the geojson that comes from Digimap. I think Digimap should somehow handle external geojson files and give them some default attributes such as marker true, balloon symbol in order to render them as they expect to.

Now as far as concenred the images Roam needs to do some special treatment on FTGB exported geojson because geojson's properties don;t have any standards of how to associate images with each record, so they have to follow the way we decided on FTGB.

[gmh04]

So I think the task for this issue would be to change the val field of the image in properties to the URL of the image instead of the file name, e.g:

{
    "id": "fieldcontain-image-1",
    "val": "http://fieldtripgb.edina.ac.uk/1.3/pcapi/records/dropbox/<token>/<record>/myimage.jpg
},

Just to clarify, if digimap (or anyone else) wanted to display the image as a marker, then they would have to write some code to do it.

[ianholmes]

Having the full URL sounds sensible to me, but we'd need to do the same for anything else that can be part of the record: audio clips spring to mind, plus anything else that could be added.

[rgamez]

I think that including the token is not a good security practice, anyone could access the user dropbox with that token, maybe we should investigate binary encoding into the json and give the two options: geojson without assets and the geojson with the assets encoded into (if happens to be feasible).

[gmh04]

Yes perhaps, but that should also cover KML and other export formats - that are currently implemented and live. And when you say you can access dropbox with the token, it is actually only the FTGB app directory.

[rgamez]

yes, I know that it is limited to the FTGB directory but the fact that anyone could put any malicious file in my computer is not a nice thing. We could encode it as base64, github API uses something similar for encoding blobs as json: https://developer.github.com/v3/git/blobs/

[gmh04]

what about CSV?

[xmichael]

As there seems to be a wider discussion about this I though I should chip in. In general adding GeoJSON with links to a protected resources (dropbox) requires either:

1. roam to use oAuth and get explicit permission from the user to share his data. In any case the token must be kept secret (too many reasons to list here including terms of use)
2. us to use of a non-protected instance of the local provider (not dropbox)
3. the user to upload an already exported self-contained filetype (e.g. KMZ) that embeds all files in the KMZ.

There are plans to add KMZ with all media included in cobweb-eu/pcapi#28. This is currently low-priority but If there is demand by EDINA I could pump this up for next week.