I want to calculate the monthly precipitation from the daily CHIRPS collection.
However, my band scale changes from 5565.97 m (0.05 Deg which is the original CHIRPS data resolution) to 111319.49 m (1 Deg) and I don't know why.
How can I calculate the monthly precipitation without changing the spatial resolution?
// Region of interest
var roi = ee.Geometry.Rectangle([26, -24, 29, -27]);
// A - CHIRPS
///Import CHIRPS rainfall data // Daily temporal resolution and 0.05 Deg/5.55 km spatial resolution
//Function for monthly sum over a period
var monthly_sum_CHIRPS = ee.List.sequence(0, 1*179).map(function(n){
var start3 = ee.Date('2002-01-01').advance(n,'month');
var end3 = start3.advance(1,'month');
return ee.ImageCollection('UCSB-CHG/CHIRPS/DAILY')
.filterBounds(roi)
.filterDate(start3,end3)
.map(function(image){return image.clip(roi)})
.sum()
.select('precipitation')
.set('system:time_start',start3.millis());
});
var collection_CHIRPS = ee.ImageCollection(monthly_sum_CHIRPS)
.select('precipitation');
// Get scale (in meters) information from band 1.
var Band_proj_CHIRPS = collection_CHIRPS.first().select('precipitation').projection().nominalScale();
print('Band scale CHIRPS:', Band_proj_CHIRPS);
Any insights will be greatly appreciated.
Regards,
Related
I am trying to distribute a number of points per acre within a square mile using Azure maps. Currently, I have been looking into the haversine formula, trig, basic division, etc, but believe I may be overthinking it.
Any ideas?
Lets say I want 3 points put per acre within a square mile in randomized but appropriate lat/lng locations within each acre.
Right now it seems I need to divide up the X and Y by feet or yard and then divide into the lat/lng to get appropriate locations.
A bit ignorant of lat/lng distances. The information I have found says that a degree of lat, for example, is worth about 69 miles. Then it divides it into "seconds," etc, apparently. A bit confusing.
Ideas?
A square with sides of 63.61 meters is equal to one acre. To calculate random points within that square, start off with a latitude and longitude coordinate for a corner, then calculate opposite corners coordinates, then calculate the latitude/longitude widths and use that to calculate random offsets from the starting coordinate. For example, take coordinate 45, -110 and assume this is the top left corner of the square. The opposite corner would have a heading of 135 degrees, and the distance to the corner would be sqrt(a^2 + b^2) = sqrt(63.61^2 + 63.61^2) = 89.9581247 meters. Here is code that would calculate three random points within that square acre.
var lat = 45;
var lon = -110;
var cornerDistance = 89.9581247;
var cornerHeading = 135;
//Bottom right corner.
var cornerPosition = atlas.math.getDestination([lat, lon], cornerHeading, cornerDistance);
var latWidth = lat - cornerPosition[1]; //Corner is lower.
var lonWidth = cornerPosition[0] - lon; //Corner is to the right.
var randomPositions = [];
for(var i=0;i<3;i++){
randomPositions.push(lon + Math.random()*lonWidth, lat - Math.random() * latWidth]);
}
The goal is to determine the start of growing season for rice in cold region annually (taking 2019 as an example) using the MODIS Terra temperature dataset, which is defined as the night temperature greater than 278.15 kelvin degree (5 celsius degree) for the first time. Thanks in advance for any hints.
// MODIS LST product
var LST = ee.ImageCollection("MODIS/006/MYD11A2")
.select("LST_Night_1km") // Night temperature in kelvin
.filterDate("2019", "2020");
The basic idea is :
turn image date to ee.Image masked with temperature mask.
get the minimum value in the stack of images of date.
var date2img = function(img){
img = ee.Image(img);
var date = img.date().getRelative('day', 'year'); // date in Day-of-Year format
var scaleFactor = 0.02 // the scale factor for the temperature band is 0.02
var mask = img.gt(278.15/scaleFactor ) // high temperature mask
return ee.Image(date).toFloat().updateMask(mask);
};
var start = LST.map(date2img).min(); // determine the first day of growing season
Let's say for example, that I have a few weather stations. Each station measures (e.g.) temperature and it's in different location.
Now I'm somewhere between those stations. I know their coordinates and I know my coordinates. How to estimate the temperature in my location?
One of simple methods - build some triangulation for weather stations
find triangle around your location, and use baricentric coordinates
to find weights for infuence of every station. Then estimate temperature as weighted combination:
T(P) = w * T(A) + u * T(B) + v * T(C)
Example of baricentric coordinates calculation
I am trying to find the area under a solar radiation intensity graph at a series of continuous time points.
Basically I want the integral of the past 24hours of solar radiation every hour over a 7 day period - a moving sum of the past 24 hours - (I suspect that temperature in the soil is a result of the past 24 hours of solar radiation)
Here is the code i am using, it works but I would like to automate it so I can change the time window of integration easily (try 12, 18, 24,36 hours ) and obtain a printed/saved table of hourly integrated solar radiation values that I may plot against my hourly temperature data to see if there is a relationship)
Here: Rg -solar radiation in 10min measurements
num - entry number in dataframe
AUC_xxx - Total solar radiation over the past 24 hours
y<-as.numeric(xx$Rg[xx$num["2015-09-13 14:10"]:xx$num["2015-09-14 14:00"]])
x<-c(1:length(y))
id <- order(x)
AUC_s14_14 <- sum(diff(x[id])*rollmean(y[id],2))
I tried with rollapply, but I'm stuck again:
rollapply(xx$Rg[xx$num["2015-09-13 00:10"]:xx$num["2015-09-14 00:00"]], width = 144, by = 6, FUN = **"INTEGRAL"**, na.rm = TRUE, align = "left")
Thanks for the help !
I'm trying to find a way to calculate the area of a polygon using lat long coordinates in a Flex 3 site. Hong007 on Google Maps for Flash group was cool enough to post the following function:
private function GetPolygonArea (polygon : Polygon):Number
{
var nVer : int = polygon.getOuterVertexCount();
var sz : Number =0;
var s : Number =0;
var x : Number =0;
var y0 : Number =0;
var y1 : Number =0;
var Maplatlng:LatLng;
if (nVer>=3){
for (var i:int=0; i<nVer; i++){
Maplatlng = polygon.getOuterVertex(i);
x = Maplatlng.lng();
if (i>0){
Maplatlng = polygon.getOuterVertex(i-1);
y0 = Maplatlng.lat();
}
else{
Maplatlng = polygon.getOuterVertex(nVer-1);
y0 = Maplatlng.lat();
};
if (i<(nVer-1)){
Maplatlng = polygon.getOuterVertex(i+1);
y1 = Maplatlng.lat();
}
else{
Maplatlng = polygon.getOuterVertex(0);
y1 = Maplatlng.lat();
};
s = x * (y0-y1);
sz+=s;
};
//경위도시 1도의 m값을 곱한다(대략 면적 환산)
Maplatlng = polygon.getOuterVertex(0);
var Maplatlng1:LatLng = new
com.google.maps.LatLng(Maplatlng.lat()+1, Maplatlng.lng()+1);
var TempDISTANCE:Number =
Maplatlng.distanceFrom(Maplatlng1) / Math.sqrt(2);
return Math.abs((sz/2.0) * Math.pow(TempDISTANCE, 2));
};
return 0.0;
}
I was also playing around with the area calculator at http://www.freemaptools.com/area-calculator.htm .
These functions produce slightly different results. I'm trying to figure out which one is more accurate. It seems that hong007's function produces results that are on average slightly larger than freemaptools' function. However, I don't know which one is more accurate. Any advice?
I added some string to this algorithm.
For google maps experimentally I found this numbers:
are = area-(area*0.2187);
and it works for me for maximum (scale = 5 meters) and minimum (500 km) zoom levels.
The method implemented here is pretty quick and dirty. It makes a couple of assumptions that can lead to incorrect results.
The first thing to know is that Lat/Long space is non-uniformly scaled with respect to measured distance on the ground. This means that a vector of length one meter has a different length in lat/long space depending on if the vector is pointing roughly east-west or north-south. Also, the magnitude of the difference between how the lat/long axes map to ground units changes depending on where you are on the globe (it's much more different at the poles than at the equator.)
The algorithm above does a very quick and dirty workaround for this, which is to generate a scale value based on the distance calculated for the hypotenuse of a unit right triangle. This tries to basically average the scales of the two lat/long axes for that point on the globe.
There are a couple of problems with this. If the polygon is very large (multiple geocells), then this average scale value will be off because it's only calculated for the local geocell around the 0 vertex. Secondly, the average scale approximation is really very coarse and will break down significantly if you have polygons that vary greatly in one dimension but not the other (a long skinny polygon oriented along one of the axes). This is because the scale will be computed as an average of the scale of the two axes but one of the axes should have very little influence because of the distribution of the vertices.
I didn't look at the other area calculator but I would guess if you're seeing discrepancies that this code is the less accurate version.