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

Reply via email to