Re: [mapguide-users] MGOS 4.0 and PostgreSQL
We say PostgreSQL 12 is supported because that was the most recent version of PostgreSQL that the FDO provider was tested with. Our matrix of PostgreSQL versions to test is small and having to add more versions to test against is more developer overhead. Having said that, the libpq library the PostgreSQL FDO provider is using is generally highly compatible across many different PostgreSQL server versions. It could very well be working with PostgreSQL 13+, I just haven't had the dev cycles to personally verify this fact. So without trying to give a cop-out answer, just try with PostgreSQL 16 yourself (spin up a docker container or something) and see if it works and let us know if there are any issues. - Jackie You wrote: Hi, The current PostgreSQL version is 16. Support for version 11 will end in February 2024 (AWS RDS PostgreSQL 11 must be migrated). So, the most advanced PostgreSQL version the new Mapguide 4.0 will support is version 12 ? It is not possible a more recent version ? It is a FDO limitation ? Regards, Liglio -- *Please Note: I no longer create new posts or post replies to any OSGeo mailing list through nabble. As a result, you most likely won't see this message appear on nabble's view of any OSGeo mailing list and may only see this message through mailing list archives or depending on your mailing list subscription settings, through daily message digests or automated notifications from the mailing lists.* ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
[mapguide-users] MapGuide Open Source 4.0 RC1 plans and some remarks on MVT tiles
Hi All, I am currently putting the finishing touches on a new mapguide-rest release that will be compatible with both 3.1.2 and current 4.0 Beta, thus fully validating the new PHP binding work (if mapguide-rest can work with these new PHP bindings, then there is no real reason your PHP MapGuide application should not work as well!) Which means that after the new release of mapguide-rest I can divert my full attention back onto MapGuide proper and work towards the RC1 release. The main goals for the RC1 release will be: - Getting the supplemental stories around the new API binding work ready, such as: - Getting the .net binding packages onto nuget - Per-language API documentation instead of using doxygen with an umbrella static gateway site to point to all 3. - Getting mg-desktop working under the new API bindings - Updating Apache/PHP/Tomcat again to whatever the current version is - Fixing the PostGIS problem reported on this list and on trac ( https://trac.osgeo.org/mapguide/ticket/2874). I'm still looking for solid reproduction steps against some PostGIS dataset that I can replicate locally. That will help drastically reduce turnaround time on a solution/fix. - Addressing any other minor MapGuide/FDO issues that can be addressed in this timeframe. But one particular item I want to talk about (and too important to fit into a single bullet point) is around the new Mapbox Vector Tile (MVT) support. I have personally been disappointed with the implementation I added because outside of the Sheboygan dataset, it is not producing the MVT tiles I am expecting, with a whole random assortment of geometry and rendering artifacts in my OpenLayers examples. I am strongly considering pulling this feature out of the codebase because I do not have the confidence to actually fix these issues because the implementation was predicated on "I trust this library of code to write/encode MVT tiles to spec and so I will integrate said code into the MG rendering/stylization pipeline". That "library of code" is the MVT tile encoder from the GDAL/OGR MVT driver and whatever "trust" I had in this code was somewhat shook when I used ogr2ogr directly to produce these MVT tiles and even then, the MVT tiles would not display correctly in my OpenLayers examples. Now admittedly, I was using an older version of the tile encoder and ogr2ogr (v2.4.4), so the implementation may have been immature. But a starting position of "not fully working" doesn't give me hope. This has been my experience with MVT tile support. How has your experience been with this new feature? Does it actually produce MVT tiles as you expect? Please try to convince me that this is a feature worth keeping. Be honest in your appraisal of the current implementation. If MVT support isn't fully working for you, then that is a situation that is not likely to improve so we're better off just pulling the feature out and just relying on external/dedicated MVT encoding tools on your data to do the job better. - Jackie ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] mapguide-users Digest, Vol 201, Issue 5
That is correct, I am referring to MapGuide's ability to generate MVT tiles out of the box. I am not satisfied with this implementation that I introduced and wish to remove this feature before RC1 (unless you can strongly convince me otherwise). This does not affect you generating MVT tiles from your data with other tools or integrating external MVT tilesets into your current viewer. - Jackie You wrote: Hi Jackie and Gordon >*From your description I presume you are talking about the generation of MVT >from Mapguide and you are considering dropping that support. *However if you have MVT tiles generated elsewhere you can display it in Mapguide. Is my understanding correct? Kind Regards Johan Nel Technical Director ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] Loading Shapefile on fly using add layer manager
Most of what mapguide-react-layout can/cannot do is driven by the underlying OpenLayers library we're using. OpenLayers cannot create client-side vector layers from SHP files, so there will not be such support in mapguide-react-layout either. - Jackie You wrote: Hi I’d like my webpage’s user to load either shapefile or tab file from their local machine using external layer manager. I use manguide react layout so the users are enable to add their data in GeoJson, kml and csv which is good. But I want them to be a ale to load their shapefiles or tab files to the map. Please advise how to proceed? And if you plan to that as additional option in the new version of map guide layout? Or let me know which JS code in the source files should be updated or change from our side? Thanks Hadis -- *Please Note: I no longer create new posts or post replies to any OSGeo mailing list through nabble. As a result, you most likely won't see this message appear on nabble's view of any OSGeo mailing list and may only see this message through mailing list archives or depending on your mailing list subscription settings, through daily message digests or automated notifications from the mailing lists.* ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] Unable to install MGOS 4 Beta 1
Hi David, As others have said, the general way to get around SmartScreen for freshly downloaded files is to right-click for file properties and unblock the file. But if this option is not available to you, you could try for a command-line based unlock solution: https://stackoverflow.com/questions/23048412/missing-unblock-button-under-properties If that fails and your computer is locked down by IT, perhaps it's some particular Group Policy in effect that is preventing you from being able to unblock this file.I can't tell you which Group Policy in particular this is, but you might ask your IT dept about this and see if they could relax such restrictions if that's the case. Failing that, then your only recourse is to try the InstantSetup bundle, which although it too is also an .exe file, it is also a 7-zip self-extracting archive, so you can open this file with 7-zip and extract the files within for a manual installation. - Jackie You wrote: I'm attempting to install MGOS 4 Beta 1 on a Windows 2022 server but am getting the following error: Microsoft Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk. [image: image.png] Has anyone encountered this before and have a workaround? Thanks, David ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
[mapguide-users] Small change of plans for MapGuide Open Source 4.0 release timeline
Hi All, Just to reiterate what I posted on my blog: https://themapguyde.blogspot.com/2023/12/minor-change-of-plans.html We won't be going to RC1 just yet. There will be a 2nd beta release of MGOS 4.0, whose release I am aiming for late January next year. This is primarily to accommodate the removal of the immature MVT tile generation feature and to give us extra time to roll in an updated Apache/PHP/FDO/Thirdparty components along with the original work I had slated for RC1. - Jackie ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] Point mapping using font symbols is not displayed
MapGuide looks for fonts in Windows' designated fonts directory (the code in question calls the Win32 SHGetFolderPath API for this directory I can't tell you what the exact directory path is). I assume that if you can see the font in Windows font settings, it should also be a font that MapGuide can get at. What font are you using in particular? Is it a font we can install ourselves (to test)? - Jackie You wrote: We installed mapguide v3.1.2.9484 on a new server (Microsoft server 2022). Point mapping using font symbols is not displayed but true type fonts are installed on the Server Do you know how to install fonts on a windows 2022 server, so that mapguide can take them into account? Thank you Martin Rodrigue ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] Maestro 6.0m12 with Mono under Ubuntu 22.04
Hi Pierre, I have long since de-emphasised any mention of "Mono Compatibility" with regards to Maestro, simply because I don't have the resources to test if it works there, so you are venturing into unknown territory. I will say however, that 6.0m12 is now a .net 6.0 application and not a legacy .net Framework 4.x application and has completely different semantics in terms of binary composition and runtime behaviour, so "valid CIL image" from Mono may actually be referring to a legacy .net Framework 4.x CIL image (that older versions of Maestro would've qualified under) and not a .net core/5+ CIL image for what it's worth. - Jackie You wrote: Hi, I am unable to run Maestro 6.0m12 with Mono under Ubuntu 22.04 LTS. The message is : Cannot open assembly './Maestro.exe': File does not contain a valid CIL image. Any solution ? Regards, Pierre ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
[mapguide-users] mapguide-rest 1.0 RC6 released
Hi All, After 6 years since the last release (!!!), I've put out the 6th release candidate of mapguide-rest 1.0. https://github.com/jumpinjackie/mapguide-rest/releases/tag/1.0rc6 The main feature of this release is: - Compatibility with MapGuide Open Source 3.1.2 (PHP 5.6) and MapGuide Open Source 4.0 Beta 1 (PHP 8.1) - A new series of APIs for performing various geo-processing tasks Refer to the release notes for more information. Special thanks to Gordon Luckett and Scott Hamiester for their assistance in testing various builds of mapguide-rest that finally culminated in this release. - Jackie ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] Memory leak with MGOS 4 Beta 1
Could you correlate the time period of 11.15am - 11.45am (where the memory usage ramps up) with entries in your access.log and see which operations are involved? - Jackie You wrote: Hello Pierre, The server is running Windows 2022 Standard, we're using Apache Server and Oracle database. There aren't any error messages generated during the memory leak. We've monitored the Memory usage on this server and notice that memory consumption increases during the incidents (image 1). We tried turning on/off layers, while monitoring the memory usage, which is how we figured out the CLOBs issue but we haven't been able to figure out what's causing the remaining memory leak. Image 1: percent memory utilization on the server showing the increase until the MapGuide services become unresponsive at the peak and have to be restarted. [image: image.png] ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] Memory leak with MGOS 4 Beta 1
Ok failing that, I'll pencil in a memory leak sweep in the beta 2 dev cycle for the King Oracle provider just like I did previously for the GDAL provider. https://trac.osgeo.org/fdo/ticket/1005 - Jackie On Sat, 3 Feb 2024 at 06:12, David Bowen wrote: > We've looked through the access.log but nothing stands out in the > preceding activity. There's nothing specific during the memory ramp up > period that we don't see at other times. > > David > > On Wed, Jan 31, 2024 at 12:01 AM Jackie Ng via mapguide-users < > mapguide-users@lists.osgeo.org> wrote: > >> Could you correlate the time period of 11.15am - 11.45am (where the >> memory usage ramps up) with entries in your access.log and see which >> operations are involved? >> >> - Jackie >> >> You wrote: >> >> Hello Pierre, >> >> The server is running Windows 2022 Standard, we're using Apache Server and >> Oracle database. There aren't any error messages generated during the >> memory leak. We've monitored the Memory usage on this server and notice >> that memory consumption increases during the incidents (image 1). We tried >> turning on/off layers, while monitoring the memory usage, which is how we >> figured out the CLOBs issue but we haven't been able to figure out what's >> causing the remaining memory leak. >> >> >> Image 1: percent memory utilization on the server showing the increase >> until the MapGuide services become unresponsive at the peak and have to be >> restarted. >> [image: image.png] >> >> ___ >> mapguide-users mailing list >> mapguide-users@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/mapguide-users >> > -- http://themapguyde.blogspot.com ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] Differences between PUBLISHED_API and INTERNAL_API
You're mostly on the money. The purpose behind these various *_API markers is documented here and they're mainly for controlling what gets exposed to SWIG https://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/Foundation/FoundationDefs.h#L49 PUBLISHED_API and EXTERNAL_API members will be exposed to the managed API surface. Everything else will remain C++ public/private and inaccessible from managed bindings. As to why certain methods are marked the way they are? Only Autodesk would know and I doubt you'll be able to get an answer from them now as to why. Regarding your current problem. Have you looked at MgHttpRequest and MgHttpResponse classes? Don't let the (horrible) name deceive you, for these are the same classes that drive all of the request handling in mapagent.fcgi meaning in your case you could provide a grpc interface with the same request parameters and call into the same code that the regular mapagent.fcgi handler would do. It's probably better performance too (theoretically) as there are less managed <-> native call transitions involved and not having to new up a whole assortment of Mg* proxy classes to do things the non-mapagent way. Such intermediate objects (like MgMap) would be new-d on the native side and would be cleaned up automatically and deterministically on that same side, without GC from the managed side. If you need .net reference code for how to use these classes, I have an ancient sample that demonstrates usages of MgHttpRequest and MgHttpResponse in a custom webforms .ashx handler (yes, that ancient!) https://github.com/jumpinjackie/mapagent-dotnet-sample/blob/master/MyCustomMapAgentHandler/mapagent.ashx.cs But despite the ancient-ness, the usage of the classes in question can easily be transplanted to something more modern, like an asp.net core controller, or a GET/POST delegate handler for a minimal API or in your case, a grpc service implementation. The only difference in all of these transplant targets is simply: 1. Figuring out how to set up the key/value collection of request parameters in the MgHttpRequest 2. Figuring out how to output the various types that a MgHttpResponse could return - Jackie You wrote: Hi, So I've decided to dust off my C++ skills and did a bit of a deeper dive into the FastCgi / HttpHandler for Mapguide. I'm trying to find new, more efficient ways to develop applications with Mapguide and making it a part of more complex systems, such as having a gRPC interface. I'm looking into using .NET Core with version 8 of the framework. I believe there's a lot of cool stuff we could make Mapguide do, but I am hitting a bit of a performance wall on some functionalities, primarily with map draws. The biggest challenge I'm encountering is that it appears some functionalities are hidden away behind the INTERNAL_API flag, that I believe just hides them from SWIG, but they still get rolled up in the C++ binaries. I did a quick check on MgPlatformBase.dll and you do get functions like MgMapBase::SetViewCenter and MgMapBase::SetViewScale. Both of these calls are used by the mapagent.fcgi whenever you're doing a GetDynamicMapOverlayImage. There's a few more of those functions that gets hidden away like that and I feel it makes hitting better performance harder when trying to use the exposed APIs. It also makes some functionalities impossible to do, such as just drawing an image with the current map selection. In keeping with my GetDynamicMapOverlayImage, if you want to do the same in C#, you need to use RenderMap method on the MgRenderingService with all the exposed options, versus duplicating what the FastCgi is doing and calling up RenderDynamicOverlay. We just can't do the same in C# and it does appear to cost 30% of performance. This is napkin benchmaking notes, I'd love to get more concrete numbers but it's difficult when comparing apples and oranges. So my question is, is there an historical reasoning behind hiding away those APIs? It feels more like an Autodesk thing than an API design thing. Although I will admit I might be missing the reason to hide away SetViewCenter. Maybe it's to prevent devs from shooting themselves in the foot. Would having a "use at your own risk" version of the API with no hidden away to C#, Java and PHP methods be something useful for the community? With all the work Jackie put in moving to a standard version of SWIG in 4.0, maybe it's even something someone with basic knowledge of C++ like myself could get done? Cheers, Ben ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] MapGuide 4.0 Beta 2
Hi David, I must apologize for these repeated delays and failed promises. The reality of the situation is that my day job has absolutely drained any energy I have remaining to tackle MapGuide and FDO dev, which is why these time frames keep slipping. Rather than throw out another date that I'll probably miss, I'll just say that I'll try to jump-start some dev activity later this month and if I get some momentum, I'll follow up with a revised time frame. - Jackie You wrote: Hi Jackie, Is there any update on when MapGuide 4.0 Beta 2 will be released? Thanks, David ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] MapGuide WMS Requests are Always in ESSG:4326 ?
Hi Crispin, Glad your problem got solved. In Maestro, clicking the Advanced button on the WMS feature source connection after testing will establish a default configuration document for the feature source, from which it can then be tweaked. I'm pretty certain that the WMS and GDAL providers almost always require configuration documents to do things properly as these providers rarely do the sensible thing in their un-configured form. - Jackie You wrote: OK, It was the configuration document that was required – I'm sure MGAuthor used to create one for you, but it was a long time ago and I'm a bit rusty on this! Found the guidance PDF and added the following as a configuration document to my .DataSource For an ArcGIS Server I had to remove the from the default schema mapping template to prevent a different server-side error being returned but with the override my requests are all EPSG:27700 I hope this is helpful to the next person searching for this. Crispin ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
[mapguide-users] MapGuide WMS Requests are Always in ESSG:4326 ?
Hi Crispin, Could you attach or send me a .mgp of the WMS feature source and its current configuration document so we have a baseline from which to determine who/what is at fault and what can be done? I want to eliminate the possibility that following your setup steps results in a different feature source + config doc combination. - Jackie You wrote: Hi, I have a client with Map and MapGuide connecting to a WMS service for UK maps. AutoCAD Map makes a request OK using similar FDO WMS provider ... but the MG logs showed a InvalidCRS message when MGServer makes a map request. I realised (via a public WMS and a helpful blog on using Fiddler) that the issue is that MG is requests always using EPSG:4326 within the Request=GetMap. When I set my .MapDefinition up I used a British EPSG:27700 that is listed as supported in the GetCapabilities but the request does not use this native projection. In the case of the problem service it ONLY published on EPSG:27700 and a few others and NOT on the most common EPSG:4326 – and as such returns an InvalidSRS response when MG sends it's converted request in using 4326. A solution, obvs, is to get the provider to add the CRS into the GetCapabilities, however I think this is a bug (is there a workaround with the configuration document?) as there is no obvious requirement for this when working with projected maps and the projection is published in the WMS. Example: 1. Create a new WMS .FeatureSource to https://map.bgs.ac.uk/arcgis/services/BGS_Detailed_Geology/MapServer/WMSServer?service=WMS=1.3.0 1. Create a new layer to "BGS 50k Bedrock" (a Maestro bug does not list all layers, edit XML by hand) 2. Create a New Map, using EPSG:27700, add the layer 3. Create a New layout and set initial view to centre on 30,60 and zoom scale 4 4. Map will preview OK but the underlying request shows similar to below https://map.bgs.ac.uk/arcgis/services/BGS_Detailed_Geology/MapServer/WmsServer?version=1.3.0=WMS=GetMap=XML=BGS.50k.Bedrock==EPSG:4326=EPSG:4326=image/png=56.211896,-3.973780,56.281919,-3.810279=782=1032=FALSE=0xFF Many thanks, Crispin Crispin Hoult ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
Re: [mapguide-users] PHP Vulnerability
Hi David, Rather than a patch, I think I'll just put out a new beta release with the updated Apache/PHP/Tomcat and roll up whatever pending/near-complete dev work I was on. Which means that my original plans for "just one more beta release" are out the window. I'm now more inclined to go with the plan of "however many beta releases required" - Jackie You wrote: Hi Jackie, There's a PHP vulnerability that's been brought to our attention: https://nvd.nist.gov/vuln/detail/CVE-2024-4577 Will there be a patch available for MGOS 4? Thanks, David ___ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
