[mapguide-users] Future plans/roadmap for MapGuide Open Source

[Jackie Ng]

Hi All,

In light of the EOL announcement of Autodesk Infrastructure Map Server,
there is undoubtedly questions and concerns about what is the future of
MapGuide Open Source project.

First of all, let me clearly state the following: MapGuide Open Source is
still alive and going. This project has been in existence for **12 years
and counting**. The EOL of Infr Map Server does not change this fact at all.

Now onto some plans and roadmaps.

1. MapGuide Open Source 3.3

The next release (tentatively MapGuide Open Source 3.3) is in active
development. I've decided on a release date of around *mid-2018*.

Here's some of the features already implemented in this release, which will
be blogged/documented in greater detail as the time comes:

- UTFGrid tile rendering support
- GeoJSON output support for WFS/WMS
- "Clean" JSON APIs in the mapagent
- GeoJSON output support
- Geometry API enhancements:
- Support for simplifying geometries
- Support for doing geometry operations (Buffer/Union/etc) over the
mapagent
- Support in mapagent for performing batch coordinate transformation and
re-projecting any operation response that returns feature data
- MgMap APIs to support stateless map/legend rendering
- Support in the mgserver executable to load packages and change admin
password from the command-line

Features slated for 3.3 currently in RFC phase:

- CMake build system for Linux

Features I am exploring some of which may or may not end up in 3.3 (no
guarantees):

- Getting 64-bit Linux support out of "preview" state
- PHP/Apache/Tomcat updates
- Support for .net Core
- Meta-tiling support (re-activating the RFC90 implementation and
retro-fitting it into the new Tile Set Definition infrastructure)
- Improved runtime map support for Tile Set Definitions
- Additional mapagent infrastructure to support building a stateless map
viewer (no session ids required).
- 2nd-level cache for CREATERUNTIMEMAP responses
- More flexible legend rendering
- WMS GetLegendGraphic support
- Mapbox Vector Tile rendering support
- Query Definition support (think OGR VRT layers, but for MapGuide)

2. Viewer plans

My viewer efforts are primarily focused around the mapguide-react-layout (
https://github.com/jumpinjackie/mapguide-react-layout) project.

I consider the AJAX and Fusion viewers to now be in permanent maintenance
mode, only receiving bug fixes. I have no plans for any enhancement work to
either of these viewers. Having said that, I would not be opposed to any
enhancement contributions.

3. Point releases

Initially I had planned to put out point releases for 2.6, 3.0 and 3.1.

However, as my development bandwidth has been severely diminished, I am
rolling back such ambitions and only going to provide a 3.1.1 release.

To make this point release more enticing (I imagine you may still be on 2.6
or 3.0 because of custom GDAL dlls), I'll be planning to update FDO trunk
to use GDAL 2.0 (it's been a long standing ticket anyways). Once done, I'll
backport this (and many bug fixes) to the FDO 4.1 branch to be bundled with
the 3.1.1 release.

This will allows you to hot swap custom GDAL dlls from gisinternals. If
hot-swapping is not possible, I can build custom GDAL dlls using their
devkit to reach the same level of driver support as the custom GDAL dlls I
made for 2.6/3.0

I've set on a release date for 3.1.1 of *around Feb/March 2018*. I'll do
one Release Candidate to allow you all to verify the custom GDAL dll
swapping and the backported FDO bug fixes are working.

4. Linux builds

For the same reason as reducing the scope of point releases. I'm
considering for the 3.3 release to standardize the Linux builds to only
target one distro: Ubuntu.

For those using the Linux builds, is dropping CentOS a deal-breaker? Do you
use the binary packages or build your own from source?

I figure as long as the source remains build-able on any Linux distro
provided available compilers and libraries that in terms of binary
packages, it would be better to only focus on one particular distro.

For the 3.1.1 release, I'll still intend to build binary packages for both
CentOS 6 and Ubuntu 14.04 LTS with autotools.

For 3.3, I really want to shake off the "preview" label I've tacked on all
64-bit releases of MapGuide on Linux thus far. There's several blockers in
FDO that need to be cleared before I can remove this label. This will be
detailed in another post.

5. Dropping 32-bit builds (for Windows at least)

This is another one I would like to poll the community on.

Do you still use the 32-bit releases of MapGuide on Windows? Most computers
today are 64-bit. Server OS versions of Windows now only exist in 64-bit.
Having to maintain 32-bit releases of MapGuide sounds quite pointless at
this point. Dropping 32-bit windows builds will halve the required build
efforts.

For the 3.3 release I want to float the idea of dropping 32-bit windows
builds for the reasons stated above. Thoughts?





Hope this gives you an idea of where this project is heading in my eyes.

Comments/Feedback appreciated.

- Jackie

[Hans Milling]

Thanks for the update Jackie. We will continue to use MapGuide for many
years.
By all means drop 32 bit support. We haven't use 32 bit for a few years
anyway.
We continue to use the MaestroAPI, since changing our WebGIS from this to
Fusion/React is a huge task and if we ever do this, we will start all over
with a brand new WebGIS I think.

GeoJSON is a great thing, we use this a lot in other projects. That would be
a very nice feature to include in MapGuide.

Best Regards
Hans Milling...



--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html

[Crispin_at_Linknode]

+1 on dropping Win32



--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html

[RenoSun]

Thank you so much Jackie. Will try my best to report bugs and provide
suggestions while the MGOS 3.1 release!



--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html

[Gabriele Monfardini]

Hi,

we're using Centos 6 MapGuide 32 and 64bit.
But I agree it's better to focus in a well supported linux build (and
remove 64bit blockers), no problems on which modern distribution is used.

Building from source was historically a cumbersome and very slow task,
since source is very big due to the huge amount of third party libs/apps
and hard coded values in makefiles, that prevent the process to be
streamlined.
I don't know if something has changed recently in this regard.

A dream as a Linux user would be to swap out third party components and
user system defaults, shipping only configuration details (f.i. Apache,
PHP).
This would make also compiling from source much easier and quicker.

Best regards,

Gabriele Monfardini

[Jackie Ng]

Now that both MapGuide and FDO have CMake build systems for building on
Linux, we can offload most of the thirdparty libs to what is provided by the
system. And in this respect, Ubuntu provides the most compatible set of
thirdparty libs we need to build MapGuide and FDO.

As of right now, we can actually build FDO trunk via CMake on Ubuntu 14.04
LTS with 100% system-provided thirdparty libs.

MapGuide via CMake is not fully there. We still need to internally build
dbxml, apache and PHP through existing build scripts and
AGG/DWFToolkit/CS-Map through hand-made CMakeLists.txt integration. But for
everything else, Ubuntu 14.04 LTS provides the right range of compatible
libraries.

I intend to use CMake over autotools as the defacto Linux build system for
MapGuide/FDO in the 3.3 release.

Once the 64-bit Linux blockers (which I've said I'll be detailing in another
post, and I still intend to) are cleared, it would also solve the problem of
what distros to support. We can simply standardize on Ubuntu and for
everything else, just run it inside a docker container based on an Ubuntu
docker image.

- Jackie



--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html