ArcGIS Query Layers

Spatialo_rdbmsOver the last couple of years, spatial database technologies have become easier to acquire, implement and configure.  Whether it's Microsoft's foray into spatial databases with the release of SQL Server 2008, the numerous Open Source spatial database options, or Oracle, organizations are starting to see the value applying a geographic context to their corporate data.

To make things even easier and more appealing to get into a spatial database, are the ‘free’ of the Open Source communities and the following offerings by Microsoft & Oracle:

Both of these RDBMS are “Free to develop, deploy, and distribute”.  This means that anybody can download, and start building a ‘GIS’ warehouse with very minimal costs. Obviously, there are some limitations with these free offerings and they are not going to provide base for a large enterprise solution, but they are a great way to get into the technology.

ESRI has been spatially enabling databases for years, and has solidly established themselves as ‘the’ GIS tool of choice, and some might even argue that ESRI = GIS.  The spatial enabling component for ESRI has been something called SDE: Spatial Data Engine.  Although this is no longer a separate component, it is still the core of how ESRI manages spatial data in a RDBMS.

My problem with this approach has always been that the data was ‘locked up’, and you needed to go through SDE to get at it.  Not really the best solution to provide interoperability…

I have long held the philosophy that in the geospatial world, it shouldn't matter what tool you need to use to do your job, the data should be open and available, and you should use the best tool suited for your task. 

It’s no secret that if you need to perform pure vector data creation, a CAD tool is probably more suited to that task, but if on the other hand you need to work with very large datasets, perform complex analysis, or create high-end cartographic output, a GIS tool is probably better suited to that task.  Recent software advancements have definitely blurred the lines on software capabilities, but I still believe the above statement to be true.

Now, I’m always looking for ways to improve interoperability between software tools.  Autodesk has been on board with this for a number of years through the FDO technology, which provides the Autodesk Geospatial solutions the ability to connect seamlessly with dozens of geospatial data formats, and work with them in their native format… No importing or exporting required.

From a purely spatial database perspective, I would prefer the ability for software tools to be able to work with the databases native geometry, and not have to worry about adding a middle tier, management application to control access to the spatial data.  Again, Autodesk is doing this with FDO, and now ESRI has opened up to this philosophy as well.

We are now seeing some improvements from ESRI on this front as well with the introduction of Query Layers.  Query Layers essentially allow you to connect to “native geometry” within a spatial database, with no SDE component required.

This new functionality, along with ability to use native geometries in SDE tables, will go a long way to improve application interoperability.  The possibilities are endless…

Until next time,
Take care.

Warren M

Comments

Post a Comment

Popular posts from this blog

ArcGIS: Packaging error - General function failure

Image
Whoa... 2 posts within 2 months...  I'm on a roll baby...   :-) In today's episode I want to document what I've discovered with the following lovely error when attempting to create a Map Package: I've had this very insightful (hint:sarcasm) message box pop-up a number of times when trying to create a Map Package.  After much copying/pasting, renaming, re-connecting data sources I finally figured out what the problem was in this particular instance. This particular map had some DWG files connected to the map, and some of these DWG names contained a special character "#", and also contained extra 'dots' in the name to delimit a date.  For example: Name#-2013.04.09.dwg In my testing and trials, removing the '#' symbol did not resolve the issue, and it wasn't until I removed the extra 'dots' in the name that I was finally able to successfully generate the package.  Further testing revealed that the '#' symbol
Read more

More ArcGIS Woes with 'Special' Characters...

Image
It's no secret that I've griped and complained about many of ArcGIS's quirks that seem stuck or rooted in the 80's ...  One would think I wouldn't be surprised anymore when I come across such silly issues... But I am. The latest 'undocumented feature' I've discovered is that the Field Calculator will fail if there is forward slash ( '\' ) in the Layer name. ArcGIS 11 can't come soon enough.
Read more

ArcGIS Collector: Update Error Code 1006

Image
Alright, this is the second time this happened to me, and I neglected to document it the first time, so I had to search again to find the answer, so I will document it here, and now. Here goes... If you happen to come across ArcGIS Collector throwing an error when updating a feature, and the error states something along the lines of: Invalid untrusted Html content detected in field: Have no fear, there is a simple fix.  Well, that is, it's a simple fix if this is 'local' map, not accessible to the general public.  That's only because ESRI doesn't actually 'recommend' this fix. So what is 'this fix' I speak of? A little more background... If you have any fields that contain HTML content, there is a chance that Collector could see that as malicious content, and it will block it.  You can see a list of allowable HTML tags in Collector a this link . In my instance, I am running some database triggers to populate and update a URL field, where
Read more