[mapguide-users] SQL Server 2005

Thu Oct 5 14:22:18 EDT 2006

If I'm not mistaken, you can also create feature classes and apply those to
your objects. Once the objects are classified then there use to be an option
to load that directly to a connection. I'll take a look and see if this is
still true.

Brad

  _____  

From: Warren Medernach [mailto:warren.medernach at imaginit.ca] 
Sent: Thursday, October 05, 2006 9:30 AM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

Hello Keith,

The basic process is as follows:

    - Create the datastore using the FdoUserManager.exe found in the <Map
Install>\FDO\Bin folder

    - Create a user for this datastore using the same tool above.

As for getting data into the store...  this is the tricky part as there are
no direct tools in Map to get dwg data into the datastore.  Once connected,
you could define the schema manually and populate it manually in Map.
However one method I have employed for getting data into the datastore is to
export the dwg data as SHP (yes I know there are inherent problems with this
method...  i.e. Arcs), and then connecting to that SHP file, and then
performing a Bulk Copy from the SHP to the SS Datastore.  This method has
worked pretty well to populate the SS datastore.

Hope this helps.

   Warren Medernach

   IMAGINiT Professional Services

  _____  

From: Campbell, Keith A [mailto:keith.campbell at atkinsglobal.com] 
Sent: Thursday, October 05, 2006 3:22 AM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] SQL Server 2005

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
<http://bluepages.wsatkins.co.uk/?4318150> MailControl

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.
<http://www.blackspider.com/> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20061005/1b55dac6/attachment.html