Esri Technical Support Blog

cancel
Showing results for 
Search instead for 
Did you mean: 

Latest Activity

(377 Posts)
Regular Contributor II

 

 

Users/Administrators of ArcGIS Online Organizations may have noticed some irregularities with feature storage credit charges between January 1st and July 4th, 2018. This was a result of a bug in the credit accounting process that resulted in sporadic timeouts and increased execution times while running the feature storage credit calculation service. This issue fixed on July 4th, 2018. The operations team is working towards being able to detect such scenarios with improved monitoring of these services.

BUG-000100343: Occasionally, users are not charged for feature service storage for an hour at a time.

 

As a result of the bug, some organizations were sporadically not charged for feature storage in hour long increments over this time. Organizations will not be charged for any missing feature storage charges. Although no action is required on your part, we want to show you what the error may have looked on the status tab and point you to the reporting tools to understand credit storage. understand if you were affected by this bug

 

Identify irregularities:

1. Navigate to the status tab and view the last 60 days, or a time period that includes before and after July 4th

2. View Irregular and Consistent Feature Storage in status reporting.

NOTE: Keep in mind that if members in the organization were publishing, deleting or adding to new features to hosted feature layers, feature storage may fluctuate due to changes in data storage.

3. Click on a specific day to verify if the charges were consistent for each hour. If there are sporadic missing hourly charges, then you have probably experienced BUG-000100343. If you are consistently charged hourly across the day, then you were not affected. As this bug was sporadic, you may have been affected on some days and not others, so feel free to check out multiple days.

BUG-000100343:

 

 

 

Correct hourly credit charges:

 

 4. To verify the amount of data stored for a specific day, click on the storage ring and view the table below. You will notice that the size remains the same when comparing the feature storage before July 4th and after July 4th, but the credits charged may vary.

BUG-000100343: Before July 4th 2.76 GB, 11.83 credits

 

After July 4th, 2.76 GB,  21.84 Credits

 

 

To verify your feature storage size, throughout this time period, please  view the feature storage details on the status dashboard. As mentioned above, there is no action required on your part, but as an administrator you can dig into your credit reporting to see if you were affected. If something doesn't quite seem right, feel free to get in touch with us in Technical Support to answer any questions.

 

Some helpful blog links:

Feature Storage Reporting on the Status Tab:

https://www.esri.com/arcgis-blog/products/arcgis-online/administration/understanding-feature-storage... 

Strategies for managing credits:

https://www.esri.com/arcgis-blog/products/arcgis-online/administration/five-strategies-and-tools-for... 

Help:

http://doc.arcgis.com/en/arcgis-online/reference/credits.htm 

http://doc.arcgis.com/en/arcgis-online/administer/view-status.htm#ESRI_SECTION1_1D001100A7A24CDF85A0...     

more
5 0 1,547
Occasional Contributor

In a previous blog post, my esteemed colleague and board game nemesis Kelly Gerrow-Wilcox discussed the basics of capturing web traffic in a web browser using the built in browser developer tools.  But what about when you’re consuming services in ArcGIS Pro, ArcMap or any other non-browser client?  Enter: web traffic capturing tools.  There are numerous free tools (such as Fiddler, Wireshark, Charles and others) which allow users to capture web traffic from their computers.  This blog will focus on capturing HTTP/HTTPS traffic using Fiddler.  I've chosen Fiddler because of its relatively simple interface and broad adoption within Esri Technical Support. 

Basics: download, configuration and layout

Fiddler can be downloaded here.  After installation, the only critical configuration that needs to occur is to enable it to capture traffic over HTTPS.

  1. With Fiddler open go to Tools > Options
  2. In the pane that opens, check Capture HTTPS CONNTECTs and Decrypt HTTPS traffic. (This allows you to capture any requests sent using HTTPS, which is slowly but inevitably replacing HTTP as the protocol for transferring data across the web). 

If it’s necessary to capture network traffic from a mobile device, some extra configuration is required.  Both the mobile device and the machine where Fiddler is installed will need to be using the same wifi network.  The following documents outline the steps to capture mobile traffic:

The Fiddler application itself is split into two main sections; the Web Sessions list and the…other pane (I couldn’t find an official name so for the purposes of this blog we’ll refer to it as the Details pane). 

The Web Sessions pane includes a sequential list of every request sent by the client to a web server.  Important information contained here includes:

  • The type of protocol used (HTTP or HTTPS)
  • Which server the request was sent to, and the full URL
  • The HTTP/HTTPS response code (here’s a description of what these mean)
  • The size of the body of the response (in bytes)
  • The content type (image, text, etc)

 

Note: the columns in the Web Sessions pane can be custom configured by right clicking anywhere in the headers and selecting Customize Columns.  Some useful fields to turn on can be:

  • Overall Elapsed (available under Collection: Session Timers. This is the overall time it takes for the request to be sent and returned)
  • ClientBeginRequest (available under Collection: Session Timers. This is the time your software first began sending the request, using your computer’s time)
  • X -HostIP (Select Collection: Session Flags and manually enter in the Header Name. This is the IP address of the server destination of the request)

 

