Fri, Mar 10 2006
01:06:38
|
|
Request created by hbowman
|
|
Subject: v.in.org location= misses lat_ts and datum settings.
Hi,
I'm trying to create a new location from a shapefile's .prj info via the
'v.in.ogr location=' method as the documentation is unclear to me.
When I do this it misses the datum and the standard lat settings.
Here is what is listed in the docs:
The projection used [...] is:
Mercator Projection
Central Meridian = 100
Standard Parallel = -46
False Easting = 0
False Northing = 0
Spheroid/Datum = Clarke 1866
here is the contents of the .prj file:
PROJCS["Clarke_1866_Mercator",GEOGCS["GCS_Clarke_1866",DATUM["D_Clarke_1866",SPHEROID["Clarke_1866",
6378206.4,294.9786982]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Merca
tor"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",10
0.0],PARAMETER["Standard_Parallel_1",-46.0],UNIT["Meter",1.0]]
here is what the PROJ_INFO ends up as:
G61-cvs> g.proj -p
-PROJ_INFO-------------------------------------------------
name : Mercator
proj : merc
a : 6378206.4
es : 0.006768657997609644
lat_ts : 0
lon_0 : 100
k : 1.000000
x_0 : 0
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1
lat_ts = 0 ??!
G61-cvs> g.region -p
projection: 99 (Mercator)
zone: 0
datum: ** unknown (default: WGS84) **
ellipsoid: a=6378206.4 es=0.006768657997609644
north: -1899000
south: -5288000
west: 4412000
east: 6974000
nsres: 1000
ewres: 1000
rows: 3389
cols: 2562
Datum is missing, can't blame it as I don't understand how Clark 1866 is the
datum either (as specified in the .prj file).
test data:
http://www.niwascience.co.nz/ncco/mec/mec_example.zip
http://www.niwascience.co.nz/ncco/mec/mec_manual.pdf/view_pdf
?
thanks
Hamish
|
|
Fri, Mar 10 2006
01:53:25
|
|
Area changed to grass6 by hbowman
|
|
Tue, Mar 14 2006
00:32:16
|
|
Mail sent by mneteler
|
|
Hamish,
I have recently updated the lib/proj/*.csv files to
EPSG 6.9 as FrankW updated them in GDAL-CVS.
He also updated in PROJ-CVS.
Maybe this cures the problem?
Otherwise have a look at lib/gis/geo_init.c
...
TABLE[MERC][LON0].ask = 1;
TABLE[MERC][LON0].def_exists = 1;
TABLE[MERC][LON0].deflt = -96.0;
TABLE[MERC][LATTS].ask = 1;
TABLE[MERC][LATTS].def_exists = 1;
TABLE[MERC][LATTS].deflt = 0.;
TABLE[MERC][KFACT].ask = 1;
TABLE[MERC][KFACT].def_exists = 1;
TABLE[MERC][KFACT].deflt = 1.0;
TABLE[TMERC][LAT0].ask = 1;
TABLE[TMERC][LAT0].def_exists = 1;
TABLE[TMERC][LAT0].deflt = 23.0;
TABLE[TMERC][LON0].ask = 1;
TABLE[TMERC][LON0].def_exists = 1;
TABLE[TMERC][LON0].deflt = -96.0;
...
I believe that all is handled by OGR in GRASS.
Markus |
|
Tue, Mar 14 2006
06:10:10
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 14 Mar 2006 18:10:02 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Markus Neteler via RT <grass-bugs@intevation.de>
|
Subject |
Re: [bug #4160] (grass) v.in.org location= misses lat_ts and datum settings.
|
Message-Id |
<20060314181002.12cf3b36.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060313233216.E33231005D3@lists.intevation.de>
|
References |
<20060313233216.E33231005D3@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-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> I have recently updated the lib/proj/*.csv files to
> EPSG 6.9 as FrankW updated them in GDAL-CVS.
> He also updated in PROJ-CVS.
>
> Maybe this cures the problem?
no
> Otherwise have a look at lib/gis/geo_init.c
> ...
> I believe that all is handled by OGR in GRASS.
will do
Hamish
|
|
Tue, Apr 18 2006
11:52:19
|
|
Subject changed to v.in.ogr location= misses lat_ts and datum settings. by hbowman
|
|
Mon, Apr 24 2006
05:28:23
|
|
Priority changed to 75 by hbowman
|
|
Thu, Apr 27 2006
04:26:28
|
|
Comments added by hbowman
|
|
Cc: grass5@grass.itc.it
[create new location with v.in.ogr sets central parallel wrong]
The shape file's .prj reads:
PROJCS["Clarke_1866_Mercator",GEOGCS["GCS_Clarke_1866",DATUM["D_Clarke_1866",SPHEROID["Clarke_1866",
6378206.4,294.9786982]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Merca
tor"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",10
0.0],PARAMETER["Standard_Parallel_1",-46.0],UNIT["Meter",1.0]]
(ignore datum problems for now)
The problem happens in lib/proj/convert.c
either in line 243:
OSRMorphFromESRI( hSRS );
or on line 277
if( OSRExportToProj4( hSRS, &pszProj4 ) != OGRERR_NONE )
At least as soon as we are past line 277, the pszProj4 contains a string with
+lat_ts=0
I am using debian/stable's gdal 1.2.6.
I will update to the DebianGIS GDAL 1.3.1 package for stable and report back.
Hamish
|
|
Thu, Apr 27 2006
04:45:05
|
|
Comments added by fwarmerdam
|
|
Hamish,
I'll have Mateusz Loskot take this problem and work on the appropriate
fix for OGR. I don't think it will be completed in time for the GDAL 1.3.2
release that is pending now.
|
|
Thu, Apr 27 2006
05:03:49
|
|
Status changed to resolved by hbowman
|
|
Thu, Apr 27 2006
05:03:49
|
|
Comments added by hbowman
|
|
Cc: grass5@grass.itc.it
The update to GDAL 1.3.1 fixed the problem.
closing this bug.
Hamish
|
|