Latest Contributions by NikolasStevenson-Molnar

Yes, I have tried it as a dynamic service. The interesting thing there is that the speed is pretty reasonable once you've zoomed in. It's not great rendering the full extent, but as long as it has a spatial index, the dynamic rendering while zoomed into to a specific areas is pretty good. Which makes it all the more strange that the on-demand cache is so incredibly slow. Overall, rendering at full extent is slow enough that I do want to use it as a tiled service. If I could automatically switch from tiled to dynamic past a certain threshold, that would work, too but that's not supported (and even if it were, it would need to be supported by the map clients, too). So I'm afraid it's tiles or bust! ... View more

Yes, I do have an EDN subscription, so that could work for testing. The other problem, however, is that I'm dealing with a feature dataset and if I understand correctly, the Image extension is for images and rasters only. ... View more

Oops, I spoke too soon. It was just a trial license for the Image extension. ... View more

Thanks, I'll look into Image Server. We're actually not a very big organization, but it does look like we have access to the Image extension. ... View more

Hi Rebecca, Thanks for the suggestions! Unfortunately, it won't work for us to use our existing cache because it's incomplete. It's likely people would hit uncached areas pretty quick. Similarly, we can't effectively predict which areas are most likely to be hit at the 13+ levels (especially as we get close to 19). Whichever areas we pre-cache, the other areas would be used frequently enough that 2+ minute render times are going to be a problem. To give a bit more context, this is a US-wide dataset (incl. Hawaii and Alaska) which means an estimated 64 billion tiles at level 19. _Nik ... View more

The server manager for 10.1 no longer works in Chrome because it uses Dojo 1.6 and Chrome recently broke the 1.6 implementation of dojo.query. Usually when something "hangs", it's indicative of a JavaScript error on page. To confirm this, take a look at the JavaScript console. In Chrome, click the menu button (three lines in the upper-right corner) and choose Tools > JavaScript console. When I do this, I see a slew of errors for the server manager. This may or may not be the problem you're seeing. To confirm, I'd give Firefox a try. I've been able to use the Server 10.1 manager in the latest version of Firefox. _Nik ... View more

I'd like to add by 0.02 and provide a workaround for those struggling with this problem. First, I agree with many of the previous posters that the process for deploying GP tools to server is extremely kludgy and unnecessarily burdensome. It's un-intuitive (publish from the result of a tool run?), and makes a number of problematic assumptions: namely that you're deploying from a machine with ArcGIS Desktop, that you're deploying individual tools, not toolboxes (unless I've missed an option?), and that the tools are even intended to run in a Desktop environment. Additionally, the extra burden to deploy tools does very little to ensure tools are fully functional before deployment. Any tool with even a bit of complexity will have multiple execution paths and what may succeed with one set of inputs may fail with another. The only way to ensure the functionality of all execution paths is to write good tests, and frankly you can't force people to do that; they either will or they won't. Now, for a workaround. You can by-pass the whole run->puslish-from-result process by using the ArcGIS Server REST API. If your sources are already present on the target server (e.g., my deployment process involves pulling sources from a Mercurial repository onto the target server), then you can POST to the "createService" admin endpoint with JSON-formatted service info to create the service (http://resources.arcgis.com/en/help/server-admin-api/createService.html) and then POST to the "startService" admin endpoint (http://resources.arcgis.com/en/help/server-admin-api/startService.html) to start the previously created service. Wrap this all up into a deploy script and you'll be set. If your sources aren't already on the server, I imagine you could use the upload API to get them to the server, though I haven't tried this approach. Server is sort of finicky about creating and starting services, so be prepared for a bit of trial and error. Often, if you get something wrong, it will let you create the service, but you won't be able to start the service. If your service fails to start, check the server log for clues about why. I found that the "outputDir" and "virtualOutputDirectories" parameters are actually required despite being reported as "optional" by the API docs. If you create your service without those parameters, then it will fail to start. Cheers, and happy deployments! _Nik ... View more

We do hope to support wxPython in the future as the Python UI Framework for hooking into ArcGIS Desktop. Thanks, Jason Pardy Esri Alright!!! I second that 'Alright!' 🙂 _Nik ... View more