Location wizard (missed window to select +towgs params)

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Location wizard (missed window to select +towgs params)

epifanio
Hi All,

i did svn up on the grass65 src code,
now tring to create a location

"  Gauss Boaga Rome 40 fuse E "

using :

 "location wizard -> select epsg code -> search for : 3004"

in the paste release (build less than 1 month ago) after select the epsg:code(3004)
grass prompt me to the window :

http://img534.imageshack.us/img534/8254/schermata20100312a09564.png

to select the +towgs parameters

with the latest svn version this window doesn't appair and  the locaqtion is created using the defaults parameters :

http://img705.imageshack.us/img705/6675/schermata20100312a10350.png


i can see there are recent code changes about the location wizard, maybe something is missed?
thanks for any comment.

Regards,

Massimo.


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Martin Landa
Hi,

2010/3/12 Massimo Di Stefano <[hidden email]>:

>  "location wizard -> select epsg code -> search for : 3004"
>
> in the paste release (build less than 1 month ago) after select the epsg:code(3004)
> grass prompt me to the window :
>
> http://img534.imageshack.us/img534/8254/schermata20100312a09564.png
>
> to select the +towgs parameters
>
> with the latest svn version this window doesn't appair and  the locaqtion is created using the defaults parameters :
>
> http://img705.imageshack.us/img705/6675/schermata20100312a10350.png

it seems to be bug in g.proj -

g.proj epsg=3004 datum=-1

no output is printed...

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Markus Neteler
On Fri, Mar 12, 2010 at 8:38 PM, Martin Landa <[hidden email]> wrote:

> Hi,
>
> 2010/3/12 Massimo Di Stefano <[hidden email]>:
>>  "location wizard -> select epsg code -> search for : 3004"
>>
>> in the paste release (build less than 1 month ago) after select the epsg:code(3004)
>> grass prompt me to the window :
>>
>> http://img534.imageshack.us/img534/8254/schermata20100312a09564.png
>>
>> to select the +towgs parameters
>>
>> with the latest svn version this window doesn't appair and  the locaqtion is created using the defaults parameters :
...
> it seems to be bug in g.proj -
>
> g.proj epsg=3004 datum=-1
>
> no output is printed...

When you add -t, it works:

g.proj epsg=3004 datum=-1 -t

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Martin Landa
Hi,

2010/3/12 Markus Neteler <[hidden email]>:

[...]

> When you add -t, it works:
>
> g.proj epsg=3004 datum=-1 -t

right, strange that it worked without -t flag some months ago. Anyway
it's confusing feature from user's perspective. I should assume that

g.proj epsg=3004 datum=-1

prints available datums for EPSG:3004.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Martin Landa
Hi,

2010/3/12 Martin Landa <[hidden email]>:

>> When you add -t, it works:
>>
>> g.proj epsg=3004 datum=-1 -t
>
> right, strange that it worked without -t flag some months ago. Anyway
> it's confusing feature from user's perspective. I should assume that
>
> g.proj epsg=3004 datum=-1
>
> prints available datums for EPSG:3004.

reported as #997.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Paul Kelly
In reply to this post by Markus Neteler
On Fri, 12 Mar 2010, Markus Neteler wrote:

> On Fri, Mar 12, 2010 at 8:38 PM, Martin Landa <[hidden email]> wrote:
>> Hi,
>>
>> 2010/3/12 Massimo Di Stefano <[hidden email]>:
>>>  "location wizard -> select epsg code -> search for : 3004"
>>>
>>> in the paste release (build less than 1 month ago) after select the epsg:code(3004)
>>> grass prompt me to the window :
>>>
>>> http://img534.imageshack.us/img534/8254/schermata20100312a09564.png
>>>
>>> to select the +towgs parameters
>>>
>>> with the latest svn version this window doesn't appair and  the locaqtion is created using the defaults parameters :
> ...
>> it seems to be bug in g.proj -
>>
>> g.proj epsg=3004 datum=-1
>>
>> no output is printed...
>
> When you add -t, it works:
>
> g.proj epsg=3004 datum=-1 -t
The fact that the -t flag needs to be specified, suggests that somehow
when g.proj is querying GDAL for a projection description for EPSG code
3004, it is coming back fully specified, i.e. with complete towgs84
parameters, and thus g.proj thinks the datum information is already all
specified and correct, so it doesn't even offer the option of modifying it
unless the user requests to override the datum information in the input
co-ordinate system with the -t flag. (I'm sure there is a logical reason
for working like that although it doesn't immediately come to mind at the
minute!)

