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 ...


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

The operation your looking for is called buffering, and is a standard function available in most GIS libraries. In PostGIS/spatialite it's called ST_Buffer(geometry g1, float radius_of_buffer); In shapely it's called buffer. An example from the shapely docs: >>> coords = [(0, 0), (1, 1), (1, 0)] >>> r = LinearRing(coords) >>> s ...


4

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 ...


3

To me, your basic approach appears sound yet overly complicated. I'd start with this: scale_x = (img_right - img_left) / (x_right - x_left) scale_y = (img_top - img_bottom) / (y_top - y_bottom) new_x = img_left + scale_x * (x_in - x_left) new_y = img_bottom + scale_y * (y_in - y_bottom) You may need some minor variation due to screen Y coords being in ...


3

WGS 1984 has had several "releases". I'm not sure whether or not to call them re-adjustments. WGS 1984 is loosely tied to the International Terrestrial Reference Frame (ITRF), maintained by IERS. The first transformation, WGS_1984_(ITRF00)_To_NAD_1983, assumes that WGS 1984 is the one tied to ITRF00 and the NAD 1983 realization is CORS96 or similar. That ...


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

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

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 ...


2

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


2

Try this below. ST_AsText returns the well-known text. ST_X and ST_Y return the actual longitude and latitude (assuming geom is in the appropriate SRS). SELECT ST_AsText(geom), ST_X(geom), ST_Y(geom) FROM table Hope it works.


2

The AB_CSRS file seems to have been replaced with abcsrsv4.dac. Esri hasn't added another transformation to use the new file yet (we don't have a copy). You could rename it and use the NAD_1983_To_WGS_1984_8 transformation, or create a new transformation with the geoprocessing tool, Create Custom Geographic Transformation. You will still have to change the ...


2

ogr2ogr provides 3 command line options dealing with coordinate systems -a_srs srs_def: Assign an output SRS -t_srs srs_def: Reproject/transform to this SRS on output -s_srs srs_def: Override source SRS The one you are looking for it -t_srs to transform, though you may also need -s_srs if your source data does not have it's coordinate system ...


2

You would need to georeference (that's the term) image with QGIS. See my answer to this question for tutorial links.


2

Terminology By definition, the scale is the amount by which (infinitesimal) distances are multiplied by the projection. Whenever a tiny displacement of d meters on the earth is associated with a displacement of d/s meters on the map, the scale is written as 1:s. It may depend on the direction of the displacement. The scale factor compares the scale at ...


2

Looking at the map that you have given, One can see that the points are coming close to the expected point, and are about 1 Degree Away. Lokking at your data, I can see that your code is converting -122.0, 40.0, 4.0819802 to -121.33219944994444 when it should be -122.66780055005556 This tells me that while you are flipping the sign of the Degree ...


2

I'm not sure who you consulted, but this doesn't seem like great advice. The problem seems to be not one of negative values but more the order of x and y co-ordinates. A latitude (y) can only be in the range of -90 to +90. Longitude (x) can be -180 to +180, broadly speaking. These co-ordinates are from the equator and the Greenwich meridian, respectively. ...


2

You can perform raster algebra using the Raster Calculator (Spatial Analyst). The syntax would be like the following: Float(Ln("flowAccumulation.img"))


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

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

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

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

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

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

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

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 ...



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