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

Modern mathematics characterizes transformations in terms of the geometric properties that are preserved when the transformations are applied to features. A time-honored example is the set of Euclidean transformations of the plane: these are the ones that preserve all distances and (unoriented) angles. The study of this group of transformations is the ...


5

When talking about geographic locations, we usually say and use Lat-long. This has been codified in the ISO 6709 standard. When dealing with Cartesian coordinate geometry, we generally use X-Y. Many GIS systems, work with a Geographic Location as a special case of a 2 D coordinate point, where the X represents the longitude and Y represents the Latitude. ...


3

Don't set the layer CRS to WGS84 if they are in ETRS89! You are giving QGIS the misleading information that these layers contain data in WGS84 and therefore QGIS won't reproject the geometries anymore because it thinks they already are in degrees.


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

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


2

There are different 2D adjustment methods because there are different sources of deformation. 1) deformations due to acquisition of an image by a remote sensor (central projection or push-broom) 2) deformations due to the representation of the Earth surface on a 2D plane 3) local errors My rule is to use the simplest method possible (the one that ...


2

Your transform goes from WGS84 to mercator. However, the coordinates of your bounds are not in WGS84 (a geographic coordinate system , with lat/long in degrees). Maybe your coordinates are already in mercator, or you should try to identify the correct coordinate system of your source before projecting the data.


2

You can use ogr2ogr with SpatiaLite support (GDAL version >= 1.10): ogr2ogr points_shifted.shp points.shp -dialect sqlite -sql "SELECT ShiftCoords(geometry,30000,0) FROM points"


2

the datum of BNG is GCS_OSGB_1936. When you project the data (or move to lat/long coordinate), you should also make sure that you set the correct datum transformation. Usually, any transform that you would choose in ArcGIS is precise enough for common mapping needs, but ArcGIS is not transforming datums by default in case of projection.


2

Sure, you should be able to go to Toolbox->Data Management->Projections and Transformations->Feature->Project. There, simply select your dataset and then click the button for output coordinate system, where you can browse to Projected Cordinate Systems->UTM->WGS 1984->Northern Hemisphere->WGS 1984 UTM Zone 33N.prj and press Open, Apply then OK. If you ...


2

I think you are almost there: If you post your workspace (or screenshot would be easier to follow) What I think you are missing is the BoundsExtractor for your polygon (rather than the vertices) http://docs.safe.com/fme/html/FME_Transformers/Default.htm#Transformers/boundsextractor.htm *2014 FME Desktop used here (looks different to 2013)


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

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


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

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

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

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

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

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