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
Re: [mapguide-users] MapGuide Open Source 4.0 RC1 plans and some remarks on MVT tiles
HI Jackie, from my perspective, I never use the MVT. I would not be disappointed if you dropped it from the next build (at least for now). On Fri, Oct 27, 2023 at 10:16 AM Jackie Ng via mapguide-users < mapguide-users@lists.osgeo.org> wrote: > 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 > ___ 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
