#773: r.in.gdal unclean import of southern UTM zone
---------------------------------+------------------------------------------
Reporter: hamish | Owner:
[hidden email]
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Projections/Datums | Version: svn-develbranch6
Resolution: | Keywords: r.in.gdal, utm
Platform: Unspecified | Cpu: Unspecified
---------------------------------+------------------------------------------
Comment (by hamish):
Replying to [comment:1 pkelly]:
> How long ago was the location created? g.setproj had a bugfix on
> 7 October 2003 to create a negative zone number for southern
> hemisphere UTM locations
It was created a few days ago with "grass65 -text" and a new location
name, then defined by following the prompts.
> Are you saying that that doesn't work (i.e. the negative zone
> doesn't go into the WINDOW file)
negative zone number doesn't make it into WIND, DEFAULT_WIND, or
PROJ_INFO.
> because libgis doesn't handle negative zone numbers? If so that
> would make this an incredibly long-running bug...
I've used southern hemisphere UTMs for ages without problems. I guess the
"new" thing here is r.in.gdal imported data actually gets it right?
the PROJ_INFO file has
{{{
zone: (some positive number)
south: defined
}}}
so to me putting a negative zone in PROJ_INFO is just confusing+redundant,
and so that part seems ok. (PROJ.4 uses +south to define a southern UTM
btw)
The WIND and cellhd files can not have a "south: defined" tag as south: is
used for the bound, so it should get a negative zone number there.
r.in.gdal is doing that for cellhd files (but eg r.mapcalc does not for
new maps), and WIND files are not getting it.
Part of the solution I think is to have G!__.window.zone report a negative
int for southern UTMs. That would mean that anything which writes a new
raster or WIND file should do that too.
(should opencell.c be using G_zone() instead?)
To avoid massive breakage from that we'd also have to improve the logic of
G!__open_cell_old() to test the abs() of the zone number and the south-
ness of the projection (but how?).
Everything seems to run through the WIND file and not the PROJ_INFO file,
so setting it in DEFAULT_WIND correctly seems to be the first step at
fixing this properly.
which brings us back to g.setproj/main.c which is currently asking the
'South Hemisphere? [n]' question BEFORE the 'Enter Zone:' prompt, so when
you enter the zone number it clobbers the cellhd.zone variable. The South
question has to come after, somehow.
Hamish
--
Ticket URL: <
https://trac.osgeo.org/grass/ticket/773#comment:2>
GRASS GIS <
http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