If you click a single web session, that triggers the Details pane to populate with a wide variety of information for that specific request. 

 

Intermediate:  What do these details mean? Do they mean things? Let's find out!

There are numerous tabs in the Details pane.  The most useful (for our purposes) are Timeline, Statistics, and Inspectors.  The others are all advanced functionality outside of the scope of this blog.

 

The Statistics and Timeline tabs are both helpful when investigating any performance related issue, for example if a service is taking a long time to load in the Map Viewer.  The Timeline tab is useful for identifying which request in a multi-request process is acting as a bottleneck.  To utilize the Timeline tab, select multiple requests in the Web Sessions list.  The timeline will display the requests in a sequential “cascade” format.  Any requests taking an unusually long time will clearly stand out with a significantly longer bar in the timeline.

 

Statistics displays the exact times every step of the request took, from the client initially making a connection to the last step of the client receiving the response.  This breakdown is useful to potentially identifying which step in the process of a single request is acting as a bottleneck.  For example, if every step is taking a fraction of a second, but there is a multi-second pause between ServerGotRequest and ServerBeginResponse that would indicate that something on the server side is causing a slowdown. 

 

Lastly, the Inspectors tab is the where the bulk of information is displayed and likely where the vast majority of any troubleshooting will be done.  Here is where the curtain is drawn back to reveal the nitty gritty of how applications interact with web services.  Inspectors is further divided into two main sections; the Request information (everything related to the request sent by the client) and the Response information (everything related to the response returned by the server).  Both divisions have a nearly identical set of subdivisions which display the content of the request/response in different formats.  Below are the useful tabs for our purposes:

  • Headers – A list of additional information that is not part of the main request. This may include information like security/authentication information, the data format of the request or response, the type of client making the request, etc. This is a good place to find an ArcGIS Online token, when relevant.
  • WebForms (request specific) – Depending on the type of request, this will display a breakdown of each request parameter and the value of that parameter. For example, when submitting a search query this section will display the parameters of the query (like keywords, date ranges, etc).
  • ImageView (response specific) – If the request is for an image, the ImageView will display the image which is returned. Obviously, this is particularly useful for requests involving tiled services.
  • Raw – This will display the entire request or response in text format.
  • JSON – If the request/response includes content in JSON format, this tab displays the content in a more human readable format. This is particularly useful for requests/responses to the REST api of ArcGIS Enterprise servers.
  • XML – If the request/response includes content in XML format, this tab displays the content in a more human readable format. This is particularly useful for requests/responses to OGC services.

Advanced: That’s great Alan.  But what am I supposed to actually do with this information? 

How you use network traffic information is going to depend on what you’re trying to learn or solve.  Checking network traffic can help identify the where and what of a problem but cannot tell you the solution.  This is where your knowledge of your app, your web services and if all else fails, some good old fashioned web searching come into play.  Here are a few common examples of ways to isolate the problem you’re facing:

 

  • Check the HTTP/HTTPS response code in the Web Sessions pane. Anything that isn’t 200 should be investigated (it might not necessarily be a problem, but it’s worth looking at).  Again, here’s a description of what these mean.  Even a 200 response could contain error messages or other useful information.
    • A 304 response from a server will trigger the client (web browser, ArcMap, etc) to use the client’s cache and Fiddler is therefore not actually capturing a complete response from the server. If there is a 304 response on a critically important request, try again either in Incognito mode or clear your client’s cache. 
    • A 401 or 403 response typically mean the server requires some sort of authentication. This would help, for example, identify an unshared feature service in a web map which is shared publicly. 
    • A 504 response typically means something timed out. Use this in conjunction with the Timeline, Statistics and Overall Elapsed column mentioned above to troubleshoot performance issues.

  • If you can’t find the problematic request, open the Raw, JSON or XML tabs of the response and just scroll through the requests looking for one that returns an error.
    • Raw, JSON and XML contain the exact same information, just formatted differently.
    • When errors occur, the error listed in the response may be more detailed than the error provided in the user interface of whichever application was being utilized.

  • Find a way to ignore irrelevant requests!!
    • One of the most challenging factors in troubleshooting network traffic is the volume of requests that are sent/and received for even minor actions. Below are strategies to help avoid cluttering your log with unnecessary requests.
      • Turn off Capture (File > uncheck Capture Traffic) when you know Fiddler’s not capturing relevant information.
      • Close any browser windows or background processes that don’t need to be running.
      • If Fiddler is capturing traffic you know is not related to what you’re investigating, Filter it out of the Web Sessions by right clicking a session > Filter > select what session parameter you want to filter.
      • If you’ve captured a number of requests that you know you don’t need, select and delete them.
      • Target Fiddler to only capture requests from a single application by clicking the ‘Any Process’ button (next to the small bullseye icon), holding and then releasing your mouse over the application you want to capture from. This would be useful, for example, to capture all traffic coming from ArcMap while ignoring everything that occurs with your browsers. 

 

