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


2

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


2

You didn't give any details about the crash. I've repeated the same process using your shapefile, the Affine Transformations 1.0.0 plugin with QGIS 2.2.0, and everything was ok (after a five minutes waiting time). I must tell you that, during the transformation, if you see the Not responding message, this doesn't means the software stopped to work. Few days ...


2

Some kinds of transformations are lossy. Transverse mercator for example can only be used for the visible half of the globe. The back side gets lost when you try to re-transform. Mercator only looses the poles, because it is accepted that the cylinder is unrolled in a world map. This is important if you have huge shapefiles, e.g. complete Russia or the ...


2

projections of vector datasets are not lossy in theory (if you don't have rounding errors, of course, which will depend on your software and your data storage precision). You should however be careful with projection of raster datasets, which are lossy because of the resampling. Now, if you change the datum (from one geographic coordinate system to ...


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

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


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

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

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

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

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


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

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.



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