Database Views and Metadata

[RandyKreuziger]

Getting users to create metadata is always hard but they sure complain when it doesn't exist.  With SDE views, created using sdetable -o create_view, metadata could be attached to the views.    Now at version 10.1, creating a database view is very easy through ArcCatalog, but you can't attach metadata to the views as far as I can see.  How are other sites handling this with users expecting metadata?

We are just starting to test ArcSDE 10.1 with SQL 2012.

[MarcoBoeringa]

Can anyone tell me if it is not good practice to have metadata on database views and if so please explain why?

Tim,

Good you managed to dig up this thread yourself, I just looked over it...

Of course it is good practice to add metadata to (subsets of) your data. The things I wrote in the other thread are merely to explain to you that there is a technical issue here, that is not a bug, but requires a potential enhancement to allow storage of metadata with spatial database views.

The support analyst�??s comments were that it does not make much sense to create meta data for a view when one would have the metadata for the original data source

I don't agree, I think you have a legit desire, but that doesn't make it a fault of ESRI or bug in the ArcGIS for Desktop application. It is a matter of choice in where to put development effort in, and if there is a need, than ESRI is likely to full fill it at some point, see Kimberly Peter's remark.

The functionality for creating database views from within ArcGIS for Desktop is relatively new, keep that in mind also.

If that is the case what is the best practice when you need to publish a subset of data, complete with its own metadata and you�??d rather not duplicate your original database tables, to avoid redundancy in your database.

We are currently in the process of publishing data until our obligations to do use under the EU INSPIRE Directive. However some of our database tables cover multiple INSPIRE Themes so we need to create views of the data. Clearly the metadata has to reflect what we are publishing, rather than what the original database contains. Besides, if we publish a view, how can we publish the metadata if the view doesn't contain any?[/URL]

I don't know if this is a real solution to your issue, but you might consider setting Definition Queries on your layers in ArcMap that need to be published, and save them out as stand alone layer files (*.lyr) outside the ArcMap document. You can than use ArcCatalog to create metadata for this specific layer file, which will be stored as a separate XML file next to your layer file in the folder where you stored it. Additionally, you can limit the number of visible fields in the layer properties.

[RandyKreuziger]

ESRI is moving away from the SDE command line to create views to the new "Create New View" functionality in ArcGIS Desktop, but don't consider it a bug when the replacement function loses functionality?  Not uncommon for ESRI since they did that when going from ArcInfo Workstation to ArcGIS Desktop taking around 10 years to regain automated map production.

Losing the ability to attache metadata to database views is a serious loss.  There is no way for the user to know what the base feature is or what definition queries are placed on the data.  Layer files are pointers to data (and symbolozation) but once you've added the layer to your MXD metadata in the .lyr.xml file is no longer associated with the MXD entry!

[TimLangner]

Of course it is good practice to add metadata to (subsets of) your data. The things I wrote in the other thread are merely to explain to you that there is a technical issue here, that is not a bug, but requires a potential enhancement to allow storage of metadata with spatial database views.

I don't agree, I think you have a legit desire, but that doesn't make it a fault of ESRI or bug in the ArcGIS for Desktop application. It is a matter of choice in where to put development effort in, and if there is a need, than ESRI is likely to full fill it at some point, see Kimberly Peter's remark.

The functionality for creating database views from within ArcGIS for Desktop is relatively new, keep that in mind also.

I guess the issue we found was that we were trying to achieve something that was possible in the past, via a different way of working. ESRI then decide they were prefer us not to use the existing way of working and stated they were going to remove it. So we switch our way of working and find we can't do what we previously were able to do. We have an ObjectID with our spatial views.

Then a support analyst decides the solution is to simply provide a better error message. We need a solution to the problem rather than just a more helpful error message. To their credit, it was actually one of the ESRI UK support analysts who found this thread and forwarded the link onto us.

Tim,I don't know if this is a real solution to your issue, but you might consider setting Definition Queries on your layers in ArcMap that need to be published, and save them out as stand alone layer files (*.lyr) outside the ArcMap document. You can than use ArcCatalog to create metadata for this specific layer file, which will be stored as a separate XML file next to your layer file in the folder where you stored it. Additionally, you can limit the number of visible fields in the layer properties.

That could be really helpful. I wasn't aware metadata could be created for layer files.

[MarcoBoeringa]

I guess the issue we found was that we were trying to achieve something that was possible in the past, via a different way of working.

Very true, and the bold and underlined text is significant in this context.

I guess the issue we found was that we were trying to achieve something that was possible in the past, via a different way of working. ESRI then decide they were prefer us not to use the existing way of working and stated they were going to remove it. So we switch our way of working and find we can't do what we previously were able to do. We have an ObjectID with our spatial views.

First of: The ArcSDE Command Line tools aren't retired yet. You can still use them at 10.2(.1) if you need them, but you are encouraged and adviced to look for other options by ESRI. They will, however, be retired soon, but hopefully, ESRI will come up with a solution for the specific "metadata" issue before they do (as Kimberly hinted on).

Anyway, while you may feel ESRI is limiting you, ESRI actually opened up a whole new world to us: being able to easily create both native, and persisted, database views in an RDBMS that aren't entangled with the ArcSDE / Geodatabase repository (of course, if the database view is based on an geodatabase Feature Class, there still is some dependency), and the ability to add layers based on standard SQL via Query Layers, all straight from the ArcGIS for Desktop user interface.

That is a big bonus to the new 10.x versions of ArcGIS. Many people have wanted this functionality for a long time.

This bonus comes at a price though: you are no longer working within the scope of the geodatabase. This means several limitations, since the RDMBS database is not "geodatabase aware", even if you use layers from a geodatabase as the basis for the database views! This is because you are accessing the database not through ArcObjects classes designed for geodatabase access, which incorporate the intelligence to use the full geodatabase functionality in their code, but through other classes that deal with standard ODBC / database client connections.

The limitations are therefore (not a complete list):

- No awareness of complex datasets or geodatabase features like "Feature Datasets", "Geometric Networks", "Topologies", "Parcel Fabrics" and so on.

- No standard support for metadata on data layers

- No automatic translation of domain "codes" to human readable domain "descriptions"

- No knowledge of feature type (point, line, polygon) until dataset is accessed, because this is not registered in the ArcSDE / Geodatabase Repository, hence dataset must be selected in ArcCatalog before it shows its proper icon.

[KimPeter]

However, it seems the above will work only if the spatial type is SDEBINARY, and not if the spatial type is GEOGRAPHY or GEOMETRY.  Would you be able to confirm if this is the case?  If so, is this Esri would consider as part of whatever solution is implemented to deal with this issue?

Hi Miguel,

The steps you describe are not limited to feature classes that use SDEBINARY, and should work with the SQL Server Geometry and Geography types.  Did you get an error when you ran them on a Geometry feature class?

[KimPeter]

As an aside, Tim requested this on the Ideas page.

http://ideas.arcgis.com/ideaView?id=087E000000059hjIAA

Those of you who need this functionality, please promote his idea.

Thanks 🙂