Once you have isolated the request(s) relevant to the issue you’re investigating, the following tips can help determine what the actual problem is.

  • If you can isolate the problematic request, consider what is the nature of that request in order to help determine any next steps.
  • It’s possible to resend any requests by right clicking a Web Session > Replay > Reissue and Edit.
    • This is especially helpful for isolating a specific header or request parameter that might be problematic. Modify the information under WebForms or Headers to see if that fixes the problem you’re encountering or reproduces the problem you’re investigating.
    • If you have a request that’s succeeding and one that’s failing, copy the headers or WebForms parameters one at a time from the request that’s working to the request that’s failing. Once the request works, you’ve successfully isolated the parameter/header in the requests that’s causing the problem.
  • It’s possible to send repeated requests by right clicking a Web Session > Replay > Reissue Sequentially.
    • This is helpful for capturing issues which might be intermittent. Send the request 20 or 30 times automatically and see if hit the issue you’re looking for.
  • Web service query requests can be viewed in the browser with a user-friendly interface. This allows you to easily tweak and resend requests.  To view a query request in the browser:
  1. Right click the query session
  2. Copy > Copy the URL
  3. Paste in a browser window
  4. Change the section in the URL “…f=json…” to “…f=html…”
  5. Click enter to browse to the page

 

Fiddler and other network capture software are not silver bullets to solve all web traffic related GIS issues, but they are useful tools to help.  With a bit of practice, utilizing this type of software can help resolve a wide variety of issues when accessing web services in GIS applications. 

Got any good Fiddler (or general network traffic logging) tips?  Feel free to leave them in the comments!

more
21 11 17.2K
Esri Contributor

This post provides insight into how we manage version 3.x of the ArcGIS API for JavaScript (JSAPI) release plan and technical support strategy.

 

The JavaScript development team has made great progress bringing version 4.x of the JSAPI closer to parity with 3.x, meanwhile introducing new tech for building very dynamic, expressive 2D and 3D apps. Over the next year, each release will be a balance between capabilities for reaching full parity with 3.x and brand-new innovation. Many customers’ app requirements are fully met by the current release of the 4.x API (4.7) while others are still dependent on 3.x (either with existing apps that they are maintaining or new apps that have requirements such as full editing support). We also have many Esri apps built on 3.x, such as the 2D version of Web AppBuilder for ArcGIS.

 

Technical Support Plan

Because we have a large customer base that still depends on 3.x, we are very careful about how we manage the Product Life Cycle (PLC). Our strategy is to make all PLC dates relative to our estimation of the last 3.x release. When is the last release? It depends on when we reach full parity in 4.x, enabling us to move critical apps such as ArcGIS Online’s map viewer to 4.x. When we reassess our estimation of the final release date, PLC phase dates are updated accordingly.

 

Relative dates for each PLC phase are determined in the following manner:

- 3.x remains in "General Availability" until the last release of 3.x.

- 3.x moves into "Mature Support" after the last release, and lasts for 1 year. 

- 3.x is retired 3 years after General Availability ends. 

For more information about the above software support phases and what they entail, refer to the PLC.

 

Recent Update to the PLC

Version 3.x was scheduled to move into mature phase next month; July 2018. Based on the current status of the API, this was moved to July 2019, with the mature phase starting August 2019 and retirement in August 2022. As mentioned above, these dates will be revisited depending on progress made towards 3.x parity.

 

If you need further clarification on the above, please reach out to Technical Support through the normal channels.

 ArcGIS API for JavaScriptKwasi Asante‌ 

more
5 2 1,800
Occasional Contributor

Have you ever suspected that there might be a service disruption with ArcGIS Online or one of the services provided by Esri?  Perhaps you can’t add a layer to your web map, or you’re receiving errors when trying to access the REST endpoint or item page of a service?  Although service disruptions are rare, this article will provide you with some resources to easily report a problem and get in contact with us to troubleshoot, ask questions and get things working again.

 

What are service disruptions?

ArcGIS Online is Software as a Service and is designed to be available always. In the rare event that you notice one of the services hosted in the Esri Cloud is not responding, not loading, or providing error messages and you suspect it may be caused by the underlying architecture, please report this as a potential service disruption. Many services are covered under the ArcGIS Online Service Level Agreement (SLA) and have guaranteed uptime. Whether it’s covered by the SLA or not, if you suspect there are issues with any Esri service, it’s important to report the problem.

                                                                                                                                    

How to confirm whether there is a known issue with ArcGIS Online

