This is perfectly normal behaviour in a transverse Mercator projection. The fact that a specific northing does not match a specific latitude (except for the Equator itself) can be easily visualized.
We are used to seeing global maps of the more familiar equatorial-aspect (or normal) Mercator projection, which depicts parallels and meridians as perfectly ...
Also you can try using projfinder. For instance, when one paste provided coordinates (4581211.88, 5811848.94)
You will see several options. Then you may assume the CRS, which is mostlikely the "EPSG:31468 | DHDN / 3-degree Gauss-Kruger zone 4".
But in your case I will simply follow what @Erik explained.
And then answering your another question &...
It says right there in your column title "GK4" - which is for Gauss-Krüger Zone 4 (https://epsg.io/31468).
Another hint is the leading 4 on the X-coordinates.
An last but not least you should know where the data should be situated and thus reduce the CRS-options.
You can't determine the projection of a set of points just from the coordinates. Without some other information they are just random numbers. Go back to the data supplier and make them give you some metadata.
If you know where the points are supposed to be then it may be possible to guess which projection they are in.
For pyproj you should be mindful of axis order changes.
If you want it to always be in the lon, lat order, you should specify it when creating the transformer.
from pyproj import Transformer
transformer = Transformer.from_crs(..., ..., always_xy=True)
Otherwise, you should inspect the axis order of your CRS as shown in the getting started ...
You are mixing and matching two distinct projections which why they don't match. You need to do something like this:
>>> import pyproj
>>> x = -20509.2462745155
>>> y = -125891.862952247
>>> lon, lat = p(x, y, inverse=True)
>>> nx, ny = p(lon, ...
In the Universal Transverse Mercator system, most of the parameters are implied and fixed. utm does not have a x_0 parameter, so the PROJ library ignores it.
You have to use the more generic Transverse Mercator projection, write out all the implied parameters, and then change those:
+proj=tmerc +datum=WGS84 +lon_0=-75 +k_0=0.9996 +x_0=500000 +y_0=0
For the latitudes and longitudes, you can divide the numbers by 11930465 (2^32 / 360) to get values in decimal degrees. The values seem to be stored in a signed 32-bit integer range, to represent the full range of geographic coordinate values possible.
Here is a link to a related question: Convert Garmin or iPhone weird GPS Coordinates
The difference is that reproject changes the geometry coordinates.
Let me start with a Point layer, with one feature, wich geometry is a point located in latitude = 1°, longitude = 2°.
The geometry WKT is POINT ( 1 2 ) and the layer is defined with CRS EPSG:4326.
And I have a custom projected CRS which map those coordinates to x = 2000m, y = 1000m. ...
UTM zones are 6 degree bands, see figure https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system - and then the EPSG code is 32600+x where x is the band number. e.g. New York is between 72W and 78W so that's zone 18, North, so use EPSG code 32618: https://epsg.io/32618
There are some exceptions where UTM zones get split and tweaked in ...
I had a similar problem:
rasterio.errors.CRSError: Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
After much testing and an error I arrived at the root of my problem: GDAL was installed through Anaconda while rasterio through pip
The solution: uninstall rasterio ...
When you import the CSV files with latitude and longitude in them - I'm assuming that means values like 51,2 (or other "small" values) - you commit the cardinal sin of lying to QGis about their projection. QGis is very trusting and believes you when you say these values are in metres measured from some distant origin. Thus you get incorrectly placed data (...
Those two coordinate systems are quite similar. The difference is on the 'False Easting'.
This means that if a point coordinates in the EPSG 25832 are X, Y (X for east coordinate and Y for north coordinate), the coordinates of this point in the EPSG 5652 are X + 32,000,000, Y.
The idea behind this is to be able to recognize coordinates based on their value. ...
QGIS uses gdal_rasterize command to convert vector to raster. It cannot reproject between spatial reference systems (SRS). So your first step has no effect. Your third step uses gdal_translate to change output format which cannot reproject to target SRS, too. Your steps should be:
Vector to raster conversion of the layer (it keeps the source SRS) into ...
You can calculate the UTM Grid of a point using the expression:
zone_number = math.floor(((longitude + 180) / 6) % 60) + 1
and then look at the latitude to decide if it's north or south.
So, all you need to do is apply that formula to each corner of the polygon's bounding box and you'll be able to calculate the entire range covered.
One quick way would be to choose North Pole Azimuthal Equidistant (EPSG:102016), but it may not return satisfying result if your study area is not close enough to the north pole.
Second option: Create custom projection by modifying the above mentioned EPSG:102016. For instance, if your central position is located at (latitude: 86, longitude: 135), then the ...
If you use the last version of Geopandas:
Starting with GeoPandas 0.7, the .crs attribute of a GeoSeries or GeoDataFrame stores the CRS information as a pyproj.CRS, and no longer as a proj4 string or dict.
Therefore your crs is not correct
crs = "EPSG:32651"
crs = "+proj=utm +zone=51 +ellps=WGS84 +datum=WGS84 +units=m +no_defs"
crs = '...
Updating the code to
// very approximate calculation of projection extent
var worldExtent = [bbox, bbox, bbox, bbox];
var extent = applyTransform(worldExtent, fromLonLat);
will prevent the errors https://codesandbox.io/s/reprojection-by-codegraticule-5ujx2
The graticule ...
I found a Python Library called utm 0.5.0.
The conversion.py module in that library seems to do the trick.
I've modified the code by removing the reference to numpy and the custom OutOfRangeError library.
import math as mathlib
__all__ = ['to_latlon', 'from_latlon']
K0 = 0.9996
E = 0.00669438
E2 = E * E
E3 = E2 * E
E_P2 = E / (1.0 - E)
SQRT_E = ...
I agree with everything @FSimardGIS commented:
The UTM grid north does not match True North except on the central
meridian and Equator. There can be a difference of a few degrees.
(This is called Grid Convergence) Moreover, UTM being a Projected
Coordinate System, you will have distance distortions if you use those
coordinates (although quite ...