Skip to content

Instantly share code, notes, and snippets.

View philvarner's full-sized avatar
💭
creating bugs

Phil Varner philvarner

💭
creating bugs
View GitHub Profile
Metadata:
Identification_Information:
Citation:
Citation_Information:
Originator: USDA-FSA-APFO Aerial Photography Field Office
Publication_Date: 20151125
Title: NAIP Digital Ortho Photo Image
Geospatial_Data_Presentation_Form: remote-sensing image
Publication_Information:
Publication_Place: Salt Lake City, Utah
@philvarner
philvarner / seeds.txt
Last active April 16, 2020 02:54
Phil's seeds
Greens
Lacinato (Dinosaur) Kale
Lacinato Rainbow Kale
Arugula (Roquette)
Rainbow (Five Color Silverbeet) Swiss Chard
Green Glaze Collards
Willam Alexander Heading Collards
Even'star Landrace Collards
Spring
{
"features": [
{
"assets": {
"B5": {
"eo:common_name": "nir",
"eo:name": "B5",
"title": "L1TP - Band 5 - Near Infrared (NIR) 0.851-0.879μm (30m)",
"href": "https://landsat-pds.s3.us-west-2.amazonaws.com/c1/L8/034/030/LC08_L1TP_034030_20190513_20190521_01_T1/LC08_L1TP_034030_20190513_20190521_01_T1_B5.TIF",
"eo:gsd": 30.0
@philvarner
philvarner / modis_extent.sh
Created September 25, 2018 17:24
Use the GeoSWAK docker container and GDAL tools to create shapefile for a raster reprojection from sinusoidal to WGS84/EPSG:4326
#!/bin/bash
# extract the band as geotiff from the HDF source
docker run -v $(pwd):/data s22s/geo-swak gdal_translate 'HDF4_EOS:EOS_GRID:"MCD43A4.A2018220.h19v02.006.2018233203810.hdf":MOD_Grid_BRDF:Nadir_Reflectance_Band2' B02.tif
# reproject the geotiff in WGS84/EPSG:4326 so we can manually compare it to the geojson
docker run -v $(pwd):/data s22s/geo-swak gdalwarp -s_srs '+proj=sinu +R=6371007.181 +nadgrids=@null +wktext' -r lanczos -t_srs '+proj=longlat +datum=WGS84 +no_defs' B02.tif B02-wgs84.tif
# extract the shapefile from the sinusoidal geotiff
docker run -v $(pwd):/data s22s/geo-swak gdaltindex -tileindex location B02-extent.shp B02.tif

Using Custom AWS IAM Roles and Policies for Execution

The default IAM policy created by Zappa for executing the Lambda is very permissive. It grants access to all actions for all resources for types CloudWatch, S3, Kinesis, SNS, SQS, DynamoDB, and Route53; lambda:InvokeFunction for all Lambda resources; Put to all X-Ray resources; and all Network Interface operations to all EC2 resources. While this allows most Lambdas to work correctly with no extra permissions, it is generally not an acceptable set of permissions for most continuous integration pipelines or production deployments. Instead, you will probably want to explicitly manage your IAM Policies.

There are three options for explicitly managing the IAM Policies: