On Sat, Jun 15, 2013 at 12:39 PM, <svn_grass@osgeo.org> wrote:
Author: hamish
Date: 2013-06-15 03:39:21 -0700 (Sat, 15 Jun 2013)
New Revision: 56717Modified:
grass/trunk/demolocation/PERMANENT/PROJ_INFO
Log:
"no defaults" not needed here. (see /usr/share/proj/proj_def.dat)
... then our mechanism to generate EPSG 4326 is suboptimal and
needs to be fixed. See
http://trac.osgeo.org/grass/changeset/56715
Markus
Hamish:
grass/trunk/demolocation/PERMANENT/PROJ_INFO
> Log:
> "no defaults" not needed here. (see /usr/share/proj/proj_def.dat)
MarkusN:
... then our mechanism to generate EPSG 4326 is suboptimal
yes, that is known since 'g.proj -c' first arrived; grass's
datum and projection support is better developed than proj4's
(at least from the POV of grass's libs). By making grass's
support = proj4's (e.g. assuming 'g.proj -c' results are the
acme) we limit ourselves and make our own support worse. So
we take advantage of what proj4 offers, but we are not limited
by it, and do not become it.
Responding to an earlier email by Nikos, it is also known that the
location wizard is not as exact as the text based g.setproj. e.g.
the location wizard does not support extra known-to-grass datums
and US FIPS county codes, and all the g.proj conversions to and
from WKT and +proj4 strings are many and not perfect. It's also
known that g.setproj can't take EPSG and georef'd files as input,
so less convenient.
and needs to be fixed.
in the case of the demolocation PROJ_INFO file I think it's
enough to just craft it by hand to make it as it should be.
For locations created by 'g.proj -c' it's always going to be
laundered through proj4 (actually it's OGR lib code) and that
incurs some proj4-related cruft. shrug, that's the cost of
using proj4 to create locations I guess.
regards,
Hamish
On Sat, Jun 15, 2013 at 1:08 PM, Hamish <hamish_b@yahoo.com> wrote:
...
in the case of the demolocation PROJ_INFO file I think it's
enough to just craft it by hand to make it as it should be.
Well, then this should be followed by a test if "v.unpack"
works with it. All problems arose while trying to transfer
a country map (from NaturalEarth )into it which I prepared
time ago in a different latlong location.
Markus
Hamish wrote:
> in the case of the demolocation PROJ_INFO file I think
> it's enough to just craft it by hand to make it as it should
> be.
MarkusN:
Well, then this should be followed by a test if "v.unpack"
works with it. All problems arose while trying to transfer
a country map (from NaturalEarth )into it which I prepared
time ago in a different latlong location.
The v.unpack projection matching method is fundamentally flawed
and should not be trusted.
line 102:# check projection compatibility in a rather crappy way"
I designed the check and wrote that comment in the initial
checkin of r.unpack, but to be honest I never meant for those
*.pack modules to become a core part of GRASS, they were just
some quick scripts I threw together and put in addons svn in
case they'd be useful to someone.
To see why it is so bad you can go back to the extended fun QGIS
and Maciek both had with epsg numeric precision issues when the
checks were based on exact string matches, and then the string
rounding changed one day.
It is not impossible to write a good check, but as an
understatement, it is rather complicated.
regards,
Hamish
On Sat, Jun 15, 2013 at 1:33 PM, Hamish <hamish_b@yahoo.com> wrote:
...
The v.unpack projection matching method is fundamentally flawed
and should not be trusted.line 102:# check projection compatibility in a rather crappy way"
...
It is not impossible to write a good check, but as an
understatement, it is rather complicated.
Perhaps it would be worthwhile to get the (good) checks done in
v.in.ogr into the Python API?
Markus
Markus Neteler wrote:
Perhaps it would be worthwhile to get the (good) checks done
in v.in.ogr into the Python API?
a generic way to do that would be quite a useful thing indeed.
v.in.ogr's checks are still not perfect but at least it would
outsource the tricky problem to a quality resource.
what's the status of using ctypes in grass7 to access libgis
and the other C libraries? can it be relied on for core needs?
Hamish