James Fee GIS Blog

25 responses so far ↓

• 1 sohbet // Aug 6, 2008 at 7:06 pm

  very good wonderfull

• 2 Tim Maddle // Aug 6, 2008 at 8:15 pm

  I hope this brings additional competition to the desktop GIS market. I wonder if the next version of Office will have a GIS viewer/editor component just like a word processor and spreadsheet.

• 3 JW // Aug 6, 2008 at 8:48 pm

  MMS RFC 38 check it out….the future of enterprise GIS.

• 4 Chris M // Aug 7, 2008 at 8:23 am

  Can anyone comment on how hard it will be to migrate an existing SDE Geodatabase from SQL 2005 to SQL 2008 platform?

• 5 Steven // Aug 8, 2008 at 6:42 am

  And what tools are out there to get a regular shape-file into 2008 ?

• 6 bob // Aug 8, 2008 at 6:59 am

  And what tools are out there to get a regular shape-file into 2008 ?

  Manifold GIS can do this, and I believe FME will have some tools too. Finally, I’m sure there will be a bunch of free downloads that could do it too.

• 7 JW // Aug 8, 2008 at 7:39 am

  it is extremely easy to migrate a SQL 2005 instance to 2008. Now if you are implying changing the storage type from SDE BLOB to SQL spatial, that is a lot more involved. It will involved a similiar migration process that people had to go through to migrate SDE LONG RAW to ST_GEOMETRY.

  Data Interoperability with 9.3 already supports 2008, but it will get updated to support 2008 RTM when the 9.3 SP comes out (very soon now) you will be able to bring shapefiles into SQL spatial columns.

• 8 James Fee // Aug 8, 2008 at 8:51 am

  There are reasons to use Manifold GIS with SQL Server, but as a data loader you are probably wasting your money.

  http://www.sharpgis.net/page/SQL-Server-2008-Spatial-Tools.aspx

  I’m not sure if Morton needs to update his code for RTM or not but I’ll find out when we get the “final” release.

• 9 bob // Aug 8, 2008 at 2:09 pm

  Yes, thats right - sharpnet. That was the free stuff that I couldn’t remember what the name was. Thanks.

  Really great free tool too. But, Manifold and FME would be money well spent if you wanted to do any kinds of coordinate transformations beforehand, or possible pre-processing of data.

• 10 Morten // Aug 8, 2008 at 5:06 pm

  As far as I can tell, my tool continues to run just fine on the RTM version.

• 11 JW // Aug 11, 2008 at 7:46 am

  can anyone tell me how to place a constraint on the spatial column so only one SRID can be used? It seems scary that you could populate the column with any SRID info. I feel this should have been included as a design property. Now granted it may be, I’m working with a real early CTP.

• 12 Bill // Aug 11, 2008 at 8:16 am

  @JW

  Yes. Here it is:

  http://geobabble.wordpress.com/2007/11/26/spatial-references-in-sql-server-2008-part-2/

• 13 JW // Aug 11, 2008 at 11:55 am

  ok thanks. That is easy enough. I still think this should be a property you should be able to set when you design the column. Something as static as a spatial reference shouldnt be treated so non chalantly.

• 14 Dale Lutz // Aug 11, 2008 at 4:55 pm

  Just wanted to confirm that:

  a) FME 2008 works just fine with the SQL Server 2008 RTM

  b) Data Interop extension in 9.3 that shipped DID NOT include SQL Server 2008 Spatial support (but works fine with the non-spatial in SQL Server 2008)

  c) There is a very very good chance that SQL Server 2008 spatial will be part of 9.3 SP1, and a 100% chance it will be there for 9.3 SP2.

  Lastly, Johannes posted a good story of using SQL Server Spatial, FME, and Virtual Earth together in an interesting way over on his blog at

  http://tinyurl.com/59mla3

  that some of you might find interesting.

  Dale

• 15 Dimitri // Aug 12, 2008 at 9:14 pm

  Regarding…

  Can anyone comment on how hard it will be to migrate an existing SDE Geodatabase from SQL 2005 to SQL 2008 platform?

  Trivial, if what you mean is moving your data from SDE into SQL Server 2008 native.

  Link the SDE data source into your project and open it. Choose File - Export to send it into your SQL Server 2008 data source and you’re done.

  Ah… one more step: Break out the drinks and celebrate freeing your data from the horribly obsolete SDE silo. Feel smarter, accept the congratulations of your friends and beam with self confidence when your girlfriend asks you if you’ve lost weight or have been working out…

  If you have zillions of drawings in SDE (I feel your pain…) you could, of course, automate this with a script.