The ArcGIS Online Health Dashboard is the best resource for determining whether ArcGIS Online is experiencing any known issues, including historical incidents in the past 28 days. 

 

How to report a service disruption

If you think you are encountering a service disruption, please report it to Esri Technical Support!  You can report a service disruption at the link above by either calling the Support number, starting a Chat or clicking the ‘Request a Case’ link to create a case via a webform.  If you select ‘Request a Case’, be sure to select ‘ArcGIS Online Outage’ under the Issue Category section (during Step 2 in the webform) so that your case is correctly flagged as a potential service disruption.

Note: If you receive an error message trying to create a case via Chat or Request a Case, you can report a service disruption without authorized caller credentials by using the Report ArcGIS Online Service Disruption tool. Just follow the steps below:

  1. Go to the Request a Case page.
  2. Sign in (if you’re not already signed in within your browser session).
  3. Following the error message about not being able create a case, you will be provided with a list of options, including Report ArcGIS Online Service Disruption. Click this link.
  4. When prompted, submit your contact information and a brief description of the issue. Please provide the URL of the service you’re having issues with, a description of your steps to reproduce the problem and the text of the error you get (if an error is received).  With this information we can investigate the specific issue as soon as we receive the report, even before we talk to you personally.

 

What will Tech Support do once an issue is reported?

Once an issue is reported, Tech Support will first attempt to determine the nature of the issue: whether it appears to be an issue with the Esri-maintained infrastructure or services, or an issue specific to the customer’s data, workflow, organization settings, etc.  If the issue is determined to be isolated to a customer’s data, workflow, organization settings, etc., Tech Support will continue to troubleshoot the issue to resolution.  If the issue is determined to be a service disruption with Esri maintained infrastructure or services, it will be reported to the ArcGIS Online Operations team for resolution. 

Note: The Report ArcGIS Online Service Disruption reporting link listed above is only used for service disruptions. If it is determined that a reported issue is due to another factor (such as network connectivity, data, or browsers) and not a service disruption, you will be redirected to the appropriate resource (your International Distributor, the authorized caller for your organization, GeoNet, etc.). 

Any tips for the overachievers?

Although it is not your responsibility as the customer to isolate any issue before calling Tech Support, we know that some of you are technical and detail-oriented, and love digging into service requests.  Here are some of the questions Tech Support will typically use to identify the source of service issues reported to us:

  • Is the issue browser specific? Does it happen in Chrome, Firefox, Safari, Internet Explorer or all of the above?
  • What service is generating the error?
    • Pro Tip: if you don’t know the service that is having the problem, network traffic logging can help you determine that. The Dev Tools functionality built into all web browsers are the most convenient tool for issues you see in your browser.  Third-party applications like Fiddler can be utilized to log traffic from non-browser clients like ArcMap, Pro, or custom applications. 
    • The blog Introduction to Monitoring Network Web Service Requests provides a good basic overview of logging network traffic. Service disruptions can often be identified by looking at the HTTP Status responses (the most common problematic responses being 403 – authorization error, 404 – not found, 500 – general server error, and 504 – timeout).  Performance issues can normally be identified by looking at the Time column. 
  • What is the error received? (This error might be either in a popup in the user interface, or it may appear as a message in the Response section of any network traffic logging application.)
  • If the issue is intermittent, how regularly does it occur?
  • Is it reproducible with other services within the organization?
  • Is it reproducible with other services outside the organization? 
    • Pro Tip: if you’re having a problem and your hosted service is on, for example, http://services3.arcgis.com, try Google searching site:http://services3.arcgis.com for hundreds of publicly accessible test services.  You may have to click “show omitted results” to get a complete list. 

more
12 0 3,473
Esri Regular Contributor

This blog post is the third in a series of JavaScript debugging tips and tricks to help you on your way. See JavaScript Debugging Tips Part I  and also JavaScript Debugging Tips Part II for our previous segments.

In the past two JavaScript Debugging Tips posts on the Esri Support blog, we looked at the Network Tab and the Console Tab as part of the Google Chrome Developer Tools. While most modern browsers have some form of developer tools, here we use Chrome for our examples.

Our goal for this third blog post in the series is to introduce more advanced tips and tricks to enable you to more effectively debug and troubleshoot your JavaScript code. Specifically, we will focus on three areas: enhanced messaging to the console, better ways to set breakpoints using conditions specified at runtime, and a more efficient way of stepping through breakpoints in the Sources tab with a method called blackboxing.Part 1: Console.table

Console.log is our primary debugging function, but this function's output can be a bit difficult to read (especially when viewing a lot of data). One way to enhance our console log messaging and view data more easily is to display a list of objects as a table, which is accomplished using the console.table function. This function takes one mandatory argument, which must be an array or an object, and one additional optional parameter. Each element in the array is a row in the table.

Let’s take a look at the Console Table sample.

