Tag Info

Hot answers tagged

9

PyProj assumes that your coordinates are in meters. I'd guess something relating to feet/meters is the cause of the issue. Calling a Proj class instance with the arguments lon, lat will convert lon/lat (in degrees) to x/y native map projection coordinates (in meters) If the optional keyword 'preserve_units' is True, the units in map ...


8

First, Proj4 uses what EPSG calls the "Position Vector" version of the 7 parameter method. It's possible that GeoTrans and Leica GeoOffice use the other version which EPSG called "Coordinate Frame". Both methods are equivalent, but the rotation matrices are different and the signs of the angular parameters have to be changed. Second, thank you for ...


7

The OGR Spatial Reference part of GDAL should do the trick. capooti provided an excellent answer to another question which demonstrates how to peform the translation from a shapefile to WKT. You may also want to check out the class reference. The reverse is simply: from osgeo import osr srs = osr.SpatialReference() wkt_text = ...


7

It might be tricky to handle Robinson from within ggplot2. AFAIK ggplot2 coord_map solution you explored will use projection information as defined in mapproject package. There are few available there but unfortunately Robinson is not one of them and I'm not sure if you can add your own. Also - the world data you are using (from ggmap package I presume) ...


6

I get the same results as @geographika when I run gdaltransform and the proj.4 tool cs2cs: $ gdaltransform -s_srs EPSG:3734 -t_srs EPSG:4326 739400.9 2339327.3 -87.3195485720169 45.9860670658218 0 cs2cs +proj=lcc +lat_1=41.7 +lat_2=40.43333333333333 +lat_0=39.66666666666666 +lon_0=-82.5 +x_0=600000 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=us-ft ...


6

You could explicitly set the output coordinate range using the target extent option to gdalwarp (ie. "-te -180 -90 180 90") but you can also use the CENTER_LONG configuration option to force rewrapping around a new central longitude. Something like this: gdalwarp -t_srs WGS84 ~/0_360.tif 180.tif -wo SOURCE_EXTRA=1000 \ --config CENTER_LONG 0 ...


6

Your input coordinates are in the wrong order. Pyproj expects long, lat. >>> import pyproj >>> p = pyproj.Proj(init='epsg:32633') >>> p(*p(15.6, 58.4), inverse=True) (15.6, 58.399999999999991)


6

It's EPSG:6372, a projection for Mexico, defined by the Instituto Nacional de Estadística y Geografía (INEGI).


5

I've run your coordinates through gdaltransform: $ gdaltransform -s_srs EPSG:32017 -t_srs EPSG:4326 759232.003438, 1149854.52147 -77.6116223688997 43.1517747887723 0 And it appears to come up with the right answer. This means that proj4 (which GDAL and PyProj are based on) is doing the right thing. Sometimes these sorts of errors can be caused by ...


5

Your source coordinate system is most likely not defined in the CVS file that GDAL searches for proj4 strings. It looks like you might be able to pass the source EPSG as 3031 (from spatialreference.org) Note that it looks like your input is in a local projection. Is this clipped from a larger raster? To explicitly define the source you could just provide ...


5

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


5

For such problems, I try to visualize the points in QGIS to see where they are placed. From your parameters, I created a custom CRS with the definition: +proj=sterea +lat_0=54.4353877827032 +lon_0=18.4514121640352 +k=0.999790760649094 +x_0=41614.2107651061 +y_0=17150.1692507701 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs and created points in ...


4

Looking here, you can use the +pm parameter to specify your own prime meridian relative to Greenwich, so using this command: $ cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=180dW I get this: 0.0 0.0 180dE 0dN 0.000 1 0 181dE 0dN 0.000 179 0 359dE 0dN 0.000 -179 0 1dE 0dN 0.000 Which seems to be what you want. I'm not ...


4

Well, screw the ordnance survey of Mecklenburg-Vorpommern (and Brandenburg for that matter). They decided to go with their own custom CRS which add a leading 3 or 33 to the easting value (must remind them of their beloved Gauß-Krüger coordinates I suppose). I know that at least in Brandenburg they were offically forced to use the official UTM variants in the ...


4

