Tag Info

New answers tagged

0

I agree with Micky T, it looks like you are using the wrong proj4 string. First, you will need to ensure which projection your numbers are in. WGS84 is the datum, not the projection. One possible projection is UTM, which defines your starting point for your easting and northing in meters. The x and y values that you give sure look like they are a ...


0

Longitude conversion from elliptical Mercator (same formula in both systems?: import math def merc_x(lon): r_major=6378137.000 return r_major*math.radians(lon) Mercator X now known. Divide this by the longitude to get the scale value. Latitude conversion from spherical Mercator: import math def lat2y(a): return ...


1

Take a look at Proj4 https://github.com/OSGeo/proj.4/wiki python's implementation pyproj https://github.com/jswhit/pyproj You could specify src and dest projections (like EPSG:4326 and EPSG:3857) and convert coordinates between them. And pyproj will made all raw calculations.


1

I guess you stumbled over this note on page 53: subsequent civilian adoption of the systems usually ignores the zone prefix to easting. Where this is the case the formulas below do not apply: use the standard TM formula separately for each zone The formulas on page 54 should only be used if the zone number is written before the false Easting, which ...


1

Actually, the manual is incorrect. If the SRID is unknown, it is assumed to be WGS84. For PostGIS 2.0 and later, the radius of the spheroid is obtained from the SRID. Let's add a Martian projection system for fun: SELECT Postgis_version() INSERT INTO spatial_ref_sys (srid, auth_name, auth_srid, proj4text, srtext) VALUES (49900, 'IAU2000', 49900, ...


5

It doesn't use WGS80. You are looking at old documentation for version 1.4. In more up to date documentation it states WGS84 is assumed. See here where it states: This function currently does not look at the SRID of a geometry and will always assume its in WGS 84 long lat. The version you quote from (1.4) also only implemented ST_Distance_Sphere ...


2

The postgis 2.1 manual states that it assumes WGS84. And uses a sphere to return a faster result than ST_Distance_Spheroid which returns the minimum distance between two lon/lat geometries given a particular spheroid.


0

Given an Esri coordinate reference system prj file (well-known text aka WKT), for RD New, DotSpatial is able to map it to a PROJ.4 string. RD New has an EPSG well-known ID of 28992. DotSpatial includes a +towgs84 parameter which is not part of the original wkt: ...


3

The length functions work differently with 3D linestring geometries: ST_Length - returns 2D distances for geometry types, and oddly 3D distances for geography types (but not in this question) ST_Length_Spheroid - returns 3D distances for geometry types Your example is in 3D, so it will calculate the 3D length with ST_Length_Spheroid and the 2D length ...


1

Postgis is correct. Your line is in 3d space, and in fact has a length of ~482m even in the British National Grid. 338 meters is also correct but it corespondents in the projection of the 3d line in the 2d space. with a as ( select st_Geomfromewkt('SRID=27700;MULTILINESTRING(( 423216.279 574665.249 0, 423206.315 574708.077 44.649, 423158.458 ...


2

If the degree coordinates should be in Helsinki (for which UTM zone 35 is correct), you should enter 24.9993393, 60.184716. Note that proj expects East - North order, with negative singns for Southern and western coodinates. Converted to EPSG:3067, the coordinates are 389042, 6673664.


3

The correct syntax is: cs2cs +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666 +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs +to +init=epsg:4326 -f %%.8f<nad.txt >out.txt with 987043 206407 in the input file nad.txt to get this output: -73.98992216 40.73321572 ...



Top 50 recent answers are included