[GRASS-dev] Re: [GRASS GIS] #773: r.in.gdal unclean import of southern UTM zone

[GRASS GIS]

#773: r.in.gdal unclean import of southern UTM zone
---------------------------------+------------------------------------------
  Reporter:  hamish              |       Owner:  grass-dev at lists.osgeo.org
      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>