Tag Info

Hot answers tagged

8

You can put the WKT text into a text file, and run gdalsrsinfo on it: gdalsrsinfo test.txt >out.txt PROJ.4 : '+proj=lcc +lat_1=26.666667 +lat_2=29.333333 +lat_0=28.002808 +lon_0=84 +x_0=500000 +y_0=500000 +a=6377301.243 +b=6356100.230165384 +units=m +no_defs ' The ellipsoid parameters look very much like Kalianpur 1962, EPSG 4145: +proj=longlat ...


6

Your data seems not to be in WGS84, but in a metric system as you can see from the metadata you posted. The xmin/ymin coordinates 3572722/5453423 have 7 digits both, while coordinates in WGS84 are much smaller (from -180 to 180 degrees). If your coordinates would have 6 digits and 7 digits, it could be e.g. a UTM projection. Furthermore, your first ...


6

While shapely doesn't natively understand coordinate systems, shapely.ops.transform() can do that along with pyproj. If pyproj.Proj can understand your both of your coordinate systems, then it can be made into a function that shapely can transform with. From the shapely docs: from functools import partial import pyproj from shapely.ops import transform ...


5

Using QGIS, you can load the shapefile as a new layer, and Set CRS for Layer to EPSG:7405 (or better EPSG:27700). Then use Save As... to save it to another filename and EPSG:4326. Alternatively, GDAL ogr2ogr is the right tool for you. ogr2ogr -t_srs epsg:4326 -s_srs epsg:27700 dst_datasource_name src_datasource_name should deliver the data you want, ...


4

Your Gauss-Krueger projection uses +datum=potsdam. Up to 2012, this was hard coded in proj4 to a very unprecise value using a 3-parameter-transformation. You find more exact values for 7-parameter transformations in this topic: http://forum.openstreetmap.org/viewtopic.php?id=12723 There is an even better ntv2-grid transformation available here (take the ...


3

For the first part of your question: GDAL can guess the format of the input file from the file extension. The output format is defined by the -f option. If it is missing, Geotiff is assumed, but you get that warning if the file extension is not .tif. For a .grd output, you can select between GS7BG (rw+v): Golden Software 7 Binary Grid (.grd) GSAG (rwv): ...


3

Two separate marker-transform properties can't be applied for the same object, but if you can apply a single property with multiple functions in it: marker-transform: 'scale(0.5) rotate(180)'; However this would likely require you rearrange your code to apply the correct rotations at the same time and make things more complicated. A simpler approach ...


3

You can't transform from one SRID to another without knowing what the SRID you are transforming from is. It looks like in your case that the coordinates are Spherical Mercator, which is SRID 3857. So, if this is true, then you can use ST_Transform in conjunction with ST_SetSRID: UPDATE roads SET geom = ST_Transform(ST_SetSRID(geom, 3857), 4326); and then ...


3

You can create a local CRS with an oblique mercator projection, and transform the data with gdalwarp and gdal_translate into it. See my advice here: Using customized Coordinate System for Archaeological site data This should work with 16-bit or grayscale data the same way. Paletted colours shoud be expanded to RGBA in advance. UPDATE Using QGIS, ...


3

You do not need to transform the points. The projection applies to the location, not to the attributes (which could be in knots, or ms-1, or nothing to do with any units, like the colour of the soil). The only potential case where this could be a problem is where the target CRS is rotated from the source CRS. Then you'd may need to project u and v into the ...


3

In QGIS, the projection string for EPSG:3399 is: +proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=5500000 +y_0=0 +ellps=bessel +units=m +no_defs This projection string has no datum shift +towgs84, which I would expect for every transformation from the German DHDN/bessel to the WGS ellipsoid. See this page in German for more information on official transformation ...


3

