New answers tagged coordinate-system
0
I would recommend looking into the area of use for each of the CRS you are using in this example.
For the two options you have suggested for the input CRS, the bounds (min_lon, min_lat, max_lon, max_lat) are (113.76, 22.13, 114.51, 22.58).
>>> from pyproj import CRS
>>> CRS("ESRI:102140")
<Projected CRS: ESRI:102140>
Name: ...
1
Currently it does not seem to be supported in PROJ. With the latest version, I used the projinfo command:
$ projinfo -s "WGS84" -t "epsg:5819"
Candidate operations found: 1
-------------------------------------
Operation n°1:
unknown id, Inverse of Null geographic offset from WGS 84 to WGS 84 + EPSG topocentric example A, 0 m, World
PROJ string:
Error ...
-1
LINZ has an online converter on their website.
0
I found the source of this issue. Sometimes the image units in AutoCAD would show up a "inches" so the scale would be wrong. It looks like some of my drawings had the units set to Unitless. I found that by making sure the drawing units were correct listed as Inches, and I set the drawing units to metres, the image would come in correctly.
2
A quick search with ProjFinder reveals that your coordinate reference system might be one of these :
EPSG:3835 Name:Pulkovo 1942(83) / Gauss-Kruger zone 3
EPSG:3333 Name:Pulkovo 1942(58) / Gauss-Kruger zone 3
Which correspond to a point located just south of Ludwigsfelde, near 52°15'58.7"N, 13°15'41.3"E:
Without more information, it is hard to tell which ...
1
Problem solved: It worked fine with cubic convolution and bilinear interpolation with ArcMap 10.6. Thx for the tip!
0
I would use this one ( https://epsg.io/102003):
Look for this in QGIS: USA_Contiguous_Albers_Equal_Area_Conic
According to this link: http://www.hydroterre.psu.edu/HydroTerre/Help/FAQ/FAQ_Projection.aspx , it is the same.
Or: https://spatialreference.org/ref/sr-org/usa_contiguous_albers_equal_area_conic_usgs_version-2/
0
Try something like:
readandproject = function(filenames){
lapply(filenames, function(filename){
r = raster(filename)
crs(r) = "+init=epsg:4326" # fix broken CRS
r = projectRaster(r, crs="+proj=robin +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs")
return(r)
}
)
}
Then prasters = readandproject(c("file1.nc","file2.nc")) ...
0
I ran into this problem and eventually realized that the gdal version I had in my build.gradle file (v3.0.0) was newer than and apparently incompatible with the gdal version installed on my computer (v2.4.2). I changed the version number in build.gradle to 2.4.2 and it worked.
0
I faced the exact same problem and eventually managed to get it to work, see the answer here: https://gis.stackexchange.com/questions/288245/no-common-crs-between-two-wms-service/288470?noredirect=1#=
I have not invested time to find out exactly where the issue was originating as I needed to move forward, but these were quite the frustrating few weeks.
0
I do not know how to project many raster files but I figured a method in ArcGIS Pro.
First, find the tool "Project Raster" in the Geoprocessing and then right-click this tool. You will find "Batch" when you right-click the tool. Choose this "Batch" and then you will find the Batch Project Raster, you can choose many raster files in the "Input Raster" and ...
3
First import the data in the CSV it's actually in. Once the data is imported, then you can reproject it into the desired CRS.
The coordinates in your CSV are in latitude and longitude. This means they're actually in a geographic coordinate system. The standard/most commonly used geographic CRS is EPSG:4326.
Here's how your workflow should go (with the same ...
6
Reproject your data:
load your text file with EPSG:4326 as CRS
Right click on that layer and choose "Export --> Save features as..."
Choose the CRS you want your data to be in (WGS 84 58S)
Save it (choose a file format you like)
Add this new file to your project
0
In R you can use rotate function
library(raster)
library(gdalUtils)
workdir <- "Your workind dir"
setwd(workdir)
ncfname <- "adaptor.mars.internal-1563580591.3629887-31353-13-1b665d79-17ad-44a4-90ec-12c7e371994d.nc"
# get the variables you want
dname <- c("v10","u10")
# open using raster
datasetName <-dname[1]
r <- raster(ncfname, ...
4
Just a wild guess, to me it looks similar to a Lambert azimuthal equal-area projection, rotated 80 degrees (I mean, looking from N80E toward N100W direction).
(Above: North Pole area by QGIS 3.8 on EPSG:102017 North_Pole_Lambert_Azimuthal_Equal_Area, rotating 80.0 degrees).
3
As @Vince already stated in comments, Web Mercator is not suitable for this.
Reproject your layers (Save as...) to a local metric one. Regarding epsg.io this could be UTM Zone 54N (EPSG:3095) for example.
0
As commented by @mkennedy a guess might be:
north pole-centered stereographic with a central meridian/longitude of origin around -20
Otherwise I think you will be best to try and contact the author(s) of the maps.
3
Neither +proj=igh or +proj=goode are currently supported by proj4.js but mproj does support +proj=goode Demo here https://jsfiddle.net/3bjo7rsL/ and the code below. Error catching is needed to handle "off the world" transforms at the edges.
<!DOCTYPE html>
<html>
<head>
<link href="https://cdn.rawgit.com/openlayers/openlayers.github....
0
I tried this string in pyproj:
Proj(proj='lcc', R=6371200, lat_1=25, lat_2=25,lon_0=-95, ellps='clrk66')
and my results were strange. when I changed the lat field names:
Proj(proj='lcc', R=6371200, lat_0=25, lat_1=25,lon_0=-95, ellps='clrk66')
I got the results I was expecting.
3
You can cast your geometry as XY before outputting it to GeoJSON:
ogr2ogr -f csv -dialect sqlite -t_srs epsg:3857 -sql "select
AsGeoJSON(CastToXY(geometry)) AS geom, * from PVS_19_v1_vtd_21031"
PVS_19_v1_vtd_21031_2D.csv
partnership_shapefiles_19v1_21031/PVS_19_v1_vtd_21031.shp -dim 2
0
You might try the National Geodetic Survey Coordinate Conversion and Transformation Tool (NCAT). It has a multi-point option and an API as well. I haven't used the API.
When using the single point option, you can override the output UTM zone in the bottom, output portion.
-1
If you are using EPSG:27700 and all you want to do is measure distances any errors will depend on the accuracy of the data. If this is OS data the errors will be very small.
0
EPSG:29221 turned out to be the right option. I also had to use polynomial model as suggested (I had stupidly thought those models only determine the quality, not the actual transformations allowed).
2
I don't think there are practical limitations to ned2geodetic.
The conversion from LLA to ECEF coordinates has closed form solution.
The rotation of NED vector to ECEF has closed form solution.
Vector addition in ECEF is trivial.
Conversion of ECEF coordinates to LLA as implemented in Matlab is not closed form solution. However, the algorithm employed is ...
1
The distance-distortion in the map projection will be independent of the software (ignoring blunders); it is instead dependent on the projection used, and is also spatially variable.
Ordnance Survey National Grid is a Transverse Mercator projection chosen that the distances on the ground are identical to distances in the grid along two meridians: two lines ...
3
Finding the proper proj4-string can be a bit funny.
Such strings provide information on both the ellipsoid and how coordinates on the surface are arranged. Deciphering your example gives us the following two core elements:
+proj=utm +zone=18 +datum=WGS84 +units=m +no_defs +ellps=WGS84
projection is UTM zone 18 with a WGS84 datum
ellipsoid is WGS84
When ...
1
This question How to convert MGRS to Lat/Long or UTM? helped. I adapted the answer by Sasa Ivetic and although the solution is somewhat obscure, I hope it may help someone. If any of you think it wrong or imprecise for geeky cartographic reasons please let me know.
In order to convert coordinates from USNG/ MGRS to lon/lat, when there are far too many ...
0
Open this GISsurfer map
https://mappingsupport.com/p2/gissurfer.php?basemap=ESRI_aerial&overlay=ESRI_roads_and_labels
Click Menu ==> Search
and enter any of your coordinates, such as 48Q YD 307 682
Click Search
The map will center at that spot.
The lat lng for the center of the map is shown in one corner of the screen.
For more info about GISsurfer ...
1
At the site http://legallandconverter.com/p50.html you can convert USNG coordinates to lat/lon.
For example, for your 48Q YD 307 682, you will get:
2
If the rasters have correct location but one of them is rotated, then you can georeference incorrect raster based on the correct (georeferenced) one. You can either use Raster -> Georeferencer tool to do the job, or use Freehand raster georeferencer plugin which has the function to rotate the raster data.
You can download Freehand raster georeferencer ...
0
If it's possible, use Capabilities File: https://openlayers.org/en/latest/examples/wmts-layer-from-capabilities.html
First, try to display it in it's source projection. Then, OpenLayers should be able to reproject it to any other projection defined with proj4
1
Georeference it to UTM Zone 21, using the UTM coordinates.
That should be a good fit.
You would need to select a different model like polynomial for reprojecting.
0
There is some useful information on Rotation of Coordinates Based On CORDEX Domains and you can contact to AgriMetSoft to get help.
Cheers
0
So @Spacedman pointed me in the right direction, all praise goes to him. I just want to show the complete code for my question:
import pyproj as proj
...
crs_wgs = proj.Proj(init='epsg:4326') # assuming you're using WGS84 geographic
#Erect own local flat cartesian coordinate system
cust = proj.Proj("+proj=aeqd +lat_0={0} +lon_0={1} +datum=WGS84 +units=m"....
2
You could use an Azimuthal Equidistant projection centred on your origin point.
In PROJ4 syntax, "+proj=aeqd +lat_0=1.234 +lon_0=5.678".
That long/lat coordinate should project to (0,0) in that coordinate system, and points away from there should be in metres. You might want to add "+datum=WGS84 +units=m" but they may be default. Not sure what ellipsoid is ...
2
If there's no data, then no, there are no coordinates to be transformed and therefore no transformation (reprojection) to be done.
As an alternative method, without having to export/import with XML, you could iterate through all the feature classes in the GDB and for each one, create a new empty feature classes based on the existing feature class' schema. ...
0
I did some reading online, and I think the answer is probably as follows. A satellite photo is taken from a high elevation, but not necessarily from the zenith of the point being imaged. The angle with respect to the zenith may be something like 30 degrees. This causes parallax displacement, which has to be fixed in orthorectification. Orthorectification, ...
0
Google Earth Pro (desktop version) might be a better option for you to do your analysis
Using the history tool you can cycle through the best images for your work
6/2011 looks good.
0
Could you please be more specific in the type of data you are using? But from my understanding, you have inserted a Raster file into QGIS, and a .csv file of points with x and y coordinate values. You would then like to extract the raster value to those points?
If this is the case, in QGIS, you can use the "Add raster values to points" tool from "SAGA" ...
1
One further step missed for native box
from geoserver.catalog import Catalog
cat=Catalog("http:// localhost:8080/geoserver/rest")
myResource = cat.get_resources(store='storeName', workspace='workspaceName')
layers = cat.get_layers(myResource)
for rss in myResorce:
print rss.name
print rss.native_bbox ## this is for native bounding box
print rss....
1
You can do this but I'm not sure its a good thing. I'd work in EPSG:27700 because all my other map data is most likely to have this, and if I lose the projection info for something with a custom CRS then guessing it is very very hard.
But here's how to do it:
Suppose we start at 3W, 58N. What's that in EPSG:27700?
>>> proj.transform(crs_wgs, ...
0
I found the answer to my question here.
Finding a custom projection for the Gulf Coast was difficult because my data spans five states (west to east coast) and in some cases data points fall far off-shore. The spatial reference required making reasonably accurate estimates of distance and estimates of area.
The ppt in the link above recommends using a ...
1
With help from the answer of @MappaGnosis, the polygon layer was projected on "EPSG:2056 - CH1903+ / LV95".
I managed to make it work by projecting the point layer to "EPSG:2056 - CH1903+ / LV95".
Import CSV file
Chant CRS to "EPSG:2056 - CH1903+ / LV95"
The points appear ok on top of the polygons
Reproject layer
Add geometry attributes
Export to CSV
2
The CRS and coordinates you have ringed in red in the images are not the CRS and coordinates of the layer itselft but of the data frame (ie the project's over-arching coordinate system).
Changing the CRS of the layer's properties will not reproject the data (a common misconception). It only changes how the existing coordinates are interprested and ...
0
When you import you point layer, make sure you import it in the right CRS (your source CRS is obviously not 4326, maybe WGS84?).
After your import, export it again. Now is the time to change the CRS - in the export menu chose in the drop down menu EPSG 4326 and voila, your point layer should now be in the desired CRS.
1
Note: Back up your data beforehand.
In QGIS open the Processing Toolbox and go to Vector General > Assign projection.
Select that layer and assign the correct projection.
Leave the output as [Create temporary layer].
Run the tool and make sure the output is correct.
Remove the original layer and overwrite it with the output (only if you have made a ...
1
Applying coordinate systems to datasets and using them within the coordinate system of a data frame can be confusing.
I think the way to sort it out is:
Look at the Properties of each shapefile to see what coordinate range is present.
If they are -180 < long < 180 and -90 < lat < 90 then they are in a Geographic Coordinate System and you use ...
1
Yes, it is. EPSG 4326 is the identifier for the World Geodetic System 84 (WGS84). If you check the Well Known Text (WKT) for WGS84 you will see it uses degrees as units:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
...
0
The values of (x,y) that you are trying to evaluate are outside of the range of the Earth, hence the contents of the square root in the calculation of r is negative. These coordinates fall off in space and the corresponding projected line never intersects the Earth. With valid values of x,y, the code works well.
You could try to capture these exceptions by ...
1
EPSG 4326 is a coordinate system. Its units are degrees of latitude and longitude. If you define the lat/long of a point, then you know where that point is. There's nothing wrong with using EPSG 4326 for locating points.
You'll have accuracy problems if you try to calculate distance, area or angles in EPSG 4326, but that's not what you're doing. If you ...
Top 50 recent answers are included
