Latest Contributions by TomShindler

Currently, when you go to the "description" of any element of a web map, web app, or web service, you get only what was saved at the time of publishing. It would be quite useful to enable a view of the actual native metadata for any dataset included in a map service. This would eliminate the need to replicate and manually update metadata through the process of publishing a service. Currently, if you have a web service with several layers, and their native metadata is updated (in catalog, etc), you must manually copy the description and credits to the ArcMap project (mxd), then re-publish the service. Only then will the layer's metadata be reflected in the web environment. If a given dataset (like parcels, or streets) are used on several services, their metadata must be replicated manually into the each map project used to published each service. This represents a LOT of repetitive manual labor. Viewing the layer metadata directly would eliminate all of that work. ... View more

Currently, when you go to the "description" of any element of a web map, web app, or web service, you get only what was saved at the time of publishing. It would be quite useful to enable a view of the actual native metadata for any dataset included in a map service. This would eliminate the need to replicate and manually update metadata through the process of publishing a service. Currently, if you have a web service with several layers, and their native metadata is updated (in catalog, etc), you must manually copy the description and credits to the ArcMap project (mxd), then re-publish the service. Only then will the layer's metadata be reflected in the web environment. If a given dataset (like parcels, or streets) are used on several services, their metadata must be replicated manually into the each map project used to published each service. This represents a LOT of repetitive manual labor. Viewing the layer metadata directly would eliminate all of that work. ... View more

I would like to get a pair of scripts/tools to update all the "Description" and "Credits" in the layer properties of each layer in an ArcMap MXD from the corresponding values in the source data's metadata fields. These values are inherited from the source only when the data is added to the ArcMap project, with no ongoing connection. As metadata is updated, the old or missing values in the MXD are not updated. Since the metadata for the layers on the published map service for web maps come from the MXD, not from the data layers themselves, it is essential that the current metadata be written to the MXD before publishing. Currently this must be done manually, which is a prohibitively time consuming process. Since there are potentially many layers in an MXD, it would be useful to have a script tool that would update metadata on all layers at once. In some cases, there may be values for these fields that are intentionally different in the MXD than on the source data's metadata, so the script should provide for identifying layers to be excluded from the process. Consequently there should be two scripts/tools. One to create matrix of the values for each layer in both the MXD and layer metadata, the second would do the updates. The specifications for the first script are as follows: The script would have a single parameter: filename path to an MXD The script would run the following steps: Create a list of all data sources referenced in the MXD Iterating through this list, write the "Layer Name", "Description", and "Credits" from the MXD layer properties. Iterating through this list, parse each source's metadata for filename and path, and "Description" and "Credits" from that source data's metadata. Create a CSV file containing the above values, with one line per layer: Layer name, original MXD Description, original MXD Credits, source filename and path, source file Description, source file Credits. The file created above could be used to preview the results of the update script, including potential discovery of unintended overwriting of better metadata. Such layers could be excluded from the update in the following script. The specifications for the second script are as follows: The script would have two parameters: filename path to an MXD, and a comma delimited list of layers to exclude from the update.  The script would run the following steps: Create a list of all data sources referenced in the MXD Iterating through this list, parse each source's metadata for "Description" and "Credits" Write those values to the corresponding layer properties in the MXD (except those layers in the exclude list). The complications to this script would be that the layer's source data could be in several formats, all of which store metadata differently. The easiest would be shapefiles and images, where it would simply parse the xml file for these values, but to be complete, it would also need to be able to extract them from a file geodatabase, a personal geodatabase, and an SDE layer. Metadata could also simply be missing. It would also need to navigate the structure of grouped layers, updating the properties of the sublayers that actually point to a data source, and leaving the group layer's properties alone. If the "exclude list" makes this too complicated, it could be omitted. Though it would be a nice thing to have, its use would be rare enough that I'd hate to have that feature discourage development of the basic functionality. Though I want this for ArcMap, where I work now, it would be useful to have it for Pro as well. ... View more

Many services and web maps contain common layers, usually the most important, and often most complex layers. Currently, each web map must have the Pop-Up configuration process repeated for every layer, no matter how many other maps have used that same layer. In addition, if a service is updated with even one layer added or subtracted, all such configuration must be repeated, and you hope that you remember all the configuration changes that need to be made. For example, every map that has our parcel layer requires a 15 minute pop-up configuration done. Every modification, or new map requires repeating the process. It would save hours of work, and avoid errors, if the pop-up configuration for a given layer could be saved somewhere and re-loaded into a new or modified web map. This would apply to both Portal and ArcGIS Online Web Maps. ... View more

