New answers tagged coordinate-system
0
did you manage to solve it? I have the same problem
1
I could reproduce your problem. You did not reproject your layer, you just assigned a new CRS to it. When you saved the temporary layer in EPSG 4326 from Quick-OSM to a geopackage, you did not set the CRS there, in the epxort dialogue. You thus saved (exported) the layer in 4326 and afterwards, you imported the layer and than set the CRS to 25833 - din't you?...
1
I would hazard a guess that the latitude is off by 1 degree, and the coordinates may refer to Williamstown Observatory, because using 37 instead of 38 degrees, the coordinates would be S37° 52' 6.6", E144° 54' 49.5", a mere 200 meters away from the Williamstown Timeball Tower (37°52′00.6″S 144°54′45.7″E) (seen on the right in the picture below). ...
0
The answers by @JGH and @Gabriel Bragion didn't work for me because abs() refused to parse "0,00" (because comma is not a valid separator for a floating point number)
Reordering helps (first abs() then format_number()), as done below:
format_number( abs(@grid_number) ,2)
|| ' °'
|| CASE
WHEN @grid_axis = 'x'
THEN
IF(@...
1
An Australian National Grid page says:
Prior to 1966, Australian maps used a transverse mercator projection,
in yards, with the Clarke 1858 ellipsoid. This was called the
Australian National Grid (ANG).
Where in the World… Geodetic Datum Mapping Issues suggests the same:
As an example, in Australia, there are 3 main datums in use: AGD66,
AGD84 and the ...
1
If I'm not mistaken, it's an issue with the way QGIS (since 3.10) report CRS info taken from GDAL 3.0.4. This issue on GitHub explains everything. What you can do is use this python script written by rouault to update the metadata of your GeoTIFF (it removes the TOWGS84 string that cause the problem). The bug has been patched in GDAL 3.1.0 and when QGIS will ...
0
How to add coordinates to attribute table
I was looking for an answer to the first part of the question as I just wanted to see the coordinates in QGIS. The information above helped me work out a solution so I am posting for other QGIS beginners. I am using Windows10 and QGIS 3.4
Open Layer Properties
Select Source Fields (initially only id existed)
Select ...
3
The .prj file normally conatins the CRS for a shapefile.
See here: https://desktop.arcgis.com/en/arcmap/10.3/manage-data/shapefiles/shapefile-file-extensions.htm
0
Store as 4326 as the data spans multiple zones. Convert to a suitable projection to make calculations.
3
The interval units should be set to map unit, i.e. in degrees.
I believe the CRS is not used unless map unit is selected.
2
I'm using [...] EPSG4326
there's your problem. This CRS is based on degree, so any distance/area calculations you do on this layer are done in degree, too.
Save your layer to a CRS based on meters, which fits your area of interest, then do the calculations.
2
The formulas you are using are for the spherical case. You will have to use the ellipsoidal formulas if you want your results to match PROJ and use the WGS84 parameters:
a = 6378137
b = 6356752.314245
e^2 = 1 - b^2 / a^2.
The ellipsoidal formulas are described at page 187 of Snyder's Map Projections Working Manual.
2
You can store it in EPSG:4326/EPSG:3857, you could have two geometry columns for example. Then cast to Geography from 4326 for distance calculations:
https://postgis.net/workshops/postgis-intro/geography.html
0
EPSG:4326 is built in. Note the order, its [x,y], so [lon,lat]
proj4.defs("EPSG:27700", "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +datum=OSGB36 +units=m +no_defs");
proj4('EPSG:27700','EPSG:4326').forward( [480069, 186342] ).reverse();
// [51.57027349352602, -0.8461130514492281]
...
0
After a lot of experimenting, I could not get QGIS 3.12 to output the degree values in a csv.
Quite desparete I downloaded QGIS 2.18 and, lo and behold, it worked. Set the display coordinates to degrees in the project properties and just copy/paste the attribute table to Excel worked like a charm.
3
changeset data from osm data for administrative municipality of porto shows min_lat="41.1383507" min_lon="-8.6912941" max_lat="41.1859353" max_lon="-8.5520090". the changeset bounding box covers the area shown in the relation.
0
I think the issue is that you are using projected coordinates, not geographic coordinates (even though you call them lat/lon in one example). The pyproj.Geod object needs geographic coordinates. So, you need the geographic equivalent for the points:
gdf_pt = gpd.GeoDataFrame(df, geometry=gpd.points_from_xy(df['x'], df['y']), crs=myepsg)
gdf_pt_geog = gdf_pt....
0
I'm not completely sure if you need to do the projection or if you just want to define the new CRS in the metadata (so my answer also includes the projection step but I guess you will be able to adapt it if you only need the metadata part) :
import rasterio as rio
from rasterio.warp import calculate_default_transform, reproject, Resampling
# The destination ...
4
With Pyproj 2.x, it's better to use the Transformer class, as below :
from pyproj import Transformer
transformer = Transformer.from_crs("epsg:3855", "epsg:4326")
print(
transformer.transform(34.68016909181368, 38.31245226053967, 100)
)
and the output is :
(34.68016909181368, 38.31245226053967, -100.0)
0
Looks like RT90 (2.5 gon V, epsg 3021) coordinates to me, possibly with inverse X/Y. Sweref99tm usually have 6 X digits. You need to set epsg 3021 in the import dialogoue when importing the table to QGIS. Then you can reproject it to Sweref after import.
1
Based on the input from @snowman2 I was able to find a solution:
trans = pyproj.transformer.Transformer.from_pipeline('+proj=pipeline +a=3396190 +b=3376200 +step +proj=geoc')
lon, lat = trans.transform(0, np.radians(45), errcheck=True)
np.degrees(lat) = #44.6617680466192
The inverse is then:
itrans = pyproj.transformer.Transformer.from_pipeline('+proj=...
-1
go to table of content
right click layers
go to coordinate system
the layer's coordinate system and shapefiles/csv coordinate system must be same
try it if it isn't working let me know
also check you have added data correctly while adding xy data
x(long)
y(lat)
thanks
3
I suspect that ArcMap is interpreting your coordinates as Meters, rather than Degrees. If you Identify one of the points you may see this reflected as such
The reason for this is beause the World Topographic Basemap comes in with a Coordinate System WGS_1984_Web_Mercator_Auxiliary_Sphere with a linear unit of meters - Linear Unit: Meter (1.0)
When you ...
0
You can use CRS.get_geod:
Here is an example:
from pyproj import CRS
crs = CRS.from_epsg(epsg_code)
geod = crs.get_geod()
2
It's this bit, is wrong it assigns the crs doesn't apply it by transforming the data:
projection(landcover) <- CRS("+init=epsg:32735")
you're expected to transform the raster i.e.
new <- raster(healthfac_point_projected)
res(new) <- c(150000, 150000) ## change resolution to suit, this is metres (the width,height of each cell)
landcoverutm ...
2
First, some previous considerations and decisions: Both systems are 2D. EPSG:28356 is a projected (Transverse Mercator method) one. About the local reference system we don't know its procedence, but we can think that it is just a local cartesian 2D system.
We have some options, but let me consider two:
One is transform the EPSG:28356 coordinates to ...
1
In the end what solved it was to add r before the name of the path
e.g :
r"this/is/my/path/image.tif"
2
I don't think you can do it with the proj4 library. I don't know if you can do it with pyproj.
What you must do is run projinfo command, that once installed is accessible from the command console. You will see how to implement it in Python.
Also take this answer just as a hint. The transformation is also needed in the export tool, and must be checked if ...
3
If you upgrade to QGIS 3.12, then you'll see the transformation details directly in the reproject algorithms and be able to manually pick a transform from there.
1
Found it! Just go to Layer Styling and adjust the offset, x or y.
2
Proj library has a copy of the contents of the EPSG database in the SQLite database "proj.db". That's the immediate source that QGIS is using. The ultimate source is EPSG database, for example
http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:coordinateOperation:EPSG::15948
reports the accuracy in section
<gml:coordinateOperationAccuracy&...
0
you can use this code to transform.
it works for me.
layCountries.CoordinateTransformation = fact.CreateFromCoordinateSystems(
shpLaye.CoordinateSystem ?? ProjNet.CoordinateSystems.GeographicCoordinateSystem.WGS84,
ProjNet.CoordinateSystems.ProjectedCoordinateSystem.WebMercator);
layCountries.ReverseCoordinateTransformation = ...
1
A message saying that QGIS does not have a suitable transform available (and is using a ballpark transform) indicates that there is a better transform available than that installed by the QGIS Standalone installer by default.
You can obtain updated grid shift files here (PROJ 7) or the updated legacy files (e.g., europe, north america, etc..)
PROJ 7.0 shift ...
2
Go back and repeat the load using EPSG:27582 or use ST_SetSRID to set the correct CRS - then use the ST_Transform function to convert them to be in EPSG:2154 if that is what you require.
UPDATE table SET geom = ST_Transform(ST_SetSRID(geom, 27582), 2154);
Though QGIS is quite capable of reprojecting on the fly for you once the correct SRID is set using just:...
0
If your question is regarding PostGIS functions:
the ST_Transform function is what you are looking for. Something like this should do the trick:
UPDATE table
SET geom = ST_Transform(geom, 2154)
On the other hand, if your question is refering to a QGIS operation. You can change the SRID of your layer or the whole project from its properties.
2
You were almost there.
There were 3 mistakes in your code:
reduceResolution() needs a coordinate reference system (crs) of the input image so that it understands the resolution of the input image (and thus can reduce that resolution). Generally this is done implicitly because each image has its own crs. However, when you take a mosaic the crs defaults to ...
0
It looks like your data files are coming from a program that has a different idea of the correct WKT definition of EPSG:27700 is than QGIS has. But this doesn't actually matter, QGIS seems to have still parsed it and used it to align your layers.
If you are really worried about this then use Set Layer CRS to set the layer to EPSG:27700 (this will not in any ...
1
So after discussion, the workaround here was to set the crs to a projected one, then scale everything up by 110,000 using GRASS's v.transform for all vector layers.
For the raster layer, it was re-georeferenced against a few reference points from the fresh vector layers.
1
Incidentally, "tilt" may be normal, depending on the coordinate reference system chosen for the projection, and how far from the center one looks.
All projections distort, and in fact, different projections are created to minimize distortion in the area of interest (while distorting areas further away more severely) or by spreading the distortion ...
0
You can use Virtual Layers e.g
from qgis.core import QgsVectorLayer, QgsProject
query = 'SELECT *, x(st_transform(geometry, 2154)) AS x_l93, y(st_transform(geometry, 2154)) AS y_l93, LongLatToDMS(x(geometry), y(geometry)) AS dms FROM "Your Layer name"'
vlayer = QgsVectorLayer( "?query={}".format(query), "vlayer", "virtual&...
1
Just an example to get you started. I have QGIS3, dont know if this will work in QGIS2:
lyr = iface.activeLayer() #Click layer in tree
gs = [f.geometry() for f in lyr.getFeatures()]
#From: https://gis.stackexchange.com/questions/163645/transforming-single-qgsgeometry-object-from-one-crs-to-another-using-pyqgis
sourceCrs = QgsCoordinateReferenceSystem(int(...
4
EPSG:4326 (WGS 1984, degrees of longitude and latitude) seems to be correct, as the deviations are very small. QGIS (and hence Proj) might have inaccurate transformation parameters for "EPSG 27700 1936 British National Grid" that could cause the effects that you are reporting.
But there could be other reasons - your positions may be inaccurate (...
0
This is a practical answer of sorts. I conclude a) that how layers finally appear do depend on the choice of project CRS, and that similarly named proj. coord. sys. do not necessarily give similar results, and b) that sometimes the obvious thing to do is precisely wrong.
I post three images. In the first two, the Project's CRS is 5070 (NAD83-Conus-Albers). ...
1
Is there a 'toggle' between displaying GCS and PCS in the main QGIS window?
When the map reference system is geographic, you can only see geographic coordinates. But when the map system is projected, you can see the geographic coordinates referring to the base geographic system from which the projection is made, instead of the projected plane coordinates.
...
1
Summary: changing (restoring?) ownership of QGIS3.ini file from root to current user causes changes to be saved. Immediately after the change of ownership, I ran QGIS and changed the default CRS settings and then exited and restarted; they were saved, and the QGIS3.ini file had an updated timestamp.
I did more research at qgis.org, and taking the advice ...
-1
Here's the answer. I was missing two seemingly innocuous but apparently critical steps; between steps 3 and 4, insert two lines and edit step 4 as a consequence.
Insert steps
3.1 Set VRT Layer CRS to 5070.
3.2 Zoom to that layer (merely to confirm it is rectilinear with the screen: not rotated)
4.[modif.] Export that CRS-modified layer as a Geopkg in EPSG:...
0
This is not a full answer but may help someone with the same issue.
I suceeded in testing my raster file on a different installation and the file loads successfully.
Problem appears to be something wrong with my installations of 3.10 and 3.12.
As I have a working version 3.4, I will not risk fixing the problem at the moment. The update to OSTN15NTv2 did not ...
0
This misalignment comes from differences in Earthwatch source imagery accuracy and orthorectification process. As a result there is approximately a +/- ~15 m difference in locations between the 2 bases for the 2018 and 2019 EarthWatch basemap imagery.
Worth noting if you are using this base to create geographic features you want to compare over the years - ...
0
Im suffering from the same problem. Tried to read in raster files with CRS set to EPSG:3067. Same message of ETRS89 datum being discarded arises.
One can add manually the information to the crs-string. I just do not believe that this actually fixes the problem.
#EXAMPLE OF ADDING DATUM INFO TO CRS STRING
library(raster)
file = raster("yourFilePath)
...
0
Your latitudes and longitudes are expressed in milliarcseconds. Divide them by 3,600,000 to get values in degrees:
Latitude : -106994676 / 3600000 = -29.7207433°
Longitude : 488026770 / 3600000 = 135.5629916°
Top 50 recent answers are included
