You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Feedback products for individual collectors are really important, since they confirm that the data is being collected correctly, and that the user produced something useful. These don’t have to be terribly sophisticated: a simple PDF would do; but they do need to be automated.
Consider, therefore, a container that had an installation of GMT, with the PyGMT extensions so that the Tools/geojson2jpeg.sh can be run in Python instead, given a list of the GeoJSONs to process (and reading the GeoJSON directly from the S3 bucket, rather than converting it to an XYZ file). The output could be a JPEG or PDF, etc., and should be cached somewhere so that the user can receive it as a processing result at some point.
Details of how to get the product out efficiently may vary. One option would be to stash the resulting object in an S3 bucket with a UUID, and then send the URI to the user for download. Another option would be to have the result streamed back to the user as the result of a web-page hit on a cloud-based server (as the interface for volunteer collectors, or as part of the command and control interface for the TN, with the TN then sending the result back to the volunteer by conventional local methods).
Bonus points for the background layer being a tile data service like Open Street Map rather than the GEBCO grid (which is very low resolution on the order of the data). Bonus points of allowing the service to specify wildcards, e.g., “all data from observer X in the last month” or “all data currently in store for observer X” or “all data in the last month, for all observers”, and so on, with the code reading the metadata service to further information on which files these imply.
The text was updated successfully, but these errors were encountered:
Original report by Brian Calder (Bitbucket: brian_r_calder, ).
Feedback products for individual collectors are really important, since they confirm that the data is being collected correctly, and that the user produced something useful. These don’t have to be terribly sophisticated: a simple PDF would do; but they do need to be automated.
Consider, therefore, a container that had an installation of GMT, with the PyGMT extensions so that the Tools/geojson2jpeg.sh can be run in Python instead, given a list of the GeoJSONs to process (and reading the GeoJSON directly from the S3 bucket, rather than converting it to an XYZ file). The output could be a JPEG or PDF, etc., and should be cached somewhere so that the user can receive it as a processing result at some point.
Details of how to get the product out efficiently may vary. One option would be to stash the resulting object in an S3 bucket with a UUID, and then send the URI to the user for download. Another option would be to have the result streamed back to the user as the result of a web-page hit on a cloud-based server (as the interface for volunteer collectors, or as part of the command and control interface for the TN, with the TN then sending the result back to the volunteer by conventional local methods).
Bonus points for the background layer being a tile data service like Open Street Map rather than the GEBCO grid (which is very low resolution on the order of the data). Bonus points of allowing the service to specify wildcards, e.g., “all data from observer X in the last month” or “all data currently in store for observer X” or “all data in the last month, for all observers”, and so on, with the code reading the metadata service to further information on which files these imply.
The text was updated successfully, but these errors were encountered: