please allow to export projection information in more formats

[timmie]

There are several modules which print region or projection information: g.region, g.proj, etc.

Please add the following output formats:

• EPSG code
• GMT format

[timmie]

An example for formats of interest is at: ​http://spatialreference.org/ref/epsg/4326/

[hamish]

THis is only appropriate for g.proj. see other tickets regarding storing +proj string in the WKT of v.out.ogr and r.out.gdal maps. EPSG number is expanded, it's not really a reverable process (e.g. datum transform params can be added after).

Also, what does GMT format look like?

Hamish

[timmie]

Replying to hamish:

THis is only appropriate for g.proj. see other tickets regarding storing +proj string in the WKT of v.out.ogr and r.out.gdal maps.

OK.

EPSG number is expanded, it's not really a reverable process (e.g. datum transform params can be added after).

But difficult at time when you want to reproject data outside GRASS with gdal or ogr based on EPSG number.

Also, what does GMT format look like?

It's like:

-JB-100/35/33/45/6i

May aim with this proposal is to ease the process of sharing projection information. proj4 has its format which can be printed by GRASS. ESRI hat its format which can be saved by v.out.ogr GMT have another format... So I though that EPSG would unify this a bit.

[hamish]

Also, what does GMT format look like?

It's like:

-JB-100/35/33/45/6i

I'm not sure what the -JB and /6i are for

       -R     xmin, xmax, ymin, and ymax specify the Region of interest.
              For  geographic  regions, these limits correspond to west,
              east, south, and north and you may specify them in decimal
              degrees  or in [+-]dd:mm[:ss.xxx][W|E|S|N] format.  Append
              r if lower left and upper right map coordinates are  given
              instead  of  wesn.   The  two shorthands -Rg -Rd stand for
              global domain (0/360 or  -180/+180  in  longitude  respec-
              tively,  with  -90/+90  in  latitude).

they use the same D:M:S format as us, should be pretty easy to add a new -t flag for that... standby.

Hamish

[hamish]

[GMT] use the same D:M:S format as us, should be pretty easy to add a new -t flag for that... standby.

done in devbr6 and trunk in r38139 and r38140.

Hamish

[timmie]

Thanks.

Do you not think that the format +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

or GEOGCS["WGS 84",

DATUM["WGS_1984",

SPHEROID["WGS 84",6378137,298.257223563,

AUTHORITY["EPSG","7030"]],

AUTHORITY["EPSG","6326"]],

PRIMEM["Greenwich",0,

AUTHORITY["EPSG","8901"]],

UNIT["degree",0.01745329251994328,

AUTHORITY["EPSG","9122"]],

AUTHORITY["EPSG","4326"]]

cannot be converted back to the corresponding EPSG number?

Here are some python modules that may help us: ​http://mateusz.loskot.net/software/gis/pyepsglookup/ ​http://pyproj.googlecode.com/svn/trunk/README.html

[hamish]

Do you not think that the format +proj=longlat +ellps=WGS84 +datum=WGS84

...

cannot be converted back to the corresponding EPSG number?

adding datum transform parameters is a non-reversible process. likely there is precision and other translation/expansion issues as well. Neither Frank's EPSG DB -> PROJ.4 epsg file nor QGIS's +proj4 term matching code has a solution yet, and that's before you consider that we maintain our own ellipse and datum tables which may add and/or modify terms.

I don't want to say it can't be done, but it's not easy and I would not trust well any result which claims to be able do it to be complete. IMHO better to just use the explicit expanded version and not worry..

Hamish

[timmie]

There are 2 cases where I think the EPSG code can be stored and later printed: 1) location wizard -> create location with EPSG code => the code is entered by the user. it can be stored by GRASS 2) location wizard -> create location with georeferenced file => the code is mostely retrived by gdalinfo or ogrinfo.

[hamish]

For keeping track of the EPSG code used to create the location, try r49298 in trunk.

the wxPy location wizard (ie 'g.proj -c') should now save a PERMANENT/PROJ_EPSG file in locations created by epsg code, and 'g.proj -pg' will display it.

NOTE: The EPSG code is preserved for historical metadata interest only; the contents of this file are not used by pj_*() routines at all. The PROJ_INFO file contains the active projection parameters; to avoid conflicts of consistency this term should not be mixed into that file or used in its place. (e.g. the epsg code typically does not define datum transform parameters, or in the case of current PROJ 4.7.1svn's copy it can contain incorrect datum transform terms)

Hamish

[hamish]

printing the region in GMT style was already accomplished with 'g.region -t'. (see comment:5)

Hamish