Latest Contributions by KevinHibma

‎06-06-2017

Do you mean something like - your featureclass has the following fields: A, B, C, D, E but you only want to copy C, D, E into your final output? Then, yes, absolutely. See the "Field Map" parameter for both the Merge and Append tool. That control allows you to control what field from the source inputs get created/copied into the output featureclass.

‎06-05-2017

Thomas, The tools honor the selection. If you're inside ArcMap with a selection and run Merge, only the selected features are copied over.

‎06-05-2017

There are many different ways to accomplish this. You can use Python, or Modelbuilder or just run tools individually. I'd personally go about it in this way (running the tools one at a time unless you need to turn this into some sort of automated process): Select you features Run Merge with those features into a new featureclass Note that you need all the same feature type (poly, point, line) to run merge Run Table to Excel from that new featureclass to get your excel If you dont have the same feature type, you can: Select your features run Copy Rows (this will generate a table of the selected attributes) Run Append or Merge to combine all the tables Run Table to Excel

‎05-23-2017

From your screen shot it looks like the Buffer tool was used first with 50nm. Then the erase tool was used to remove the land/shore boundary from the resulting buffer.

‎04-19-2017

This is not a bug, and Server is working properly based on how you've configured it and have setup your script/tool to be published. First, you're correct on the data copy point. If you've disabled data copy to the server you can't publish something that needs to upload data as part of the service. What's going wrong is how you've setup your scratch directory and your assumptions of registering the folder and the service behavior. You have a few ways to configure/change your publishing to be more successful. 1) Set the scratchworkspace inside ArcMap prior to running the tool and publishing. If its writing to: C:\Users\MyUserName\Documents\ArcGIS\scratch.gdb then I can tell you haven't set it and you're letting it use the default location. A better practice is to make a scratch directory inside your current working directory, point ArcMap at that. Reference the root folder in your datastore. Now it wont copy the data when you publish. See the second screen shot here: A quick tour of authoring and sharing geoprocessing services—Documentation | ArcGIS Enterprise The tool has been built in a directory with a ToolData and a Scratch folder. Everything is nice and contained. Reference the folder the model lives in. 2) Change your intermediate outputs to in_memory. Unless the tool absolutely needs to write to disk, writing to in_memory is generally faster. (I say generally because theres some caveats). This is probably the easiest and best option. 3) Allow data copying to the server during publishing If you go with option 1) above you need to understand that just because you've referenced the folder during in the datastore does not mean the service will write results to this directory. A Geoprocessing Service when using %scratchGDB% or arcpy.env.scratchGDB writes to a specific JOBS folder inside the arcgisserver directory structure.

‎03-09-2017

That'll be from MY line #22 above. It sounds like for some reason it couldnt find the new MXD it saved. If this is coming from the service you'll need to manually inspect those directories and make sure something got created in the scratch directory. You may also need to add some AddMessages to see whats going where. Sorry, the code above is untested, but fundamentally I'm sure of what needs to happen/flow.

‎03-09-2017

Not exactly. They're actually the same thing. One is just a path on disk (tempMXD) and the other is an arcpy.mapping-MapDocument (newMXD). You could pass the tempMXD out of the function and handle this line somewhere else if you want: newMXD = arcpy.mapping.MapDocument(tempMXD)

‎03-09-2017

I'm not setup to quickly test, but I'm 99% certain line 16 (save) is the problem. User A choosing ICELAND executes and has their own MXDObject. User B chooses Brazil and again they have their own MXDObject. These two objects exist in their own process (arcsoc.exe) independent from each other. It is only at that time of line 16: mxd.save() do worlds collide and one process tries to write over the other process. So, if you were to slightly modify your code: def update_background_layers(mxd,df,input_country): background_layers_list = ["cities", "country", "oceanout","whiteout", "six_largest_cities"] for background_layer in background_layers_list: for lyr in arcpy.mapping.ListLayers(mxd): if lyr.supports("DATASOURCE"): if background_layer == str(lyr.name): old_source = os.path.dirname(lyr.dataSource) new_source = "C:\\Website_Test\\Report_Tests\\Background_Layers\\" + input_country lyr.findAndReplaceWorkspacePath(old_source, new_source, False) #mxd.save() tempMXD = os.path.join(arcpy.env.scratchFolder, "mxd2Export.mxd") mxd.saveACopy(tempMXD) # re-load that MXD up as a true MXD object, not just the path # because the next function wants the object newMXD = arcpy.mapping.MapDocument(tempMXD) return newMXD # You'll need to change whatever called "update_background_layers" to accept the # new MXD bein returned. As you have it now, you're kind of relying on a "global" MXD # so this function would spit out the new MXD and your code would have to be updated to # handle that.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