1. Open the Chrome Developer Tools by using shortcut keys (Windows: Control + Shift + I, and Mac: Command + Option + I), or by navigating to the top right-hand pane of the browser, clicking the three grey vertical dots, and choosing “More tools” > “Developer tools”.

2. Select the console tab.

3. Click “Perform Query” in the sample application. This performs a query task to view all counties in Connecticut. The code uses the console.table to print the results in a table as shown below.

console.table_.png

console.table



Every row in the table shows all attributes for a specific county. Next, we use the console.log to compare the console.log and console.table. This function will print a line with an array of objects.
console.log_.png

console.log



Once we expand the array, we can view the objects in a list.
console.log-expanded.png

console.log expanded



To view the attributes, we must expand the objects in the list.
console.log-expanded-with-attributes.png

console.log expanded with attributes

While we can access the attributes of one feature when using console.log, we can view all attributes for all features at once using console.table! The image below shows both functions in the console window.
console.table-console.log_-e1496352191442.png

console.table & console.log

Part 2: Conditional Breakpoints

In JavaScript Debugging Tips Part II, we talked about setting a breakpoint in the Sources tab, refreshing the application, and pausing the application at that line of code. This is a great way to examine your code and how functions are called, and where potential areas of trouble could arise.

However, sometimes we don’t want the breakpoint to be reached every time. Sometimes we only want the breakpoint to be reached if certain conditions are met. While we could write some logic code in the form of a loop to check for values, there is an easier way to do this at runtime.

For example, let’s look at a sample.

1. Open the Edit Features sample and the Chrome Developer Tools.

2. Navigate to the Sources tab, and left-click line 301 to set a breakpoint there.

3. After the breakpoint is set, right-click the breakpoint and select “Edit breakpoint…”.
EditBreakpoint2.png

Edit Breakpoint

Note: We could also get here by first right-clicking line 301 and selecting “Add conditional breakpoint…”.
AddConditionalBreakpoint1.png

Add Conditional Breakpoint



4. Set a condition whereby the breakpoint will be reached only if the user inputs “test” into the “Contact:” field when updating a feature. Here is the code: editFeature.attributes["Incident_Address"] == “test”Note: We do not want to use "=" because this assigns a value and thus always returns true, so we must use "==".
BreakpointExpression1.png

Breakpoint Expression



5. If we input “test” for the “Contact:” and click “Update incident info”, the breakpoint will be reached and the application pauses.
ConditionMet1.png

Condition Met



These conditional breakpoints can be useful for testing when you want to ensure data is sent back to the server correctly, or for error handling when you want the application to pause so you can inspect the object(s) of interest rather than letting your error handling code take over.Part 3: Blackboxing

While setting breakpoints is a great way to make friends and go through your code, this process can occasionally kick you out of the file of interest and into another source file or into a third-party JavaScript library.

For example, let’s look at a sample.

1. Open the Query SceneLayerView sample to follow along (this is similar to the sample found on developers.arcgis.com).

2. Open the Chrome Developer Tools, select the Sources tab, and left-click line 49 to set a breakpoint.

3. Refresh the page so the debugger pauses on line 49. From here, a "Paused in debugger" message appears (next to a "Play" button and a "Step Over" button). See below for a screenshot.
PausedAtLine49.png

Paused At Line 49



4. If you click the "Step Over" button about five times, you exit out of the main .html file and into the init.js file of the ArcGIS API for JavaScript. You can explore the init.js file, but we want to focus on the code that we wrote. Click the "Play" button to get home safely.
DebuggerInInitJSFile.png

Debugger in init.js file



Enter blackboxing to save the day. Blackboxing is a method to exclude files and libraries from the debugger, so that your focus remains on your file(s) of interest. Let’s take a look at how we can blackbox the ArcGIS API for JavaScript library so we can just step through the main file of interest.

1. With the Developer Tools open, click the three vertical dots in the far right-hand pane of the window and select Settings.
Developer-Tool-Settings.png

Developer Tool Settings

Developer-Tool-Settings2.png

Developer Tool Settings



2. On the left-hand side of the window, click “Blackboxing” to open the “Framework Blackbox Patterns”.
Blackboxing.png

Blackboxing



3. Click the “Add pattern…” button, and enter this framework pattern: js.arcgis.com.*\.js
Blackboxing-Pattern.png

Blackboxing Pattern



4. Click “Add” and check the box above the pattern input to “Blackbox content scripts”.

5. Close the Settings window and return to the Sources tab.

6. Refresh the page so the debugger pauses on line 49.

7. If you click the "Step Over" button about five times, you exit out of the main .html file and into the debugger:///VM file (this is an empty function which you can safely ignore, or read more about here), as well as complete one more "Step Over" operation into the application. Now rather than debugging unnecessary, ancillary libraries, you can focus on debugging the code you wrote or are trying to understand.Debug_Blackbox.gif

