PROJ problems with Win32 builds of MapServer

[dmorissette]

Assefa, Frank,

See the message below, it would seem that our Win32 builds of MapServer 3.6 give 
the following error when you omit the ellps parameter with proj=latlong:

> msProcessProjection(): Projection library error. major axis or radius = 0
> or not given


Assefa: can you confirm that this happens on your machine too?
Frank: does this problem ring a bell to you?  Why would the UMN build forgive 
this when ours doesn't?

Thanks.



"Martin, Daniel" wrote:
> 
> Well, I believe I was mistaken about the error being the location of the
> epsg file.  I can make the error go away by defining an ellipse in every
> projection:
> 
> This doesn't work:
> 
>   PROJECTION
>     "proj=latlong"
>   END
> 
> This does:
> 
>   PROJECTION
>     "proj=latlong"
>     "ellps=WGS84"
>   END
> 
> This goes for every layer as well as the overall map projection object.
> Does this mean anything to you?  Is the ellipse required with your builds?
>

[assefa]

From a quick test I did (using php/mapscript), I could not replcate the bug. I 
did manage to reproject a layer "init=epsg:42304" and a map projection of 
latlong (without the ellipse parameter).
 Is it possible to have a mapfile causing this problem ? 

[dmartin@…]

The following MAP file does not work for me in the DM build, but does in the 
UMN build.  It can be made to work by in the DM build by uncommenting the 
ellpse parameter of the main PROJECTION object.

#
# Start of map file
#
NAME TigerTest 
STATUS ON
SIZE 800 600
UNITS dd
IMAGECOLOR 255 255 255
FONTSET "..\fonts\fontset.txt"
SYMBOLSET "..\symbols\symbolSet.txt"
IMAGETYPE GIF
EXTENT -130.816299 10.715319 -57.122196 66.003112
#
# Projection definition
#
PROJECTION
	"proj=latlong"
#	"ellps=WGS84" 
END

#
# Start of web interface definition
#
WEB
  TEMPLATE ../Clients/rosaClient.html
  MINSCALE 1000
  IMAGEPATH "\inetpub\wwwroot\temp\"
  IMAGEURL "/temp/"
	HEADER "../queryTemplates/query_head.html"
	FOOTER "../queryTemplates/query_foot.html"
	EMPTY "/MapServer/noRecords.html" 
END

QUERYMAP
  SIZE 200 200
  STATUS ON
  STYLE HILITE
  COLOR 255 255 0
END


# Reference map

REFERENCE
  IMAGE ../referenceImages/US_reference.gif
  EXTENT -125.150691 14.977643 -66.541138 58.946890
	MARKERSIZE 5
  SIZE 160 120
  STATUS ON
	COLOR -1 -1 -1
  OUTLINECOLOR 255 0 0
END


# LEGEND object
LEGEND
   STATUS ON
   KEYSIZE 18 12
   # LABEL object
   LABEL
     TYPE BITMAP
     SIZE MEDIUM
     COLOR 0 0 89
     SHADOWCOLOR 200 200 200
		 SHADOWSIZE 2 2
   END
   TEMPLATE "../legendTemplates/checkBox_legend.html"
END
  
#
# Scalebar
#
SCALEBAR
  IMAGECOLOR 255 255 255
	BACKGROUNDCOLOR 150 230 150
	OUTLINECOLOR 255 255 255
  LABEL
    COLOR 255 255 255
    SIZE large
  END
  STYLE 0
  SIZE 200 10
  COLOR 255 255 255
  UNITS miles
  INTERVALS 3
  TRANSPARENT TRUE
  STATUS TRUE
END

# Layer definitions
#
LAYER
  NAME "USA"
	
  PROJECTION
    "proj=latlong"
		"ellps=WGS84"
  END

  CONNECTIONTYPE OGR
  CONNECTION "\GISData\Namerca\USA\Usa_Maps\USA.TAB"
	STATUS DEFAULT

  TYPE POLYGON

  CLASS
    COLOR 225 225 185
  END
END

LAYER
  NAME "Canada"
	
  PROJECTION
    "proj=latlong"
		"ellps=WGS84"
  END

  CONNECTIONTYPE OGR
  CONNECTION "\GISData\Namerca\Canada\Canada.TAB"
	STATUS DEFAULT

  TYPE POLYGON

  CLASS
    COLOR 225 225 185
  END
END

LAYER
  NAME "Groups US"
	
  PROJECTION
    "proj=latlong"
		"ellps=WGS84"
  END

  CONNECTIONTYPE OGR
  CONNECTION "\GISData\ERAC\Maps\ERAC Map Groups\Gp US\GpBdyUS.TAB"
	STATUS OFF

  TYPE POLYGON
  STYLEITEM "AUTO"
  CLASS
		NAME 'Groups US'
  END
END

LAYER
  NAME "Groups CA"
	
  PROJECTION
    "proj=latlong"
		"ellps=WGS84"
  END

  CONNECTIONTYPE OGR
  CONNECTION "\GISData\ERAC\Maps\ERAC Map Groups\Gp CA\GpBdyCA.TAB"
	STATUS OFF

  TYPE POLYGON

  STYLEITEM "AUTO"
  CLASS
		NAME 'Groups CA'
  END
