You're on the right lines. The what3words grid is algorithmically generated to be nearly exactly 3m by 3m to within a couple of centimetres at latitudes between -85º and +85º. Between +/- 85º north and south and the poles, the notional grid squares expand the closer to the poles you get and at their largest extent are ~4.5m by ~4.5m with some deformation at ...
There are a variety of ways to navigate across oceans without the aid of maps and in particular the Mercator Projection. It is worth noting that before the invention of the chronometer (calculation of longitude) in 1764 there wasn't a reliable way of measuring longitude when out-of-sight of land.
Most of the history I have read includes the Mediterranean ...
To add a column to an existing table, use the ALTER TABLE DDL, e.g.:
ALTER TABLE my_table
ADD COLUMN the_geom_mercator
which can be populated from another column (the_geom) using:
UPDATE my_table SET
the_geom_mercator = ST_Transform(the_geom, 3857)
WHERE ST_SRID(the_geom) = srid;
(the third line FROM ...
You are absolutely correct.
From wikipedia's Mercator projection: scale factor = secant (latitude) = 1 / cosine (latitude)
Generally, divide map distance by the scale factor to get globe distance.
But what about "long" lines, at different latitudes, what scale factor to use?
According to EF Burkholder, for
short lines, just calculate one scale factor
Firstly, crop the image source (coords are expressed in pixels here) with:
gdal_translate -srcwin 115 18 1360 2156 2104.gif 2104_cropped.tif
Then, transform the known WGS84 coordinates of the upper left and lower right corners to the "WGS 84 / World Mercator" projection (EPSG:3395):
cs2cs +init=epsg:4326 +to +init=epsg:3395
By definition, the scale is the amount by which (infinitesimal) distances are multiplied by the projection. Whenever a tiny displacement of d meters on the earth is associated with a displacement of d/s meters on the map, the scale is written as 1:s. It may depend on the direction of the displacement.
The scale factor compares the scale at ...
As a first step, you could look at the distortions of the Mercator projection, which is a conformal projection. Distance with this projection is only correct along the equator, then the error increase with the latitude. Indeed, as you can see on a global view, the parallels keep the same legnth on the maps. For example, the horizontal scale factor, which is ...
Simple answer? They didn't really.
Their routes are mostly coast-hopping. When they left the known coasts (i.e. crossing non-contiguous continents), they really hadn't a clue where they were. Latitude was OK with a star chart, but longitude was impossible until the chronometer was invented. Dead reckoning runs out of accuracy pretty quickly, and fails ...
Projected coordinate systems always have metres or feet as units. CRS with degrees are called Geographic coordinate systems. Pseudo-Mercator does not belong to them.
The only thing you can have in QGIS are degree grids over your Pseudo-Mercator map:
How to display both scalebar in kilometers and grid in lat/long degrees in Quantum GIS 1.8 Composer?
For the Mercator projection, the extent can not reach North and South pole for mathematical reasons.
The standard Google and Openstreetmap mercator projection is limited to 85.011° North and South to get a square map.
See http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames#X_and_Y for explanation.
Using EPSG:3857, the extent of a map is -20037508,-...
The Polynesians observed and learned a star catalog of declination and right ascension--This allowed them to ( a ) identify and name a navigation course, ( b ) transmit it orally to another navigator, ( c ) follow such a course.
My understanding is that they learned "chains"--a chain is a sequence of stars that rise at approximately ...
You have to be sure whether the coordinates are in degree-minute-second or decimal degrees.
From the sample you gave, it is not easily detectable.
If you need decimal degrees, you have to calculate degrees + minutes / 60 + seconds / 3600.
This can be done easy with any spreadsheeet calculation.
Here is your test point, once taken as decimal degrees, and ...
I'll try, but I've never used D3. I do know projections and the state plane system very well. Let's look at a full definition of EPSG::26729.
PROJCS["NAD27 / Alabama East",
Thanks to your good description I guessed that the projection that Hummingbird is using is "WGS 84 / World Mercator" which has EPSG-code EPSG:3395. More information about this projection:
Web Mercator is rarely the right answer, unless you want pictures that line up with other stuff in Web Mercator.
An extract from the NGA's Implementation Practice Web Mercator Map Projection, which is worth a read in full:
5.2 The Web Mercator map projection has several defining mathematical formulas and parameters that make data referenced to Web ...
Set lon_0 to the middle of your study area.
k can be set to 0.9996 (as UTM has).
lat_0, x_0 and y_0 have no effect on the quality of the projection. They are usually set to the equator and/or the inverse of the lower left point so that all coordinates are positive.
A similar question was asked before: Is it possible to have another CRS in the status bar than used for the map? and the asker finally wrote this piece of code:
But I got stuck with it sometimes on startup.
You might be better of with the new QuickMapServices plugin, which can deal with different projections far ...
You can study the error by making SQL queries with Spatialite-gui which has a function ST_Length with a description at https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html
return the length of c (measured in meters). If the use_ellipsoid
argument is set to TRUE the precise (but slower) length will be
computed on the Ellipsoid, otherwise will ...
Your polygons (Russia, Aleutians) are crossing the antimeridian (-180W/E) and R isn't able to break them. You need to open the shapefile in QGIS or other GIS and edit the polygons so they break at +/-180.
It sounds like there may be a misunderstanding of the difference between defining a dataset's projection and reprojecting the data itself. This ESRI blog post does a pretty good job of explaining the difference, and this QGIS documentation explains the underlying concepts.
In short, every dataset has a CRS—a way of defining what it's coordinates mean. Some ...
This is not the best system architecture, because it requires some dirty reprojections, but I suggest...
Reproject the file using ogr2ogr, forcing the input and output SRSs
ogr2ogr is my go-to projection swiss-army knife, and can handle weird reprojections and manually force SRS/CRS/geoid changes. It's part of the GDAL utilities, and readily available in ...
Even if you find historical maps that use a cylindrical projection, or even Mercator projection, they're not going to overlay without further work. Even in the Mercator case, the datums or projection parameters will be different.
You can try to georeference the historical map to reference data that's in a coordinate system as close as possible to the one ...
But it does--it's just implicitly defined. Instead, a standard parallel (+/-) is used to make the cylinder secant. For the transverse case, there's no easily defined line (you can't use a meridian), so a scale factor at the central meridian is used instead.
I've written tiny programs to go between the two variants.
At some point, we'll add the scale-...
I believe you need a minimum of 3 points to translate, scale, and rotate.
The procedure and open source code for doing this is explained here: http://docs.opencv.org/doc/tutorials/imgproc/imgtrans/warp_affine/warp_affine.html
I'm assuming your images are not georeferenced, so it should not matter what your map projection is since the user only has to ...
It depends on the extent of your area of interest.
Transverse mercator is conformal along the central meridian, while Mercator (in its original form) is conformal along the center latitude. That does not have to be the aequator.
So if your area is mostly north-south orientated, tmerc is better, if it is more east-west, merc is better.
Transverse is ...
If you have data from the poles, avoid EPSG:3857, because that is undefined at the poles. Reprojection might fail, and the rest of the data might get lost.
Try EPSG:4326 instead. To get the full picture, include the target extent (for the Arctic region):
gdalwarp -t_srs EPSG:4326 -te -180 -90 180 90 northpsg.20141027 output.tif
and you will get your ice (...