[Chameleon] Chameleon installation woes

[Paul Spencer]

Rhys,

Rhys Ickeringill wrote:
> G'day Paul, thanks for the speedy response. My comments inline as well
> 
> 
>>Rhys, comments inline ...
>>
>>Rhys Ickeringill wrote:
>>
>>>Hi All,
>>>
>>>I'm unsucessfully trying to get Chameleon working on my linux system.
>>>Presently I'm close, but not quite there. All the "Basic Widget" sample
>>>pages are working correctly bar the reference map not displaying. I
> 
> *think*
> 
>>>I have traced that to the fact that I've disabled all projection related
>>>keywords in the chameleon.map file (I don't have the Canadian
> 
> projections
> 
>>>which is used in this map file - what's 42304's projection type and
>>>parameters?).
>>
>>um ... this is a bit of a problem, in the future I'm going to remove
>>projections from the distributed data.  In the mean time, you can get an
>>updated epsg file from:
>>
> 
> Could you not replace the init='epsg:42304' in the distributed map files
> with the actual parameters of the projection (thereby removing the proj4
> default package dependency)?

yes ... or it can be removed entirely since all the data is in the same 
projection.  Projections are only really needed when the data is not all 
in the same projection or you want a differently projected output.

To support changing output projections, however, Chameleon must know the 
starting projection.

> 
> 
>>>The "Enhanced Widgets" sample "Widgets from the Enhancesd Widget Group"
>>>fails to work at all. I get the message:
>>>"Fata error: [MapServer Error]: msProcessProjecrtion(): projection not
> 
> named
> 
>>>in /usr/local/chameleon/htdocs/widgets/TrueNorth/TrueNorth.widget.php on
>>>line 124
>>>
>>>Looking at the code in TrueNorth.widget.php, I'm guessing line 121 is
> 
> meant
> 
>>>to catch this error, but isn't.
>>
>>this could be a bug.  Try the epsg file first and if this persists,
>>please report again :)
>>
> 
> Acquiring the extended epsg file has solved this. Probably something along
> the chain Chameleon > PHP_MapScript > MapServer > Proj4 should handle this
> [essentially invalid input] more gracefully. I'll send the appropriate party
> a diff when (if?) I get my head around PHP and MapScript.

Please file a bug for this.

> 
> 
>>>The "Bilingualisation" and "XML Theme Legend" samples work as they
> 
> should,
> 
>>>bar the reference map problem outlined above.
>>>
>>>But most puzzling of all, I've followed the instructions in the
> 
> Chameleon
> 
>>>online help "Installation Guide" and set up the sample page from the
>>>"Application Developers Guide"  to test everything is working properly
>>>(actually this is the first thing I did, I tried the sample pages
>>>afterwards, but I digress). Sadly all I get is an empty document -
>>>specifically a pair of HTML and BODY tags. The only changes I've made to
> 
> the
> 
>>>samples provided are to update the include path for chameleon.php and
>>>commenting out the projection related keywords from the map file.
>>
>>depending on how you have configured PHP, your error messages may be
>>going into the apache error log.  We need an error message somewhere to
>>figure this out.
>>
> 
> The reference map issues on the sample pages have been solved by the updated
> epsg file as expected. Is it a requirement that a projection must be defined
> for the reference map to work? To be honest I was quite surprised that any
> map images were generated after I commented out every reference I could find
> to projections in the map file...
> 
> Unfortunately I'm still just getting an empty page by the code essentially
> cut-n-paste from the Application Developers Guide. My apologies, I forgot to
> mention that there's nothing in the apache logs other than that the page was
> accessed (no corresponding message in the error log). PHP is configured to
> display error messages inline in the generated page, hence why I am stumped
> by the completely emtpy document. My main concern in all of this is to
> ensure Chameleon / MapScript / MapServer is functioning as it should before
> I start development - this way I'll know I've only got myself to blame if
> things aren't working ;-) . Should I be concerned that this page is not
> functioning? Or is having the other sample pages fully functioning good
> enough to prove everything is as it should be?

um.  The reference object in mapscript doesn't support a projection so 
we have a method of doing this in php.  I'm guessing that it assumes 
that there will always be a valid projection defined.

> 
> 
>>>On an asside, I've noticed in my peeking around in the Chameleon code
> 
> that
> 
>>>many of the modules are incorrectly named (or my system is strange). eg.
>>>there is code to test whether the "gd" PHP module is loaded, and if it
>>>isn't, Chameleon attempts to load module "php_gd.so". On my system at
> 
> least,
> 
>>>this module is called just "gd.so"...
>>
>>sadly this is true.  On windows, all extensions are built as modules and
>>named 'php_xxxx.dll'.  On linux, extensions are normally built into php.
>>  I have recently discovered that on linux, if you build extensions as
>>modules, the names will be without the leading 'php_'
>>
>>I had hoped to keep the code to ensure modules are loaded fairly tight,
>>hence:
>>
>>if (!extension_loaded('gd'))
>>   dl( 'php_gd.'.PHP_SHLIB_SUFFIX);
>>
>>now I will have to look into trying both the php_gd.so and gd.so versions
> 
> :(
> 
> 
> Why not
> 
> if( !extension_loaded('gd'))
>    dl( PHP_SHLIB_PREFIX.'gd'.PHP_SHLIB_SUFFIX );
> 
> I agree, its' not a clean as before, but once you've gone and done the
> suffix, you might as well go all the way, no? I guess the other option is to
> publish a list of PHP extensions which must be either compiled in or loaded
> via php.ini "extension=<module_name>.<module_suffix>" in the install
> instructions and not concern yourself at all with extension loading. The
> latter is how I've worked around the problem...

we could use something like this I guess ...
// some constanst for pre php4.3
if (!defined('PHP_SHLIB_SUFFIX'))
{
     define('PHP_SHLIB_SUFFIX',strtoupper(substr(PHP_OS, 0,3)) == 'WIN' 
? 'dll' : 'so');
}
if (!defined('PHP_SHLIB_PREFIX'))
{
     define('PHP_SHLIB_PREFIX',PHP_SHLIB_SUFFIX == 'dll' ? 'php_' : '');
}

but mapscript is built as php_mapscript.so (for example) so the rule is 
not universal (or mapscript doesn't adhere to the convention, is more 
likely).

I agree with publishing a list, although one of our goals is to make the 
software independent (as much as possible) of client configuration of 
PHP.  There are certain required values that we just cannot work around, 
but most of the rest we can.  In this case, I think we'll probably 
implement a helper function to load modules.

> 
> Thanks for you support.
> 
> Rhys
> 
> 

Cheers

Paul

-- 
+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+