‎03-09-2017

While that code is fine.... and nobody is stopping you from doing that.... I really dont think you need to go that route. (personally I wouldnt, but I understand at the end of the day we all just want something that works) I can open 2 instances of ArcMap and reference the same MXD object in each. I only receive a runtime error when I do a save (that matches your original error message). Having 1-n of instances of a GP Service executing against 1 MXD is the same principal. Each instance gets its own space (folder) to execute against. This folder is unique and other executing instances have zero knowledge of it -- thus no write problems. This is why I suggest doing a saveAs. All instances make use of 1 MXD (your source), do the modifications to it in memory (meaning just acting on the mxd object) and then do the final saveAs to persist this information and then export. So like I said to begin with, if you really want to go down the path of multiple MXDs using a try/export....I wont stop you. It's just more heavy handed and will be more of a maintenance problem if you want to do updates later. OHH EDIT -- ya, with the multiple MXD approach, if you're letting the publishing process copy the data, this will fail. The publishing process doesnt know to traverse code to find all MXDs and copy them. You'd need to create a variable that references the folder those MXDs exist in. That way the publishing process copies everything inside the folder (all mxds). Alternative if you set a data store folder to this location, nothing will need to be copied and it should work.

‎03-09-2017

Without seeing your code, I assume you're doing some sort of .save() on the MXD object. I could imagine that 2 people trying to work off and save the MXD would fail. Two people (2 instances) simply reading the same MXD should be fine. If you're in fact doing a save, change it to a .saveAs() and write the output of this operation to your scratch.: myNewMXD = os.path.join(arcpy.env.scratchFolder, "newMXD.mxd") mxdObject.saveAs(myNewMXD) #... carry on processing/exporting from this new MXD.‍‍‍‍‍‍‍‍‍‍‍‍ newMXDobj = arcpy.mapping.MapDocument(myNewMXD)‍‍‍‍

‎02-09-2017

My bad - khibma@esri.com

‎02-09-2017

I dont get a crash following those steps. I attached the KML that followed those steps (projected, symbolized on zone_ and turned into KML). If the crash file is under 5mb, could you email it to me? You'd find it here: C:\Users\USER NAME\AppData\Local\ESRI\ErrorReports

‎02-09-2017

We identified and have a fix for the projection/conversion problem. It'll be included in the next release of ArcGIS Pro. Thank you for reporting it. My understanding of the issue is it should have been present in previous versions, not something we introduced at 1.4. Unfortunately for right now, the only work around I can provide is to project the data manually to WGS84 before running the Layer to KML tool. I'm sorry for the inconvenience this has caused you. Can you explain what you mean by cannot use the tool with unique value symbology? What results are you getting in your output KML? As for rolling back - no, there is no mechanism to roll back a version. You'd have to uninstall ArcGIS Pro 1.4 and re-install ArcGIS Pro 1.3.

‎01-26-2017

Anthony, Thanks, I can reproduce what you're saying, but am unsure why it started happening. We're investigating it right now. I can say that its a problem reprojecting. If you manually reproject your features to WGS84 from NAD 1983 StatePlane Colorado South FIPS 0503 Feet using the Project tool, and then convert that to KML, it'll work. I'll post back here when we understand more about why this is happening. Thank you for sharing your data.

‎01-26-2017

Anthony, unfortunately a LYRX is just a pointer with symbology information. There is no actual data there. You'll need to either zip the original GDB (CorteztoMancos.gdb) or run make a layer package with that layer and share that.

Online Status	Offline
Date Last Visited	‎09-30-2025 06:25 AM

My Ideas

Latest Contributions by KevinHibma

Re: Rapidly Export Multiple Selected Features from Multiple Layers into Excel?

Re: Rapidly Export Multiple Selected Features from Multiple Layers into Excel?

Re: Rapidly Export Multiple Selected Features from Multiple Layers into Excel?

Re: Buffer with Land Avoidance

Re: Scratch GDB on server

Re: GP Service Multiple Processes from MXD

Re: GP Service Multiple Processes from MXD

Re: GP Service Multiple Processes from MXD

Re: GP Service Multiple Processes from MXD

Re: GP Service Multiple Processes from MXD

Re: Layer to KML

Re: Layer to KML

Re: Layer to KML

Re: Layer to KML

Re: Layer to KML

Re: Feature service webhooks error at 11.0

Re: Enterprise server referenced feature services ...

Re: Webhook URL update for Power Automate

Re: WebhookManager available for AGOL?

Re: Feature Service Webhook