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<traian.sta...@autodesk.com> 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: mapguide-users-boun...@lists.osgeo.org
[mailto:mapguide-users-boun...@lists.osgeo.org] 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
mapguide-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-users
_______________________________________________
mapguide-users mailing list
mapguide-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-users
_______________________________________________
mapguide-users mailing list
mapguide-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-users
