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
