I'm affraid my email got lost in all that "whinging" debate so I'm resending
just in case. Please read below. Could that bug be easily fixed? It brings troubles to all using EPSG codes in Grass.
Maciek
From: "Harmish Bowman via RT" <grass-bugs@intevation.de>
>> GRASS 6.0.cvs:~ > d.barscale -m
..
>> unable to open panel No such file or directory
..
> Are you sure that "unable to open panel No such file or directory"
> is exact? I can't find that error message.
Yes, it is an EXACT copy/paste from the terminal output.
The only "unable to open panel" I could find was in
display/drivers/XDRIVER/XDRIVER24/Panel.c, but that is always "unable to
open
panel file".
?
Forgive me Hamish, you are right. It should be "unable to open panel file:
No such file or directory" like you say.
My finger had to slip when coping/pasting then.
> does running:
> g.tempfile pid=$$
> seem to work correctly?
After running g.tempfile pid=$$ I get:
/home/grassdata/caves92/PERMANENT/.tmp/localhost/3219.0
Is that what it should be?
Yes, I wanted to check if your temporary directory was writeable.
Seems to be ok.
Do you see the same problem if you try from a newly created location &
mapset?
Yes - but only if creating a new location from EPSG code! And this way I
found the reson that d.barscale doesn't work: the PROJ_INFO file syntax is
different when a location is set up via the Grass interface and when
automatically generated from EPSG code. See this:
Via Grass set up:
unit: meter
units: meters
meters: 1.0
Automatic, from EPSG 2180:
unit: metre
units: metres
meter: 1
After replacing the automatic one with the Grass one d.barscale works fine.
Could there be any more commands which don't like the EPSG-generated
PROJ_INFO files?
just in case. Please read below. Could that bug be easily fixed? It brings troubles to all using EPSG codes in Grass.
[...]
Yes - but only if creating a new location from EPSG code! And this way I
found the reson that d.barscale doesn't work: the PROJ_INFO file syntax is
different when a location is set up via the Grass interface and when
automatically generated from EPSG code. See this:
Via Grass set up:
unit: meter
units: meters
meters: 1.0
Automatic, from EPSG 2180:
unit: metre
units: metres
meter: 1
Wow. What a long-standing bug you found---this has been in the automatic location generating code in r.in.gdal for 4 years and was propagated into the gproj library in 5.7. It should of course be meters: 1, not meter: 1.
I have fixed in CVS. Just goes to show how little-used PROJ_UNITS is I suppose.
> Via Grass set up:
>
> unit: meter
> units: meters
> meters: 1.0
>
> Automatic, from EPSG 2180:
>
> unit: metre
> units: metres
> meter: 1
>
Wow. What a long-standing bug you found---this has been in the
automatic location generating code in r.in.gdal for 4 years and was
propagated into the gproj library in 5.7. It should of course be
meters: 1, not meter: 1.
I have fixed in CVS. Just goes to show how little-used PROJ_UNITS is I
suppose.
does "unit: metre" vs "unit: meter" make a difference to anything?
can "meters: x" be set so it can used in Lat/Lon locations for scaling?
(realizing it will only be accutate on one axis)
1852.0*60
does "unit: metre" vs "unit: meter" make a difference to anything?
That would be returned by the function G_database_unit_name().
Grepping in the 5.7/6 tree shows only ps.map using it.
Functions in the gproj library access the value directly from an input PROJ_UNITS and it is used in all WKT projection descriptions created by GRASS. Sidenote that the WKT format doesn't allow specification of the plural of the unit name so you can end up with things like units: foots when automatically generating a location.
In 5.4 there is also p.map, i.points3, v.digit, v.out.idrisi, v.import at least.
can "meters: x" be set so it can used in Lat/Lon locations for scaling?
(realizing it will only be accutate on one axis)
1852.0*60
Maybe. But does it not change depending on where you are standing?