Latest Contributions by KevinHibma

There is no maximum amount of memory the RuntimeLocalServer process can use. It depends on 2 things: 32bit/64bit and the tool being run. The RuntimeLocalServer process is the same process if you're using regular 32bit Background. In this case its bound by the operating system rules of about 3GBs. If you're using 64bit Background, then it could possible use as much RAM as you have on the system. Of course this is all tool dependent. Some tools no matter how big the dataset may only use a few hundred MBs, or other tools may want to use and load as much into the RAM as possible. Its hard to talk in absolutes, but generally the Intersect tool will make use or available RAM, thus you could see high utilization. If there actually is a memory leak the only thing you can do is bring down the .exe and start it back up again. Understand though, there may not actually be a memory leak here, it could just be the tool is trying to use as much memory as possible to get the job done. A leak would be more indicative if you run the tool start to finish and after it finishes the process still has GBs of memory. Having a few hundred MBs would be normal. But these are generalized statements, each case (computer, OS, version, data, etc) will have a different "correct" answer. I'd actually give this blog a read, I think its very relevant to what you're doing:  Dicing Godzillas (features with too many vertices) | ArcGIS Blog  Be successful overlaying large, complex datasets in Geoprocessing | ArcGIS Blog  Tiled processing of large datasets—Help | ArcGIS for Desktop  ... View more

There are some tools/functions that make use of .AGS files. There is a big difference between "those tools" and the tools in the Administration toolkit. The built-in, system tools have access to all the internal workings of ArcGIS. The tools I've written in Python dont have the same level of 'arcgis' access. Simply put, the tools I wrote dont rely on ArcGIS/arcpy, and even if they did, they couldn't make use of a .AGS file to accomplish the end goal of 'administrative tasks' on the server. Those 'hooks' are not exposed in the software to 'python developers'. You're right about the stopped|started information being held somewhere. However the interaction with the tools and the server itself is very short lived. The tools only are aware and talk to the server during their execution. As such, any tool or script needs to get all the information from the server and perform the action during that session. So the tools I wrote would need to query the server, get that information, and then perform an appropriate action. The LIST script you reference is essentially the same code I have in the STOP | START | DELETE tool. This action of getting the services and their state needs to happen each time the tool is run. The idea James offers below is a great method of hiding credentials from plain view. It isn't 100% secure (really any solution that requires you to save credentials on the client machine isn't secure). But its better plain text! ... View more

This is a great suggestion. Having user/password saved in plain text is just bad form. And sadly, I've encouraged that in places (GitHub - arcpy/update-hosted-feature-service: Update and overwrite a hosted feature service on ArcGIS.com ) Maybe I'll try to update that sample with your approach. And, yes, its still very possible for someone to find out the credentials. However, any sort of security is better than no security. Thanks, James. ... View more

Hey Becky - The ability to use the .AGS file would be an excellent enhancement. I actually really like that idea as it hides the password from being inside your scripts. The only problem: from a pure Python code perspective, I have no way to get at the contents of the AGS file, nor is there any arcpy method that could consume the file to give me what I need. Basically we'd have to do something in the core software to assist in using the connection file to help the tools get what they need. I'll have a conversation about that with some team members. I understand the not knowing if something is stopped or started from the tool UI. Would it simply be enough to show in the UI something like "MyService [STOPPED]"  or  "Service2 [STARTED]" ?  Or are you after an actual filter to only show certain services? I havent wrote any logic to filter, but if I dont consider it now, I probably wont look at making these tools "better" for another 4 years after this go. ... View more

I just came across this post and realize you might have a path forward. Just a note though - I've been trying to make time to refresh the toolkit. That includes introducing proper HTTPS support. If you're interested in it before its "done", its in a branch here: GitHub - khibma/ArcGISAdministrationToolkit at devupdates I'm close to being done. I just need to do some more testing. After that I'll update the arcgis.com sample with the newest and greatest. ... View more

Dylan, At 10.4 we enhanced Server in regards to updating database connections. If you're on 10.4, simply updating your datastore connection will update the reference for any service (feature, gp, etc) that referenced it. This topic has more info: Register your data with ArcGIS Server using ArcGIS for Desktop—Documentation | ArcGIS for Server  (note that the GP Service has to have been published with 10.4 for this to work) ... View more

Come by the Analysis island in the Expo Tues/Wed/Thurs and look for me - we can chat about this. I'm also presenting a Creating Geoprocesing Services session, but wont be going over exactly what you're asking. ... View more

Do you have a reference to the doc you mentioned? Everything you've said is correct. However, Server underwent many, many changes between 10.0 and 10.1. As such, I'm not 100% confident that you could use the {'url' : 'http://myfile'} method at 10.0. I'm 100% sure you can at 10.1. (If the doc you have was written for 10.0, then I'd take it as true you can use this method) The other thing, and I'm sure you've tested it, but asking just to be sure - you can access the file you reference over HTTP? ... View more

