I've just got a site production ready that is on Windows Server 2016 and
version 3.1.1 using the previously compiled 3.1 and manual update of Fusion
folder. There were no issues at all with Apache but there were problems with
IIS10 associated with different security settings. In the end that
Fabio,
I have been working to update a client from AIMS 2013 to MGOS 3.1 since
November as there’s custom code and had some issues. Are you using IIS10? This
proved too large a stumbling block and after much experimentation the decision
was made to switch to Apache. Once that was done there
Jackie,
I had already tried adding in constants.php; it resolved that error but creates
wrong parameter count errors for MgMap and another fatal error so I removed it
as I hadn't needed it in AIMS.
Thanks for confirming it needs to remain.
Kind Regards,
Lisa
-Original Message-
I didn't need to make changes but I'm using Apache. The only modifications I
made were to add more scales into the widget javascript.
Lisa
-Original Message-
From: mapguide-users [mailto:mapguide-users-boun...@lists.osgeo.org] On Behalf
Of BMason
Sent: Thursday, 14 December 2017 4:03
I am updating codebase originally running on AIMS 2013 to MGOS 3.1 on Apache
and have hit an issue.
When updating code associated with calling a layer it keeps erroring out
before calling the layer. The error is:
PHP Fatal error: Class 'MgServiceType' not found in C:\Program
Hi there,
Yes I have success using both, in 3.0 and in 3.1. However, the basemaps are
proprietary and can be used only with an API key. As such, they are not allowed
to be part of the physical print as that removes control of the imagery. I am
not aware of any programmatic method to overcome
When I moved two sites from 2.6 to release 3.0 I experienced the issue for all
composite layers. All of the theme layers had to be rebuilt. The other layers
had to be manually accessed in Maestro and repointed. To move 200 layers across
using a package required nearly 60 hours of work. Going
Thanks Jackie. That did the trick. I was unaware that the alterations to
httpd.conf were required, as I used the same approach to the LDAP dll as I have
with Oracle and SQL Server dlls, which to date have not required an entry into
httpd.conf.
Thanks again,
Lisa
-Original Message-
,
Lisa Weber
___
mapguide-users mailing list
mapguide-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapguide-users
Gordon,
Great post! Thanks for the fix, I have tested and it's now working in MGOS 3.0.
The fix will only allow the google map base to work for a given layout, not
multiple base layer external providers that a user can switch between , not
bing or openstreet maps and google bae maps at the
is not recognized by google as a valid client key. It throws
the error:
Am I correct; is it true that MGOS will only accept a client ID? Also, has
anyone successfully used an API key for Google Maps Javascript API with MGOS
2.6?
Kind Regards,
Lisa Weber
Interesting. I experienced the same problem last week on a site but had been
running 3.0 on it since November with google maps and bing maps base with no
problem - but only when the application definition is loaded using PHP. The bug
appeared recently for the PHP code; the google maps simply
Remy,
I have had similar experiences. I have tested the same tile cache process using
MgCooker on two servers and a desktop and found it difficult to sustain a CPU
usage above 27%. When I greatly increased the number of concurrent requests
(over 10) that lifted the CPU to 34%, but a lot of
13 matches
Mail list logo
