It might be an issue with the size of the raster layer. Try generating raster overviews to compress the size of the raster and reduce its resolution to speed up the rendering process. You can do this on QGIS by going to Vector > Miscellaneous > Build Overviews (Pyramids). This makes the layer show only the necessary data on the particular zoomed out ...
Let's make some data:
> pts = st_as_sf(data.frame(x=runif(50),y=runif(50)),coords=1:2)
> pts$S = factor(sample(c("Presence","Absence"),nrow(pts),TRUE))
To do join-counts, you need to decide where the joins are. For a grid that's usually the 4- or 8- nearest neighbours (rook or queen ...
It looks like Schwarzeck Lo/22/17: https://epsg.io/29377
False Easting should be: 0 and unit: GLM (German Legal Meter).
You can also use meter as unit and use a scale factor of 1/GLM =0.9999864037
Here are the published PROJ.4 settings:
(+proj=tmerc +lat_0=-22 +lon_0=17 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=bess_nam +towgs84=616,97,-251,0,0,0,0 +to_meter=1....
As Vince noted, the raster has the wrong CRS attached to it. Looking at the extents, one can guess that the values are in degrees and not in meters and they actually correspond to the extents of Colorado which is 37 to 41 N and 102 to 109W. The solution is to attach a geographic coordinate system to the raster such as WGS84 (or GRS1980) and then reproject to ...
According to people who attempted recreating the AuthaGraph projection, the map indeed have some distortion, but the trick is those distortion are limited to South Pacific, South Indian Ocean, South Atlantic, and the Siberia/North Pole area, and these area are mostly covered by ocean with little population, thus they can preserve the proportion of land on ...
You probably want 4326 (4326 is just the EPSG identifier of WGS84, latitude and longitude in degrees, which it looks like you are expecting), those numbers look approximately right for 3857 (Web Mercator)
If your numbers are latitude/longitude: 43.259404, -2.026318; that is on the coast of Spain.
Your result on an OpenLayers map (which defaults to EPSG3857)
All I can say is it works on my machine - I added ISTN02_NTv2.gsb to data/user_projections. Restarted GeoServer (not sure if it is necessary but never hurts) and now I see this in the reprojection tool.
I downloaded the OSTN15_NTv2_OSGBtoETRS.gsb file and added it to data/user_projections too. Now when I look at the transformation in the reprojection ...
See comments in your question, but an alternative approach when you understand that geoprocessing tools return Result objects is this:
resObj = arcpy.CreateFileGDB_management(output_folder, "DEM.gdb")
You can use the following expression with the fieldcalculator in your attribute table, so you do not need to care about anything (except for the used project CRS). No reprojection of your layers or looking up EPSG-Codes or something like that.
If anyone else is stuck with a similar problem, I finally got it working with the WKT2 string shown below.
I got the affine transformation parameters from a MapInfo PRJ definition of the custom projection (just the cosine and sine of the custom grid's rotation angle, scaling values and the x and y offsets), then added a DERIVINGCONVERSION ...
I was able to get around the problem by using the sf::st_crs() function to transform in wkt, instead of directly using sp::CRS("+init=epsg:4326").
wkt <- sf::st_crs(4326)[]
CRS arguments: +proj=longlat +datum=WGS84 +no_defs
I think the code above by @user2232395 has been crippled by copy/pasting. Looking at the UTM zone map, it looks like the indentation is wrong. Also, there is a "fix" missing for Norway. I think it should be:
def getZones(lon, lat):
"get UTM zone number from latitude and longitude"
if lat >= 72.0 and lat < 84.0:
I couldn't really figure out these answers, but I found a pretty straightforward way to create a star map.
I downloaded the Yale Bright Star Catalogue, and converted it to a csv file that I could use in Excel and in QGIS.
The key fields are the Right Ascension, which gives the x value, and the Declination, which gives the y value.
Right Ascension is given in ...
You should use ST_Translate for this intent https://postgis.net/docs/ST_Translate.html
SET your_geom_column_name = ST_Translate(your_geom_column_name, 4, 4);
Be aware 4 are units from your geometry projection. Would be better if meters instead of degrees as 4 degrees something like hundred of kilometres...
Here is my Python code. Ref to this link
# Converting lat, lon (epsg:4326) into EPSG:3857
# Ref: https://stackoverflow.com/questions/37523872/converting-coordinates-from-epsg-3857-to-4326-dotspatial/40403522#40403522
def ConvertCoordinate(lon, lat):
lonInEPSG4326 = lon
latInEPSG4326 = lat
lonInEPSG3857 = (lonInEPSG4326 * 20037508.34 / 180)
The CRS drop down in the Save Layer dialog just gives you a selection of recently used CRS's. After you have opened the Coordinate Reference System Selector with the Select CRS button ('globe icon') shown below...
...you will have access to all the predefined Coordinate Reference Systems via a tree view which you can expand and browse:
To quickly find a ...
From the QgsCoordinateReferenceSystem documentation it accepts WKT text for the CRS definition.
The Well-Known Text format supports a keyword for defining 'local' ungeoreferenced coordinate systems 'LOCAL_CS'. See geotools documentation here.
Therefore you could try the following:
You've got a good grasp of it. EPSG 4326 (i.e. WGS 84) is not a projection. But if you don't associate a projection to this geographic coordinate system, and naively render the coordinates as x/y coordinates on a grid, you do get something that is sort of a projection: the pseudo plate carée (equirectangular) projection. (This is not the same as an actual ...
When you calculate the area of a geometry with SRID 4326 (ST_Area(polygon::geometry)), the implied projection is plate carrée, which has large distortions the farther away you are from the equator.
When you calculate the area of a geography object (ST_Area(polygon::geography)), the calculation takes the curvature of the earth's surface into account, which is ...
The only solution I found so far is to edit proj.db directly to add the custom projections.
It looks like the pyproj library has evolved over time but MapProxy hasn't caught up with its changed file conventions yet.
I've submitted a bug report to MapProxy - https://github.com/mapproxy/mapproxy/issues/493
The easiest way I found to add a new projection to ...
Maybe ProjNet (for GeoAPI) suits your needs. From personal experience I know that the Java and ...
Seems like EPSG:3106001 as stated on https://www.rainviewer.com/radars/france.html.
If you analize the website with your favourites browsers inspector, you will find a carto.js file at https://donneespubliques.meteofrance.fr/template/js/carto.js where you can see they are using Openlayers for this with the following projection:
I'm interpreting your question that you have this saved image as a picture (raster), with no world file or other georeferencing information. And you say approximate is OK.
In this case, especially given the grid is shown, you could use QGIS' Raster > Georeferencer feature to force-stretch it to a desired projection rather than to try to guess/determine ...
It sounds as if you have the layer in QGIS. If I assume this right, you can just go to the properties of the layer (right or double click onto the layer) and go to the tab "information". There you have meta information about the layer at the top of the page such as Geometry, CRS (Coordinate Reference System) and Extent.
If the projection is not ...
What exactly is in target_crs? For example, using the USA Contiguous Albers Equal Area Conic ESRI projection (ESRI:102003), your code performs flawlessly:
disp_win_trans = sf::st_transform(
, crs = "ESRI:102003"
# Simple feature collection with 2 features and 0 fields
# geometry type: POINT
# dimension: XY
You are passing in the latitude and longitude Series instead of the latitude and longitude column names.
import pandas as pd
def get_zipcode(df, geolocator, lat_field, lon_field):
location = geolocator.reverse((df[lat_field], df[lon_field]))
except (AttributeError, KeyError,...
It looks like you imported your layer correctly, however there is a problem with your OSM Layer. The display shows coordinates in the millions, but the display CRS is 4326, which makes no sense. My guess is that the CRS of the OSM Layer was wrongly set to 4326 previously.
So, reset the CRS of the OSM Layer to EPSG:3857 / Web Mercator, and everything should ...
I'm not sure where your issue is as I get the same result using below samples. PS: I suppose you will use Python API to call GDAL and not quick execution of GDAL binary within Python using subprocess or os.open
With Python and GDAL combined
srs_def = "+proj=lcc +lat_1=13.342499732971191 +lat_2=47.317501068115234 +lat_0=30.330001831054688 +...
Shapely geometries are unaware of their CRS. Using pyproj to transform them only changes the values of the coordinates without leaving any trace of the final CRS in the resulting geometries. Serializing a shapely geometry to wkb will never write the CRS information.
However, one option I am aware of is using GeoPandas to set the CRS and write to a file ...
(Converting my old comment to an answer)
Notice that the X coordinate is in the millions. That is much too high for the "east" coordinate in a UTM system. It is, however, a reasonable value for the "north" coordinate. Plugging N=8582266, E=239737 into UTM zone 19 S puts you here.
(Also: XKCD 2170)
If you use matplotlib-basemap as you do with your attached code, you already have the functionality of direct and inverse coordinate conversion.
Conversion from (long,lat) to lcc projection:
lon = [8, 10]
lat = [47, 49]
x,y = m(lon,lat)
Computation check, i.e. conversion from lcc (x,y) to (long, lat):
lon2,lat2 = m(x, y, inverse=True)
You will get:
EPSG = 2232. Based on your LiDAR metadata your LiDAR references Colorado State Plane 0502 (Central) NAD 83 in US survey feet. See here for a map of this coordinate reference system, and here for details on the ESPG code.
I do it in the following way:
Convert geodetic (3D) to geocentric coordinates;
Find the parameters of a similitude transformation from local cartesian to geocentric system;
Convert all points to geocentric and then all points to geodetic 3D coordinates.
For first and last steps I will use pyproj (2.6.1).
For the second step, I wasn't able to find an open ...
This is a small issue in readLAScatalog(). LAS format 1.4 is not supported as well as LAS formats < 1.4. An other related question has been asked few days ago (R lidR does not read the CRS of my las file). lidR >= 3.1.2 will have a better support of LAS 1.4. And with rlas 1.4 it will have an even better support.
Meanwhile you can simply get rid of the ...
Thanks to Lena, I maybe found a R solution with the gdalUtils
You can directly reproject it with the following code, where you specify your raster file, the destination file (where outdire is the path where I want to put the results), with the projection of the MODIS product and the desire projection (here WGS84). Faster if you have mutlpile rasters to ...
Manifest uploads get merged into a single image that at the end, can only have 1 scale. So you can't upload multiple pieces that have different scales. If your files have different scale, your only option is to upload them into a collection and use a mosaic() of that collection. Everything will get reprojected on use into whatever output coordinate ...
Just taking a shot here.. I've worked with big raster datasets a lot recently, and while I mostly use R, for converting to a new projection I found that QGIS is much more efficient.
So my advice would be to try to open your raster in QGIS and use "Raster"->"Projections"->"Warp (Reproject)". You can then save your re-...