Delivered Ideas

Discuss topics with other Hexagon Geospatial Product pioneers and experts to get the most out of our products.
Showing results for 
Search instead for 
Do you mean 

Modernise GeoMedia WebMap Map Request Handling

Status: Delivered
by ‎11-02-2017 03:55 AM - edited ‎11-03-2017 02:36 AM

As an Administrator of a GeoMedia WebMap implementation I need a scalable solution for handling map requests for large datasets and the ability to run multiple web services from a single server.


As the core underlying GeoMedia API will remain on a 32-bit architecture as confirmed here the Map Request process operated by the Map Server Manager and Map Server processes should be optimised to work more efficiently within the memory limit of a 32-bit process. Customer expectations are that Hexagon software should be able to utilise the modern architecture they have available to them such as multi-core servers with large amounts of memory i.e. do more with less.


When running multiple web services (15 or more) from a single server the memory usage on a MapSvr.exe can be large once all Service Sources are initalised leaving limited available memory to handle map requests sent to the web services. The only way to implement a large web service implementation is to spread web services across multiple servers. This is deemed costly by customers due to the costs associated with licensing Hexagon and third-party software on additional servers.


One possible method to optimise memory usage with MapSvr.exe processes would be define pools of Map Server processes. The Map Server Manager would then pass requests from certain web services to a particular pool of Map Server processes to handle. 


As an Administrator I would benefit by being able to utlise the server architecture more efficiently with a single WebMap implementation ensuring the most used web services have a dedicated pool of Map Server processes.


This architecture is similar to how the Hexagon NetWorks product Map Server processes operate.

Status: Delivered
on ‎11-07-2017 07:10 AM
Status changed to: Under investigation
on ‎11-07-2017 07:23 AM

Having the rearchitectured Map Server Manager in place makes this idea more feasible than before. However, having per Service Source Map Server pool assignment and preemptive Service Source initialization presents some kind of a challenge.

Am I correct in understanding that per Service Instance Map Server pool assignment isn't sufficient?


Also, have you already pondered the administrative workflows? Do you imagine those to be fully automated (the Map Server Manager automagically decides what to put where) or manual, i.e. the Administrator first defines pools of Map Server and their sizes (preferably using the Administration Console web GUI) and then assignes specific Service Sources to them? Would that be a one Service Source to one Map Server pool assignment or are there any benefits in doing one-to-many?

on ‎11-08-2017 02:54 AM

Hi hbm,

I am familiar with working with Service Instances that use Service Sources so I was focused on pooling requests to Service Sources but I agree pooling requests at the Service Instance level is a valid option.


In terms of administrative workflows, I see this pooling as an additional option that can be enabled or disabled for the GeoMedia WebMap installation. When disabled the current behaviour of every map server handling requests for all Service Instances/Sources will take place. This should be the default setup in GeoMedia WebMap as not all implementations will require this type of pooling.


When enabled I would expect to have full control on defining each Map Server pool with a set number of map servers and the Service Instances/Sources that are assigned to each pool. This administration workflow should preferably be configured using the Administration Console web GUI and all Service Instances/Sources must be assigned to a single server pool. I do not see any benefits of doing one-to-many.


I hope I've answered your questions.



on ‎11-16-2017 09:01 AM

I've compiled all of our discussions in a single article here on the Community's Developers' Knowledge Base: [RFC] Modernise GeoMedia WebMap Map Request Handling

on ‎11-27-2017 03:30 AM
Status changed to: Under investigation
on ‎12-05-2017 02:51 AM
Status changed to: Candidate
on ‎10-09-2019 04:04 AM
Status changed to: Targeted for an upcoming release

Implemented for upcomming 16.6 Release (Release 2020).

on ‎10-17-2019 07:26 AM
Status changed to: Delivered