[mapguide-users] SQL Server 2005

Thu Oct 5 05:21:49 EDT 2006

Robert,

From what I can see, the documentation that comes with Map 2007 is
somewhat lacking when it comes to detailing how data, including the
geometry, can be put into SQL Server. E.g. do we need a blank database
on the SQL instance? Can you point me to any documentation?

Keith

________________________________

From: Robert Fortin [mailto:robert.fortin at autodesk.com] 
Sent: 04 October 2006 18:03
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

Jim,

The AGF is a legacy name valid until FDO 3.1 that is showing in the doc.
Although it still show up in the doc, it has been replaced by FGF (FDO
Geometry Format) for API function and class names in FDO 3.2    e.g.
GisAgfGeometryFactory became FdoFgfGeometryFactory

Look into the FDG_FDODevGuide.pdf under "The Geometry API". It describes
the binary format.
There is an API to simplifies reading/wrting binary AGF.
There is also a text version AGF text (search AGF Text).

RF

________________________________

From: Lockyer James [mailto:James.Lockyer at bradford.nhs.uk] 
Sent: Wednesday, October 04, 2006 11:37 AM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

Hi Robert

Thanks for that, I read some of the documents but none stated that the
FDO SQL only worked if you had Map 3D - it was something I guessed by
accident when I was trying to reverse engineer the process of
connection.  So effective FDO to me would mean one that didn't rely on
me purchasing a third software package.  

What information is there about FGF binary format? I've managed to
create an SQL file which sorts out the meta data on the SQL file.  I'd
stopped when I established that the expected datasource was in fact
binary rather than GML (which was my firt thought as to how data could
be stored).

Jim

________________________________

From: Robert Fortin [mailto:robert.fortin at autodesk.com]
Sent: Wed 04/10/2006 15:59
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

Jim,

I guess as for the documentation, it is an oversight and should be
fixed.  Some of this documentation exist from the FDO side
(FDG_FDODevGuide.pdf and FET_TheEssentialFDO.pdf available on the open
source side)   But I agree that even there there is not enough and could
be further refine.

Mapguide SP1 will introduce performance enhancement for reading data.  I
hope that it will cover some of your concern with your Odbc case.

"And is there any intention of creating an effective FDO for SQL." 

I'm not sure what you would consider an effective provider for SQL
server.  SQL Server doesn't have native support for geometry.
Therefore, we need some mechanism to deal with it.  Like I said, you can
still read data out of SQL server but that has limited use if you can't
get your geometry out of it.  The geometry is currently stored in FGF
binary format and the database requires FDO metadata in order to work
with geometry.  

We look at supporting geometry stored in OGC WKT format to give some
flexibility for non-FDO enable database but it is not currently
implemented at this time.

RF

________________________________

From: Lockyer James [mailto:James.Lockyer at bradford.nhs.uk] 
Sent: Wednesday, October 04, 2006 10:09 AM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

Cheers,

Can I ask why it has taken three months to point that out or why this is
not mentioned in the any of the help files/ published material on the
internet or for that matter why the UK resellers are unaware of this
fact.  And is there any intention of creating an effective FDO for SQL.

In case you have X,Y,Z coordinates stored in different columns, the ODBC
provider should be used against SQL Server data. - has this been speeded
up in the latest release?  As when I tried this it took over 40 minutes
to map out four points.

Has anyone thought about using GML as a storage mechanism?

Jim

James Lockyer
GIS Specialist
IM&T
Bradford and Airedale Teaching PCT
New Mill, Victoria Road, Saltaire, Shipley, West Yorkshire, BD18 3LD

Tel: 01274 366031

This email is intended for the use of the addressee only and may contain
confidential information, copyright material or views/opinions that do
not necessarily reflect those of the organisation. If you receive this
email by mistake please advise the sender immediately. All should be
aware that this email may be subject to public disclosure under the
Freedom of Information Act 2000 and that emails are monitored
periodically.

________________________________

From: Robert Fortin [mailto:robert.fortin at autodesk.com]
Sent: Wed 04/10/2006 14:39
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

The SQL Server provider is intented to work with datastore created with
Map 3D 2007 inside SQL Server 2000 and 2005.
It has it's own geometry storage and spatial indexing mechanism.
Although it could reverse engineer existing database, this would be done
for non-spatial data only as it has no mean to identify geometry
property in the database.

In case you have X,Y,Z coordinates stored in different columns, the ODBC
provider should be used against SQL Server data.

Just wanted to make sure the provider was not being used for what it was
not design for.

RF

________________________________

From: Lockyer James [mailto:James.Lockyer at bradford.nhs.uk] 
Sent: Wednesday, October 04, 2006 2:59 AM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

Supported yes - does it work... now that's the question.

________________________________

From: Gord McKenzie [mailto:gord.mckenzie at canam.com]
Sent: Tue 03/10/2006 22:04
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

Thanks

________________________________

From: Warren Medernach [mailto:warren.medernach at imaginit.ca] 
Sent: Tuesday, October 03, 2006 1:33 PM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

Hello Gord,

I was informed by the ADN that the FDO provider supports: SQL Server
2000 (SP4) and SQL Server 2005.

Warren Medernach

This message has been scanned for viruses by MailControl
<http://bluepages.wsatkins.co.uk/?4318150> 

This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_users/attachments/20061005/2e28ec69/attachment.html