Many services and web maps contain common layers, usually the most important, and often most complex layers. Currently, each web map must have the Pop-Up configuration process repeated for every layer, no matter how many other maps have used that same layer. In addition, if a service is updated with even one layer added or subtracted, all such configuration must be repeated, and you hope that you remember all the configuration changes that need to be made. For example, every map that has our parcel layer requires a 15 minute pop-up configuration done. Every modification, or new map requires repeating the process. It would save hours of work, and avoid errors, if the pop-up configuration for a given layer could be saved somewhere and re-loaded into a new or modified web map. This would apply to both Portal and ArcGIS Online Web Maps. ... View more

Metadata needs a universal, externally accessible database, so that all of our data tools can be employed to build, maintain, and access it. This database needs to be integrated into ArcGIS, but accessible to any relational database management system. Metadata has continued to be a major headache and stumbling block for GIS data stewards. The "standards" involve creating a document that is cumbersome and isolated. It can only be read by a human (or with custom XML code), it cannot be joined to or queried like a database, and can only have limited representations made from it. Editing is a very manual process. So it doesn't get done, and when it does, it is often not used, because the data is only document based. I propose a that esri create and support a database structure that would contain all the elements required by the various metadata standards, and be stored as accessible table objects in each level of a geodatabase, including SDE, where it could be exposed to all SQL tools. It would be relational, with three core tables: Master Dataset table (containing a record for each feature class, with all the info applicable to the feature class level) Attribute Field table (with a record for every field in all the attribute tables, linked to the Master record Field Value table (containing defined value/description pairs in every field, linked to the field record.) Table domain content would be a subset of this table. Those three tables would be enough, but the design could include other utility tables, as necessary to assist in such things as facilitating inheritance of metadata from master to derivative datasets, providing tools for an organization to manage the data included in the database, and for the database internal management. By containing all the metadata in a relational database, its editing could make use of all the wonderful database tools we have (views, models, scripts, reports...), instead of being stuck in a manual one-off document for each dataset, as we currently are. Report formats could easily represent the data in whatever standard form is desired, and easily modified when the standard changes. Each geodatabase could then include its own copies of these three tables, which could allow export and import of metadata to the enterprise in ways that are far more robust than anything we have now. All the power of a SQL database, and related utilities could be brought to bear on the use and maintenance of this data. Integration with ArcGIS would include auto populating the fields that can come from the system (as currently done), but also, any domains in a geodatabase would automatically populate records in the field value table. Import export tools would be available, and consequently could be included in models and scripts. Imagine having the data manipulation power that we currently have for maps and tables applied to metadata! ... View more

Metadata needs a universal, externally accessible database, so that all of our data tools can be employed to build, maintain, and access it. This database needs to be integrated into ArcGIS, but accessible to any relational database management system.   Metadata has continued to be a major headache and stumbling block for GIS data stewards. The "standards" involve creating a document that is cumbersome and isolated. It can only be read by a human (or with custom XML code), it cannot be joined to or queried like a database, and can only have limited representations made from it. Editing is a very manual process. So it doesn't get done, and when it does, it is often not used, because the data is only document based.   I propose a that esri create and support a database structure that would contain all the elements required by the various metadata standards, and be stored as accessible table objects in each level of a geodatabase, including SDE, where it could be exposed to all SQL tools. It would be relational, with three core tables: Master Dataset table (containing a record for each feature class, with all the info applicable to the feature class level) Attribute Field table (with a record for every field in all the attribute tables, linked to the Master record Field Value table (containing defined value/description pairs in every field, linked to the field record.) Table domain content would be a subset of this table.   Those three tables would be enough, but the design could include other utility tables, as necessary to assist in such things as facilitating inheritance of metadata from master to derivative datasets, providing tools for an organization to manage the data included in the database, and for the database internal management.   By containing all the metadata in a relational database, its editing could make use of all the wonderful database tools we have (views, models, scripts, reports...), instead of being stuck in a manual one-off document for each dataset, as we currently are. Report formats could easily represent the data in whatever standard form is desired, and easily modified when the standard changes. Each geodatabase could then include its own copies of these three tables, which could allow export and import of metadata to the enterprise in ways that are far more robust than anything we have now. All the power of a SQL database, and related utilities could be brought to bear on the use and maintenance of this data.   Integration with ArcGIS would include auto populating the fields that can come from the system (as currently done), but also, any domains in a geodatabase would automatically populate records in the field value table. Import export tools would be available, and consequently could be included in models and scripts. Imagine having the data manipulation power that we currently have for maps and tables applied to metadata! ... View more