[mapguide-users] RE: [fdo-users] FW: PostGIS provider connection question

[Orest Halustchak]

Hi Mike,

Thanks very much for your comments. As a summary, you're saying that we should 
fix major bugs first before this enhancement since there are ways to work 
around the connection to access other schemas. The bugs are the more important 
problem right now. Makes sense!

Thanks,
Orest.

-Original Message-
From: fdo-users-boun...@lists.osgeo.org 
[mailto:fdo-users-boun...@lists.osgeo.org] On Behalf Of Mike Toews
Sent: Thursday, July 16, 2009 6:22 PM
To: FDO Users Mail List
Cc: mapguide-users@lists.osgeo.org
Subject: Re: [fdo-users] FW: PostGIS provider connection question

Hi Orest,

I've been working with the provider for about a year now using Map3D 
2008 (soon 2010) and PosgreSQL 8.3/PostGIS 1.3.4 on an Ubuntu server. 
Over the course of this period I've experienced many incompatibilities 
with my schema and what we can implement in a production environment. 
I've submitted many bug reports for these, including the use of multiple 
geometry columns and using array data types. Several of these are fixed 
(Thanks!).

To overcome the incompatibilities with the FDO provider, I have found 
that I needed to isolate all data for FDO into it's own schema, and keep 
it separate from the main data. So I have a main schema for SQL work, 
QGIS, ODBC/MS Access, etc. and an fdo schema for the FDO provider 
(only), which is a subset of the main schema. I've even developed local 
replication triggers (set up using a PL/Python script) which replicates 
tables in both schemas (I can't use views with rules, since this is also 
a bug). This way, edits to data in either schemas are replicated.

This setup was a lot of work, is fragile to schema changes, and I'd 
rather use a single schema, just like the other client apps. Much of the 
recent work in the FDO provider will hopefully allow me to forget about 
the second replicated schema altogether, and connect/use the main schema.

Bruno's second comment about caching the schema is a bit of a concern 
for me. I have 10 schemas (three which are replications for fdo), with 
about 250 tables total (some of which are locally replicated between two 
schemas) and about 30 views. Also, Bruno's third comment about naming 
conventions is also a concern, since I have similarly named tables in 
different schemas, regardless if they are locally replicated between two 
schemas. I will have many many conflicts.

I don't see any limitations using the datastore to define the schema, as 
is presently done in the provider. This limits the scope of caching, 
which is good. I can always create additional FDO connections to other 
datastores if I need to get data from other schemas. Or I can create a 
cross-schema view if it is read-only.

I think I'd rather have development go toward fixing the current issues 
and bugs with the provider so that it is up to par with the capabilities 
of other PostgreSQL client software, such as ODBC and QGIS.

-Mike

Orest Halustchak wrote:
>
> *From:* fdo-internals-boun...@lists.osgeo.org 
> [mailto:fdo-internals-boun...@lists.osgeo.org] *On Behalf Of *Orest 
> Halustchak
> *Sent:* Friday, June 26, 2009 11:06 AM
> *To:* FDO Internals Mail List
> *Subject:* [fdo-internals] PostGIS provider connection question
>
> Hi,
>
> I have a concern about the current connection parameters that the FDO 
> PostGIS provider is using.
>
> The current situation is this.
>
> To make a connection to PostGIS we need to specify a service and a 
> datastore.
>
> The service is mapped to
>
> datab...@server:port
>
> And the datastore to
>
> The physical postgis schema
>
> So a typical connection would be
>
> Service : mypgdatab...@myserver:5432
>
> Datastore : public
>
> But a PostGIS server can contain multiple databases with each database 
> containing multiple schemas, which contain the tables. My question is 
> why wouldn't we set up a connection mapping that exposes the PostGIS 
> databases as FDO datastores and the PostGIS schemas as FDO schema, 
> similar to how we do it with SQL Server, which has similar concepts.
>
> So, connection information would be:
>
> Service: server:port, e.g. MyServer:5432
>
> Datastore: PG database name, e.g. MyPGDatabase
>
> Then, within that datastore, we have schemas called 'public' and any 
> other schemas that the user has created there, such as "landbase", 
> "transportation", "utilities", etc.
>
> I realize that this has already been implemented and changing this 
> could have some backwards compatibility issues with applications and 
> MG resource definitions. But, maybe the benefits of having a better 
> datastore / schema mapping to PG database / schema would be worth 
> figuring out how to deal with the compatibility issues?
>
> What do you think?
>
> Than

[mapguide-users] FW: PostGIS provider connection question

[Orest Halustchak]

Expanding the audience ...


From: fdo-internals-boun...@lists.osgeo.org 
[mailto:fdo-internals-boun...@lists.osgeo.org] On Behalf Of Jason Birch
Sent: Tuesday, July 07, 2009 1:52 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: PostGIS provider connection question

I don't have any real objections to this, though I don't have a vested interest 
in the PostGIS provider at this point.  It would probably be best to go to the 
mapguide and fdo users lists for feedback from real PostGIS users.

The original design decision was made because we had limited resources after 
moving away from the initial decision to implement using the generic RDBMS 
framework.  It was easier not to support multiple databases (something about 
ListDataStores, a lack of cross-database query capabilities in PostgreSQL, 
getting a bit fuzzy now) and at the time I didn't have a requirement for 
multiple databases on the same server, or cross-schema data access from a 
single connection.

As a note, I believe that best practice is not to store the PostGIS support in 
the public schema, but in an alternate schema using a search path.  I'm not 
entirely up to date on this though.

Jason