Yes. Double-click the dataframe name in the Table of Contents, or right-click it and choose Properties. On the Coordinate System tab, at the bottom, click the Transformations button. This will bring up the same dialog as when you add the layers. Here you can select the CRS of the layers present in the top box, the CRS you want to specify them to (your ...


3

The length functions work differently with 3D linestring geometries: ST_Length - returns 2D distances for geometry types, and oddly 3D distances for geography types (but not in this question) ST_Length_Spheroid - returns 3D distances for geometry types Your example is in 3D, so it will calculate the 3D length with ST_Length_Spheroid and the 2D length ...


3

The EPSG: 3857, WGS 84 / Pseudo Mercator in QGIS is called WGS84 Web Mercator (Auxiliary Sphere) in ArcGIS. You are simply not using the right projection.


2

Affine Transformations is included now in the plugin repository. Vector Bender has a similar georeference-like approach, but is still only experimental.


2

The problem is that the data was never in UTM to begin with, and so by having a UTM projection, the file was ultimately being told to be something it wasn't. (Such is life) :) Reprojecting it doesn't fix the problem, because the transformation math is based on coordinates that don't match the assigned projection. To fix this I deleted the .prj file, and ...


2

Since your data is already in UTM 34N projection, all you have to do is reproject it to your local CRS. You can do this with gdalwarp (even in batch mode for a whole folder), or inside QGIS with Raster -> Projections -> Warp . ARCGIS should offer similar tools. So no need for georeferencing manually.


2

Inspired by WhiteboxDev's comment I have added MODIS support to i.tasscap in revision 62197. It is yet untested, please try it and report if all works fine. In order to obtain this improvement, you need to either install/update GRASS GIS 7.1 or even simply grab the updated i.tasscap (which is a Python script here).


2

The GRASS program that you linked to was written by Markus Neteler and he's done an excellent job of documenting the code. It appears that the tool has been written with the Tasseled Cap transformation (TCT) coefficients that are specific to Landsat TM and ETM (Landsat 4, 5 and 7). He makes a note in the documentation about whether or not it would make sense ...


2

If you have data from the poles, avoid EPSG:3857, because that is undefined at the poles. Reprojection might fail, and the rest of the data might get lost. Try EPSG:4326 instead. To get the full picture, include the target extent (for the Arctic region): gdalwarp -t_srs EPSG:4326 -te -180 -90 180 90 northpsg.20141027 output.tif and you will get your ice ...


2

Vincenty's formula (ellipsoid based) is more accurate than haversine (sphere based). Also, lat and long are usually expressed in degree, but your coordinates are not in 0-180, therefore you could be in another system than expected.


2

Using gdal. Have a look at gdal_translate to convert to from tif to another format (although the tif is likely the best option). Then use gdalwarp to reproject to mercator. Gdal is written in python so you should be able to incorporate it straight into your workflow.


2

What sort of transformation options are available to you depends on whether the LiDAR data in question was collected by a terrestrial (fixed position) scanner or some sort of mobile or airborne platform. If it was collected terrestrially, the answer also depends on whether the data you are speaking of was collected from one scan or multiple scans. Below I ...


2

Is this data sourced from India or Nepal? The EPSG Geodetic Parameter Dataset lists two transformations that apply to Nepal. It's difficult to recommend something in particular because the geographic coordinate reference system (datum) that you have just lists the ellipsoid information. tfm 6208 is actually for Nepal 1981 to WGS 1984. The ellipsoid is a ...


2

In addition to AndreJ's answer, the gdalwarp command can be simplified as this: gdalwarp -s_srs EPSG:28193 -t_srs EPSG:4326 -of GS7BG in.grd out.grd No need to specify the entire proj.4 definition. On Linux systems this might work, as root: ln -s /usr/lib64/libproj.so.0 /usr/lib64/libproj.so


2

Rather simple method is to write a new world file (.tfw) which contains rotation parameters. You can make such with OpenOffice Calc, for example. If you have a GeoTIFF file which contains reoreferencing info as stored into the image tag you must clear the geotiff tags and create a baseline tiff to start with. It can be done with gdal_translate: ...


2

Using QGIS 2.6.1 (and probably some previous versions as well) Go to "Processing toolbox" and search for "Reproject layer" under QGIS geoalgorithms, Select the tool and right click to open contextual menu, Select the "Ëxecute as batch process" option Select each one of your "input layer", "Target CRS" and "Reprojected layer name" Click ...


2

You need to define you own projection system: Find you x0 and y0 (the origin of you system) based on the points for which you know the real coordinates In the Coordinate Reference system selector (right click on a layer and Set Layer CRS), use user-defined coordinate-system (use the definition of the CRS you mentioned as "real coordinate" and change your ...


2

You can test it with gdalsrsinfo http://www.gdal.org/gdalsrsinfo.html gdalsrsinfo epsg:3068 PROJ.4 : '+proj=cass +lat_0=52.41864827777778 +lon_0=13.62720366666667 +x_0=40000 +y_0=10000 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.45 5,6.7 +units=m +no_defs ' OGC WKT : PROJCS["DHDN / Soldner Berlin", GEOGCS["DHDN", ...


2

Either the WGS 1984 in the original raster, or in the target UTM doesn't match Esri's definition of WGS 1984. It's probably one of the names. If it's the original raster, try using the Define Projection tool to reset it to Esri's WGS 1984 definition. If it's the output coordinate system, try using Esri's version instead.



Only top voted, non community-wiki answers of a minimum length are eligible