Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1815 closed defect (wontfix)

Maestro does not find datasource from successful connection by Postgres FDO 3.5

Reported by: captainst Owned by: jng
Priority: low Milestone: Maestro-4.0
Component: Maestro Version: 2.2.0
Severity: major Keywords: FDO Postgis Maestro
Cc: External ID:

Description

I have the shape file with coordinate system as EPSG:4326, which I believe is a Geography type (not sure).

I am using the windowsXP prof SP3, maestro 4.0 beta2, Mapguide 2.2, Postgres 8.4 with Postgis 1.5.

I successfully imported the data into a newly created database (with temp_postgis as template).

In Maestro, I am able to use the FDO3.5 provider to connect to the database.

However, after the "connection success", the Maestro does not find the "source" for a coordinate system, which remains empty. So the layer can not find instance for the data source.

This problem does not show up when I use the FDO SQL 2008 express provider, which shows "default" as the data source in the coordinate system.

I learned from the following link that the Postgres FDO 3.5 provider is known to work with Geometry type data http://trac.osgeo.org/fdo/wiki/FdoPostgreSQLNotes

While I have geographic type. Could this be a problem ?

Change History (3)

comment:1 by jng, 13 years ago

Resolution: wontfix
Status: newclosed

Downgrade your version of PostGIS (< 1.5) or roll your own build of MapGuide/FDO from trunk. This is nothing to do with Maestro.

comment:2 by captainst, 13 years ago

You are great jng !!!

I downgraded the PostGIS version to 1.3 and the problem is resolved.

However, the performance by the Postgres server gave me a suprise: In maestro, the layer "preview" from a alias source (shp file 300MB) takes about 40sec to show up in the brower, while layer from a Postgres source (same data) takes roughly 90sec, during which the CPU load is always 100% (core 2 duo, 3GB ram), shared by Mapguide, and Postgres services...

comment:3 by jng, 13 years ago

Note the Maestro will always try to preview data and layers at *full* extents. I would say 40s is par for the course, given that it is not normally expected to show a 300MB SHP at full scale and level of detail.

This is where you then employ layer filters and scale ranges to reduce the level of detail and complexity at higher zoom levels, and you should then start to see improved rendering performance.

Note: See TracTickets for help on using tickets.