[mapguide-users] Some thought on FDO PostGIS Provider

[Gabriele Monfardini]

@all
Thank you for your quick replies.

@Traian
> It never was compiled with PostGIS by default.
> Before, I was doing a custom build with a static link to an
> OGR build which has PostGIS support built in.
Ok. I was only saying that there was PostGIS support out of the box in
Windows binaries.

>Needless to say that takes a long time to do due to the huge dependency list
> and there have only been one or two people who have asked for it,
> so not enough demand to make it worth my time.

Compiling GDAL with support to all takes about 30 minutes on my Linux
box, against 15 minutes if I disable all except the core.
However, I don't want to blame you if you drop some less used dependencies, but

1. PostgreSQL+PostGIS is by far one the most used in open source GIS,
much more than MySQL.
Moreover it is at the state of the art w.r.t. much more expensive
other solutions.
2. PostGIS provider doesn't always work, and it is not so well mantained.

Don't you think that it would be useful for the casual user to have
PostGIS support working well out-of-the-box?

> However, since the default build now uses dynamic link to the GDAL DLL,
> you should be able to replace the Gdal.dll with one that has PostGIS support
> compiled in it and automatically get PostGIS support.
>I only have such builds for FDO 3.3 (MG 1.2), posted at 13-9.com.
> If there is enough demand, I could try to do a build with whatever FDO
> the "new" MGOS is using -- but it would really be better if someone else
> who is more vested in this volunteered, and I could provide some support
> with how to build it.

I've found this link.

http://n2.nabble.com/FDO-OGR-Driver-3-4-0-Connecting-to-PostGIS-8-2-with-AutoCAD-Map-3d-2010-fails-td3728628.html#a3736552

It is not perfect since you have to add 2 more dll to the list in
order to solve all dependencies, and choose the correct gdal version.

The fact that MapGuide is tied to one specific version of gdal and its
dependencies may make difficult in the future to find all the dlls in
the required versions (that moreover, AFAIK are not well documented
anywhere...)
It is one of the cons to include gdal source in mapguide instead of
building against the current stable tree.

I propose this solution, that I think is a win for all.
Add one page into FDO site that hosts all dlls needed, in the
"versions-needed-for-current-Mapguide-stable-tree" (TM) and a step by
step procedure (that simply says delete these dlls, add these other
ones).
If you want I can help you finding all dlls, since my setup now seems to work.

In this way you may keep compiling OGR faster without PostGIS support
but PostGIS users are no more needed to guess which particular
gdal.ddl, libpq.dll etc... are required, nor to find tricky hints into
forums.

@Jason
> but the fact is that it's languishing because it hasn't had enough community
> interest and development support.
It is surely true, but also the contrary may be true.
It hasn't had enough community interest since it has never worked well
out of the box.
I cannot promise my boss I can solve all the problems, thus it is
difficult to "support" Mapguide adoption in a PostGIS environment.
Let's at least make easier to use OGR that has supported PostGIS well
until several years and it is maintained independently from MapGuide

@Kenneth
>I have recorded the requests as issue #1275:
Thank you very much. Let me thank you again for the time saved using
Mapguide Maestro, a very good project.

> The "update layers, when featuresource changes" request, is recorded as issue #1067
> If there is any way you can provide reproduce able instructions for the save problem,
> please let me know.
I'll do my best.
For what I've seen, the problem happens only when the FDO PostGIS
"timestamp with time zone" bug is triggered.
The bug cause also FdoToolbox to crash, so I'm pretty sure is a FDO bug.
When the schema is read correctly, also the save works in Maestro.
I need to do some more tests, in order to provide you a small test
that is reproducible.

>Each time you start a map or something similar, MapGuide
> issues a DescribeSchema request. If you simply reference
> your entire database, this will take much longer than if you
> split it up in "schema" parts.
I understand the point.

> Also, if you expose your entire db, be aware that you are effectively
> exposing the database to the users. A rouge user can easily
> get MapGuide to hand over all exposed data, so the less there
> is avalible to MapGuide, the better.
I also understand this point, however PostgreSQL has access control on
all objects, it is not difficult to setup it to restrict access only
to the needed data.
This is the why all other libraries use connection to the db and not
to the schema.

> I have also built the OGR and Gdal provider with PostGIS support
> some time ago. I belive the build procedure is now so simple that
> it is just a matter of installing Visual Studio, checking out the code with
> SubVersion, and running the "build.bat".
I use Windows binaries in order to have them in the correct versions
and working fast.
In order to understand if it is worth to spend my time compiling on
Linux, that is  by far my preferred environment.

I would prefer, as a starting point, not to build things on my own on
windows, since I want to know which is the current state of Mapguide
project in terms of stability, performance and robustness using only
"known-to-work components".

@Zac
> this relates to http://trac.osgeo.org/fdo/wiki/FDORfc43
I've read it, thanks.

Regards,

Gabriele