using gdalwarp to transform from wgs84 to EPSG:3857 does not cover world - gdal

i am using gdal 1.10 and 2.1.1.
i have a VRT datasource in WGS84 where i forced the corner coordinates to the min/max values of EPSG:3857 (-180,85.5,180,-85.5).
gdalinfo output for this VRT looks like this:
Size is 1296001, 601200
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,85.500000000000000)
Pixel Size = (0.000277777563443,-0.000284431137725)
Corner Coordinates:
Upper Left (-180.0000000, 85.5000000) (180d 0' 0.00"W, 85d30' 0.00"N)
Lower Left (-180.0000000, -85.5000000) (180d 0' 0.00"W, 85d30' 0.00"S)
Upper Right ( 180.0000000, 85.5000000) (180d 0' 0.00"E, 85d30' 0.00"N)
Lower Right ( 180.0000000, -85.5000000) (180d 0' 0.00"E, 85d30' 0.00"S)
Center ( 0.0000000, -0.0000000) ( 0d 0' 0.01"E, 0d 0' 0.00"S)
Band 1 Block=128x128 Type=Int16, ColorInterp=Gray
Basically, i have the world minus the poles.
Now i want to convert this to EPSG:3857.
I use gdalwarp for this, using bilinear interpolation:
./gdalwarp -of VRT -co TILED=YES -srcnodata 9999 -t_srs 'EPSG:3785' -multi wgs84.vrt wmerc.vrt -overwrite -r bilinear
running gdalinfo on wmerc then gives this:
Size is 995026, 1025175
Coordinate System is:
PROJCS["Popular Visualisation CRS / Mercator (deprecated)",
GEOGCS["Popular Visualisation CRS",
DATUM["Popular_Visualisation_Datum",
SPHEROID["Popular Visualisation Sphere",6378137,0,
AUTHORITY["EPSG","7059"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6055"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4055"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH],
EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=#null +wktext +no_defs"],
AUTHORITY["EPSG","3785"]]
Origin = (-20037508.342789247632027,20644642.363762538880110)
Pixel Size = (40.275313937642778,-40.275354414328227)
Corner Coordinates:
Upper Left (-20037508.343,20644642.364) (180d 0' 0.00"E, 85d28'11.27"N)
Lower Left (-20037508.343,-20644644.098) (180d 0' 0.00"E, 85d28'11.28"S)
Upper Right (20037476.183,20644642.364) (179d59'58.96"E, 85d28'11.27"N)
Lower Right (20037476.183,-20644644.098) (179d59'58.96"E, 85d28'11.28"S)
Center ( -16.0797308, -0.8670919) ( 0d 0' 0.52"W, 0d 0' 0.03"S)
Band 1 Block=512x128 Type=Int16, ColorInterp=Gray
NoData Value=9999
Note that the corner coordinates for upper/lower left look correct, but the corner coordinates for upper/lower right (the longitude) is missing is missing 32 units.
Broadly put, i am missing a sliver on the right side, but only in regards to the coordinates. The data is there, but the coordinates to the right seem wrong.
Why is that?
i could just modify the coordinates to match the world (longitudinal) using gdal_translate but i fear i am overlooking something else here which might just come back to bite me.


EPSG 3857 bounds latitudes to be between -85 and 80 degrees. It does this for two reasons:
It allows the entire earth to be square and be indexed by a quadtree where every node is a square.
The Mercator projection blows up at the poles; considering that most people who use maps aren't interested in them anyways, the projection kills two birds with one stone and discards them.

Related

Line Profile Diagonal

When you make a line profile of all x-values or all y-values the extraction from each pixel is clear. But when you take a line profile along a diagonal, how does DM choose which pixels to use in the one dimensional readout?

Not really a scripting question, but I'm rather certain that it uses bi-linear interpolation between the grid-points along the drawn line. (And if perpendicular integration is enabled, it does so in an integral.) It's the same interpolation you would get for a "rotate" image.
In fact, you can think of it as a rotate-image (bi-linearly interpolated) with a 'cut-out' afterwards, potentially summed/projected onto the new X-axis.
Here is an example
Assume we have a 5 x 4 image, which gives the grid as shown below.
I'm drawing top-left corners to indicate the coordinates system pixel convention used in DigitalMicrgraph, where
(x/y)=(0/0) is the top-left corner of the image
Now extract a LineProfile from (1/1) to (4/3). I have highlighted the pixels for those coordinates.
Note, that a Line drawn from the corners seems to be shifted by half-a-pixel from what feels 'natural', but that is the consequence of the top-left-corner convention. I think, this is why a LineProfile-Marker is shown shifted compared to f.e. LineAnnotations.
In general, this top-left corner convention makes schematics with 'pixels' seem counter-intuitive. It is easier to think of the image simply as grid with values in points at the given coordinates than as square pixels.
Now the maths.
The exact profile has a length of:
As we can only have profiles with integer channels, we actually extract a LineProfile of length = 4, i.e we round up.
The angle of the profile is given by the arc-tangent of dX and dY.
So to extract the profile, we 'rotate' the grid by that angle - done by bilinear interpolation - and then extract the profile as grid of size 4 x 1:
This means the 'values' in the profile are from the four points:
Which are each bi-linearly interpolated values from four closest points of the original image:
In case the LineProfile is averaged over a certain width W, you do the same thing but:
extract a 2D grid of size L x W centered symmetrically over the line.i.e. the grid is shifted by (W-1)/2 perpendicular to the profile direction.
sum the values along W

Transforming Robinson to EPSG:3857 with GDAL

I’m trying to convert a full globe Robinson Projection to Mercator. For example, I use this image.
First, I apply geo-tagging:
gdal_translate -a_ullr -180 90 180 -90 -a_srs ESRI:54030 source.jpg source_tagged.tif
and finally warp it to Mercator:
gdalwarp -t_srs ESRI:54030 -s_srs EPSG:3857 source_tagged.tif target.tif
The outcome is slightly stretched vertically but nowhere near proper Mercator. What am I doing wrong?

There are a couple of issues in your commands. The first is that -180 90 isn't in the top left corner pixel of global Robinson projection GeoTIFFs. The top left corner would be something like -338.2187147689 90, and the bottom right would be 338.2187147689 -90. However, you're also specifying your srs as ESRI:54030, so those bounds need to be in projected coordinates, not lat/lons. The command to generate a GeoTIFF from your image would be:
gdal_translate -a_ullr -17005833.3305252 8625154.47184994 17005833.3305252 -8625154.47184994 -a_srs ESRI:54030 source.jpg source_tagged.tif
Your second command has the -t_srs and -s_srs switched. Given that you're projecting to EPSG:3857, you'll also need to provide bounds since Mercator goes to infinity at the poles. So the updated command will look like:
gdalwarp -s_srs ESRI:54030 -t_srs EPSG:3857 -te -180 -81 180 81 -te_srs EPSG:4326 source_tagged.tif target.tif
I made the following projected image from your example using these commands (cropping the whitespace in the image prior to running them).

Can I move the axes of a ggplot to centre the data in R

I am plotting meteor observation data from a sky camera, sometimes using right ascension and declination for my x and y axes, at other times azimuth and elevation. The problem I have in both cases is with the x axis when my observations span the 360 degree mark. Sometimes I get a batch of observations on the left of my plot (near zero degrees, and a batch on the right hand side (near 360 degrees), with a big expanse of nothing in the middle. Is there any easy way I can change the x axis so that the 360/0 degree wrap over is in the centre of the plot? I would still want to show the true azimuth (or right ascension) in the axis labels.
PS. Pointing the camera elsewhere is not an option ]1
PPS So in the image shown the plots on the left hand side should be to the right of those on the right hand side with x axis from 250 (via 360/0) to 100.
PPPS So the second image shows what I am after - but I got to that by doctoring the data - as is obvious from the scale of the x axis in this plot

Relation between horizontal, vertical and diagonal Field-of-View

Is there a mathematical relation between those values? If I know hFOV and vFOV can I calculate the diagonal FOV without involving other values like focal lengths etc?
My first thought was to use Pythagorean theorem but maybe it's wrong.

The physical quantities of interest are the sensor size and the focal length. The latter, in the pinhole camera model, is the the distance between the camera center and the image plane. Therefore, if you denote with f the focal length (in mm), W and H respectively the image sensor width and height (in mm), and assume the focal axis is orthogonal to the image plane, by simple trigonometry it is:
FOV_Horizontal = 2 * atan(W/2/f) = 2 * atan2(W/2, f) radians
FOV_Vertical = 2 * atan(H/2/f) = 2 * atan2(H/2, f) radians
FOV_Diagonal = 2 * atan2(sqrt(W^2 + H^2)/2, f) radians
Note that, if you have the sensor size and horizontal or vertical fov's, you can solve one of the first two equations for f and plug it into the third one to get the diagonal fov.
When, as is usual, the focal length is estimated through camera calibration, and is expressed in pixels, the above expressions need some adapting.
Denote with K the 3x3 camera matrix, with the camera frame having its origin at the camera center (focal point), X axis oriented left-to-right, Y axis top-to-bottom and Z axis toward the scene. Let Wp and Hp respectively be the width and height of the image in pixels.
In the simplest case the focal axis is orthogonal to the image plane (K12 = 0), the pixels are square (K11 = K22), and the principal point is at the image center (K13 = Wp/2; K23 = Hp/2). Then the same equations as above apply, replacing W with Wp, H with Hp and f with K11.
A lil more complex is the case just as above, but with the principal point off-center. Then one simply adds the two sides of each FOV angle. So, for example:
FOV_Horizontal = atan2(Wp/2 - K13, K11) + atan2(Wp/2 + K13, K11)
If the pixels are not square the same expressions apply for FOV_vertical, but using K22 and Hp, etc. The diagonal is a tad trickier, since you need to "convert" the image height into the same units as the width. Use the "pixel aspect ratio" PAR=K22/K11 for this purpose, so that:
FOV_Diagonal = 2 * atan2(sqrt(Wp^2 + (Hp/PAR)^2) / 2, K11)

How to find the coordinates of point?

I have finite set of points in simple 2-dimensional Euclidean space ( I know coordinates of these points).
Let's say I pick point A(x1,y1) and B(x2,y2) in 2-dimensional Euclidean space. So I have a line AB. I need to find coordinates of such point C (actually I need to find if point C is in my set of points) , that length of AB = AC and lines AB and AC form right angle. (Actually two points should satisfy these conditions: on one side of the line AB and on other side)
This should be done in constant time.

You basically just want to rotate point B around point A by 90 degrees, right? If so, then first you translate A to the origin, then rotate, then translate back.
C = [-(y2-y1)+x1,x2-x1+y1]; // rotate +90 deg
C = [y2-y1+x1,-(x2-x1)+y1]; // rotate -90 deg