New answers tagged coordinate-system
0
This is more of a graphical comment/clarification than answer, but hopefully you can see that the NSDIC shapefiles are in EPSG:3413, and correctly align with another EPSG:3413 backdrop (from a WMS), so the NSDIC shapefiles aren't faulty.
Your track data is in degrees lat/long, but EPSG:3413 length units are metres, so you will need to either reproject your ...
6
Following on Ian Turton's comment... Prior to performing ANY geometry calculations or analysis on a layer(s), the layer(s) MUST be 1) projected to the desired CRS, and 2) that CRS must be the same for all layers. (Sidenote #1: in QGIS, projecting a layer to a different CRS is typically accomplished using Save As...)
Your analysis will always fail if the ...
1
The issue you are running into is a pyproj 1x issue.
I would recommend installing pyproj 2+. You can do this with conda using the conda-forge channel:
conda config --add channels conda-forge
conda config --add channels conda-forge
conda config --set channel_priority strict
conda create -n geo geopandas
conda activate geo
Or, you can install the latest ...
7
Reprojecting rasters is usually a bad thing to do. It involves a non-reversible transformation from one grid system to another grid system that can have a non-linear relationship to the first. Hence the value in a cell of the new system can end up being some average of whichever grid cells in the source raster it overlapped.
If you have a raster and points ...
1
Lambert equal-area projection
laea_centered <- "+proj=laea +lat_0=-70.30744 +lon_0=43.15268"
call me crazy, but don't you have the lat and long switched around?
0
Earth Centred Earth Fixed (ECEF) coordinates is a Cartesian system typically defined by the EPSG as:
Z axis corresponding with the earth’s rotation axis positive northwards, the X axis through the intersection of the prime meridian and equator, and the Y axis through the intersection of the equator with longitude 90°E.
In ECEF coordinates therefore there ...
6
Custom crs are stored is a sqlite database table tbl_srs. The database itself is under your profile path and the file is called qgis.db. So, it should be safe to delete the rows of the table. To do that, close QGIS, make a copy of that db-file (if something goes wrong...), and open qgis.db in a sqlite-database sql-monitor, like spatialite-gui or ...
1
The issue you are running into is a pyproj 1x issue.
I would recommend installing pyproj 2+. You can do this with conda using the conda-forge channel:
conda config --add channels conda-forge
conda config --add channels conda-forge
conda config --set channel_priority strict
conda create -n geo geopandas
conda activate geo
Or, you can install the latest ...
1
Simple solution using the 'sf' package
library(sf)
library(ggplot2)
library(mapview)
library(lwgeom)
library(rnaturalearth)
# world data
world <- rnaturalearth::ne_countries(scale = 'small', returnclass = 'sf')
# Fix polygons so they don't get cut in ortho projection
world <- st_cast(world, 'MULTILINESTRING') %>%
st_cast('LINESTRING', do_split=...
0
If you don't want to have to change the CRS, just tick Ignore Axis Orientation in the WMS properties and it will be displayed correctly (see screenshot below, overlapping with 3857 OSM background)
0
They are certainly not the same. WGS is a datum(for lat/loong specifations) while EPSG is a database of CRS and related information. Those who think these are same actually ignore the basic purpose of EPSG. The main purpose of EPSG is to assign a code for Geodetic Parameter Dataset that contains a repository of parameters needed to define a CRS. This ensures ...
2
You are assuming several things that are not correct, but the biggest is in the calculation of what parallel segments should be. Think of the triangle you are drawing between two points that are located on the same parallel and the center of the sphere, move those points to the north. Their longitudes remain the same, but the drawn triangle is increasingly ...
3
It depends on your localization
Take a look at this site: https://epsg.io/?q=India
4
I just figured it out. You can't go passing ingdf.crs formatted dicts or their contents into rasterio metadata. It won't work. You actually have to build up a rasterio crs object so it will recognize it:
import numpy as np
import rasterio
from rasterio.warp import calculate_default_transform, reproject, Resampling
import geopandas
src_file = 'output/out....
0
You need to do a datum transformation, using the parameters below:
Tx = 175.787m
Ty = 121.804m
Tz = -242.608m
scale = -6.046ppm
Rx = 17.281 seconds
Ry = 12.235 seconds
Rz = 10.664 seconds
That lines up the coordinates correctly.
2
I downloaded the glc_shv10_DOM.Tif and get very different gdalinfo output with Origin = (-180.000000000000000,90.000000001440014) and Pixel Size = (0.008333333333400,-0.008333333333400). You appear to have stripped the georeferencing out of the tif somehow or possibly an issue with your GDAL install.
If you just want to tile internally and specify the CRS, ...
0
As of 2019, you can do the following in ArcGIS Pro:
Right click on map, select Properties to open the Map Properties
module.
Select Coordinate Systems Look to the right for a globe icon
with a green plus sign, select to access "Add Coordinate System"
Select New Projected Coordinate System to bring up the following dialog box.
In the Name row, change the ...
8
As you found, EUREF-FIN is a realization of ETRS89 in Finland.
Some countries, when displaying coordinates or transmitting data, use the convention northing, easting order while other countries use easting, northing order. Most GIS software wants easting, northing so the EPSG registry (http://www.epsg-registry.org NOT epsg.io) often has both versions ...
6
I can't answer why they would flip N/E but if I had got data (e.g. OSM) in WGS84 and wanted to projected it in ArcMap into EUREF_FIN_TM35FIN (WKID: 3067) then I would have set the transformation as shown below. According to this ESRI documentation the transformation has a WKID of 108227.
Not sure my answer helps?
0
As documented on ESRI support website, the EPSG (acronym from European Petroleum Survey Group) codes in general correspond to WKID (well-known ID).
Majority of coordinate systems using by ESRI comes from the EPSG library, they are noted as Authority: EPSG. Some systems however come outside from EPSG library and as identification use WKID. Therefore, the ...
6
Step 1. Defining unknown CRS
I would suggest double-checking if suddenly there is a prj-file, placed in the shapefile location.
If not, you can try using projfinder. For instance, when one tried it with provided coordinates (3465878, 5482952)
There are two options:
EPSG:31467 Name:DHDN / 3-degree Gauss-Kruger zone 3, as was mentioned by @MrXsquared
EPSG:...
2
I am pretty sure this is GK3 (EPSG:31467).
Go to layer properties --> Source and set source CRS to EPSG:31467
Then do the transformation (Export as...) to WGS84.
If everything is located perfectly, you are good to go. (If not, I was wrong about the CRS...)
1
If you do really mean that the 0-degree axis points North, the 90-degree axis points East and the Z-axis points vertically up, then is called a Left-Handed Coordinate System. Strictly speaking, however, you really have to be willing to relabel your "X" and "Y" axes the other way around, where "X" is North and "Y" is East.
In this image, from wiki/Right-...
2
In the output, I expect the "y" parts of the two coordinates are the same, because these two points are on the central line of projected
coordinates. However, they are not (14191389.18 != 3987778.87).
Your expected result is only true in the "unrectified" uv plane. Some academicians view the Hotine Oblique Mercator to be a triple-projector, i.e., (1) from ...
1
I imagine that you are working with spherical trigonometry, and that you already have the formulas for the length of the flight and for the initial azimuth, and the way in which the azimuth varies at each point of the trip.
You need to calculate the maximum latitude reached, which is the one in which the azimuth of the flight is 90º. Being as you're ...
0
If you have longitude, latitude and ellipsoidal height, you have coordinates over an ellipsoid (the WGS84 ellipsoid in your case) and related to a coordinates frame (the WSG84 geodesic frame in your case). Imagine that, a single ellipsoid among all possible, with its center, axes (ellipsoid axes) and origin of coordinates (center meridian) positioned and ...
0
The answer I arrived at is
EPSG:6933
There might be others, but this appears to be appropriate for area computation for any arbitrary polygon on the earth, except for near the poles.
0
The ellipsoidal height does not affect the latitude longitude. so only extracting xy from xyz should be fine.
3
You actually have two questions and answers here.
The input coordinate system uses a conformal map projection, transverse Mercator / Gauss-Krüger. Conformal projections maintain local shapes and angles, not areas. It's using DHDN as the earth model. That's an older system that is definitely offset compared to a more recent geographic coordinate reference ...
1
EPSG:3857 uses the Mercator projection and the latitude and longitude lines are straight and form rectangles. Both a grid using projected coordinates and a graticule using latitude-longitude values (EPSG:4326) will be rectangular.
Here's an image of EPSG:3857 with a 10° by 10° degree graticule superimposed on it. A grid of the projected units would be ...
1
You can find the Proj.4 string with gdalsrsinfo utility. You may need GDAL version 3.x. I used GDAL 3.1.0dev
gdalsrsinfo "PROJCS["Conica_Equivalente_de_Albers_Brasil", GEOGCS["GCS_SIRGAS2000", DATUM["D_SIRGAS2000", SPHEROID["Geodetic_Reference_System_of_1980",6378137,298.2572221009113]], PRIMEM["Greenwich",0], UNIT["Degree"...
1
Don't change the CRS of the Open Street Map layer.
Return the CRS of the layer to the original CRS that it came with (which was probably EPSG:3857). If you don't remember for sure, remove the layer and re-add it the same way you added it the first time.
Change the CRS of the Project.
Click on the project CRS in the bottom-right corner of the window. ...
0
Indeed, you have objects with different projection strings.
> identicalCRS(shape, point.rep)
[1] FALSE
Inspecting them makes it clearer:
> shape@proj4string
CRS arguments:
+proj=utm +zone=22 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0
> point.rep@proj4string
CRS arguments:
+init=epsg:32722 +proj=utm +zone=22 +south +datum=WGS84 +...
1
The likely scenario is that you require a world file for the tif data.
This is an ascii text file with the same filename as the source tif but with a tfw extension, and contains the georeferencing for the data. i.e. you will have:
rastername.tif, and
rastername.tfw
If you know the raster georeference details you can create this yourself. There are 6 ...
0
Try re-projecting the Aerial Images to Coordinate system "New York Long Island State Plane 3104". Make sure all the data added to Data Frame should be in same Datum.
0
I know this wasn't requested, but for those of us working on the web, I've transformed the equation to JS too.
// Convert NZTM2000 to Latitude Longitude
function convert(X, Y) {
var a = 6378137;
var f = 1 / 298.257222101;
var phizero = 0;
var lambdazero = 173;
var Nzero = 10000000;
var Ezero = 1600000;
var kzero = 0.9996;
var N = Y;
...
1
According to the GeoJSON specification https://tools.ietf.org/html/rfc7946#page-7 the coordinates should be in order lon lat. Your data seems to have order lat lon.
1
This is actually three map projections. For example, Hawaii has been magnified and Alaska has been greatly reduced in size.
So you cannot do this in the main map display, but you can produce maps for printout that look this by using the Composer and creating 3 inset maps.
The Composer is essentially a Layout Manager intended to make final images, posters, ...
0
There are many easily identifiable points, so I suggest to use georeferencing tools. It is available in qgis. https://www.qgistutorials.com/en/docs/advanced_georeferencing.html
1
If I understand correctly, the pixel coordinates of the small images are referring to the main image. And I assume you know Python.
I would start by rotating the main image to be perpendicular to axis and then apply the same rotation to the other images. Then, using the coordinates of the upper left corner and resolution (pixel size), set up the ...
4
You can check the coordinate transformation pipeline with the gdaltransform utility https://gdal.org/programs/gdaltransform.html#gdaltransform starting from GDAL version 3.0 that is using new Proj library version 6 or higher.
Example
gdaltransform -s_srs epsg:3078 -t_srs epsg:4326 --debug on
10 30
OGRCT: Selecting transformation +proj=pipeline +step +inv ...
4
According to spatial reference.org, EPSG:3078 is a Hotine Oblique Mercator projection.
The equations for converting between (E,N) and (lat,lon) using a Hotine Oblique Mercator projection may be found in the EPSG Geomatics Guidance Note 7 part 2.
1
The problem you are having is the projection information has no .crs() method so a null value is being provided to the crs argument in the reprojection function. If you print the projection of ref_image you see it actually has a WKT property, after fiddling around it seems like .wkt() is what you would want to use to get the CRS information from your ...
0
I created a simple custom map on Google Maps that illustrates the estimation algorithm mentioned by the accepted answer (1/111111 == one meter). Feel free to see and play with it here:
https://drive.google.com/open?id=1XWlZ8BM00PIZ4qk43DieoJjcXjK4z7xe&usp=sharing
0
Following up on the answer of @Russel at ICS. Today I rewrote his code to convert wgs84 (epsg:4326) coordinates to wgs84/pseudo mercator (epsg:3857) in R:
vertex = list(x_coordinate, y_coordinate)
smRadius = 6378136.98
smRange = smRadius * pi * 2.0
smLonToX = smRange / 360.0
smRadiansOverDegrees = pi / 180.0
vertex[[1]] = vertex[[1]] *smLonToX
y = vertex[[...
Top 50 recent answers are included