One last point worth mentioning is that blackboxing applies to the browser, not just to the webpage or web app of interest. After testing completes, feel free to remove the blackboxed pattern(s) to ensure a conventional web browsing experience.

This concludes our blog about advanced tips for using the Google Chrome Developer Tools with examples from the ArcGIS API for JavaScript. We hope you found the above tips useful and entertaining. For more information about debugging tips with JavaScript applications, here are a couple additional resources from the past several years:Additional Resources
Join us next time as we continue to delve ever deeper into Developer Tools and learn some valuable lessons. Happy debugging!</span>

Artemis F. and Noah S. - Esri SDK Support

more
3 1 3,588
Esri Contributor

icon3.png3D data is becoming more ubiquitous nowadays and is especially promoted throughout the ArcGIS Platform. From web scenes, to CityEngine, to ArcGIS Pro, there are many different applications to import, manage, model, and share your 3D data. To get the output you are looking for, it may require numerous steps and tools. To navigate some of these steps and tools, here are some tips and tricks for working with 3D data in ArcGIS.

3D File Coordinate Systems


The majority of 3D formats do not store a coordinate system. GeoVRML and KML are the lone exceptions. KML will use a WGS 1984 coordinate system and meters for the unit of measurement. All other types (DAE, 3DS, OBJ) must be placed properly, otherwise they may import at "0,0" (off the coast of Africa).Trick #1

If you are using CityEngine, you can drag and drop your shape from the Navigator window into the scene (this workflow assumes a scene coordinate system is already set). When you export the shape to a multipatch feature class, the coordinate system is created with the data so you can bring it into another ArcGIS product.Import OverviewTrick #2

The same workflow can be accomplished in ArcGIS Pro. Create an empty multipatch feature class, navigate to Editor > Create Features > Select Model, and click the globe to place the model.SelectModel-300x125.pngTrick #3Use the Replace with Model tool (ArcScene or ArcGlobe) or the Replace with Multipatch tool (ArcGIS Pro).replace.pngArcGIS Desktop Replace with ModelArcGIS Pro Replace with MultipatchTrick #4

If you are using ArcScene, ArcGlobe, or ArcGIS Pro, manually place the model during an edit session using the Move, Rotate, or Scale operations.Move, rotate, or scale a featuremove.pngNote: There is known issue with the Import 3D files tool. The placement points parameter is not honored so as of ArcGIS 10.4.1 or ArcGIS Pro 1.3, this tool is not a viable option. This issue is planned to be fixed in a future release.

Textures


To import your 3D file with textures, you must ensure the texture resides next to the 3D file, either as an individual image file or a folder with the images.Note: Both the file and folder must have same name for the software to recognize the texture.Trick #1

Textures are only supported in file or enterprise geodatabases. Shapefile multipatches do not support textures, so make sure to import the multipatch into a geodatabase.

Z-values


Make sure your 3D data has valid z-values. When sharing a web scene or importing the data into ArcGIS Pro, you want to make sure the elevation values are correct.Trick #1

If your multipatch is not at the correct elevation, you can use this trick. In ArcGIS Pro,Elevation-300x190.pngset the multipatch data "on the ground" and use the Layer 3D To Feature Class tool. The elevation values are then embedded into the multipatch.Trick #2

If you are using simple feature data (non-multipatch), use the Add Surface Information tool to add z-values to the data. Also, you can add z-values to an attribute table and with the Add Z Information tool, you can verify the values with the tool's output. If the data does not have valid elevation values, see the next tip.

Tools to Create 3D Data


Understand which tools can create 3D data: Layer 3D To Feature Class, Interpolate Shape, or Feature To 3D By Attribute.

Understanding 3D Data


Understand your 3D data. Extruded 2D polygons are not true 3D features, so you must export to multipatch to make the polygon a true 3D feature. Simple point, line, and polygon features can be considered 3D data if they have the correct z-values. 2D features can also be symbolized using 3D marker symbology.

Know the difference between a z-enabled feature class and a non-z-enabled feature class with a z field in the attribute table. Feature classes must be z-enabled to display at the correct elevation. You might see a z field in the attribute table, but that does not mean the geometry has the correct z-values. This can be verified by editing the vertices or adding z-values to an attribute table, as described above.

While this blog does not cover every facet of working with 3D data, it is my hope that this will provide some valuable information for working with 3D data on the ArcGIS Platform.
Andrew J. – Desktop Support Analyst

more
1 0 2,238
Occasional Contributor

This blog pertains to web maps and layer items that have both of these characteristics:

  • Web maps and layers authored with ArcGIS Online prior to the June 2016 update.
  • Contains polygon layers that are styled using Smart Mapping tools to adjust symbol size and/or outline width automatically based on scale

