New answers tagged coordinate-system
0
You'll see different offsets depending on the coordinate reference system. The north-south 200 m offset is classic when working in UTM and comparing comparing coordinates based on NAD27 versus NAD83. Part of the issue is the different ellipsoid sizes and shapes between Clarke 1866 (used for NAD27) and GRS80 (used for NAD83). The mathematics of the transverse ...
3
OK, thanks to ycartwhelen I found the answer in the section 5.9 of this document. Indeed, the codes are unique for each type. From the document:
In the EPSG Dataset codes are assigned to CRSs, coordinate
transformations, and their component entities (datums, projections,
etc.).
Within each entity type, every record has a unique code. Whilst
...
1
The EPSG dataset describes coordinate reference systems (CRS), each of which are inherently affiliated with a datum.
You might find the answers to this question useful, in particular Dan S.'s answer.
This document published by the same organization in charge of EPSG goes into more depth. Specifically you might find sections 4.2 and 5.1 helpful.
4
Here's one way to find a similar CRS to the one used for an existing map. Since your map has lat/long lines, you can make a GIS project with the same lines into different CRS's until you find one where the lines are curved and angled the same as in the image.
Create lat/long lines:
Use the grid tool to make a lat/long grid for this area (longitudes 23 E ...
3
Python would be so slow at this, I would use C++. Read your XYZ file using a normal ifstream then use strtok to break apart the single line into tokens and make the string tokens into double.
You will need to find the local WGS UTM coordinate reference system and project your origin to this CRS (sorry the OGR API is offline at the moment). From here you can ...
1
Additional information would be useful here. How do you know the coordinate system is unknown? Is there any info in the metadata?
If there is no coordinate system projection assigned to the file, you can define one. Sometimes people forget to do this (sometimes it's just wrong). Your goal is to guess the correct projection. Make a copy of the file and use ...
1
This is an old questtion but I got here trying to find a solution to a similar problem so I'll share my solutions:
I have two solutions for this problem.
Option 1: add SRID to the table
One is adding an srid to the table that is missing one, or removing the srid from the one that has an srid. Basically make sure the SRID of the two tables match.
Option ...
2
After months later I found a solution. You should add two lines before and end of the script which is from @Domokos Endre:
import os
iface.mainWindow().blockSignals(True)
layer = QgsVectorLayer(path, "My Layer", "ogr")
crs = layer.crs()
crs.createFromId(32637) # Whatever CRS you want
layer.setCrs(crs)
QgsProject.instance().addMapLayer(layer)
iface....
4
Method 1: Add a reprojector before the coordinate extractor to convert the points from the source coordinate system into LL84. The points will then be in latitude/longitude.
Note that following the coordinateExtractor the X attribute will hold longitude and the Y attribute will hold latitude.
This method assumes the GDB has the current map projection for ...
0
A very though answer from Joseph clarifying how QGiS makes measurements However, the question is now clearer to me and it is:
How can I place the shape of defined dimensions (in metres, 5000m X 2000m) measured on the WGS84 ellipsoid at a location on the ellipsoid (51 degrees N 2 degrees W)?
1
Try defining the output extent in the coordinate system you are reprojecting the raster to. You can reproject your extent using the following code:
# Code for QQIS 3.xx - QgsCoordinateTransform is different in v 2.xx #
crsSrc = QgsCoordinateReferenceSystem(rlayer.crs())
crsDest = QgsCoordinateReferenceSystem(4326) #epsg of target crs
xform = ...
2
You can create a new feature class and use a data access insert cursor, projecting each Geometry with projectAs.
Sample code; update with correct values for spatial reference, geometry type, etc.:
mergeFcs = ["fc1", "fc2"] #merge feature classes
outFc = "out_feature_class"
#---
import arcpy
outPath, outName = os.path.split (outFc)
arcpy....
0
I just solved a similar problem, trying to import several geocoded JPEGs with lon/lat-Values from exif-header to qgis.
I parsed the exif-headers and created world-files and prj-files for every image with epsg 4326, f. e.:
0.000001
0
0
-0.000001
6.3252777777778
50.677222222222
Importing my 5312 x 2988 pixel image to qgis an measuring with srid 25832 the ...
0
I tesselated it again and added some areas, you could select, but it really is difficult to select a useful sector:
2
QGIS 3 uses ellipsoid length calculations by default whereas in previous versions, this was ignored and instead planimetric distance calculations were used. If you measure the lines using the expression:
length($geometry)
You should get the values you were looking for (5000m and 2000m):
Before you use your code, set your project ellipsoid measurement to ...
1
You need to use Query.setCoordinateSystemReproject(CRS) not Query.setCoordinateSystem(CRS). One changes the output coordinates and the other tells the system what CRS the coordinates of any geometries in the query are in.
This code fetches the boundary of Pennsylvania in EPSG:2272.
public static void main(String[] args)
throws IOException, ...
0
You actually need to change this on the resource level:
layer=cat.get_layer("layer_name")
resource=layer.resource
resource.projection='EPSG:4326'
cat.save(resource)
cat.save(layer)
cat.reload()
0
I would recommend upgrading to pyproj 2.2.0 as it should take into account the datum shifts.
https://pyproj4.github.io/pyproj/v2.2.0rel/examples.html
>>> import pyproj
>>> pyproj.__version__
'2.2.0'
>>> pyproj.CRS("EPSG:27700")
<Projected CRS: EPSG:27700>
Name: OSGB 1936 / British National Grid
Axis Info [cartesian]:
- E[...
0
The only difference between what my map's url and the url from the GeoServer's openlayers preview is that the SRS parameter is different.
A WMS GetMap request needs a bounding box specified in the SRS of the request, if all you change is the SRS code in the request to get a map, then you almost certainly have an issue with the bounding box (bbox).
1
That rotation is being handled by the client so the server has no idea of the rotation angle.
For example - https://www.add.scar.org/ogc/60/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&LAYERS=add%3Aantarctic_facilities&STYLES=add%3Aantarctic_comnap_facilities_2018&CRS=EPSG%3A3031&SRS=EPSG%...
0
Here is a C# port of LINZ free nztm.zip download for anyone that's interested. I have tried to stick as close as possible to the original code by using the unsafe flag to handle memory pointers in original C code. You will need to enable -unsafe flag on c# compiler.
Program.cs
using System;
using System.Threading;
namespace NZGD_to_WGS84
{
unsafe ...
1
pyproj 2.2.0 can solve this:
>>> import pyproj
>>> pyproj.__version__
'2.2.0'
>>> transformer = pyproj.Transformer.from_crs("esri:102001", "epsg:4326")
>>> transformer.transform((-5171461.906673405, 3372679.8809247203), (209275.49942131247, 5395930.584568907))
((22.775277555142978, 62.48292643585552), (-145.4797312671488, ...
1
As Fran Fraga said, you probably have a typo in your layer definition. The reference system is set using
“?crs=epsg:3879” and not “?crs:epsg=3879”.
Change the syntax and try again, it should solve your problem.
1
The data has coordinates in both geographical and projected CRS.
EPSG:4326 / LONGITUDE, LATITUDE
ESRI:102671 EPSG:3435 / X COORDINATE, Y COORDINATE
You have chosen LONGITUDE and LATITUDE as input, then just select EPSG:4326.
Try;
tif_data <- read.csv("~/Documents/code/ChicagoPackage/data/TifProjects.csv")
tif_data <- tif_data[!is.na(tif_data$...
5
From the screenshot, it's clear that this is a projection issue. The layers all have sufficient detail, that their misalignment cannot be due to low resolution. Also, they are offset by varying amounts in different places. So, to fix this issue we have to figure out the cause of the projection issue. Here are the various things to check:
If using a version ...
1
If you don't get any geographic/datum transformations, that usually means we couldn't recognize either the input or output geographic coordinate reference system. The geographic/datum transformations contain the input/output geographic coordinate reference systems.
While a person can tell it's WGS 1984 being used by Web Mercator or that the state plane zone ...
0
When help from pauldendulk, here is a working code to transform layers.
Store the supported WKT as string constants.
Create a dictionaries of ICoordinateTransformations using GetFromLatLong(WKT) and GetToLatLong(WKT).
Create a second set of dictionaries of Func generated from
GenerateToLatLong(string constant for WKT) and GenerateFromLatLong(string ...
3
QGIS has two different area functions. One respects the project settings, while the other uses the layer's spatial reference system. To see identical results to the GeoPandas area calculation, use area($geometry) of the $area.
$area
The area calculated by this function respects both the current project's ellipsoid setting and area unit settings. For ...
4
Change your QGIS map projection to match your custom CRS:
Then re-compute your areas and you should get
I am not sure why this matters, but clearly QGIS gets some information for computing area from the canvas's CRS (which seems dumb). One way to avoid this is to re-project and save your shapefile, so when you pull it into a fresh map canvas it will ...
3
The SpatialReference object which can be accessed using Describe has the name property:
import arcpy
arcpy.env.workspace = r'X:\somefolderwithrasters'
rasters = arcpy.ListRasters()
for r in rasters:
spatref = arcpy.Describe(r).spatialReference
print 'Raster: {0} has spatial reference: {1}'.format(r, spatref.name)
Example output:
Raster: s1milj....
3
Looking at your image you are accessing the geodatabase from within MS Access? That is a real no-no! You can easily (if you have not already done it) corrupt the database.
You must only interact with a personal geodatabase from within ArcMap to ensure data integrity. You create personal geodatabases from within Arcmap, you cannot simply convert an existing ...
3
You're specifying the function instead of calling it. I.e.
layer1.extent
should be:
layer1.extent()
Do this with width and height:
calc = QgsRasterCalculator(exp,
output,
'GTiff',
layer1.extent(),
QgsCoordinateReferenceSystem("EPSG:3003"),
...
2
The accuracy values listed refer to the specified datum/coordinate transformation, not to the projection itself (the page you link to lists other transformations with differing accuracy). It's nothing to do with whether a certain projection is distance, shape or area preserving.
From the EPSG Registry:
Accuracy
Estimate(s) of the impact of this ...
0
NCAT contains several countrywide transformation files between NAD83 (1986) and HARN because it's using NADCON5 files. The files in ArcGIS are the older NADCON files which were built for individual states or a small group of states.
NCAT/NADCON5 also differentiates between different HARN re-adjustments that were done in the various states. The older ...
2
I think this issue is coming from the projection setting the CONUS 2016 NLCD data has. As you have described in your post, it has +datum=WGS84, however, the Proj4 textstring of NAD83 / Conus Albers; EPSG:5070 has +ellps=GRS80.
QGIS is following this definition and created a new custom projection, as it did not recognize the CRS.
You can fix it in two ...
2
As commented by @MichaelStimson the way to do this is by using the batch grid:
Right click on the Define Projection tool and select 'batch' then drag
and drop your PNG files from ArcCatalog or Explorer into the tool,
define the CRS you want to give in the first row then right click and
select 'fill' and all others will be populated.
For more ...
8
Some software will use great circle arcs to connect unprojected vertices (sometimes when using a special data type, like PostGIS geography), while projected (or unprojected using the geometry datatype) vertices are connected using straight lines.
This can result in a point being inside a polygon expressed as geography but outside of it if expressed as ...
2
Yes. projections will never reproject a point that was inside a polygon in one projection to be outside it in another--unless there's some sort of precision error. I'm not sure what this property is called in geography, but I just realized it's essentially relativistic invariance, which basically says that as time dilates for us, and our coordinate systems ...
-2
my thoughts are it's in the ax=themap extents, my take is the calculation of projection coordinates seems to fall outside the ax extents, given the diff lat/long coordinates. I used a your code and plugged the lat/long in directly and the ax extents were out of bounds. Using -90/0 coordinates gave:
...:Failed to determine the required bounds in ...
3
Using NUTS-3 centroids with the Near (Analysis) tool, the geodetic distance between the Shetland Islands and Jersey was calculated to be 1191878.03 meters.
Using a Euclidean distance after projecting to British National Grid (with the default datum transformation), those two points are 1191362.07 meters apart (a delta of 515.96 meters, or 0.043 percent).
...
0
I don't know if it's possible to edit a CRS to use mm as unit.
Anyway if your data are point one way would be adding X and Y field (there is a calculate geometry tool for that), exporting the data to table then dividing the X and Y field by 1000 to convert to meter.
You could then use the updated table and display the XY data.
If your data are line or ...
1
I made a tesselation of your image.
1
Everest_Bangladesh is Kalianpur 1937
Transformation to wgs84 is
Kalianpur 1937 to WGS 84 (1)
https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:coordinateOperation:EPSG::1155
X-axis translation 282 metre
Y-axis translation 726 metre
Z-axis translation 254 metre
COORDINATEOPERATION["Kalianpur 1937 to WGS 84 (1)",
SOURCECRS[
GEODCRS["Kalianpur ...
1
Nepal_Nagarkot is Nepal 1981
Transformation to wgs84 is
Nepal 1981 to WGS 84 (1)
https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:coordinateOperation:EPSG::6208
X-axis translation 293.17 metre
Y-axis translation 726.18 metre
Z-axis translation 245.36 metre
COORDINATEOPERATION["Nepal 1981 to WGS 84 (1)",
SOURCECRS[
GEODCRS["Nepal 1981",
...
1
TLDR: They're not the same. The reported equality is the result of
approximations and is only true in limited circumstances. GDA94/2020
co-ordinates are defined on different datums and reference frames. The
appropriate transformation between them depends on the level of accuracy
desired.
The issue here is the assumption in the question that proj.4 ...
2
Andrea Aime answered it in the geoserver-users list, which I quote here for the records:
the syntax looks like a WKT2 representation, which GeoServer is not
able to parse (code contributions or funding to get it going more than
welcomed). I believe you'll have to rewrite it using WKT compatible
sytanx instead (I'm not aware of an automatic ...
2
Finally I was able to make the transformation correctly. Thanks to @mkennedy for the answer because that code was useful for the WKT 3857 but I also needed to change the WKT 25831.
I post the strings I have finally used to make the transformation correctly in case someone wants to use it:
string wkt25831 = "PROJCS[\"ETRS89 / UTM zone 31N\",GEOGCS[\"ETRS89\"...
0
Importing the file you shared:
add points
edit the table, selecting for example the easting filed
enter the formula format_number($x,0)
Update all
Exit edit mode, thus saving
The files retains the updated coordinates.
However, since you mention that "co-ordinates are accurately recorded" I guess you originally had a virtual field.
Just to make sure, I ...
Top 50 recent answers are included