If you read carefully the page you mentioned first, you see that EPSG:29902 is the correct CRS. The shapefiles do not have a .prj file. For reprojecting, you might create one on your own, or load the data in QGIS, set the CRS to EPSG:29902, and Save As... QGIS creates the following prj file: ...


4

As was stated in the comments, QGIS doesn't do interrupted projections. You could use the Generic Mapping Tools (GMT) to reproject your vector files strip by strip and stitch them together. Note that for making a globe, you probably want the transverse Mercator projection (that's also the one used in the boehmwanderkarten.de code): This image was created ...


4

The shapefile should have a .prj file which defines the projection. You can use it together with one of the following 3 options to get either the proj4 string, WKT definition or EPSG code. To get proj4 definition: If you have gdal installed on your system, you can use the gdalsrsinfo command line application to get the proj4 definition as the OGC WKT ...


4

After further investigation, I've managed to solve the problem. What is causing the problem is that Proj4js will dynamically load any parts it needs rather than immediately loading all of it's scripts. Internet Explorer has most trouble with this, but also Firefox and Chrome show the symptom. IE managed to not be able to use any transformations, even after ...


3

For any projection different than EPSG:4326 and EPSG:900913 you need to attach the proj4js project with projection definitions


3

Did you import the proj4js definitions for EPSG:27700? http://spatialreference.org/ref/epsg/27700/proj4js/ 27700 is not included by default.


3

SELECT ST_AsEWKT(st_setsrid(ST_Transform(ST_Transform(ST_SetSRID(ST_Point(-633510.090428,7506727.67383),900913),4269),4326),4326));


3

I had similar problem and this helped me http://www.mail-archive.com/postgis-users@postgis.refractions.net/msg12634.html Copying the directory \share\contrib\postgis\proj from the zip to program files (C:\Program Files\PostgreSQL\9.1alpha1\share\contrib\postgis\proj ) and restarting postgres helped. (but on Ubuntu)


3

I don't think it is well defined as UTM 30 is outside the US and the rest of us don't use NAD83 as a datum. Spatialreference.org provides a list of possible datums you could chose.


3

This might be the correct EPSG Code (4044): http://spatialreference.org/ref/epsg/4044/ Confirm the parmeters based on the WKT definition : http://spatialreference.org/ref/epsg/4044/prettywkt/


3

You can have a look at the proj4text string, and whether or not it has "+units=x" (usually m for metres) in there. @dariapra's answer implies that all cartesian co-ordinate systems are projected using Universal Transverse Mercator, which isn't the case at all.


3

You seem to be looking to conduct an affine transformation between your local coordinate system and a georeferenced coordinate system. Affine transforms underly all coordinate systems and can be represented by the matrix equation below. |x_1 y_1 1| |a d| |x'_1 y'_1| |x_2 y_2 1| |b e| = |x'_2 y'_2| |x_3 y_3 1| |c f| |x'_3 y'_3| input transform. ...


3

For proj4, the signs of the parameters have to be reversed. See this definition page: http://www.spatialreference.org/ref/epsg/62826405/prettywkt/ GEOGCS["Pointe Noire (deg)", DATUM["Congo 1960 Pointe Noire", SPHEROID["Clarke 1880 (IGN)",6378249.2,293.4660212936269, AUTHORITY["EPSG","7011"]], ...


3

I'd add the +towgs84 parameters in EPSG:2322 definition in order to have a quite correct transformation (accuracy: 2 meters), as reported here (EPSG Geodetic Parameter Dataset): Proj4js.defs["EPSG:2322"] = "+proj=tmerc +lat_0=0 +lon_0=36 +k=1 +x_0=500000 +y_0=0 +ellps=intl +units=m +towgs84=-84.1,-101.8,-129.7,0,0,0.468,1.05 +no_defs";


3

The files are in EPSG:27700 OSGB 1936 British National Grid. Make sure you have the 7 parameters +towgs84 installed. There are 3-paramater datasets around, which have some offset.


3

You can cheat, because the EPSG numbers for UTM zones have a pattern than incorporates the zone number. 269ZZ for UTM north zones, where ZZ is the zone number 327ZZ for UTM south zones, where ZZ is the zone number And, since PostGIS uses the EPSG number for the SRID, you're all set.



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