From: fdo-internals-boun...@lists.osgeo.org 
[mailto:fdo-internals-boun...@lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Tuesday, July 07, 2009 6:55 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: PostGIS provider connection question

Hi,

Does anyone have any thoughts on the topic below?

Thanks,
Orest.

From: fdo-internals-boun...@lists.osgeo.org 
[mailto:fdo-internals-boun...@lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Friday, June 26, 2009 11:06 AM
To: FDO Internals Mail List
Subject: [fdo-internals] PostGIS provider connection question

Hi,

I have a concern about the current connection parameters that the FDO PostGIS 
provider is using.

The current situation is this.

To make a connection to PostGIS we need to specify a service and a datastore.

The service is mapped to
 datab...@server:port

And the datastore to
The physical postgis schema

So a typical connection would be
Service :  mypgdatab...@myserver:5432
Datastore : public


But a PostGIS server can contain multiple databases with each database 
containing multiple schemas, which contain the tables. My question is why 
wouldn't we set up a connection mapping that exposes the PostGIS databases as 
FDO datastores and the PostGIS schemas as FDO schema, similar to how we do it 
with SQL Server, which has similar concepts.

So, connection information would be:
Service:  server:port,  e.g. MyServer:5432
Datastore:PG database name,   e.g. MyPGDatabase

Then, within that datastore, we have schemas called 'public' and any other 
schemas that the user has created there, such as "landbase", "transportation", 
"utilities", etc.


I realize that this has already been implemented and changing this could have 
some backwards compatibility issues with applications and MG resource 
definitions. But, maybe the benefits of having a better datastore / schema 
mapping to PG database / schema would be worth figuring out how to deal with 
the compatibility issues?

What do you think?

Thanks,
Orest.


___
fdo-internals mailing list
fdo-intern...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
___
mapguide-users mailing list
mapguide-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-users

RE: [mapguide-users] Longitude, Zone and Reference meridian

[Orest Halustchak]

Hi Don,

I'm assuming you mean UTM zone?

For UTM, given the zone number the formula for central meridian is: zone * 6 - 
183

UTM zones are 6 degrees wide.

>From this, you can generate the math for going in the other direction.

Thanks,
Orest.

From: mapguide-users-boun...@lists.osgeo.org 
[mailto:mapguide-users-boun...@lists.osgeo.org] On Behalf Of Don C. MacGregor
Sent: Wednesday, January 28, 2009 12:26 PM
To: mapguide-users@lists.osgeo.org
Subject: [mapguide-users] Longitude, Zone and Reference meridian

Hi folks
There is a linear relationship among Longitude, Zone and Reference meridian, 
does anyone know any formula to calculate Zone and Reference Meridian if I know 
Longitude?
Thanks




Be smarter than spam. See how smart SpamGuard is at giving junk email the boot 
with the All-new Yahoo! Mail 
___
mapguide-users mailing list
mapguide-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-users

[mapguide-users] FW: [fdo-users] Any MySQL users out there?

[Orest Halustchak]

Hi,

Let us know if you use the FDO MySQL provider and which version of MySQL that 
you're using.

See below ...


Thanks,
Orest.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Birch
Sent: Wednesday, December 10, 2008 5:55 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] Any MySQL users out there?

MySQL is an interesting provider.  I think MySQL is the immediate choice for 
most non-geo-savvy open source users-and as such it is important to support 
it-but it wouldn't be considered by geo-types because of its lack of support 
for non-BBOX comparison operations.  I'd be interested to see the answer to 
this question; perhaps it would be good to ask on mapguide-users too?

Maybe we should build a phone-home feature into FDO so we can count actual 
usage of the providers... just kidding :)

Jason

From: Orest Halustchak
Subject: [fdo-users] Any MySQL users out there?

If you use MySQL and the FDO provider for MySQL, what version of MySQL are you 
using?

The MySQL 5.1 GA version was released recently. Is anyone planning to move to 
5.1 in the short term? It looks like the client libraries are not binary 
compatible with 5.0.
___
mapguide-users mailing list
mapguide-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-users

RE: [mapguide-users] SQL 2008

[Orest Halustchak]

Hi,

Have a look at: http://fdo.osgeo.org/

There is a beta sql server 2008 provider available that works with the recent 
CTP versions of SQL Server 2008.

Thanks,
Orest.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Berdel, Brian
Sent: Wednesday, March 05, 2008 11:07 AM
To: MapGuide Users Mail List
Subject: [mapguide-users] SQL 2008

Has anyone used SQL 2008 with MapGuide Yet? Is it possible? It now
supports spatial data.  I was going to try it, but I wanted to check
with the community first.

Thanks,

Brian  Berdel
McMahon Associates, Inc.
p: 215.283.9444
www.mcmtrans.com


___
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

RE: [mapguide-users] Applying new schema to FeatureSource

[Orest Halustchak]

Hi Ismael,

SDF does allow a new property definition to be added to an existing class (if 
there is data already in the class, the new property needs to allow nulls). 
There is no gui in MG that exposes this, though. Do you have a copy of Map3D? 
If so, the Map3D schema editor will allow you to modify the schema. Otherwise, 
the FDO api provides a way to do this programmatically (describe the schema, 
add the new property def to the class, apply schema). Unfortunately, the 
Feature Services api currently is not exposing that capability.

Thanks,
Orest.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ismael Cams
Sent: Thursday, January 17, 2008 8:20 AM
To: mapguide-users@lists.osgeo.org
Subject: [mapguide-users] Applying new schema to FeatureSource


Hello,

I have a SDF where I want to add a new propertydefinition. What is the best
practice to achieve this ?
One way is to create a new SDF with the extra property and to copy all the
features from the existing source to the new one. Only this seems a bit
complicated for just adding one column ...

Any ideas ?

Thanks in advance.
--
View this message in context: 
http://www.nabble.com/Applying-new-schema-to-FeatureSource-tp14918648s16610p14918648.html
Sent from the MapGuide Users mailing list archive at Nabble.com.

___
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