Smart Mapping tools allow you to select between various methods for using attribute values to drive the size of marker symbols when mapping data associated with polygons. You can specify a concrete size range for the symbols, or use automatic sizing so that they are optimized for the initial map zoom level and will automatically adjust so they look better across more zoom levels. We discovered an issue when using the automatic sizing option where the size of each symbol was being incorrectly represented in the web map with pixel values rather than point values (points are the correct unit of measure according to the web map specification). The ArcGIS API for JavaScript was also using pixel values. The result was inconsistent sizing between ArcGIS clients.

You also have the ability to automatically adjust the width of the outline of the polygon based on the current scale. Automatic sizing of polygon outline widths were also being represented using pixels rather than points.

Starting with the June update of ArcGIS Online, sizing values will be correctly represented using points which will enable marker sizing in web maps to be displayed consistently in all ArcGIS clients. The ArcGIS API 3.17 for JavaScript was also updated to use point values rather than pixels. While this update resolves the inconsistencies with auto sizing values going forward, it also means that web maps that were created before the June 2016 update of Online will have marker symbols and polygon outline widths that appear 1.3 times larger than the initial sizes you saw when originally authoring your map.Example map with automatic sizing before the update            Before-resaved-300x173.jpgExample map with automatic sizing after the updateAfter-resaved-300x174.jpgWhat can you do if your web map was affected by this update?

If you created a web map or layer item in Online prior to the June update with layer styles that take advantage of automatic sizing based on scale, we recommend that you reauthor your web map. This process will resave your web map with the correct sizing values for consistent display in all ArcGIS clients. Here are the steps to reauthor your web map:
  1. Open your web map or layer item
  2. Click on "Change Style" in the layer menu for the polygon layer(s) that use automatic sizing of symbols. Note: You might want to write down the options you have selected so that you can easily reselect them in step 4.
  3. Select a different style for your symbols than you originally had selected and click "Done."
  4. Click "Change Style" again on the same layer and reselect the original styling options you had, and click "Done." Any options that were configured within the original style must be reconfigured.
  5. Save your web map or layer item. Your web map will now have size represented using point values.

For information on changing the style of your web map or layer item, see this help topic.Note: this issue also occurs in web maps and layers that were created in Portal for ArcGIS and will be addressed in Portal for ArcGIS version 10.5. This article will be updated once a solution is available.Julie Powell Technical Product Manager, ArcGIS API for JavaScript

more
0 0 899
Esri Contributor

Update, 2 June 2016: Google Chrome 51.0.2704.79 was just released; it fixes the change that caused a blank screen for ArcGIS Online, Portal for ArcGIS, and applications built with the ArcGIS API for JavaScript. If you are affected by this, please click the Customize and control Google Chrome button and navigate to "Help > About Google Chrome" to force an update check and upgrade to this latest patch level.

The previous version was 51.0.2704.63, and the fixed version is 51.0.2704.79.

Update, 27 May 2016: KB 13156 has been published on the Support website to provide additional information about this issue.

---------------------

Google released an update to Google Chrome (version 51), which was pushed out to the public on Wednesday, May 25th. Unfortunately, this update included a change that impacts anyone using Google Chrome to access ArcGIS Online or Portal for ArcGIS versions 10.3, 10.3.1, 10.4, or 10.4.1.

This change impacts many apps built on the ArcGIS API for JavaScript (versions 3.8 - 3.16), several subsets of custom apps built by users, partners, and Esri Professional Services (for example, any app that uses the feature table or an analysis widget), and, most notably, the "home app" in ArcGIS Online and Portal for ArcGIS.

You may be seeing a screen similar to this after logging in: a blank screen with few or no elements.

googlechrome51.jpg

What you can do:

If you are using Google Chrome to access ArcGIS Online, the above listed Portal for ArcGIS versions, or apps built with the above-listed versions of the ArcGIS API for JavaScript, please turn off auto-update in your Chrome browser now. If Chrome was updated, you will need to temporarily use another browser (such as Internet Explorer or Mozilla Firefox) until patches have been released.

What Esri is doing:

  • The ArcGIS Online team is preparing fixes that will go live this evening.
  • We are still working on a solution for Portal for ArcGIS.
  • Developers using the hosted version of the JavaScript API are unaffected, as it has already been patched.
  • We are working on a solution for JavaScript API developers that use either a custom build of the API or use it locally.


We will provide updates at the top of this blog post regarding Portal for ArcGIS and ArcGIS API for JavaScript as soon as we have more information. A technical article has been released for this issue, KB 13156, which provides some additional detail about this problem.

If you have run into any problems as a result of this bug that impact your workflows, please contact Esri Support Services at 1-888-377-4575.


Gregory L. - Online Support Resources

more
0 0 1,715
Occasional Contributor

Beta versions of Esri vector basemaps are now available through ArcGIS Online as vector tile layers. These vector basemaps are accessible as both ready-to-use web maps and as vector tile layers you can add to a map. Additionally, vector basemaps include a variety of styles, some new and some that are similar to existing Esri basemaps. Web maps you create that contain vector tile layers can be used in web applications you configure or build using Web AppBuilder for ArcGIS. As a developer, you can build your own custom applications that use these vector tile layers using the ArcGIS API for JavaScript.

