Re: [GRASS-user] help with testing the location wizard for the upcoming release
Nikos wrote: Below, maybe not exactly something that helps the testing process... but, anyway here it goes: everything helps :) I guess it is not possible to follow the good old text- based way in building a custom coordinate system. So I guess you are missing the ability to set the datum transform terms? (+towgs84=) - Select coord sys parms from a list - tmerc - enter coeff's - ellipsoid only - grs80 - summary: +towgs84=0.0,0.0,0.0 :-( All is ok using the correct epsg code (e.g. 2100). However, what about replicating the above process with the new Wizard? epsg gives +datum=GGRS87, but that is not known to 'proj -ld' or GRASS's datum.table and datumtransform.table AFAICS. ? so the first thing to do is add it to datum*.table, then make the location wizard aware of datumtransform.table, and also have the location wizard have an option to prompt for custom datum transform terms. thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] help with testing the location wizard for the upcoming release
Hamish wrote: Hi, this is a general call for help. Hi, if anyone/everyone is able to help test, we have made some fixes to the wxGUI new location wizard since 6.4.3rc3, which really need to be tested well before the final release. We think all is ok now, but a messed up location projection definition and ruin everything downstream in the location, so it's an important thing to be totally sure of. since there are so many projections and datums and ways to select them, it's pretty hard to test for working/not working as we usally could do. Please try throwing your local odd-ball CRS at it and see what happens. (check all the way through to 'g.proj -p' and 'g.proj -j' in the final location session. make sure it does what you'd expect it to do. specifically how datum transforms are handled, and CRSs without a specificed datum or specified datum terms; usuing all methods of defining the projection system. see trac issues #1849 and #1967 for further details. [..] Below, maybe not exactly something that helps the testing process... but, anyway here it goes: I guess it is not possible to follow the good old text- based way in building a custom coordinate system. For example, like # grass64 -text [snip] LOCATION: hgrs87_test__ (enter list for a list of locations) MAPSET: PERMANENT (or mapsets within a location) DATABASE: /geo/grassdb/testing_ AFTER COMPLETING ALL ANSWERS, HIT ESCENTER TO CONTINUE (OR Ctrl-C TO CANCEL) # Would you like to create location hgrs87_test ? (y/n) [y] # To create a new LOCATION, you will need the following information: 1. The coordinate system for the database x,y (for imagery and other unreferenced data) Latitude-Longitude UTM Other Projection 2. The zone for the UTM database and all the necessary parameters for projections other than Latitude-Longitude, x,y, and UTM 3. The coordinates of the area to become the default region and the grid resolution of this region 4. A short, one-line description or title for the location Do you have all this information? (y/n) [y] # Please specify the coordinate system for location hgrs87_test A x,y B Latitude-Longitude C UTM D Other Projection RETURN to cancel D # Other Projection coordinate system? (y/n) [y] # Please enter a one line description for location hgrs87_test Hellenic Geodetic Reference System 1987 = Hellenic Geodetic Reference System 1987 = ok? (y/n) [y] Please specify projection name Enter 'list' for the list of available projections Hit RETURN to cancel request tmerc Do you wish to specify a geodetic datum for this location?(y/n) [y] Please specify datum name Enter 'list' for the list of available datums or 'custom' if you wish to enter custom parameters Hit RETURN to cancel request custom Please specify ellipsoid name Enter 'list' for the list of available ellipsoids Hit RETURN to cancel request grs80 Please specify datum transformation parameters in PROJ.4 syntax. Examples: towgs84=dx,dy,dz(3-parameter transformation) towgs84=dx,dy,dz,rx,ry,rz,m (7-parameter transformation) nadgrids=alaska (Tables-based grid-shifting transformation) Hit RETURN to cancel request towgs84=-199.87,74.79,246.62,0,0,0,0 Parameters to be used are: towgs84=-199.87,74.79,246.62,0,0,0,0 Is this correct?(y/n) [y] # Enter Scale Factor at the Central Meridian [1.00]: 0.9996 Enter Central Parallel (23N) :0 Enter Central Meridian (96W) :24 Enter False Easting [0.00]: 50 Enter False Northing [0.00]: Enter plural form of units [meters]: # ...which will define a Location --%--- g.proj -p -PROJ_INFO- name : Transverse Mercator towgs84: -199.87,74.79,246.62,0,0,0,0 proj : tmerc ellps : grs80 a : 6378137.00 es : 0.0066943800 f : 298.2572221010 k_0: 0.999600 lat_0 : 0.00 lon_0 : 24.00 x_0: 50.00 y_0: 0.00 -PROJ_UNITS unit : meter units : meters meters : 1.0 ---%-- All is ok using the
Re: [GRASS-user] help with testing the location wizard for the upcoming release
Hi, Using grass64_release revision revision 56596 I did not come across any problems in creating Locations (from custom prj parameters, from a georeferenced shape file, or directly from a prj file). 1. Location created from georeferenced data file [shape file from ArcGIS] g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc ellps : grs80 lat_1 : 64.25 lat_2 : 65.75 lat_0 : 65 lon_0 : -19 x_0: 50 y_0: 50 no_defs: defined -PROJ_UNITS unit : Meter units : Meters meters : 1 (Wed Jun 5 17:35:28 2013) Command finished (0 sec) 2. g.proj -p [on location created using custom PROJ.4 parameters: --- # ISN93 / Lambert 1993 3057 +proj=lcc +lat_1=64.25 +lat_2=65.75 +lat_0=65 +lon_0=-19 +x_0=50 +y_0=50 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs --- ] g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc ellps : grs80 lat_1 : 64.25 lat_2 : 65.75 lat_0 : 65 lon_0 : -19 x_0: 50 y_0: 50 towgs84: 0,0,0,0,0,0,0 no_defs: defined -PROJ_UNITS unit : Meter units : Meters meters : 1 (Wed Jun 5 17:38:50 2013) Command finished (0 sec) 3. Location created reading projection and datum terms from a PRJ file [from a shape file folder from ArcGIS] g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc ellps : grs80 lat_1 : 64.25 lat_2 : 65.75 lat_0 : 65 lon_0 : -19 x_0: 50 y_0: 50 no_defs: defined -PROJ_UNITS unit : Meter units : Meters meters : 1 (Wed Jun 5 17:42:37 2013) Command finished (0 sec) Jon On 26 May 2013, at 13:20, Hamish wrote: Hi, this is a general call for help. if anyone/everyone is able to help test, we have made some fixes to the wxGUI new location wizard since 6.4.3rc3, which really need to be tested well before the final release. We think all is ok now, but a messed up location projection definition and ruin everything downstream in the location, so it's an important thing to be totally sure of. since there are so many projections and datums and ways to select them, it's pretty hard to test for working/not working as we usally could do. Please try throwing your local odd-ball CRS at it and see what happens. (check all the way through to 'g.proj -p' and 'g.proj -j' in the final location session. make sure it does what you'd expect it to do. specifically how datum transforms are handled, and CRSs without a specificed datum or specified datum terms; usuing all methods of defining the projection system. see trac issues #1849 and #1967 for further details. known issues: users of proj 4.7.0 and 4.8.0 will get different results for the default datum transform terms. (PROJ.4 now decides differently, beyond our control) when reading from a .prj or WKT file, or creating from a geo- referenced file, with unspecified datum transform opts, you will not be prompted to enter them. the location will be created not mentioning them, but in the background PROJ.4 will assign some default value (of its choosing) silently. for those who use Subversion and compile, you know what to do; for those who don't, nightly test builds are available for Windows and Ubuntu. thanks a bunch, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] help with testing the location wizard for the upcoming release
Should have mentioned the platform: Mac OSX 10.7.5 On 5 Jun 2013, at 17:54, Jon Eiriksson wrote: Hi, Using grass64_release revision revision 56596 I did not come across any problems in creating Locations (from custom prj parameters, from a georeferenced shape file, or directly from a prj file). 1. Location created from georeferenced data file [shape file from ArcGIS] g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc ellps : grs80 lat_1 : 64.25 lat_2 : 65.75 lat_0 : 65 lon_0 : -19 x_0: 50 y_0: 50 no_defs: defined -PROJ_UNITS unit : Meter units : Meters meters : 1 (Wed Jun 5 17:35:28 2013) Command finished (0 sec) 2. g.proj -p [on location created using custom PROJ.4 parameters: --- # ISN93 / Lambert 1993 3057 +proj=lcc +lat_1=64.25 +lat_2=65.75 +lat_0=65 +lon_0=-19 +x_0=50 +y_0=50 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs --- ] g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc ellps : grs80 lat_1 : 64.25 lat_2 : 65.75 lat_0 : 65 lon_0 : -19 x_0: 50 y_0: 50 towgs84: 0,0,0,0,0,0,0 no_defs: defined -PROJ_UNITS unit : Meter units : Meters meters : 1 (Wed Jun 5 17:38:50 2013) Command finished (0 sec) 3. Location created reading projection and datum terms from a PRJ file [from a shape file folder from ArcGIS] g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc ellps : grs80 lat_1 : 64.25 lat_2 : 65.75 lat_0 : 65 lon_0 : -19 x_0: 50 y_0: 50 no_defs: defined -PROJ_UNITS unit : Meter units : Meters meters : 1 (Wed Jun 5 17:42:37 2013) Command finished (0 sec) Jon On 26 May 2013, at 13:20, Hamish wrote: Hi, this is a general call for help. if anyone/everyone is able to help test, we have made some fixes to the wxGUI new location wizard since 6.4.3rc3, which really need to be tested well before the final release. We think all is ok now, but a messed up location projection definition and ruin everything downstream in the location, so it's an important thing to be totally sure of. since there are so many projections and datums and ways to select them, it's pretty hard to test for working/not working as we usally could do. Please try throwing your local odd-ball CRS at it and see what happens. (check all the way through to 'g.proj -p' and 'g.proj -j' in the final location session. make sure it does what you'd expect it to do. specifically how datum transforms are handled, and CRSs without a specificed datum or specified datum terms; usuing all methods of defining the projection system. see trac issues #1849 and #1967 for further details. known issues: users of proj 4.7.0 and 4.8.0 will get different results for the default datum transform terms. (PROJ.4 now decides differently, beyond our control) when reading from a .prj or WKT file, or creating from a geo- referenced file, with unspecified datum transform opts, you will not be prompted to enter them. the location will be created not mentioning them, but in the background PROJ.4 will assign some default value (of its choosing) silently. for those who use Subversion and compile, you know what to do; for those who don't, nightly test builds are available for Windows and Ubuntu. thanks a bunch, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] help with testing the location wizard for the upcoming release
On 26/05/13 13:20, Hamish wrote: known issues: when reading from a .prj or WKT file, or creating from a geo- referenced file, with unspecified datum transform opts, you will not be prompted to enter them. the location will be created not mentioning them, but in the background PROJ.4 will assign some default value (of its choosing) silently. Trying to define a sector in Belgian Lambert (1972 or 2008) projections, I see the following oddity (linked to the above ?): Using EPSG codes, I do get prompted with a choice for either no transformation or one choice of transform parameters, but even when I chose Do not apply any datum transformations I get a sector with the towgs84 parameter defined for transformation. The same happens when I try to define these projections manually by choosing in a list. When I enter the proj4 string without the towgs84 parameter it works as expected, i.e. no towgs84 defined. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] help with testing the location wizard for the upcoming release
since there are so many projections and datums and ways to select them, it's pretty hard to test for working/not working as we usally could do. Please try throwing your local odd-ball CRS at it and see what happens. (check all the way through to 'g.proj -p' and 'g.proj -j' in the final location session. make sure it does what you'd expect it to do. EPSG 3416 ETRS89 / Austria Lambert System Info GRASS version: 6.5.svn GRASS SVN Revision: 56422 GIS Library Revision: 50936 (2012-02-25) GDAL/OGR: 1.9.2 PROJ4: Rel. 4.8.0, 6 March 2012 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) Select datum transformation 0 Do not apply any datum transformation g.region -p projection: 99 (Lambert Conformal Conic) zone: 0 datum: etrs89 ellipsoid: grs80 north: 1 south: 0 west: 0 east: 1 nsres: 1 ewres: 1 rows: 1 cols: 1 cells: 1 g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc datum : etrs89 ellps : grs80 lat_1 : 49 lat_2 : 46 lat_0 : 47.5 lon_0 : 13.33 x_0: 40 y_0: 40 no_defs: defined -PROJ_UNITS unit : metre units : metres meters : 1 g.proj -j +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33 +x_0=40 +y_0=40 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1 1 Used in whole etrs89 region: towgs84=0.000,0.000,0.000 (Default 3-Parameter Transformation) g.region -p projection: 99 (Lambert Conformal Conic) zone: 0 datum: etrs89 ellipsoid: grs80 north: 1 south: 0 west: 0 east: 1 nsres: 1 ewres: 1 rows: 1 cols: 1 cells: 1 g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc datum : etrs89 ellps : grs80 lat_1 : 49 lat_2 : 46 lat_0 : 47.5 lon_0 : 13.33 x_0: 40 y_0: 40 no_defs: defined towgs84: 0.000,0.000,0.000 -PROJ_UNITS unit : metre units : metres meters : 1 g.proj -j +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33 +x_0=40 +y_0=40 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1 GRASS version: 6.4.3svn GRASS SVN Revision: 56413 GIS Library Revision: 50937 (2012-02-25) GDAL/OGR: 1.9.2 PROJ4: Rel. 4.8.0, 6 March 2012 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) Select datum transformation 0 Do not apply any datum transformation g.region -p projection: 99 (Lambert Conformal Conic) zone: 0 datum: etrs89 ellipsoid: grs80 north: 1 south: 0 west: 0 east: 1 nsres: 1 ewres: 1 rows: 1 cols: 1 cells: 1 g.proj -p -PROJ_INFO- name : Lambert Conformal Conic proj : lcc datum : etrs89 ellps : grs80 lat_1 : 49 lat_2 : 46 lat_0 : 47.5 lon_0 : 13.33 x_0: 40 y_0: 40 no_defs: defined -PROJ_UNITS unit : metre units : metres meters : 1 g.proj -j +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33 +x_0=40
Re: [GRASS-user] help with testing the location wizard for the upcoming release
since there are so many projections and datums and ways to select them, it's pretty hard to test for working/not working as we usally could do. Please try throwing your local odd-ball CRS at it and see what happens. (check all the way through to 'g.proj -p' and 'g.proj -j' in the final location session. make sure it does what you'd expect it to do. gdalinfo iseldem.tif Driver: GTiff/GeoTIFF Files: iseldem.tif Size is 3117, 2601 Coordinate System is: PROJCS[Lambert Azimuthal Equal Area, GEOGCS[grs80, DATUM[European_Terrestrial_Reference_System_1989, SPHEROID[Geodetic_Reference_System_1980,6378137,298.257222101, AUTHORITY[EPSG,7019]], AUTHORITY[EPSG,6258]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Lambert_Azimuthal_Equal_Area], PARAMETER[latitude_of_center,52], PARAMETER[longitude_of_center,10], PARAMETER[false_easting,4321000], PARAMETER[false_northing,321], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (4471032.62800724990,2686202.52683254010) Pixel Size = (22.717005998822735,-22.717005998819641) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 4471032.628, 2686202.527) ( 11d58'53.33E, 47d16'16.87N) Lower Left ( 4471032.628, 2627115.594) ( 11d57'41.52E, 46d44'22.62N) Upper Right ( 4541841.536, 2686202.527) ( 12d54'57.39E, 47d15' 1.05N) Lower Right ( 4541841.536, 2627115.594) ( 12d53'11.78E, 46d43' 7.68N) Center ( 4506437.082, 2656659.061) ( 12d26'11.02E, 46d59'45.72N) location wizard = georeferenced file iseldem.tif g.region -p projection: 99 (Lambert Azimuthal Equal Area) zone: 0 datum: etrs89 ellipsoid: grs80 north: 2686202.52683254 south: 2627115.59422961 west: 4471032.62800725 east: 4541841.53570558 nsres: 22.717006 ewres: 22.717006 rows: 2601 cols: 3117 cells: 8107317 g.proj -p -PROJ_INFO- name : Lambert Azimuthal Equal Area proj : laea datum : etrs89 ellps : grs80 lat_0 : 52 lon_0 : 10 x_0: 4321000 y_0: 321 no_defs: defined -PROJ_UNITS unit : metre units : metres meters : 1 g.proj -j +proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=321 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1 - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/help-with-testing-the-location-wizard-for-the-upcoming-release-tp5055791p5055897.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] help with testing the location wizard for the upcoming release
since there are so many projections and datums and ways to select them, it's pretty hard to test for working/not working as we usally could do. Please try throwing your local odd-ball CRS at it and see what happens. (check all the way through to 'g.proj -p' and 'g.proj -j' in the final location session. make sure it does what you'd expect it to do. testgkat28.prj PROJCS[MGI_Ferro_M28, GEOGCS[GCS_MGI_Ferro, DATUM[D_MGI, SPHEROID[Bessel_1841,6377397.155,299.1528128]], PRIMEM[Ferro,-17.67], UNIT[Degree,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[False_Easting,15.0], PARAMETER[False_Northing,0.0], PARAMETER[Central_Meridian,28.0], PARAMETER[Scale_Factor,1.0], PARAMETER[Latitude_Of_Origin,0.0], UNIT[Meter,1.0]] GRASS version: 6.4.3svn GRASS SVN Revision: 56413 GIS Library Revision: 50937 (2012-02-25) GDAL/OGR: 1.9.2 PROJ4: Rel. 4.8.0, 6 March 2012 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) Select WKT or PRJ file g.region -p projection: 99 (Transverse Mercator) zone: 0 datum: hermannskogel ellipsoid: bessel north: 1 south: 0 west: 0 east: 1 nsres: 1 ewres: 1 rows: 1 cols: 1 cells: 1 g.proj -p -PROJ_INFO- name : Transverse Mercator proj : tmerc datum : hermannskogel ellps : bessel lat_0 : 0 lon_0 : 28 k : 1 x_0: 15 y_0: 0 pm : ferro no_defs: defined -PROJ_UNITS unit : Meter units : Meters meters : 1 g.proj -j +proj=tmerc +lat_0=0 +lon_0=28 +k=1 +x_0=15 +y_0=0 +pm=ferro +no_defs +a=6377397.155 +rf=299.1528128 +towgs84=653.000,-212.000,449.000 +to_meter=1 no asking which transformation should be used. Used in whole hermannskogel region: towwgs84=653.000,-212.000,449.000 is preselected, but not the best e.g. if location used for Austria. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/help-with-testing-the-location-wizard-for-the-upcoming-release-tp5055791p5055901.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] help with testing the location wizard for the upcoming release
Hi, this is a general call for help. if anyone/everyone is able to help test, we have made some fixes to the wxGUI new location wizard since 6.4.3rc3, which really need to be tested well before the final release. We think all is ok now, but a messed up location projection definition and ruin everything downstream in the location, so it's an important thing to be totally sure of. since there are so many projections and datums and ways to select them, it's pretty hard to test for working/not working as we usally could do. Please try throwing your local odd-ball CRS at it and see what happens. (check all the way through to 'g.proj -p' and 'g.proj -j' in the final location session. make sure it does what you'd expect it to do. specifically how datum transforms are handled, and CRSs without a specificed datum or specified datum terms; usuing all methods of defining the projection system. see trac issues #1849 and #1967 for further details. known issues: users of proj 4.7.0 and 4.8.0 will get different results for the default datum transform terms. (PROJ.4 now decides differently, beyond our control) when reading from a .prj or WKT file, or creating from a geo- referenced file, with unspecified datum transform opts, you will not be prompted to enter them. the location will be created not mentioning them, but in the background PROJ.4 will assign some default value (of its choosing) silently. for those who use Subversion and compile, you know what to do; for those who don't, nightly test builds are available for Windows and Ubuntu. thanks a bunch, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