END

END #Layers

END # Map File

[fwarmerdam]

Folks,

Note that PROJ.4 gets the default ellipsoid by looking it up in the
proj_def.dat file in the $PROJ_LIB directory.  Perhaps Daniel Martin's system
is unable to find the proj_def.dat file for the usual reasons (ie. PROJ_LIB 
not defined). 

[dmorissette]

Makes sense, but then why would the UMN build not complain?  They would use an 
older version of PROJ?

For sure I know that most Windows users that download our binaries do not have 
any of the PROJ files in the C:\PROJ directory (or C:\PROJ\NAD)... Daniel 
Martin: can you please confirm that this is the case on your system?

So Frank, what would be the best thing to do and document for people downloading 
our win32 builds?  I don't think the PROJ website offers a download that can be 
used out of the box to populate the C:\PROJ directory when you don't need the 
source? Please correct me if I'm wrong.

So I guess the best solution would be to package the required files for C:\PROJ 
into a zip file and make it available on our download site, and include 
instructions about this in the Win32 readme file?

What do you think?

[dmartin@…]

I did set the PROJ_LIB environment variable before contacting you, but I did it 
as part of my troubleshooting of this error.  It made no impact to either build 
though.  Both seemed okay assuming C:\PROJ\NAD.  proj_def.dat is in the same 
folder on the system in question.  I did download the version that came with 
source, and I've even tried the PROJ libraries found on the DM download site 
(both of them).

[dmorissette]

Dan, Assefa, is this still an issue?  Can we close this bug?

[dmartin@…]

Daniel, I honestly don't know.  The UMN builds I've used lately seem to be 
fine.  I haven't used a DM build in a while (this was always specific to DM 
builds).  I don't remember where those builds were at.  Do you have a URL?  
I'll give one a whirl.

[dmorissette]

If you could test against the following build then that would help a lot: 
http://www2.dmsolutions.ca/mapserver/dl/mapserver-4.0-dev-win32-php4.3.2.zip
Thanks.

[dmartin@…]

Confirmed, still happening in the 4.0 DM build.  I downloaded the archive, and 
used all the library files from the DM archive as well as the mapserv.exe.  

The problems went away when I replaced the mapserv.exe with the one in 
http://mapserver.gis.umn.edu/win32bin/ms40-beta1_gif_pg.zip without any changes 
to libraries.

[assefa]

Just a note on this : the only way I could reproduce the error with DM builds is
if I remove the file "proj_def.dat" from the proj directory. (I have for this
test extrcated and used the proj definition  files comming from the UMN site)

 Dan Martin from earlier comments seems to have this file available in his
settings. So right now I am not sure what is going on.
 Maybe the issue is in a diffrence in the proj lib used between the 2 builds. I
will try to dig more into it. 
 

[dmartin@…]

What should be in my proj_def.dat?  Currently it looks like:

<general>
ellps=WGS84
<>
<aea> # Conterminous U.S. map
lat_1=29.5
lat_2=45.5
<>
<lcc> # Conterminous U.S. map
lat_1=33
lat_2=45
<>
<lagrng>
W=2
<>

[assefa]

I have the same file definition as the one you have. 

[dmorissette]

Do you both have them in the same location?  Maybe the problem is just that the 
file is not where Assefa's build looks for it?

[assefa]

The build assumes c:/proj but since I saw in earlier message that the PROJ_LIB
env is set, I am still assuming it is set to the location where the proj files are.

[dmartin@…]

Reading back through this thread it's obvious I tried the environment var last 
time, but it wasn't set this time.  So, to be sure I set it to "C:\Proj\nad".  
After a reboot the problem went away.

Could it be that the build, as you say, is assuming "C:\Proj" where it should 
be assuming "C:\Proj\nad"?

[assefa]

c:/proj was the first setup we had (I think It was defined like this originnaly
in the makefile). I tried to keep c:/proj after that since we had several
applications here and at clients using this assumption.
 It would make sense to modify the DM builds to c:/proj/nad but I am not sure If
It should be done for this release since It might generate problems for other
users. 

I am closing this bug since the problem can be solved using the PROJ_LIB

[dmorissette]

Can you please at least make sure that the README in your win32 distribution is 
very clear on the fact that your builds don't use the default location for PROJ 
support files and that PROJ_LIB should be set explicitly if they installed the 
PROJ files already according to PROJ docs.  

Having two sets of default behaviors makes things very confusing, so I think we 
should come back to using the PROJ4 defaults ASAP for our builds.  It will be a 
mess no matter when we do it, so why not doing it now?

[dmartin@…]

To emphasize what Daniel suggests, currently the DM build README says:
Please refer also to :
          http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?WindowProjHowTo

And that HowTo says:
1. Grab ftp://ftp.remotesensing.org/proj/proj446_win32_bin.zip and unpack it, 
if possible under the root in C:\. This creates a C:\PROJ directory. 

The files from that archive go to C:\Proj\nad.  So, following the instructions 
README as it is today results in this "bug".

[assefa]

Ok I will do the changes for the next build. I completly agree that having 2
defaults is more trouble long term.