#667: please allow to export projection information in more formats
-----------------------+----------------------------------------------------
Reporter: timmie | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Compiling | Version: svn-develbranch6
Keywords: | Platform: Linux
Cpu: x86-32 |
-----------------------+----------------------------------------------------
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
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).
#667: please allow to export projection information in more formats
--------------------------+-------------------------------------------------
Reporter: timmie | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.proj
Platform: Linux | Cpu: x86-32
--------------------------+-------------------------------------------------
Comment (by timmie):
Replying to [comment:2 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.
#667: please allow to export projection information in more formats
--------------------------+-------------------------------------------------
Reporter: timmie | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.proj
Platform: Linux | Cpu: x86-32
--------------------------+-------------------------------------------------
Comment (by 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.
#667: please allow to export projection information in more formats
--------------------------+-------------------------------------------------
Reporter: timmie | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.proj
Platform: Linux | Cpu: x86-32
--------------------------+-------------------------------------------------
Comment (by 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..
#667: please allow to export projection information in more formats
--------------------------+-------------------------------------------------
Reporter: timmie | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.proj
Platform: Linux | Cpu: x86-32
--------------------------+-------------------------------------------------
Comment (by 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.
#667: please allow to export projection information in more formats
-------------------------+--------------------------------------------------
Reporter: timmie | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: Default | Version: svn-develbranch6
Keywords: g.proj | Platform: Linux
Cpu: x86-32 |
-------------------------+--------------------------------------------------
Comment(by 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
-p|-g' 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)