When configuring a WFS-T service the only thing needed to make a WFS to be transactional is a SQL Server, SQL Server Spatial or Oracle Read-Write Data Server.
However if we want a WFS non transactional with a connection made to a SQL Server Spatial Data Server it isn't possible because the Data Server os SQL Server Spatial is only Read-Write. It doesn't exists a SQL Server Spatial Read-Only Data Server.
There is a workaround to achieve this but it required that the user changes the capabilities xml document for each service and removes the transactional part, restart all the services, clean temporary files and also establish a SQL Server Spatial connection with a db user that has only read-only privileges.
It would be great if there was a way to configure the possibility of making a WFS to be transactional (always requires a Read-Write connection), or a WFS with a SQL Server Spatial Read-Write connection to be non transactional, in the administration console configuration of the service.
We have customers that migrate from Oracle Spatial to Postgis for the high cost of Oracle maintenance. they have GeoMedia WebMap services with metadata in Oracle and we need to migrate also to Postgress like the Spatial data is possible. Now when a customer moves to Postgress they must move metadata to Access, but this has big limitations when customer has large number of services, and also the mdb gets corrupted when the edition is done having the mdb used for some process. In siebel there's also a CR# 1-7SU72S associate to this request.
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.
As an Administrator of a GeoMedia WebMap implementation (Advantage or Professional Tiers) I can only create WFS-T web services against Oracle and SQL Server databases.
I would like to leverage the use of new read-write dataservers available in GeoMedia such as GeoPackage and ESRI file geodatabase.
GeoPackage offers a very simple data warehouse for storing data without the need for installing database software.
ESRI file database support would provide closer integration with existing ESRI implementations and potentially expand the use of Hexagon software by ESRI customers by enabling editing of ESRI data via a GeoMedia WebMap WFS-T.
As a customer with a GeoMedia WebMap Essentials license I have the ability to create WFS-G web services but the web client included in this product tier (WebMap Publisher Portal) cannot perform searches against the WFS-G as there is no "Search" functionality shown in the WebMap Publisher Portal.
Provide an interface within the WebMap Publisher Portal web client to query WFS-G services.
GeoMedia WebMap Advantage offers R/W capabilities out of the box. On the other hand, the mobile apps (Mobile MapWorks in particular) support vector editing features. The GeoMedia WebMap could be integrated with Mobile MapWorks to better address the business needs where the in-field offline editing is required in addition to the standard mapping services.
The process steps required to publish a basic website (WebMap Publisher Portal) or the service (WMS, WFS) are too many and require more than one administration tool available from various places to be used.
The simplified workflow will allow a person with little experience to proceed with web configuration using one tool only. The WebMap Publisher Portal (with WMPS already pre-configured) will be created directly from the WebMap Publisher Administrator. Also, the WMS and WFS services created from WebMap Publisher Administrator (with the published service sources) will be automatically available in the Administration Console.
As a part of the simplification, the publishing GeoMedia GeoWorkspaces with dynamic labelling configurations will result in automatic LRF file creation. Administrators will no longer need to create the file manually which together with the other Simplified Publishing enhancements will reduce the time to set GeoMedia WebMap's services and portals up.
SVG files generated by GeoMedia WebMap and displayed in the browser need the modernization to improve performance and user experience.