Add worker functionality to create thumbnails

[phargogh]

This partially addresses #44 by adding a function to create a thumbnail of a parcel from its wkt and then rendering that as a PNG. I haven't yet included this in worker.py's do_work() because it sounds like we may need a separate job request for this? Let me know how you think we should hand this!

[dcdenu4]

Hey @phargogh, thanks for starting on this. I think there is only one use case for thumbnails at the moment, and that's when a user creates a pattern. So, you're right, currently the create_pattern endpoint just makes a DB entry and doesn't queue up any work. So, I propose the endpoint put work on the queue with the following payload:

    # Work to be added to queue
    worker_task = {
        "job_type": "pattern",
        "server_attrs": {
            "job_id": job_db.job_id, "pattern_id": pattern_db.pattern_id
        },
        "job_args": {
            "pattern_wkt": pattern_db.wkt,
            "lulc_source_url": os.path.join(WORKING_ENV,BASE_LULC)',
            }
        }

I also propose that the worker return results to: jobsqueue/pattern with the following structure:

    "result": {
        "pattern_thumbnail_path": "relative path to file location",
        "status": "success | failed",
        "server_attrs": {
            "job_id": int, "pattern_id": int
       }

My only question is if the frontend would want pattern statistics?

Would that be enough info to get do_work set up and included into this PR?

[davemfish]

My only question is if the frontend would want pattern statistics?

Hmm that might be a good idea, but not a requirement at the moment. The use-case for these thumbnails is 1) to show the user that something happened when they used the map to create a new pattern, and 2) to let the user select a pattern from a catalog (statistics might prove useful to people browsing the catalog, but we can wait and see).

[phargogh]

@dcdenu4 Rev 756f6b2 adds the thumbnail stuff to do_work() with mostly the same output schema as you requested, but I moved the status and server_attrs keys up a level for consistency with the rest of the worker functions:

    "result": {
        "pattern_thumbnail_path": "relative path to file location",
    },
    "status": "success | failed",
    "server_attrs": {
        "job_id": int, "pattern_id": int
    }

Does that sound right? The changes are up here in the PR, so feel free to take a look!