Tag Info

Hot answers tagged

4

The geographic coordinates systems (also called lat/long) are defined by 3 features : a datum, a prime meridian (most of the time, it is Greenwich) and a unit (most of the time, it is degree). The EPSG code help to unambiguously identify a geographic coordinate sytem (you can find the description on spatial reference.org) GEOGCS["WGS 84", ...


4

Based on the conversation on the comments, ArcGIS online is making a guess at the coordinate system, while ArcMap is not. When it encounters an unknown coordinate system, ArcGIS Online appears to automatically assume WGS 1984. ArcGIS for Desktop treats undefined coordinate systems differently and does not make assumptions about the data's actual coordinate ...


3

Web Mercator is rarely the right answer, unless you want pictures that line up with other stuff in Web Mercator. An extract from the NGA's Implementation Practice Web Mercator Map Projection, which is worth a read in full: 5.2 The Web Mercator map projection has several defining mathematical formulas and parameters that make data referenced to Web ...


2

It depends on the extent of your area of interest. Transverse mercator is conformal along the central meridian, while Mercator (in its original form) is conformal along the center latitude. That does not have to be the aequator. So if your area is mostly north-south orientated, tmerc is better, if it is more east-west, merc is better. Transverse is ...


2

My first guess would be EPSG:4326 WGS84 lon/lat degrees. Similar to this question: Import Points with WKB format to QGIS I imported the data into QGIS using the QuickWKT plugin, and the point ends up in the Greek town of Volos: If you have a postgis database attached to QGIS, you can simply copy and paste the point into an existing Postgis table of type ...


2

It seems that the proj.4 implementation of Wagner VII does not have a definition for the inverse projection: proj -I +proj=wag7 Rel. 4.8.0, 6 March 2012 <proj>: inverse projection not available program abnormally terminated In this case, no reprojection is possible. See also this ticket on similar problems: http://trac.osgeo.org/proj/ticket/234


2

Thanks @whuber for pointing me in the right direction. I found my answer here. I had to reproject the raster layer into World Mercator (EPSG 3395), and then load it back onto my map where OTF reprojection put it in the right spot. I tried Pseudo Mercator (EPSG 3857) and that seemed to work too.


2

The EPSG registry lists two versions of CGCS2000: EPSG:4479 uses a 3-dimensional cartesian coordinate system based on the Earth's center EPSG:4480 uses Latitude, Longitude and ellipsoidal height. For the first one, see Help defining custom CRS in QGIS 2.2 how to use it in QGIS and the limitations of that CRS. For the second one, you can use the projection ...


1

For those who may be interested: the problem seems to have been that my .vrt had coordinates that spanned across the -180 longitude. Left was a pixel or two beyond the line (-180.00004) and right was ~0 degrees). Clipping it seems to have solved the problem.


1

If you reproject the polygon data to Asia Lambert Conic (not just On-the-fly, but really reprojecting all vertex coordinates into a new file), you can dissolve the polygons by a common attribute. This should remove the common border line. If it does not work in first run, have a closer look at the border line. There may be a small gap after the ...


1

According to spatialreference.org, CGCS2000 should be +proj=longlat +ellps=GRS80 +no_defs The usual approach is to add this definition as a custom CRS if you cannot find it in the default CRS list of QGIS.


1

On the first pass through the loop, the extent environment variable is set to the extent of the projected version of the first shapefile. On the second pass through the loop, the extent environment variable is still associated with the first shapefile. When Project is called, only the features within that extent are processed (presumably no features in the ...


1

Join the tables together. Right Click on the point shapefile and join it with the line shapefile.


1

A 'scale factor' when specified in connection with a map projection algorithm is a way to reduce the overall distortion due to the map projection. For instance, the transverse Mercator projection usually has these projection parameters: central meridian (also known as longitude of origin) latitude of origin scale factor false easting false northing ...


1

Unfortunately, the term "scale factor" is ambiguous. In cartography, maps and projections, the concept and application of scale is of fundamental importance. By definition, it is a factor – meaning it is something to multiply or divide – so whether "scale" or "factor" is the adjective the particular word pairing has no obvious meaning, except in ...


1

QGIS is not designed to handle J2000 data. Your data would have 4 coordinates (X,Y,Z and time), while QGIS only handles 2-dimensional coordinates (long and lat or X and Y). It is possible to reproject coordinates with cs2cs if you set the prime meridian according to the time. Every hour from 12 UTC is a shift of 15° to the greenwich meridian: put 7 51 in a ...


1

I think it's the alpha band that's causing problems. To extract the data band: gdal_translate -of hfa -b 1 original.tif band1.img Then to warp: gdalwarp -of GTiff -s_srs epsg:4326 -t_srs epsg:3857 -co "tfw=yes" band1.img band1_warp.tif Gives an image: With GDALINFO > Driver: GTiff/GeoTIFF Files: D:\Testing\Tiff\band1_warp.tif > ...


1

Both CRS you mention (SIRGAS-Chile / UTM zone 19S and WGS 84 / UTM zone 19S) use the same ellipsoid with towgs84 set to all zero. So they can be regarded as identical. Apart from that: A point in the map remains on its position, regardless of the CRS you are saving it with. If you use an older CRS with a certain shift to WGS84, like PSAD56 / UTM zone 19S, ...


1

If you look inside http://trac.osgeo.org/gdal/browser/branches/1.11/gdal/ogr/ogrsf_frmts/mitab/mitab_spatialref.cpp you see: { 6277, 79, "OSGB_1936", 9, 375, -111, 431, 0, 0, 0, 0, 0}, The shift values were replaced in GDAL some time ago, but obviously not in the mitab driver. Keep in mind that EPSG:27700 in the original EPSG definition does not obey any ...


1

The values for x and y in this case are probably just indices for an X-Y-Z tilemap. The indices of a TMS service are unitless, they simply count the number of tiles from the top-left corner. In your example, the _unitsPerPixel function returns the scale of the pixels for the given zoom level. The value is the width and height of one pixel in the units of ...


1

You are correct that if your data are in a small region that you should use a geometry type. However, you would also normally transform the Lat/Long coordinates to a spatial reference system for the region. Normally most folks choose a UTM Zone, which describes coordinates for Eastings and Northing with length units in metres. Check out ST_Transform to ...



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