Hot answers tagged

24

Well, technically, NAD83 is not a subset of WGS84. If you mine further in the SpatialReference.org projetion definitions, you can see the difference between the two projections. PROJ.4 definiton of NAD83: +proj=longlat +ellps=GRS80 +datum=NAD83 +no_defs PROJ.4 definition of WGS84: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs As you can see, the two ...


23

WGS84 doesn't define a projection, so it's up to the GIS software to decide which projection to use for displaying the data on the screen (unless you manually pick a projection, of course). In the simplest case, a plate carée projection (i.e. equidistant cylindrical with standard parallel 0°) is used, which in essence just interprets the angular units of ...


17

Ian's answer is incorrect. WGS84 approximates Earth by an elipsoid, which is basically a deformed sphere. EGM96 is a more complex model based on the gravitational force of the Earth (which is not constant) that defines what "sea level" or "up/down" mean, a smooth but irregular shape called "geoid". WGS84 is the elipsoid that best fits that geoid, and this ...


17

The solution for an ellipsoid is pretty messy--it is an irregular shape, not a circle--and is best computed numerically rather than with a formula. On a world map the difference between the WGS84 solution and a purely spherical solution will only barely be noticeable (it's about one pixel on a screen). The same difference would be created by changing the ...


16

tl;dr: No. GEOMETRY and GEOGRAPHY are different PostgreSQL TYPES; exposed as higher level (SQL), user-defined composite types to the psql environment, but implemented as lower level (C) base types. These base types are defined on the C level with e.g. their own typemod constraints, TOAST support, data I/O functions, operator classes and casting behaviour. ...


15

The problem is poorly documented by authoritative sources for English speakers, despite affecting millions of people on an everyday basis. I've spend the past two days trying to understand the situation and I've created a Wikipedia article about the restrictions on mapping in China and about the China GPS shift problem. Below is the part of my research that ...


13

You need the subdataset full name from the query on the file: gdalinfo MOD04_L2.A2003001.0005.051.2010313005421.hdf >2003.txt With the subdataset name, you get the GCP coordinates in pixel and lon/lat: gdalinfo HDF4_EOS:EOS_SWATH:"MOD04_L2.A2003001.0005.051.2010313005421.hdf":mod04:Image_Optical_Depth_Land_And_Ocean >>2003a.txt With the ...


13

You can use Mapshaper for this, and then dissolve from the command line: mapshaper --dissolve -i your_data.geojson


13

Typically, NAD83 and WGS84 are within one meter of each other. Your concerns about differences of 2.5 feet, which are less than a meter, indicate you do need to perform this datum transformation. Briefly, this calculation requires knowledge of when the coordinates were collected so that their movement over time can be accounted for (primarily due to the ...


12

Have a look under the "Project Properties" dialog. QGIS will use the project's settings for ellipsoid when calculating distances in a degree based coordinate system. If you're not using OTF reprojection or have no ellipsoid set, then measurements will usually be cartesian (ie in degrees or degrees squared). The one exception to this is if you change the ...


10

WGS84 is natively XYZ, like the International Terrestrial Reference Frames (ITRF), and you can use an ellipsoid model to convert to latitude, longitude, and ellipsoidal height. Ellipsoidal heights aren't very useful. Water can flow up here, and it doesn't reflect the terrain at all. A geoid, kinda sorta, is the surface you would get if there were tubes ...


10

Be careful as WGS84 is a bit ambiguous. Most of the time it mean EPSG: 4326 that is indeed in degrees (and the base of GPS position) but the name WGS84 could be used for other CRS with different unit (see image exemple below, taken from the website referenced in JGH answer). it's safer to use the EPSG code or to be sure to have the full CRS name to ...


8

The shp2pgsql tool is used to load data into PostGIS. It is not meant for transforming projections. The -s flag of the command just tells shp2pgsql the SRID of your source data. It doesn't transform the projection at all. You can reproject it before you load it to PostGIS or after. To transform the projection before you load it to PostGIS, you can use GIS ...


8

This is not WGS84 System, WGS system is an angular system so the latitude value cannot exceed 90, and the longitude can not exceed 360. You need to figure out the coordinate system of your data, which i guess might be in WGS84 projected system which measures distance in meters. Any GIS softwares can convert it e.g. Quantum GIS. Roughly: 3 sec in WGS84 ...


8

The official OGC “Well-known Text Representation of Spatial Reference Systems” for EPSG 4326 (http://spatialreference.org/ref/epsg/4326/ogcwkt/) is (your second projection): GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",...


8

By "using WGS84 only" it sounds like you are referring to a Geographic Coordinate System based on the WGS 1984 datum. A Geographic Coordinate System does NOT have a projection. Only a Projected Coordinate System has a projection.


8

You first need to decide what distortion properties would you like to control for. That is to say, are you interested in preserving area, distance or shape? There is a decision support tool for selecting projections that is quite user friendly and available for free from Oregon State University (Map Projection Selection Tool). Note that you can select the ...


8

Easiest way is to convert the raster to a projected system, and get the cell size directly in meters. That not being possible, or desirable, you can still convert lat/lon values to metric values, but you'll run into an accuracy problem. This is because, 1º of distance represents different values in metric units depending on your location and bearing (0....


8

This seems to be the end result of an interesting conversion from radians to degrees. t.convertLength(Math.PI,"radians","degrees") 179.78993435469053 PI radians should be 180 degrees. Looking at the turf source, conversion is done by multiplying by a factor defined in the turf-helpers module: https://github.com/Turfjs/turf/blob/...


8

Mean Highest High Water is a reference surface corresponding to the height of high tides, averaged over a certain period of time (usually 19 years, a value close to a Metonic Cycle and a Lunar Node cycle). Data from tidal gauges, satellites, etc. are usually processed and stored in grid files, which contain the difference in elevation between different ...


7

You have a closing paren in the wrong place towards the end of your query. I tried this and got a NaN return, SELECT ST_AREA(ST_Transform(ST_GeomFromText('POLYGON((871325.790874952 6105405.3261047,871418.748307692 6105359.72944624,871346.22022442 6105215.141258,871254.85408906 6105261.72007212,871325.790874952 6105405.3261047))',4326),31467)) As sqm; The ...


7

Sightings constitute a (non-random) sample of some process or population. Accordingly, interpolation (especially) IDW is not a good idea: it solves a different problem altogether. Consider making a density map. When doing so, it's probably better to favor equal-area projections over conformal projections (because changes of area bias the density, whereas ...


7

I wrote a C program to do this many years ago. They are hard, being complex arithmetic series approximations that have to be solved iteratively. I had to define my own structure to handle imaginary numbers and create the complex arithmetic operations. The equations are on the LINZ website to do this. http://www.linz.govt.nz/geodetic/conversion-coordinates/...


7

The term "WGS84" refers both to a reference ellipsoid and to a geographic coordinate system (aka EPSG:4326) - hence your confusion.


7

The first archive ("Roads Data - tables and layers") doesn't contain the projection information, which is pretty bad form. However, the second archive ("Roads ArcReader Projects") has the projection information in its .prj files: PROJCS["Clarke_1866_Polyconic",GEOGCS["GCS_Clarke_1866",DATUM["D_Clarke_1866",SPHEROID["Clarke_1866",6378206.4,294.9786982]],...


7

If you are running QGIS 2.0.1, you can import the data as delimited text layer. It offers you to select DMS Coordinates, comma as decimal separator and EPSG:4326 as CRS. Once you have the data loaded, you can rightclick on the layer -> Save as and choose EPSG:32632 for the output file.


7

This should work: staffs.to_crs(epsg=4326)


7

PostGIS computes its intersections (and distances (and areas)) differently depending on your column type. if the type is "geometry" the assumption is you want to work on a plane, so you get "straight line" distances / intersection tests if the type is "geography" the assumption is you want to work on a sphere, so you get great circle distances / tests ...


7

The linked kml file seems to contain valid degree coordiantes, but fails to open in QGIS. If you follow the source given in your link to http://www.ecaidata.org/dataset/spanish-and-mexican-land-grants-in-california, you can get a shapefile which misses its prj file. With some kind of educated guess, you will find that NAD27 / California Albers EPSG:3309 ...


7

You may check http://vterrain.org/Imagery/WholeEarth/ for links to satellite imagery, or http://www.naturalearthdata.com/downloads/10m-raster-data/ for raster images. These images can be tweaked in Photoshop to get your own look&feel and rendered with MapTiler into tiles - check http://examples.webglearth.com/#customtiles and esp. http://www.maptiler.com/...


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