• 16 JW // Aug 13, 2008 at 5:58 am

  zillions of “drawings” in SDE…?

  Your CAD is showing.

  And I’m not so certain that migrating your data from an SDE blob to a SQL column managed by SDE is breaking out of the silo. SDE will still freak out if you do anything behind the scenes since those changes won’t be “registered” with the SDE mothership.

  Truly breaking out of the SDE silo would be creating a new table from scratch with a spatial object and all of the attribute columns from the SDE FC, exporting the geometries to a shapefile (with a FK to join back later) import shapefile via sharpmap, join back to SDE business table and pull the attributes across. THEN, serve the resultant dataset to ArcGIS using FME or MS4W WMS/WFS. Keeps SDE from even touching the table and you can manipulate it all you want without SDE complaining and creating all of its stupid GDB_ maintenance tables

• 17 Chris M // Aug 13, 2008 at 10:19 am

  Aren’t those the same tables that allow me to support versioned editing and distributed DBs without having to know squat about my DB administration?

• 18 JW // Aug 13, 2008 at 10:54 am

  true, if you plan on editing those tables with an ArcGIS client you will need an ArcGIS Server Basic licence on top of those databases.

  Fortunately I don’t fall into that category and can generate and update FCs outside of an ArcGIS client.

• 19 Dimitri // Aug 13, 2008 at 12:17 pm

  And I’m not so certain that migrating your data from an SDE blob to a SQL column managed by SDE is breaking out of the silo.

  I should have been more clear. My response was for “moving your data from SDE into SQL Server 2008 native” … the emphasis being on “native” as in using SQL Server 2008 native spatial types directly without needing the dead albatross of SDE around your neck.

  One of the key benefits of having a modern spatial DBMS, such as Oracle or, now, SQL Server 2008, is being able to use the spatial DBMS’s own native spatial types and spatial infrastructure in direct connections from an equally modern client. That frees you from the SDE silo because it enables any application that respects the DBMS’s standards to work with that data by connecting directly to the DBMS.

  Modern spatial software can, of course, connect directly to spatial DBMS with no need of Rube Goldberg middleware like SDE.

• 20 JW // Aug 15, 2008 at 6:02 am

  well see that’s still the problem. If you still have SDE on top of the tables in the RDBMS it is not freeing “you from the SDE silo” to enable “any application that respects the DBMSs standards”

  The day I can make schema changes and add rows to the SDE managed table wthout SDE freaking out is the day I’ll say we are free from the SDE silo.

  We are getting close.

• 21 Dimitri // Aug 15, 2008 at 1:12 pm

  well see that’s still the problem. If you still have SDE on top of the tables in the RDBMS it is not freeing “you from the SDE silo” to enable “any application that respects the DBMSs standards”

  We’re talking past each other. You’re assuming someone still has SDE on top of the tables. My point is that once you have a real spatial DBMS like SQL Server 2008 there is *no need* for SDE if you are running modern software.

  It’s true that if you are running some horribly old-fashioned client that for no good reason *requires* you to use SDE you are stuck in the SDE silo. But that’s not SQL Server 2008’s fault - it’s your choice of an old fashioned client that keeps you stuck in the SDE silo.

  If your GIS client software vendor doesn’t know how to connect directly to a modern, mainstream spatial DBMS like SQL Server 2008 without requiring a layer of living fossil middleware like SDE, get rid of them and choose a vendor who can.

• 22 James Fee // Aug 15, 2008 at 1:53 pm

  ArcGIS can connect to SQL Server 2008 without ArcSDE middleware, just needs an ArcSDE license.

• 23 J // Aug 17, 2008 at 7:13 pm

  So ESRI says to the customer, “You don’t have to use my software to do the job, just pay me for it, and you’re good to go.”?

• 24 RSF // Aug 18, 2008 at 9:06 am

  James, I just want to make sure I understand correctly. The “direct connect” hype with ArcGIS 9.3 and SQL Server 2008 is still dependent on SDE? I can’t connect to spatial data in SQL 2008 with ArcGIS desktop alone, I need to have a SDE license?

  How does this work? Would I need to connect through SDE (not using any of the management features in SDE), or does ArcGIS look for and consume an SDE connection/user license, then connect directly to SQL Server 2008 spatial data?

• 25 ChrisW // Aug 19, 2008 at 2:14 am

  J: “You don’t have to use my software to do the job, just pay me for it, and you’re good to go.”

  And that way nobody ever needs to worry about software upgrades again - just buy the new licence.

Leave a Comment