@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 _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users
