Hi,
trying to create new location from epsg number (#2258 [bug 5454]), the
gui locks up with the new location window open and the "define location"
button depressed. xkill killed both the locn and main startup gui, and
the new location exists in the list upon restart.
using debian/sarge tcltk 8.3 on a pentium4.
?,
Hamish
Is it only this one EPSG code? Or is it any code?
If it's just this code and we could figure out why it is problematic, I
could try to write a generic trap for such instances.
Michael
On 1/29/07 6:04 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Hi,
trying to create new location from epsg number (#2258 [bug 5454]), the
gui locks up with the new location window open and the "define location"
button depressed. xkill killed both the locn and main startup gui, and
the new location exists in the list upon restart.using debian/sarge tcltk 8.3 on a pentium4.
?,
Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
H:
> trying to create new location from epsg number (#2258 [bug 5454]),
> the gui locks up with the new location window open and the "define
> location" button depressed. xkill killed both the locn and main
> startup gui, and the new location exists in the list upon restart.
>
> using debian/sarge tcltk 8.3 on a pentium4.
Michael wrote:
Is it only this one EPSG code? Or is it any code?
any code.
starting with:
$ GRASS_WISH=wish8.4 grass63 -gui
does not help.
Hamish
Hi,
I can confirm this bug.
Problem is - this EPSG code requires aditional user input from comand
line - just try to run "g.proj -c proj4=+init=epsg:2258
location=EpsgBug" whithin GRASS session and g.proj will ask for
aditional parameters. As current tcl/tk code does not open xterm for
g.proj operations, it stucks on waiting user input from nonexisting
xterm app.
IMHO this should be fixed in g.proj first to make it independend from
interactive comandline usage and then startup screen can be fixed to
use new g.proj feature.
Sorry for bad news,
Maris.
2007/1/30, Michael Barton <michael.barton@asu.edu>:
Is it only this one EPSG code? Or is it any code?
If it's just this code and we could figure out why it is problematic, I
could try to write a generic trap for such instances.Michael
On 1/29/07 6:04 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
> Hi,
>
> trying to create new location from epsg number (#2258 [bug 5454]), the
> gui locks up with the new location window open and the "define location"
> button depressed. xkill killed both the locn and main startup gui, and
> the new location exists in the list upon restart.
>
> using debian/sarge tcltk 8.3 on a pentium4.
>
> ?,
> Hamish
>__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
ARRGH! I thought the EPSG module was beyond this...
Michael
On 1/30/07 3:22 AM, "Maris Nartiss" <maris.gis@gmail.com> wrote:
Hi,
I can confirm this bug.
Problem is - this EPSG code requires aditional user input from comand
line - just try to run "g.proj -c proj4=+init=epsg:2258
location=EpsgBug" whithin GRASS session and g.proj will ask for
aditional parameters. As current tcl/tk code does not open xterm for
g.proj operations, it stucks on waiting user input from nonexisting
xterm app.IMHO this should be fixed in g.proj first to make it independend from
interactive comandline usage and then startup screen can be fixed to
use new g.proj feature.Sorry for bad news,
Maris.2007/1/30, Michael Barton <michael.barton@asu.edu>:
Is it only this one EPSG code? Or is it any code?
If it's just this code and we could figure out why it is problematic, I
could try to write a generic trap for such instances.Michael
On 1/29/07 6:04 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Hi,
trying to create new location from epsg number (#2258 [bug 5454]), the
gui locks up with the new location window open and the "define location"
button depressed. xkill killed both the locn and main startup gui, and
the new location exists in the list upon restart.using debian/sarge tcltk 8.3 on a pentium4.
?,
Hamish__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Hello Maris
On Tue, 30 Jan 2007, Maris Nartiss wrote:
Hi,
I can confirm this bug.
Problem is - this EPSG code requires aditional user input from comand
line - just try to run "g.proj -c proj4=+init=epsg:2258
location=EpsgBug" whithin GRASS session and g.proj will ask for
aditional parameters. As current tcl/tk code does not open xterm for
g.proj operations, it stucks on waiting user input from nonexisting
xterm app.
The attached patch will run g.proj in a terminal Window in case it needs to prompt for user input. I think it is a good workaround for the time being?
IMHO this should be fixed in g.proj first to make it independend from
interactive comandline usage and then startup screen can be fixed to
use new g.proj feature.
How do you propose it is fixed? It is arguable IMHO that the problem is not in g.proj. It will only interactively prompt if *partially complete* datum information is passed to it. If the GUI passes projection information that has been pre-processed so the datum part is OK, then it will not interactively prompt. This was discussed in an earlier thread.
Paul
P.S. A similar patch should probably also be applied to file_set.tcl.
P.P.S. The recent little usability improvements to gis_set.tcl (new location automatically selected etc.) are great! Well done.
diff.txt (2.35 KB)
Paul Kelly wrote:
> I can confirm this bug.
>
> Problem is - this EPSG code requires aditional user input from comand
> line - just try to run "g.proj -c proj4=+init=epsg:2258
> location=EpsgBug" whithin GRASS session and g.proj will ask for
> aditional parameters. As current tcl/tk code does not open xterm for
> g.proj operations, it stucks on waiting user input from nonexisting
> xterm app.The attached patch will run g.proj in a terminal Window in case it needs
to prompt for user input. I think it is a good workaround for the time
being?
I think that "good workaround" is an oxymoron; workarounds have a
habit of relieving the pressure to actually fix the bug.
> IMHO this should be fixed in g.proj first to make it independend from
> interactive comandline usage and then startup screen can be fixed to
> use new g.proj feature.How do you propose it is fixed? It is arguable IMHO that the problem is
not in g.proj. It will only interactively prompt if *partially complete*
datum information is passed to it. If the GUI passes projection
information that has been pre-processed so the datum part is OK, then it
will not interactively prompt. This was discussed in an earlier thread.
Yes, and I proposed a solution: replace the call to
GPJ_ask_datum_params() with either a call to G_fatal_error() or some
form of error indication (e.g. "return -1"). Assuming the availability
of a terminal to obtain missing data from the user is a bug in
GPJ_osr_to_grass().
Unless someone else proposes an alternative solution soon, I intend to
change GPJ_osr_to_grass() to simply ignore the "interactive"
parameter; if datum parameters are missing, you get the defaults; it
will be up to the user to fix it afterwards. That approach has the
advantage that it doesn't require any changes to calling programs
(g.proj, v.in.ogr, r.in.gdal).
It isn't ideal, but it's a lot less non-ideal than assuming that a
terminal is available.
Also, note that g.proj already silently uses the default parameters if
you read the settings from stdin with wkt=- or proj4=-, so it isn't as
if we currently *insist* upon full datum information being provided.
--
Glynn Clements <glynn@gclements.plus.com>
First, Paul I truly appreciate your work on trying to find a way for the
TclTk GUI to deal with the xterm interaction in g.proj. This is certainly an
improvement over having the interface simply lock up mysteriously (and
thanks to Maris for discovering the cause of this so quickly).
That said, I have to agree with Glynn on the long term way to fix this. Any
module that depends on question/response interaction with a user via an
xterm is going to be problematic on any GUI that does not also depend on an
xterm. Given the limitations of the display technology in the older GRASS
xterm protocols, I agree that we should aim to stop depending on it.
A failure with an informational error message or using a set of defaults,
with a warning output to the user that some projection parameters are
lacking, should be as good as question/response in an xterm. This keeps the
projection process transparent, doesn't let the user enter incorrect or
incomplete information without being informed that he/she is doing so, and
doesn't run the risk of hanging an interface wrapped around GRASS. It is
also much better for scripting, where you don't want your script to hang
while waiting for user input from a non-existent xterm.
Finally, if the EPSG file contains incomplete projection information for
some entries, shouldn't that be fixed with whoever supplies this file? If
this becomes a useful way to create locations in GRASS, it needs to be an
accurate and complete list of projection parameters.
My 1.5 centimos worth...
Michael
On 1/30/07 3:45 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Paul Kelly wrote:
I can confirm this bug.
Problem is - this EPSG code requires aditional user input from comand
line - just try to run "g.proj -c proj4=+init=epsg:2258
location=EpsgBug" whithin GRASS session and g.proj will ask for
aditional parameters. As current tcl/tk code does not open xterm for
g.proj operations, it stucks on waiting user input from nonexisting
xterm app.The attached patch will run g.proj in a terminal Window in case it needs
to prompt for user input. I think it is a good workaround for the time
being?I think that "good workaround" is an oxymoron; workarounds have a
habit of relieving the pressure to actually fix the bug.IMHO this should be fixed in g.proj first to make it independend from
interactive comandline usage and then startup screen can be fixed to
use new g.proj feature.How do you propose it is fixed? It is arguable IMHO that the problem is
not in g.proj. It will only interactively prompt if *partially complete*
datum information is passed to it. If the GUI passes projection
information that has been pre-processed so the datum part is OK, then it
will not interactively prompt. This was discussed in an earlier thread.Yes, and I proposed a solution: replace the call to
GPJ_ask_datum_params() with either a call to G_fatal_error() or some
form of error indication (e.g. "return -1"). Assuming the availability
of a terminal to obtain missing data from the user is a bug in
GPJ_osr_to_grass().Unless someone else proposes an alternative solution soon, I intend to
change GPJ_osr_to_grass() to simply ignore the "interactive"
parameter; if datum parameters are missing, you get the defaults; it
will be up to the user to fix it afterwards. That approach has the
advantage that it doesn't require any changes to calling programs
(g.proj, v.in.ogr, r.in.gdal).It isn't ideal, but it's a lot less non-ideal than assuming that a
terminal is available.Also, note that g.proj already silently uses the default parameters if
you read the settings from stdin with wkt=- or proj4=-, so it isn't as
if we currently *insist* upon full datum information being provided.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Tue, 30 Jan 2007, Glynn Clements wrote:
Paul Kelly wrote:
How do you propose it is fixed? It is arguable IMHO that the problem is
not in g.proj. It will only interactively prompt if *partially complete*
datum information is passed to it. If the GUI passes projection
information that has been pre-processed so the datum part is OK, then it
will not interactively prompt. This was discussed in an earlier thread.Yes, and I proposed a solution: replace the call to
GPJ_ask_datum_params() with either a call to G_fatal_error() or some
form of error indication (e.g. "return -1"). Assuming the availability
of a terminal to obtain missing data from the user is a bug in
GPJ_osr_to_grass().Unless someone else proposes an alternative solution soon, I intend to
change GPJ_osr_to_grass() to simply ignore the "interactive"
parameter; if datum parameters are missing, you get the defaults; it
will be up to the user to fix it afterwards. That approach has the
advantage that it doesn't require any changes to calling programs
(g.proj, v.in.ogr, r.in.gdal).
If it has to be done I wouldn't like to see the functionality to choose datum parameters from the tables in GRASS relegated to only g.setproj. I was thinking along the lines of adding a new "interactive" flag to g.proj. If this flag was specified along with -p, -j, -w or -c it would prompt as at present if datum information was incomplete; if used along with the -d flag then after reporting the datum information it would ask the user if he/she wished to change the parameters.
And every other place that calls GPJ_osr_to_grass() or GPJ_wkt_to_grass() (I'm thinking of r.in.gdal and v.in.ogr and g.proj without the -i/interactive flag specified) would set the interactive flag in the function to 0.
It isn't ideal, but it's a lot less non-ideal than assuming that a
terminal is available.Also, note that g.proj already silently uses the default parameters if
you read the settings from stdin with wkt=- or proj4=-, so it isn't as
if we currently *insist* upon full datum information being provided.
Good point; I'd forgotten about that.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 30 Jan 2007, Michael Barton wrote:
Finally, if the EPSG file contains incomplete projection information for
some entries, shouldn't that be fixed with whoever supplies this file? If
this becomes a useful way to create locations in GRASS, it needs to be an
accurate and complete list of projection parameters.
The problem with that is that the choice of datum parameters is a subjective decision. It depends on the area covered by the user's data and the accuracy they require. There are many choices of datum transformation parameters for a particular datum - sometimes there is an indication that one is a good default, but often there isn't, and there isn't a universal way of determining this anyway (e.g. AFAIK some countries have laws passed that say a datum is actually defined by its relationship to WGS84 through a particular transformation). But a lot of datums are defined in other ways and the relationships to WGS84 are only an approximation.
We are also somewhat constrained by the historical structure of the datum tables in GRASS and the need for backward compatibility with existing locations. The original structure (dating from the late 90s or so) was based on the erroneous premise that there *was* only one correct set of parameters for each data, hence there are now two datum tables - datum.table and datumtransform.table. It is annoyingly complicated.
Paul
I was thinking that each transformation choice should be listed in the EPSG
file. Is this feasible?
Michael
On 1/31/07 4:04 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
We are also somewhat constrained by the historical structure of the datum
tables in GRASS and the need for backward compatibility with existing
locations. The original structure (dating from the late 90s or so) was
based on the erroneous premise that there *was* only one correct set of
parameters for each data, hence there are now two datum tables -
datum.table and datumtransform.table. It is annoyingly complicated.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Paul Kelly wrote:
>> How do you propose it is fixed? It is arguable IMHO that the problem is
>> not in g.proj. It will only interactively prompt if *partially complete*
>> datum information is passed to it. If the GUI passes projection
>> information that has been pre-processed so the datum part is OK, then it
>> will not interactively prompt. This was discussed in an earlier thread.
>
> Yes, and I proposed a solution: replace the call to
> GPJ_ask_datum_params() with either a call to G_fatal_error() or some
> form of error indication (e.g. "return -1"). Assuming the availability
> of a terminal to obtain missing data from the user is a bug in
> GPJ_osr_to_grass().
>
> Unless someone else proposes an alternative solution soon, I intend to
> change GPJ_osr_to_grass() to simply ignore the "interactive"
> parameter; if datum parameters are missing, you get the defaults; it
> will be up to the user to fix it afterwards. That approach has the
> advantage that it doesn't require any changes to calling programs
> (g.proj, v.in.ogr, r.in.gdal).If it has to be done I wouldn't like to see the functionality to choose
datum parameters from the tables in GRASS relegated to only g.setproj.
I was thinking along the lines of adding a new "interactive" flag to
g.proj.
That takes us back to the issue of the GUI needing to determine
whether or not a module is interactive. It's bad enough that modules
don't report (via --tcltk, --interface-description, etc) whether or
not they are interactive, but that can be fixed easily enough[1].
What can't easily be fixed is modules which are either interactive or
not depending upon the specific combination of flags and options; how
is a module supposed to communicate that information to the GUI?
[1] I was planning on adding an "interactive" field (and possibly
"xmonitor" or similar) to struct GModule, so that interactive modules
would do e.g.:
module = G_define_module();
...
module->interactive = YES;
This information would then be passed to the GUI so that it knows that
the module requires a terminal.
If this flag was specified along with -p, -j, -w or -c it would prompt as
at present if datum information was incomplete; if used along with the -d
flag then after reporting the datum information it would ask the user if
he/she wished to change the parameters.And every other place that calls GPJ_osr_to_grass() or GPJ_wkt_to_grass()
(I'm thinking of r.in.gdal and v.in.ogr and g.proj without the
-i/interactive flag specified) would set the interactive flag in the
function to 0.
IMHO, the right way to do this is to simply remove the interactive
flag from those functions, and leave it to the caller to update the
datum transformation if necessary.
g.setproj is at least consistent: it is interactive to the core, and
calls GPJ_ask_datum_params() directly. Other modules (i.e. g.proj,
r.in.gdal and v.in.ogr) should:
1. Provide an option to allow the user to specify any additional
parameters, e.g. "projparms=nadgrids=conus".
2. If complete information isn't provided by either the source data or
the aforementioned option, either:
a) use the default values and print a warning, or
b) generate an error indicating that you must manually specify either
nadgrids or towgs84 via the option.
--
Glynn Clements <glynn@gclements.plus.com>