I'm not very sure what's going on though. I will look into it, although it
might be 2-3 days before I have an answer.

Paul

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Paul Kelly
Hello all,
I have a little more insight on this. See below.

On Fri, 12 Mar 2010, Paul Kelly wrote:

> On Fri, 12 Mar 2010, Markus Neteler wrote:
>
>> On Fri, Mar 12, 2010 at 8:38 PM, Martin Landa <[hidden email]>
>> wrote:
>>> Hi,
>>>
>>> 2010/3/12 Massimo Di Stefano <[hidden email]>:
>>>>  "location wizard -> select epsg code -> search for : 3004"
>>>>
>>>> in the paste release (build less than 1 month ago) after select the
>>>> epsg:code(3004)
>>>> grass prompt me to the window :
>>>>
>>>> http://img534.imageshack.us/img534/8254/schermata20100312a09564.png
>>>>
>>>> to select the +towgs parameters
>>>>
>>>> with the latest svn version this window doesn't appair and  the locaqtion
>>>> is created using the default parameters :
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not correct, and indeed seems to be a clue as to what is going on.
The GRASS default parameters for rome40/Monte_Mario are
+towgs84=-225.000,-65.000,9.000
However the location is being created with the parameters
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
i.e. the parameters with the description "Used in Italy (Peninsular Part)"
from datumtransform.table.

This set of parameters is not being put there by GRASS; it is coming
through from GDAL when it is used to look up the EPSG code.

>> ...
>>> it seems to be bug in g.proj -
>>>
>>> g.proj epsg=3004 datum=-1
>>>
>>> no output is printed...
>>
>> When you add -t, it works:
>>
>> g.proj epsg=3004 datum=-1 -t
>
> The fact that the -t flag needs to be specified, suggests that somehow when
> g.proj is querying GDAL for a projection description for EPSG code 3004, it
> is coming back fully specified, i.e. with complete towgs84 parameters, and
> thus g.proj thinks the datum information is already all specified and
> correct, so it doesn't even offer the option of modifying it unless the user
> requests to override the datum information in the input co-ordinate system
> with the -t flag. (I'm sure there is a logical reason for working like that
> although it doesn't immediately come to mind at the minute!)
This is true, and as there have been very minimal changes in
general/g.proj and lib/proj between RC5 and now I was initially very
baffled. My latest hunch is to do with the CSV tables in lib/proj. I
notice Markus has updated them at least a couple of times since RC5 - the
latest change two weeks ago in r41248 with the description "backport from
GDAL: big upgrade to EPSG 7.4.1 with improved datum logic" sounds
particularly suspicious ;) I would hazard a guess that GDAL is now
attempting to make a "best guess" at which are the most appropriate
transformation parameters for a particular datum. Previously if there was
a choice it left them unspecified, and GRASS prompted the user. However
GRASS (i.e. g.proj) trusts the co-ordinate system it gets back from GDAL
and if the datum transformation parameters are already there, then it
doesn't query GDAL's decision! I don't subscribe to the GDAL developers
list any more as there was too much traffic, so it's likely I've missed
some discussion or announcement from Frank over there.

I haven't had time to test reverting the CSV files yet but if that works I
would suggest doing it, as if that is going to be the way GDAL works from
now on it will require quite a few changes to how g.proj works, and it is
much too late in the release cycle of 6.4.0 to go changing things there...

More later

Paul

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

hamish-2
In reply to this post by epifanio
Paul wrote:

> This is not correct, and indeed seems to be a clue as to
> what is going on. The GRASS default parameters for
> rome40/Monte_Mario are +towgs84=-225.000,-65.000,9.000
> However the location is being created with the parameters
> +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
> i.e. the parameters with the description "Used in Italy
> (Peninsular Part)" from datumtransform.table.
>
> This set of parameters is not being put there by GRASS; it
> is coming through from GDAL when it is used to look up the
> EPSG code.
...

