Tag Info

Hot answers tagged

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


2

Convert the file to WGS84 gdalwarp in_test.vrt out_test.vrt -t_srs "+proj=longlat +ellps=WGS84" Calcualte the bbox with GDAL in Python import gdal ds = gdal.Open('out_test.vrt') cols = ds.RasterXSize rows = ds.RasterYSize geotransform = ds.GetGeoTransform() bb1 = originX = geotransform[0] bb4 = originY = geotransform[3] pixelWidth = geotransform[1] ...


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

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

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.


1

From the PostGIS docs, ST_Transform — Returns a new geometry with its coordinates transformed to the SRID referenced by the integer parameter. geometry ST_Transform (geometry g, integer srid); So, to read transformed points SELECT ST_AsText (ST_Transform (geom, 4326)) FROM table ... If you want long and lat as separate fields SELECT ST_X ...


1

I solved the problem, it was in input to ptransform function in R. Instead sc <- cbind(st$LAT, st$LON) I have to use sc <- cbind(st$LON, st$LAT). Then as you say I have to use EPSG:4326 as input CRS and EPSG:3857 as destination CRS. And the transformation with this command. tr <- ptransform(sc/180*pi, '+proj=longlat', ...


1

It looks like the "EPSG: {0]" format doesn't work with the Transform methods. However, I (actually, credit goes to a co-worker of mine) was able to get the Transforms working with a PROJCS spatial reference definition. And I was also able to get it working with the SpatialReference.ImportFromEPSG. [TestMethod()] public void ...


1

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


1

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


1

Transformation parameters are the source of discrepancy. Make sure you use the same parameters while transforming back and forth.


1

Updated JSFiddle The trick is to use preFeatureInsert inside your Vector Layer constructor: preFeatureInsert: function(feature) { feature.geometry.transform(new OpenLayers.Projection("EPSG:4326"),new OpenLayers.Projection("EPSG:900913")) } My earlier comment was incorrect in that I had mistyped what projection the OSM was built in. ...



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