Wed, Mar 16 2005
09:35:38
|
|
Request created by hbowman (as #3096)
|
|
Subject: ps.map: Scale is all screwed up in Lat/Lon
grass 6.1-cvs mar 2005
When making a lat/lon map with ps.map, the scale is all messed up.
a map covering 3x4 degrees on an A4 page reports a scale of "1:16".
trying to adjust with the 'scale' ps.map command does nothing.
You have to size the map with maploc and page border size, but that doesn't
work very well.
also I think there might be a problem with the bounding box if you use the -r
rotate flag for a landscape page layout. gv and gnome-gv cut off the page at
about the portait page width if you tell it to display in landscape mode.
(not LL specific)
Hamish
|
|
Mon, Jan 29 2007
00:51:31
|
|
Request created by guest
|
|
Subject: ps.map scaling not correct when projection units are feet
Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: CVS HEAD 20070127 at 04:18 UTC
Noticed a strange anomaly in ps.map output when working in a State Plane Coordinate
System with coordinates in feet. Specifying any scale in ps.map gives manifestly
incorrect scaling. The scalebar produced also bears no obvious relationship
to the scale of the map.
To reproduce: create a location in New Mexico State Plane Coordinates, Central
Zone, NAD83 (EPSG number 2258). The result will have a PROJ_INFO file like this:
name: Transverse Mercator
proj: tmerc
datum: nad83
towgs84: 0.000,0.000,0.000
ellps: grs80
lat_0: 31
lon_0: -106.25
k: 0.999900
x_0: 500000.0001016001
y_0: 0
no_defs: defined
and a PROJ_UNITS file of:
unit: US survey foot
units: US survey foots
meters: 0.3048006096012192
Set the region to something arbitrary, for example:
> g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum: nad83
ellipsoid: grs80
north: 1485814.68884
south: 1485263.50884
west: 1525396.34529
east: 1526171.30805
nsres: 0.61310345
ewres: 0.61310345
rows: 899
cols: 1264
cells: 1136336
Now use the following ps.map file to generate postscript:
paper a0
end
scalebar f
where 1.5 1.5
length 500
height .25
segment 5
numbers 2
fontsize 12
end
mapinfo
where 11.5 15
fontsize 12
end
grid 100
color black
numbers 2
end
This should display a 100 foot grid and nothing else, and should have a
scale bar with 100 foot markings that match the grid size.
For the region specified above, ps.map will select "1:982" as the scale. Now
try tinkering with the scale by adding scale commands to the ps.map file. Even
selecting "1:982" will give completely different results than leaving the scale
out altogether. As you change scale, the scalebar will not change size to reflect
the change in the map grid.
I dug around a little in the source code, but couldn't find an obvious reason
for why this is happening. I thought it might be that the G_database_units_to_meters
function might be returning the wrong value, but I haven't actually tried to
debug so I'm not ready to say that's it.
I do not see the same behavior in a UTM location (where units are in meters).
|
|
Tue, Jan 30 2007
03:18:21
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 30 Jan 2007 15:16:46 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it, russo@bogodyn.org
|
Subject |
Re: [GRASS-dev] [bug #5454] (grass) ps.map scaling not correct when projection units are feet
|
Message-Id |
<20070130151646.4280e0ab.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20070128235131.698C01005B4@lists.intevation.de>
|
References |
<20070128235131.698C01005B4@lists.intevation.de>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
|
X-Spam-Level |
|
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5454
> ---------------------------------------------------------------------
>
> Subject: ps.map scaling not correct when projection units are feet
>
> Platform: GNU/Linux/x86
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> GRASS Version: CVS HEAD 20070127 at 04:18 UTC
>
> Noticed a strange anomaly in ps.map output when working in a State
> Plane Coordinate System with coordinates in feet. Specifying any
> scale in ps.map gives manifestly incorrect scaling. The scalebar
> produced also bears no obvious relationship to the scale of the map.
>
> To reproduce: create a location in New Mexico State Plane
> Coordinates, Central Zone, NAD83 (EPSG number 2258). The result will
> have a PROJ_INFO file like this: name: Transverse Mercator
> proj: tmerc
> datum: nad83
> towgs84: 0.000,0.000,0.000
> ellps: grs80
> lat_0: 31
> lon_0: -106.25
> k: 0.999900
> x_0: 500000.0001016001
> y_0: 0
> no_defs: defined
>
> and a PROJ_UNITS file of:
> unit: US survey foot
> units: US survey foots
foots? ^^^^^^^
> meters: 0.3048006096012192
>
>
> Set the region to something arbitrary, for example:
>
> > g.region -p
> projection: 99 (Transverse Mercator)
> zone: 0
> datum: nad83
> ellipsoid: grs80
> north: 1485814.68884
> south: 1485263.50884
> west: 1525396.34529
> east: 1526171.30805
> nsres: 0.61310345
> ewres: 0.61310345
> rows: 899
> cols: 1264
> cells: 1136336
>
>
> Now use the following ps.map file to generate postscript:
>
> paper a0
> end
> scalebar f
> where 1.5 1.5
> length 500
> height .25
> segment 5
> numbers 2
> fontsize 12
> end
> mapinfo
> where 11.5 15
> fontsize 12
> end
> grid 100
> color black
> numbers 2
> end
note you need one more "end" to finish the command list.
I moved scalebar & info into the middle of the page:
paper a0
end
scalebar f
where 15.5 25.5
length 500
height .25
segment 5
numbers 1
fontsize 12
end
mapinfo
where 11.5 27
fontsize 12
end
grid 100
color black
numbers 2
end
end
> This should display a 100 foot grid and nothing else, and should have
> a scale bar with 100 foot markings that match the grid size.
yep.
> For the region specified above, ps.map will select "1:982" as the
> scale. Now try tinkering with the scale by adding scale commands to
> the ps.map file. Even selecting "1:982" will give completely
> different results than leaving the scale out altogether. As you
> change scale, the scalebar will not change size to reflect the change
> in the map grid.
G63> g.region -e
north-south extent: 551.180000
east-west extent: 774.962760
# looks ok (feet)
A0 paper is 33.07" x 46.77", uses a 1" margin (ps/ps.map/paper.h)
so for width, 31.07" => 774.962760' (9299.55") which is 1:299 :-/
1m / 1' = 3.28
1:299 * 3.28= 1:982 !
So it's a units problem, it's assuming meters when it is really feet.
I also see the explicit scale=1:982 making something different than
the automatic "1:982" when units=feet.
explicit scale=1:982 on the command line makes the graph box correct
but the scalebar is wrong. If 1:982 is figured automatically, both
scalebar and map box are wrong.
> I dug around a little in the source code, but couldn't find an obvious
> reason for why this is happening. I thought it might be that the
> G_database_units_to_meters function might be returning the wrong
> value, but I haven't actually tried to debug so I'm not ready to say
> that's it.
>
> I do not see the same behavior in a UTM location (where units are in
> meters).
checks out for me too. ps.map works perfectly when units=meters.
more soon.
Hamish
|
|
Tue, Jan 30 2007
05:58:35
|
|
Comments added by hbowman
|
|
Cc: grass-dev@grass.itc.it
here it is:
ps.map/map_setup.c
/* set the scale */
if (!PS.scaletext[0]) sprintf(PS.scaletext, "1 : %.0f",
39.37 * 72.0 * (PS.w.east - PS.w.west) / PS.map_pix_wide);
that assumes east-west is in meters. It should be using the distance()
fn to return distance in meters like ps.map/scale.c does.
39.37 is meters->inches; 72.0 is inches to PostScript units (points, as
in font size of 10 is 10/72" tall when printed)
do_scalebar.c was assuming input segment length was in meters too.
should be:
/* convert scale size to map inches */
length = (sb.length / scale_size) *
G_database_units_to_meters_factor() * METERS_TO_INCHES;
This could very well be what is breaking the scale for lat/lon:
http://intevation.de/rt/webrt?serial_num=3096
(although due to curvature that will never be correct for both dims)
Hamish
|
|
Tue, Jan 30 2007
06:59:58
|
|
Request 3096 merged into 5454 by hbowman (as #3096)
|
|
Tue, Jan 30 2007
07:59:55
|
|
Comments added by hbowman
|
|
fixed in 6.3cvs and the 6.2 release branch.
renaming bug to address the "foots" problem.
Hamish
|
|
Tue, Jan 30 2007
08:00:23
|
|
Subject changed to projection units incorrectly pluralized by hbowman
|
|
Tue, Jan 30 2007
08:01:04
|
|
Comments added by hbowman
|
|
"foots" problem happens when location was created from EPSG code, "g.proj -c".
Hamish
|
|
Fri, Feb 2 2007
17:24:43
|
|
Comments added by msieczka
|
|
Cc: grass-dev@grass.itc.it
hbowman wrote (Tue, Jan 30 2007 08:01:04):
> "foots" problem happens when location was created from EPSG code, "g.proj -c".
I have tried to reproduce the error, but I'm not able to create a location
from the 2258 EPSG code in question.
After I enter a new location name, the 2258 code, and press 'Define location'
gui freezes and I have to "kill -9" it. Location is not created. This does not
happen with other (metric) projections I tried.
Maciek
|
|
Fri, Feb 2 2007
18:23:53
|
|
Mail sent by pkelly
|
|
I have fixed the "foots" bug now; see
http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
I will commit a temporary solution to the GUI freezing problem (changing
g.proj so it won't prompt for the datum info unless you ask it to be
interactive) shortly. |
|
Sun, Feb 4 2007
17:42:01
|
|
Mail sent by michael.barton@asu.edu
|
|
Return-Path |
<michael.barton@asu.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
User-Agent |
Microsoft-Entourage/11.3.3.061214
|
Date |
Sun, 04 Feb 2007 09:38:41 -0700
|
Subject |
Re: [GRASS-dev] [bug #5454] (grass) projection units incorrectly pluralized
|
From |
Michael Barton <michael.barton@asu.edu>
|
To |
Paolo Cavallini via RT <grass-bugs@intevation.de>, Hamish <hamish_nospam@yahoo.com>, <russo@bogodyn.org>
|
Cc |
<grass-dev@grass.itc.it>
|
Message-ID |
<C1EB5A21.1C05E%michael.barton@asu.edu>
|
Thread-Topic |
[GRASS-dev] [bug #5454] (grass) projection units incorrectly pluralized
|
Thread-Index |
AcdIeu1uK/utbrRuEduDBAAX8scpqg==
|
In-Reply-To |
<20070202172353.2A8D21005C7@lists.intevation.de>
|
Mime-version |
1.0
|
Content-type |
text/plain; charset="US-ASCII"
|
Content-transfer-encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
Thanks very much Paul. This will ameliorate a problem that is especially
disconcerting to users in that it generate no error messages.
Michael
On 2/2/07 10:23 AM, "Paul Kelly via RT" <grass-bugs@intevation.de> wrote:
> I have fixed the "foots" bug now; see
> http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
> I will commit a temporary solution to the GUI freezing problem (changing
> g.proj so it won't prompt for the datum info unless you ask it to be
> interactive) shortly.
>
> -------------------------------------------- Managed by Request Tracker
>
>
__________________________________________
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
|
|
Mon, Feb 5 2007
08:07:09
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 5 Feb 2007 20:06:34 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Paul Kelly via RT <grass-bugs@intevation.de>
|
Cc |
russo@bogodyn.org, grass-dev@grass.itc.it
|
Subject |
Re: [bug #5454] (grass) projection units incorrectly pluralized
|
Message-Id |
<20070205200634.7217027e.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20070202172353.2A8D21005C7@lists.intevation.de>
|
References |
<20070202172353.2A8D21005C7@lists.intevation.de>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
|
X-Spam-Level |
|
Paul Kelly via RT wrote:
> I have fixed the "foots" bug now; see
> http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
> I will commit a temporary solution to the GUI freezing problem
> (changing g.proj so it won't prompt for the datum info unless you ask
> it to be interactive) shortly.
Idea:
It would create a new epsg=code[,n] option:
g.proj -c location=newLocation epsg=####
It would exit with EXIT_FAILURE if the datum transform parm is ambiguous.
Here's the cunning part:
"epsg=####,n" would pick param 1,2,3,.. from the list.
"epsg=####,0" would print available options to stdout and exit with an
EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with
EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read
& make into a nice GUI popup. Maybe with a header comment line for humans.
In the GUI:
- user selects create new location with EPSG code $EPSG.
- gui runs "catch `g.proj epsg=$EPSG` > /dev/null"
- If exit code is 0, gui creates new location with:
"g.proj -c location=$LOCATION epsg=$EPSG"
- If exit code is 1, gui runs:
"g.proj epsg=$EPSG,0" then parses the output and creates a new
GUI popup with radiobutton options generated from that. (see d.menu)
(If it fails again, EPSG code is bad)
Once a parm is selected and [Create] is clicked, the popup runs
"g.proj -c location=$LOCATION epsg=$EPSG,$N"
IMO this would be many many times better than forcing a value (you
wouldn't even know better transform parms exist), and isn't a huge
amount to code.
Hamish
|
|
Mon, Feb 5 2007
16:11:36
|
|
Mail sent by michael.barton@asu.edu
|
|
Return-Path |
<michael.barton@asu.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
User-Agent |
Microsoft-Entourage/11.3.3.061214
|
Date |
Mon, 05 Feb 2007 08:10:12 -0700
|
Subject |
Re: [GRASS-dev] Re: [bug #5454] (grass) projection units incorrectly pluralized
|
From |
Michael Barton <michael.barton@asu.edu>
|
To |
Hamish <hamish_nospam@yahoo.com>, Paolo Cavallini via RT <grass-bugs@intevation.de>, Maris Nartiss <maris.gis@gmail.com>
|
Cc |
<russo@bogodyn.org>, <grass-dev@grass.itc.it>
|
Message-ID |
<C1EC96E4.1C0BF%michael.barton@asu.edu>
|
Thread-Topic |
[GRASS-dev] Re: [bug #5454] (grass) projection units incorrectly pluralized
|
Thread-Index |
AcdJN7tv+j+/nrUqEduDBAAX8scpqg==
|
In-Reply-To |
<20070205200634.7217027e.hamish_nospam@yahoo.com>
|
Mime-version |
1.0
|
Content-type |
text/plain; charset="US-ASCII"
|
Content-transfer-encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
I haven't thought through all the implications, but on the face of it this
sounds like a reasonable solution. If implemented, hopefully it would be
able to run without lockup (succeed or fail with warning) with the current
TclTk scripts until the GUI could be re-written for this.
On 2/5/07 12:06 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
> Paul Kelly via RT wrote:
>> I have fixed the "foots" bug now; see
>> http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
>> I will commit a temporary solution to the GUI freezing problem
>> (changing g.proj so it won't prompt for the datum info unless you ask
>> it to be interactive) shortly.
>
> Idea:
>
> It would create a new epsg=code[,n] option:
>
> g.proj -c location=newLocation epsg=####
>
> It would exit with EXIT_FAILURE if the datum transform parm is ambiguous.
>
> Here's the cunning part:
>
> "epsg=####,n" would pick param 1,2,3,.. from the list.
>
> "epsg=####,0" would print available options to stdout and exit with an
> EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with
> EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read
> & make into a nice GUI popup. Maybe with a header comment line for humans.
>
> In the GUI:
> - user selects create new location with EPSG code $EPSG.
>
> - gui runs "catch `g.proj epsg=$EPSG` > /dev/null"
>
> - If exit code is 0, gui creates new location with:
> "g.proj -c location=$LOCATION epsg=$EPSG"
>
> - If exit code is 1, gui runs:
> "g.proj epsg=$EPSG,0" then parses the output and creates a new
> GUI popup with radiobutton options generated from that. (see d.menu)
> (If it fails again, EPSG code is bad)
>
> Once a parm is selected and [Create] is clicked, the popup runs
> "g.proj -c location=$LOCATION epsg=$EPSG,$N"
>
>
> IMO this would be many many times better than forcing a value (you
> wouldn't even know better transform parms exist), and isn't a huge
> amount to code.
>
>
>
> 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
|
|
Fri, Feb 9 2007
04:50:31
|
|
Status changed to resolved by hbowman
|
|
Fri, Feb 9 2007
04:50:31
|
|
Comments added by hbowman
|
|
"foots" bug is fixed by Paul, closing report.
Hamish
|
|