Please consider the following before deciding to use the current release of vector tile layers:

  • Vector tile layers are only supported in applications built with the ArcGIS API for JavaScript. This includes configurable applications, applications built with Web AppBuilder, and custom applications built with the JavaScript application programming interface (API). ArcGIS Runtime SDKs will add support in 2016.
  • Vector tile layers can be displayed in Internet Explorer 11 and in most other current versions of desktop browsers, including Chrome, Firefox, and Safari.
  • Vector tile layers have the best performance on machines with newer hardware.
  • There are issues displaying vector tile layers at a large scale.
  • Maps containing an Esri vector basemap are printed with the Esri Streets basemap. All other maps containing vector tile layers are printed without the vector tile layers.
  • The Esri vector basemaps are currently in the beta stage and are subject to change during this period. You may need to update or replace vector tile layers built using the beta versions of the vector basemaps. The Esri vector basemaps have some known limitations that Esri will address during the beta period, including the following:
    • Labels in languages that display right-to-left scripts, such as Arabic, are not drawn properly.
    • Labels along vector tile boundaries sometimes do not display completely.
    • The topographic map style does not contain some layers (for example, contours, landform labels, and spot elevations) that are included in World Topographic Map.
    • The topographic and streets (with relief) maps, which reference a hillshade base layer, only enable users to zoom in to about a 1:10k scale.
    • The tiles do not include layers for one-way arrows or address labels.
    • Some parks and land polygon features extend into the adjacent ocean areas.
    • River labels along very curvy lines are sometimes too compressed and difficult to read.
    • In some areas, local road labels and shields display, but not the underlying local roads.

Learn more about vector tile layers here.
Julie P. - Technical Product Manager, ArcGIS API for JavaScript

more
0 0 1,127
Occasional Contributor

On the weekend of August 1st, the Esri summer interns came together to participate in a hackathon hosted in the Esri café. The weekend was designed to encourage innovation through the rapid creation of applications; the event was extremely successful. One of most interesting aspects of the hackathon was watching the diversity within each team harmonize to improve the overall quality of the final products. Each team included at least one developer to write the code and several other members from Marketing, Support Services, Professional Services, and other Esri departments to help with creative design, the use of GIS, and the delivery of the final presentation.

IMG_20150805_122230-300x300.jpg

Team 'Geothinkers' took 1st place with the "Map My Friend" application



The interns may not have realized it, but they were inspirational to watch; they collaborated beautifully to find a common problem and showcased the functionality of web GIS to solve that problem.

Click the link below to see coverage of the weekend through an Esri Story Map:

Esri Intern Hackathon 2015 Story Map


To assist the interns, four analysts from different teams at Esri Support Services were tasked to answer questions, provide troubleshooting tips, and address software issues encountered along the way. We worked alongside the interns throughout the weekend and were fortunate to collectively experience the challenges and rewards of working with Esri software. We also got a first-hand look at how fearlessly the ‘millennials’ approach the use of GIS and application development. Native-based applications constructed with AppStudio for ArcGIS or the ArcGIS Runtime SDK for Android were the most popular, and the importance of aesthetic design was a highlight.
IMG_20150801_190042-300x300.jpg

Esri Support Analysts onsite as mentors



Overall, the interns reminded us of how exciting it is to stay relevant and of the value of taking a chance with new products or new ways of thinking about our work.

AppStudio for ArcGIS, which was released in Spring 2015, is just one of the Esri products teams implemented while creating their apps. The tool allows you to create cross-platform apps in literally minutes (see this video from the Esri Developer’s Summit) and without any background in coding. You can get started with a pre-created template or create your own application from scratch using QML code. In just one weekend, many of the interns went from working with AppStudio for ArcGIS and QML for the first time to mastering the application interface, terminology, and workflows. It was truly inspirational watching the excitement and dedication the interns had towards learning something totally new and presenting their amazing products.

While AppStudio is currently still in Beta 3, you can already start creating apps to showcase your own ideas, maps, and data. Click this link for documentation to help you get started.

If there is anything this weekend proved, it is that application development is changing rapidly and can be a lot of fun. Esri is working hard to make the process a whole lot easier with the release of AppStudio for ArcGIS. Like the interns, if you take a bit of time to learn something new, you too can produce some amazing results. Just take a look at the apps the interns created in under 12 hours!

And, if you need help with AppStudio for ArcGIS or any other Esri products, contact Esri Support Services through a call, chat, or email. We are all very excited about this new product and can't wait to help you get started creating exciting and beautiful new apps!Resources:

Contact Esri Technical Support, or learn more about the Esri Internship Program.
Julia G. - Server Support AnalystSupriya K. - Geodata Support Analyst

more
0 0 315