Tag Archives: tool
As you may already know, ArcScripts has been closed for adding new scripts. It was a valuable resource for sharing your tools with the community, but there is the new and improved Geoprocessing Model and Script Tool Gallery.
Whether or not you took advantage of ArcScripts in the past, now is the time to jump head-first into the new gallery. Spend some time browsing the tools that are available. Download and rate the tools, submit comments about the tools, and share the tools with your friends via social media.
This resource wouldn’t be possible without the ArcGIS community. Since you’re reading this blog, you’re part of this community. It’s people like you taking the time to share resources that make this gallery so valuable.
So, take a moment and think about the models you have built and the scripts you have written. Would others in this community find these same tools useful for their workflows? If so, consider uploading them to the Geoprocessing Model and Script Tool Gallery. The process is simple and can be done in just a few steps.
- Browse to the Geoprocessing content section of the ArcGIS Resource Center.
- Find the Model and Script Tool Gallery link on the left side of the page.
Here, you’ll also find the following helpful resources: Submission guidelines and Submission checklist. The submission guidelines page will provide tips for organizing your data. The submission checklist page will help make sure you haven’t left anything out, such as scrubbing your data, setting relative paths, or removing old results from the map document results window.
3. Compile the tools and data into a ZIP folder according to the submission documents.
4. From the Model and Script Tool Gallery page, click Add an Entry.
5. On Add Gallery page, enter the information about your submission, upload a zip file for the tool and
add a thumbnail graphic. Click the Submit button and you’re done.
By following these quick and easy steps, you’ll be on your way to sharing knowledge and experience with the ArcGIS community, helping others become more efficient in their workflows and processes.
-Timothy H., Support Analyst – Geodata Raster Group, Esri Support Services – Charlotte, NC
The Skyline tool is a new tool for 3D Analysis in ArcGIS 10. Many of you may have seen this tool demo’d at the User Conference in July; don’t worry if you missed it though, the demo is still available. Watch the “ArcGIS is 3D Capable” (section 14) video available at the following link: http://video.esri.com/watch/43/arcgis-is-3d-capable. (The portion of the video that is specific to the Skyline tool and model begins at the 6:13 mark.)
The Skyline tool will create a feature that displays a line or multipatch feature class containing the results from a skyline silhouette analysis. The output can be combined with the Skyline Barrier Tool to perform shadow analysis, flight path analysis or can be used to evaluate how the skyline view changes with prospective building construction.
I want to take a moment to point out that there is a line in the Web help documentation that many miss that needs to be emphasized. The line appears in the first paragraph and states, “the analysis is conducted from observer points above a functional or virtual surface.” For the tool to work effectively, the observer points must be above the surface used in the optional inputs or not contained by the multipatch features in the ‘input features’ dialog box. When the point is below or contained, the output is not created successfully, therefore resulting in an empty feature, and no one likes an empty skyline feature.
So, as a workaround, if you are trying to create points that will model a specific point, you need to adjust the elevation of the observer points to be above the surface, especially if you are interpolating the location of the observer. Once you have determined the elevation of the observer point, be sure that it is not the same elevation as the surface.
If you are unfamiliar with how to increase the elevation of the 3D points you have created and do not have the elevation in the attribute table, consider the following workflow.
- Use the Add XY Coordinates tool to generate the X, Y and Z coordinates for each point. (Yes, I know the name of the tool says XY, but if the point is 3D it also includes the Z coordinate.)
- Add a field (double or float to preserve the decimal).
- Right-click the field, and use the Field Calculator to add to the elevation value (ultimately, it does not matter what value you provide, it just has to be above the surface).
- Now use the Copy Features tool and under Environments > Z Values set ‘Output has Z Values’ to ‘disabled’ prior to running the tool to make the feature 2D.
- Use the Feature to 3D by Attribute tool and select the new field for the elevation to convert it back to 3D at the new elevation.
Now the new observer point should be able to create your skyline normally. So to recap, be sure your observer point is above your surface or not contained by your multipatch, or else your Skyline analysis will be empty and you will still be asking, “Where did my Skyline go?”
Please leave any comments in the comment section below this blog post. NOTE: You must be logged in to your Esri Global Account to leave comments.
Jeff Swain, Esri Support Analyst – Raster group, Esri Support Services
Esri Support Services has had several summer interns that decided to cool off by working inside the air conditioning, instead of lying by the pool this summer. While they are here working in Esri Support Services, they have been given the opportunity to learn the ropes of a career in supporting GIS software and to build on their existing GIS knowledge by participating in a 12 week internship program.
Within Esri Support Services, this year’s interns have come from a wide variety of backgrounds including computer science, GIS, geography, engineering, business, and English. Depending on their focus in their studies, we placed the interns in a role that was best suited for them. So, they may be working as a Support Analyst, within the business department, or on the Support Documentation team. Each intern is provided a mentor to work closely with during their time in Esri Support Services. After initial training and onboarding, the interns took the reins with tasks involving:
- contributing to online forums
- testing software/hardware issues
- helping to assist analysts on technical work with customers
- documenting technical issues through authoring knowledge base articles
- submitting software defects/enhancements
Additionally, Support Services’ interns have listened in on support calls with analysts and attended weekly team meetings to get a feel for the collaborative environment of Esri Support Services.
We thought you’d like to hear straight from the horse’s mouth to find out more about the interns’ experiences throughout their time and the work they did in Support Services, so we’ve included some blurbs below.
Kevin Burke participated in the summer internship program on the Desktop team in the Redlands, CA Support Services department. He is a recent graduate from California Polytechnic University-Pomona with a degree in Civil Engineering and a minor in Business Management. Within Civil Engineering, he focused in Geospatial Engineering, which focused on courses that dealt with spatial data, surveying, and mapping.
“My internship here at Esri has been a great experience. Upon arriving I was intimidated; however, I quickly learned and became well-versed and comfortable both in working with the software and communicating with other employees. Everyone has been extremely helpful and always welcomed any questions or concerns that I may have had. So, these are the reasons why working for Esri has been both fun and rewarding.”
Freddie Gibson participated in the summer internship program on the Desktop team in the Redlands, CA Support Services department. He is a recent graduate of the University of Arkansas at Monticello with a degree in Spatial Information Systems with a GIS emphasis and Computer Information Systems.
“I have learned a lot at Esri. At Esri, the sky is the limit when it comes to learning. For every product supported by Esri, there are people or resources available to get you started on any topic. Every employee is willing to teach you everything they know in the hopes that it will make you a better person for both yourself and the company.
During my time here, I’ve had plenty of conversations with some of the staff about various topics. As a result of my workspace being next to Margaret Maher, author of “Lining Up Data in ArcGIS”, I know that I’ll leave with an above average understanding of projections. Also, with the many conversions I’ve had with the other members of the Desktop Team, I know that I’ll leave Esri with a better sense of how to fix my own workflows and any other incidents that I’ll have throughout my GIS career.“
As summer is quickly coming to an end, many interns are wrapping up their 12 week programs and saying farewell to the colleagues they’ve met during their time in Support. With a successful turn out and many opportunities gained this summer, by both interns and support staff, we plan on continuing the participation in the Esri Summer Internship Program in the future!
- Melissa J., Geodata team Support Analyst, Esri Support Services – Charlotte, NC
For the first time, the Esri Support Services Documentation group has a team of summer interns working with them to gain a better understanding of documentation within Support, the software products and what they do, and Esri in general. As they continue to work with us and gain more knowledge about the company and the software, they are also working on projects within a variety of documentation platforms covering different products and issues. Michael has finished his 12 week internship, so his time with us has come to an end. So, on his way out, he wanted to share some of his experiences here with you. We hope you enjoy hearing about Support Services and the Documentation group from an intern’s perspective. Happy reading!
- Collin W., Support Services Blog Content Manager – Esri Support Services
My name is Michael Wee, and this summer I was an intern within the Esri Support Services Documentation group. Throughout the course of my internship, I was able to gain a wealth of experience by being involved in a wide variety of projects and tasks. I was able to better my understanding of how the documentation group at a software company works and also how the Support Services department functions as a whole.
Right away, I began to work closely with the copy editors of the team. They helped me adapt to the work environment very quickly and taught me about their jobs, such as maintaining the knowledge base articles. Whenever I had a question, they were always willing to sit down and help resolve any problems or issues I was having at the time.
One important aspect of documentation I learned about was the knowledge base articles. These articles are the backbone of Esri’s Online Technical Support, and their maintenance is absolutely crucial in delivering answers to customers’ questions. Most people tend to take for granted the documents they find online in a company’s help section of their Web site. What I saw, however, was the process for pushing these articles out to the Web. From skilled analysts who are able to find time out of their busy schedules of helping customers, to the copy editors who make sure the articles are properly formatted and grammatically correct, to myself attempting to author articles out of the most straightforward of incidents, I can safely say that I no longer take a company’s support documents for granted.
Another form of documentation and online resource I helped with was the wiki.GIS.com site. This wiki was launched in November of 2009 and is ever-evolving. As the content continues to grow, it is shaping up to be a quality resource for GIS users and those who are curious about GIS in general. While working with the wiki, I learned about the processes involved with building a wiki page from scratch. I helped seed pages that did not previously exist, and with the help of the technical writers in the documentation group, I also edited pages to make them pertain more to GIS. An example of a wiki page I helped to make more GIS-centric is the Visual Basic page on wiki.GIS.com.
While I was given exposure to documentation, I was also called upon to help within other areas of the Esri Support Services. What interested me the most was testing the ‘My Support’ tool for incident management. This tool allows customers to keep track of their incidents online without having to call in to the company. It gives customers a quick status update while reducing the overall call volume.
What was interesting about the testing the ‘My Support’ tool was finding the bugs. It was also fascinating to see the turn-around time for fixing the bugs I’d identified. They were a big issue one day, and non-existent in a matter of 24 hours. Finding even one bug made me feel like I was helping to solve real issues and help produce a sturdy support tool that would help both customers and the company.
At the end of this internship, I feel like I can look back and see tangible results of my work at Esri. I have written a couple of pages in the wiki, drafted a couple of knowledge base articles, and helped launch a major online tool that went live less than a week ago. Best of all, with these articles that I have written, I feel that I am helping real people solve real problems.
- Michael W., Summer Intern – Esri Support Services Documentation group
GIS analysts have become the default cartographers for some organizations. The primary task of a cartographer is to simplify reality in such a way that maps can convey the maximum amount of information with a minimum amount of clutter. Accordingly, analysts have been required to develop datasets and layers that work at a variety of scales. Street datasets are particularly troublesome. Detailed road inventories are ideal for large scale mapping, but individual roads quickly turn into indecipherable blobs during the visualization of large cities and regions. Over the years, a combination of definition queries, scale range settings, and creative uses of symbology have been employed to create road basemaps that work at a variety of scales.
Figure 1:The Thin Road Network tool
The Thin Road Network tool (Cartography Tools/Generalization), available in ArcGIS 10, provides another method for the digital cartographer to simplify a street feature class, while maintaining the integrity and connectivity of the street network. The tool can pare a detailed street’s datasets for medium scale mapping of urban areas. The tool does not actually delete features—instead it identifies road segments that could be removed from the map without compromising connectivity or removing high-order routes.
Preparing the Streets
Slight modifications are necessary to prepare the street data for use as an input to the Thin Road Network tool.
- Add an Invisibility field
Create a new integer field and use the Field Calculator to set the field to 0. After the tool is executed roads that should be removed from the display are assigned a value of 1.
- Add a Hierarchy field
The street feature class must have a Hierarchy field. If this attribute needs to be created, speed limit is a decent corollary. For instance, roads with a speed limit of 65 are generally more important than roads with a speed limit of 45. Number of lanes or functional class could also be used to define hierarchy. The Hierarchy field should be an integer field with values from 0 through 5. Roads where Hierarchy = 0 will be considered “locked” and will remain visible.
Executing the Thin Road Network Tool
Running the Thin Road Network tool requires a Minimum Length parameter to be defined. This parameter defines a “sense of the resolution or granularity of the resulting simplified road collection (ArcGIS 10 Webhelp).” This value should represent the minimum length of road that is significant enough to include in the final map. The value is dependent on the desired scale at which the road layer is meant to be viewed. The tool will place a value of 1 in the Invisibility field based on an analysis of hierarchy, visibility locking, resolution, and the morphology and connectivity of the road geometry.
The structure and size of the street’s feature class that is used as an input, in tandem with computer specifications, will determine the time it takes to run the tool. With large datasets, it can take quite a while. For instance, in recent testing, the Thin Road Network tool ran for 30 minutes on 170,000 road features representing the greater Washington DC urban area.
The following graphic contains two maps. The first map contains all of the streets in the Greater Washington Urban Area. Streets in this map are not well defined and run together to form amorphous gray spaghetti-blobs. The second map shows the same street’s file after the Thin Road Network tool has identified superfluous segments that are hidden using a definition query. This map is more legible. Routes can be easily distinguished from one another. While this dataset cannot be used at all scales due to the many ensconced collector streets, it will serve as an effective basemap with more detail than a road’s layer that just contains interstates and freeways.
For more information, refer to the online help documentation for the Thin Road Network tool accessible at the following link: Thin Road Network (Cartography).
- Jake P., Support Analyst – Desktop Group, Esri Support Services
You Love GoToAssist, You Really Do!
ESRI Support Services has a variety of tools available to assist customers in resolving issues, and one of these is Citrix Online’s GoToAssist technology. GoToAssist allows our Support analysts to remotely and securely connect to our customers’ computers: allowing for faster, more accurate diagnosis of many kinds of problems – especially when the problem involves a map. We’ve been finding more and more situations where GoToAssist has been helpful in reducing resolution time and increasing the satisfaction of our customers, but you don’t have to take our word for it…
In February, ESRI Support Services conducted more than 2,700 GoToAssist sessions with customers. At the end of each GoToAssist session, customers have the opportunity to complete a survey. In February, we saw a survey response rate greater than 45%. That’s rather high for a voluntary customer survey, and we’d like to send out a big “Thank You!” to those who did their part by completing their GoToAssist surveys!
Customers are more likely to respond to a survey if they had an extreme experience, either extremely good or extremely, well…otherwise. Our reaction to the survey results is an extreme one as well; we’re extremely pleased to be able to say that, overall, our customers love GoToAssist! Consider these facts and figures from the February 2009 survey data:
- When asked whether the Support analyst’s decision to use GoToAssist was a good idea, 99.6% of the surveys received said, “Yes”. We would have been happy with 95% or even 90%, but the astounding figure of 99.6% means that there are probably even more situations in which using GoToAssist may be beneficial. ESRI Support Services will continue to look for more ways in which this tool can help you.
- When asked whether using GoToAssist increased the speed of issue resolution, 96.2% of the surveys received said, “Yes”. In many cases, the response was “Yes” even when the issue was not resolved by the end of the GoToAssist session! That means that our customers recognize and appreciate the time-saving benefits of using GoToAssist to diagnose and troubleshoot, even if the issue isn’t immediately resolved.
- Almost 75% of the responses indicated that the issue was resolved by the end of the session. To state this another way, if one of our Support analysts used GoToAssist with you in February, your odds were nearly 3 out of 4 that your issue was going to be resolved by the time you said “goodbye”!
If the numbers don’t speak loudly enough, here are just a few of the comments we received last month regarding the benefits of GoToAssist:
“It is always better when the expert is able to actually see what I am doing wrong and make it right! Yeah!”
“The [screen] sharing program was really helpful and made my task so much easier!”
“As always, this was a great way to show tech support the behavior of the problem.”
“This was one of those issues that would not have been resolved without using the screen sharing because of the nuances. It greatly sped up the troubleshooting process and helped us develop a workaround.”
“I love tech support! I love screen sharing! You guys make me look good! Thanks for all your help.”
Now, we know that screen sharing isn’t a cure-all; for example, GoToAssist won’t help if we don’t have Support staff that is available, knowledgeable, and friendly. We also know that screen sharing is less beneficial in some situations, like when reviewing large log files or trying to debug code; but there are many situations where screen sharing can make a big difference. All of us here at ESRI Support Services will continue to look for good opportunities to use GoToAssist to assist you.
Thanks for letting us know you appreciate it, and keep that feedback coming!
-Jason H., ESRI Support Services, Global Metrics Manager