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.
On Sat, Jun 15, 2013 at 1:33 PM, Hamish 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 i
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
On Sat, Jun 15, 2013 at 1:08 PM, 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.
Well, then this should be followed by a test if "v.unpack"
works with it. All problems arose while trying to transfer
a co
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 b
On Sat, Jun 15, 2013 at 12:39 PM, wrote:
> Author: hamish
> Date: 2013-06-15 03:39:21 -0700 (Sat, 15 Jun 2013)
> New Revision: 56717
>
> Modified:
>grass/trunk/demolocation/PERMANENT/PROJ_INFO
> Log:
> "no defaults" not needed here. (see /usr/share/proj/proj_def.dat)
... then our mechanism t