> This is true, and as there have been very minimal changes
> in general/g.proj and lib/proj between RC5 and now I was
> initially very baffled. My latest hunch is to do with the
> CSV tables in lib/proj. I notice Markus has updated them at
> least a couple of times since RC5 - the latest change two
> weeks ago in r41248 with the description "backport from
> GDAL: big upgrade to EPSG 7.4.1 with improved datum logic"
> sounds particularly suspicious ;) I would hazard a guess
> that GDAL is now attempting to make a "best guess" at which
> are the most appropriate transformation parameters for a
> particular datum. Previously if there was a choice it left
> them unspecified, and GRASS prompted the user. However GRASS
> (i.e. g.proj) trusts the co-ordinate system it gets back
> from GDAL and if the datum transformation parameters are
> already there, then it doesn't query GDAL's decision! I
> don't subscribe to the GDAL developers list any more as
> there was too much traffic, so it's likely I've missed some
> discussion or announcement from Frank over there.
>
> I haven't had time to test reverting the CSV files yet but
> if that works I would suggest doing it, as if that is going
> to be the way GDAL works from now on it will require quite a
> few changes to how g.proj works, and it is much too late in
> the release cycle of 6.4.0 to go changing things there...

hmmm +file lib/proj/datum_shift.csv
in https://trac.osgeo.org/grass/changeset/41248

see also r41223.


Hamish



     
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Markus Neteler
On Mon, Mar 15, 2010 at 8:44 AM, Hamish <[hidden email]> wrote:
> Paul wrote:
...
>> I haven't had time to test reverting the CSV files yet but

