this relates to http://trac.osgeo.org/fdo/wiki/FDORfc43
been a lot of discussions bout this over on FDO in the past On Thu, Feb 18, 2010 at 7:08 PM, Kenneth Skovhede, GEOGRAF A/S <[email protected]> wrote: > Traian: > Are you sure that the OGRProvider in MGOS 2.1 is dynamically loading gdal? > My stock install has a 2mb+ OGRProvider.dll and has many strings inside from > the OGR library. > Also, when running MapGuide and viewing OGR data, I'm able to delete the > gdal16.dll. > > OP: > I have little real-world experience with the PostGIS provider, so I can > only answer the Maestro related part of your question. > > The word "DataStore" is what the provider exposes the parameter as. > Probably because it is based on the common RDBMS code. > I can change the word in the userinterface for Maestro to "Schema", > but it makes it slightly harder to guess how the value is mapped. > > I can also change it so Maestro suggests "public" as the schema when > creating a new > PostGIS FeatureSource. > > I have recorded the requests as issue #1275: > http://trac.osgeo.org/mapguide/ticket/1275 > > The naming issue sounds a little weird, it is supposed to be "Schema:Table", > not "PostGIS:*" or "OGRSchema:*". The value listed in Maestro, is whatever > the provider chooses to report. If you use the intended form (Schema:Table), > you can see > why Maestro cannot drop the Schema part, even if some propviders support > using > a default schema. > > Feel free to add an enhancement request for Maestro, for not including the > schema part > of the tablename for providers that misuse the naming scheme (and support a > missing schema). > > The "update layers, when featuresource changes" request, is recorded as > issue #1067 > http://trac.osgeo.org/mapguide/ticket/1067 > > If there is any way you can provide reproduce able instructions for the save > problem, > please let me know. > > ***Non Maestro related follows *** > > 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 assume this is why the PostGIS provider > does it this way. Obviously, the provider (or MapGuide) should be > smart enough not to request all this info, but it is not. > > 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 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". > > You only have to fiddle with the Gdal file called nmake.opts to have it > include > PostGIS. > > I would expect it to take a day or two to get a working build, if you want > to try. > > Regards, Kenneth Skovhede, GEOGRAF A/S > > On 18-02-2010 06:20, Jason Birch wrote: >> >> To the OP: >> >> I understand your frusteration with getting PostGIS to work, but the >> fact is that it's languishing because it hasn't had enough community >> interest and development support. My organisation and Refractions >> Research funded initial development of the provider by Mateusz, but it >> never performed well enough to meet our needs. Following that, Geomap >> GIS performed some bug fixes and maintenance. Apart from that there >> has been very limited interest, funding, or development on this >> provider. It looks like there may be some light at the end of the >> tunnel now that Autodesk has resurrected and improved on a discarded >> version of the initial provider, but you won't see benefit from that >> until at least 2.2 if not later. >> >> To follow up on Traian's point, it's quite possible that the required >> GDAL and plugins are available in the OSGeo4W repository. The mapguide >> trac page for the GDAL provider (linked from the front page I think) >> links to a message showing how to add raster plugins. After some >> initial encouragement from Frank, all it took was a half hour or so >> sitting with "depends.exe" to work out what I needed in addition to >> gdal.dlls. I'd imagine that vector/ogr plugins work the same way. >> >> Jason >> >> On 2010-02-17, Traian Stanev<[email protected]> wrote: >> >>>> >>>> Why OGR is no more built by default with PostGIS support? >>>> >>> >>> 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. >>> 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. >>> >>> 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. >>> >>> >>> >>>> >>>> That said, if you know an URL with OGR dll compiled with PostGIS >>>> support, in a version compatible with Mapguide, I would rather try >>>> them, before starting editing the 1000 layers... >>>> >>> >>> 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. >>> >>> >>> Traian >>> >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Gabriele >>> Monfardini >>> Sent: Wednesday, February 17, 2010 6:48 AM >>> To: MapGuide Users Mail List >>> Subject: [mapguide-users] Some thought on FDO PostGIS Provider >>> >>> Hi all, >>> >>> I am trying Mapguide 2.1 and FDO PostGIS provider (using Maestro 2.0 >>> RC1). >>> >>> The provider uses the word "datastore" to refer to PostgreSQL schema >>> (http://www.postgresql.org/docs/current/interactive/ddl-schemas.html). >>> This is very misleading since there are schemas and tablespaces in >>> PostgreSQL, but no datastores. >>> Moreover (this can be a Maestro issue) the default value seems to be >>> empty instead of "public", that is the default schema present in all >>> PostgreSQL databases. >>> >>> Second problem: what is the reason to include the schema in the >>> dataconnection? >>> I mean, I want to connect to a specific database, not to a specific >>> schema inside the database. >>> The schema and the table should be part of layer definition, as in OGR >>> Provider. >>> This would be better from a logic point of view and I don't know of >>> any application that requires to specify the schema before connecting >>> to a PostgreSQL db. >>> >>> One may think this is a minor issue. >>> In fact it depends on the size of the repository. >>> >>> I'm about to migrate from Mapguide 1.2 OGR Provider to 2.1 PostGIS >>> Provider. >>> I have around 40 databases, each one with 5-10 schemas for a total of >>> over 1000 layers. >>> With Postgis Provider I have to create 200-400 dataconnection (instead >>> of 40) and manually modify all 1000 layers. >>> The last part is needed since the layer specifies in the FeatureName >>> the dataconnection provider type (that has to be updated from >>> OGRSchema:schema~table to FdoPostGIS:table) and from my preliminary >>> experiments Maestro is not so smart to update the layers when I change >>> only the dataconnection type, but not its name. >>> >>> I do not consider this a Maestro issue (in fact its smartness is >>> already invaluable), but a not so smart decision when designing the >>> XML schema. >>> Since the layer specifies the ResourceId, IMHO there is no apparent >>> need to decorate its FeatureName with dataconnection provider type. >>> But maybe I'm ignoring something. >>> >>> I've also probably found a bug in FDO PostGIS provider. >>> If at least one table in the schema contains a field of type >>> "timestamp with time zone", the provider is not able to describe the >>> schema. >>> >>> Trying to save such a dataconnection into the repository (with >>> Maestro) or trying to create a layer with this dataconnection leads to >>> errors in Mapguide 2.1. >>> Not always the errors are the same (different paths in the code >>> depending to resource already cached or not?), and I report the three >>> more commons: >>> >>> 1 - "describe schema command failed" at >>> mgdev\server\src\services\feature\ServerDescribeSchema.cpp, line 204 >>> >>> <2010-02-15T18:06:59> 512 MapGuide Maestro >>> v2.0.0.4569 10.1.1.244 Administrator >>> Error: An exception occurred in FDO component. >>> The describe schema command failed for 'FdoPostGIS' schema. >>> StackTrace: >>> - MgFeatureServiceHandler.ProcessOperation() line 83 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\FeatureServiceHandler.cpp >>> - MgOpDescribeSchemaAsXml.Execute() line 110 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\OpDescribeSchemaAsXml.cpp >>> - MgServerFeatureService.DescribeSchemaAsXml() line 333 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerFeatureService.cpp >>> - MgServerDescribeSchema.DescribeSchemaAsXml() line 628 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp >>> - MgServerDescribeSchema.DescribeSchema() line 564 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp >>> - MgServerDescribeSchema.DescribeFdoSchema() line 204 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp >>> >>> >>> 2 - "Null reference" at >>> \mgdev\server\src\services\feature\ServerDescribeSchema.cpp, line 77 >>> (not so auto-explaining message for the user) >>> >>> <2010-02-15T17:50:02> 2556 MapGuide Maestro >>> v2.0.0.4569 10.1.1.244 Administrator >>> Error: Null reference. >>> StackTrace: >>> - MgFeatureServiceHandler.ProcessOperation() line 83 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\FeatureServiceHandler.cpp >>> - MgOpDescribeSchemaAsXml.Execute() line 110 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\OpDescribeSchemaAsXml.cpp >>> - MgServerFeatureService.DescribeSchemaAsXml() line 333 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerFeatureService.cpp >>> - MgServerDescribeSchema.DescribeSchemaAsXml() line 628 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp >>> - MgServerDescribeSchema.DescribeSchema() line 564 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp >>> - MgServerDescribeSchema.DescribeFdoSchema() line 77 file >>> >>> c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp >>> >>> >>> 3 - A terrible MgInvalidStreamHeaderException that seems not properly >>> catched and crashes the server, without logging anything at all. >>> This seems to happen more often when trying to create the layer >>> selecting the dataconnection. >>> This one appears to be a bug in Mapguide. >>> >>> I've also find a possible bug in Maestro. >>> When I try to save the problematic dataconnection it warns me that FDO >>> connection failed and offers to save it anyway. Sometimes, even if I >>> save it, it does not record correctly the Datastore, leaving it empty >>> in the XML. >>> >>> Last "rant". >>> Why OGR is no more built by default with PostGIS support? >>> It would have provided me a much more smooth upgrade from 1.2. >>> Moreover, FDO PostGIS Provider is quite recent, initially developed >>> only for Windows, and I suspect not so much used. >>> Having 2 possible connection to PostGIS would offer the possibilities >>> to compare the performances (that in my situation are very important) >>> and choose the best one. >>> >>> I am not so happy to drop here and there new dlls, also because in my >>> experience MG is quite strict on library versions, and at least >>> version 1.2 quite poor on logging useful information. So this could >>> lead to not-logged crashes or generic errors that are very difficult >>> to solve. >>> >>> That said, if you know an URL with OGR dll compiled with PostGIS >>> support, in a version compatible with Mapguide, I would rather try >>> them, before starting editing the 1000 layers... >>> >>> Regards, >>> >>> Gabriele Monfardini >>> _______________________________________________ >>> mapguide-users mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/mapguide-users >>> >>> >> >> _______________________________________________ >> mapguide-users mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/mapguide-users >> > > _______________________________________________ > mapguide-users mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapguide-users > -- Zac Spitzer Solution Architect / Director Ennoble Consultancy Australia http://www.ennoble.com.au http://zacster.blogspot.com +61 405 847 168 _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users