If the tool works as a regular tool before publishing, but not as a service, your parameter index are probably correct. My guess is when publishing it hasn't updated, or incorrectly updated the paths to either the templates, or the selected features you're passing in isn't working correctly. The first and easiest test is to consume the service back in ArcMap - ArcMap will always pass the features correctly. If you get the correct result there, but not the webapp, its something to do with how the service + web application is setup. If that isn't the problem, I'd try changing your first bit of code import os layouttemplatemxd = arcpy.GetParameterAsText(0) if arcpy.GetParameterAsText(0) else "StewardshipTractBoundaryMap"  #I think this should work Layout_Template = arcpy.GetParameterAsText(0) if Layout_Template == '#' or not Layout_Template:     Layout_Template = "StewardshipTractBoundaryMap" layouttemplatemxd = Layout_Template templatePath = 'D:/ArcGISData/Geoprocessing_Examples/Advanced_HighQualityPrinting3' Selecting_Features = arcpy.GetParameterAsText(1) Input_Polygons = "Stewardship" mxd0 = arcpy.mapping.MapDocument(os.path.join(templatePath, layouttemplatemxd + '.mxd') And if none of that does it, it might be how you're doing the select itself. It looks a little strange to me, setting the definition query then doing a select. Is that needed? ... View more

A couple things to clear up - you say published to AGOL?  Do you mean your ArcGIS Server (not ArcGIS Online)? You cannot publish GP Services to ArcGIS Online, you can place a reference to them, but the service itself exists on your ArcGIS Server (not arcgis.com) GP Services dont...lets say "work" with a user defined workspace. A workspace is an unsupported item for a GP Service, as such, it becomes hardcoded when you publish. Thats why you're seeing the user having no choice when they execute the service. If you go back and re-publish the service, inside the Service Editor if you go to that parameter, you'll see its hardcoded. There are ways to deal with providing an input workspace, but looking at your workflow, I dont think this is the path you need (or really want) to go down. Keep in mind, if this were to 'work', whatever directory the user was supplying as input would have to exist on the server itself, not a local path on their computer (I'm sure you can see possible problems here.) So, all that considered, some options: Looking at your script, my guess is your 'output' in the end is the text file which you're creating inside the directory the user has specified. Instead of asking for a directory to save a text file, you have a few options. You could specify a FILE itself, where the user would provide 'c:\temp\mytext.txt'. Alternatively you could ask for a STRING and use that to build a file and path, c:\temp\USERSTRING.txt. Or, better yet, since GP Services have a well defined pattern of where results get created, just use the options available to you and return the FILE (which you internally create/manage) to the end user. So (and I cant find the button to make this nicely formatted code....) do something like this: Code reportFile = os.path.join(arcpy.env.scratchFolder, "report.txt") # ... code that puts stuff in the file. arcpy.SetParameterAsText(0, reportFile) Tool Param (in the UI) output file  | type=file | derived output ... View more

Yes, 10.4 = 2.7.10 ... View more

I'd give this help topic a read. It explains how KML is created based on the input features: Creating KML in ArcGIS for Desktop—Help | ArcGIS for Desktop ... View more

Changing the output in Copy Features from something on disk to "in_memory\ManHoles" should 'make it fast again' (or comparable to before changing from MFL to CF). As for it ignoring the barriers -- I've got no idea how/why that would happen. Your barriers are right at the start of the model. This is step happens before copy features.  Unless it has something to do with the coordinate systems still, but if that were the case I wouldnt expect your FLAGS input to work. ... View more