(I wonder how CSV files could mess up a logic but how knows...
 Of course let's revert in 6.4 if this breaks things)

(it also reminds me of my suggestion to leave all this business
 to GDAL instead of having a potentially conflicting private
 solution, but of course one can see it also the other way round)

>> if that works I would suggest doing it, as if that is going
>> to be the way GDAL works from now on it will require quite a
>> few changes to how g.proj works, and it is much too late in
>> the release cycle of 6.4.0 to go changing things there...

Sure. Note: if so, it is the first time that CSV updates really break
the mechanism in GRASS.

> hmmm +file lib/proj/datum_shift.csv
> in https://trac.osgeo.org/grass/changeset/41248
>
> see also r41223.

FrankW has published a blog with details:

http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html

Perhaps that's giving more insights.

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

hamish-2
Markus wrote:
> FrankW has published a blog with details:
>
> http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html
>
> Perhaps that's giving more insights.

it does:

[...]
"While this got rid of one family of errors, it also triggered lots of additional frustration and confusion. Part of this was just because there was a change of behavior. But it was also pushing people a bit harder to determine the appropriate datum shift and they did not like having to do this.

So, at last, I have taken the plunge and reworked the scripts used to translate the EPSG dictionary so that they attempt to pick one shift if there are several available. I follow a few heuristics in this effort."
[...]


In the past GRASS has sided with correctness over convinence
(aka save time in the long term vs. short term); I suggest we
figure out a way to stick with our old "show the user a list
of alternatives and make them choose (forcing them to look it
up or make some phone calls, if necessary)" method.
it may be a PITA but in the long term you are doing them a big
favour. Software which are primarily data-viewers may have other
priorities of course.


"Currently GDAL, and the PROJ.4 dictionary are just using the preferred datum shift. But the intention of keeping the datum_shift.csv file with all the possible shifts for any given GCS is that savvy applications could let the user choose."


so for future merging we'll have to be more savvy.
(I'm pretty happy with our internal dautm.table and
datumtransform.table to be honest)

until then, I guess we revert the .csv files, while checking
for intermingled bug fixes if possible.


"datum_shift_pref.csv" prefers the 7-term NZGD49 transform over
the 3-term. But that ignores the NTv2 file if present(??).
And often you are given data known to be in the "less desirable"
transform parms (still used by the vast majority of other
software) but documented numeric consistency is more important
that keeping up with the latest transform ideas.


make 'em eat their veggies,
Hamish



     
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Paul Kelly
In reply to this post by Markus Neteler
On Mon, 15 Mar 2010, Markus Neteler wrote:

> On Mon, Mar 15, 2010 at 8:44 AM, Hamish <[hidden email]> wrote:
>> Paul wrote:
> ...
>>> I haven't had time to test reverting the CSV files yet but
>
> (I wonder how CSV files could mess up a logic but how knows...
> Of course let's revert in 6.4 if this breaks things)

Hi Markus, After reading Frank's blog post (thanks for the link) I
understand - simply the CSV files now contain datum transform parameters
for all the datums that previously had no parameters specified because
there was a choice, and as Frank said he thought it best to force the user
to make a decision - this suited GRASS very well since as Hamish mentioned
the decision only needs to be made once, when setting up a new location,
and it is no trouble to take a few extra minutes to determine what is the
best choice.

> (it also reminds me of my suggestion to leave all this business
> to GDAL instead of having a potentially conflicting private
> solution, but of course one can see it also the other way round)

Yes I definitely plan to do that in 7.x, but I note that the problem would
have been the same, except it would presumably have appeared more
noticeably after an upgrade to GDAL.

>>> if that works I would suggest doing it, as if that is going
>>> to be the way GDAL works from now on it will require quite a
>>> few changes to how g.proj works, and it is much too late in
>>> the release cycle of 6.4.0 to go changing things there...
>
> Sure. Note: if so, it is the first time that CSV updates really break
> the mechanism in GRASS.
>
>> hmmm +file lib/proj/datum_shift.csv
>> in https://trac.osgeo.org/grass/changeset/41248
>>
>> see also r41223.

I can confirm that
svn merge -c -41248 .
fixes 6.4 release branch. Any opinions on whether we should also revert
r41223, or should I just commit the reversion now?

Paul
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Markus Neteler
On Mon, Mar 15, 2010 at 4:10 PM, Paul Kelly
<[hidden email]> wrote:
> On Mon, 15 Mar 2010, Markus Neteler wrote:
>> On Mon, Mar 15, 2010 at 8:44 AM, Hamish <[hidden email]> wrote:
>>> Paul wrote:
...
> I can confirm that
> svn merge -c -41248 .
> fixes 6.4 release branch.

OK, so please revert it.

> Any opinions on whether we should also revert
> r41223, or should I just commit the reversion now?

I would keep r41223 since it appears to be a bugfix for the previous versions:
https://trac.osgeo.org/grass/changeset/41223

Of course it is a pity that CSV-sync'ing no longer works between
GDAL and GRASS.

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Location wizard (missed window to select +towgs params)

Paul Kelly
On Mon, 15 Mar 2010, Markus Neteler wrote:

> On Mon, Mar 15, 2010 at 4:10 PM, Paul Kelly
> <[hidden email]> wrote:
>> On Mon, 15 Mar 2010, Markus Neteler wrote:
>>> On Mon, Mar 15, 2010 at 8:44 AM, Hamish <[hidden email]> wrote:
>>>> Paul wrote:
> ...
>> I can confirm that
>> svn merge -c -41248 .
>> fixes 6.4 release branch.
>
> OK, so please revert it.

Done now in all branches. (r41248-51 reverted)

>> Any opinions on whether we should also revert
>> r41223, or should I just commit the reversion now?
>
> I would keep r41223 since it appears to be a bugfix for the previous versions:
> https://trac.osgeo.org/grass/changeset/41223

It's left as is.

> Of course it is a pity that CSV-sync'ing no longer works between
> GDAL and GRASS.

I suppose so, but there has been a big change in the datum transform
philosophy of GDAL and for the moment it is incompatible with GRASS. I
would imagine keeping things as-is for 6.x, but for 7.x extending g.proj
to also report the other possible datum transformations from the EPSG
database (obtained via GDAL) as well as GRASS's own parameters from
datum.table and datumtransform.table. I think it is necessary to keep the
internal GRASS lists because (a) the descriptions as to validity seem to
be more detailed than in the GDAL EPSG list - I need to check that for
sure but for Monte_Mario at first glance they seemed to be, and (b) there
is no support for gridshift-based transformations in the EPSG-derived
list.

Paul
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev