topic Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent in Python Questions

Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Tue, 21 May 2013 21:14:31 GMT

To All Python Users:

I have a script that loops through all the layers in an mxd and then saves the mxd. I have found that when I open up the saved mxd the extent of the map in the data view has changed even though I did not write code for the extent to change. Has anyone come across this phenomenon before?

The problem I am finding is that the layout view, that could be setup for a print job, has changed. Now the user has to go back and fix the extent for the layout to be printed correctly. I am eventually looking to run this script on many mxds in batch and I do not want to disrupt all the mxds where the endusers need to go back and fix the extent.

Why would the map extent change if all I am doing is looping through the layers in a python script?

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

T__WayneWhitley — Tue, 21 May 2013 22:12:02 GMT

Just curious, have you read the df extent at the beginning if the run, then re-read the df extent at the end of the run where you've completed your layer manipulations in order to check for a difference?

If nothing else you may be able to 'reset' the df extent back to the original using the extent obj read at the beginning of the run.

Enjoy,
Wayne

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Wed, 22 May 2013 10:48:40 GMT

Wayne:

I will try that, but it just seems like the extent should not change if the operations you are performing on the mxd have no connection to the extent.

I added the following code for checking the extent before and after looping through the layer:

df = arcpy.mapping.ListDataFrames(mxd)[0]
oldExtent = df.extent
print("The old extent = " + str(oldExtent)) - Prints the dataframe extents before looping through layers

Now I loop through layers and save mxd

df = arcpy.mapping.ListDataFrames(mxd)[0]
newExtent = df.extent
print("The new extent = " + str(newExtent)) - Prints the dataframe extents before looping through layers

The extents that are printed out are identical, but the map has been zoomed out to almost double its intial extent.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

T__WayneWhitley — Wed, 22 May 2013 12:52:19 GMT

hmmm, could be a bug... I don't know, but if you're at 10.1, a possible workaround to try may be to save the extent to a bookmark, then when manipulating the layers, set the df.extent to the previously saved bookmark extent as shown in the help ref example from the link below. I did not test this......but based on what you said it sounds like the extent is somehow being overridden by something else...

ListBookmarks (arcpy.mapping)
Desktop » Geoprocessing » ArcPy » Mapping module » Functions
http://resources.arcgis.com/en/help/main/10.1/index.html#//00s300000060000000

A slight aside - I have set text elements X and Y page coordinates, and all would go well during testing, then the wheels would come off and the X coord set would take on some wild values --- I could still read the values, but something wasn't quite right about consistently writing the values. So I tested a clunky workaround to loop on reading/writing until the read matched the write vals I intended --- not at all the 'safe' way to write code, but it worked. It hasn't blown up, but if I remember correctly it would have to make the set twice in some instances to get it right. Not saying that's related to your quirk, but something is interfering with your extent and you may not be able to trust the return vals. What about the save process alone?--if you open the mxd, and simply save it again with arcpy, is the extent affected?

Hope you figure it out...
Wayne

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

JeffBarrette — Thu, 23 May 2013 13:40:30 GMT

If this is truely a problem, please report this to support services. They'll need data and repro steps.

Thanks,
Jeff

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

LorindaGilbert — Wed, 18 Sep 2013 19:04:31 GMT

Hi All,
Any idea on this? I've noticed it as well and can't deploy a script that is supposed to fix things to have it break something else.

I've noticed that it resets your printer back to your default windows printer. So if we had a mxd with a layout set to 36x68 on our plotter or a pdf writer, then after changing the source data, the layout is now set to our default laser printer at 8.5x11. Not cool. We are using Arc 10.0.

As the orginal poster noted, why does the printer settings get changed when all you are changing is the source of the data? Especially when this data is a duplicate of the previous data source?

Thanks.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Thu, 19 Sep 2013 11:29:18 GMT

Lorinda:

There is a bug for this issue NIM092164 that ESRI has classified with a low severity (I don't agree with that assessment). An ESRI Technical Support supervisor told me that only 6 users has identified this as an issue. Please contact technical support about this issue so they might have more of an impetus to fix the bug. I need to run my script in v10.0 before upgrading to v10.2, but the bug may still exist in v10.2 (I do not know). What version of ArcGIS Desktop are you running python with?

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

LorindaGilbert — Thu, 19 Sep 2013 13:59:56 GMT

Good Morning,
Thanks for the reply. Using V10.0 SP2. I'm testing whether changing your default printer makes a difference, but that is an added step for the users. Some of my users are not as computer/ESRI savvy as the rest of us and I'm just attempting to make the server switch easier for them (which there will be more in the future). This is NOT accomplishing this goal.

I have reported as a bug and related it to the issue NIM092164 too. Thank you for letting me know that it had been reported and needed more reports to maybe get them off the stick and get it fixed. I too will be upgrading to the newer releases, but luckily, this will be after this server change.

I agree that it is a bug that SHOULD be fixed. There is ABSOLUTELY NO REASON for the printer and layout settings to be changed if you are not touching the layout window or doing anything with printing. Or there should be a way of finding the printer and layout settings in Python to be able to be retained during updates.

The test for changing the default printer was minimially productive. Most of our maps are either printed to a large size plotter or to Cute pdf writer. If you use this pdf writer as the default printer in the windows system, then it will keep the pdf writer as the default, but still changes it to be the 8.5x11 size paper, but does retain the custom size the Map Page Size. Interestingly, if you set the default to your plotter or to Adobe pdf printer, it changes the extent to 8.5x11 for both the paper size and the map paper size. GRRRR

Thanks.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Thu, 19 Sep 2013 15:49:03 GMT

Lorinda:

Does your python script work on updating the datasources for annotation feature classes in SDE? I thought mine was processing this type of layer, but it is not.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

LorindaGilbert — Thu, 19 Sep 2013 16:06:31 GMT

That's a good question, I'm not sure. We don't have that many layers of annotation. The one mxd that I know has annotation is coming from a data source that wasn't changed. I'll have to look through some of the 200+ mxds to see if any have annotation. I'll do it the 'easy way' by looking at the text file that I had written out to show what was changed and if any broken links in the mxd. I did notice that if there was a very old data source listed that no longer exists, it was less likely to change them and reported them as broken links.

I'll get back with an update in a bit.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

LorindaGilbert — Thu, 19 Sep 2013 17:48:59 GMT

I found one mxd that was using an annotation feature class, it does appear to have changed it according to the source under properties.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Thu, 19 Sep 2013 18:05:34 GMT

Do you need to process SDE annotation feature classes differently than standard SDE feature classes?

I think I see why my annotation feature classes are not being processed. I bypass group layers so I only process individual layers. In looking at the properties of an annotation feature class, it appears to be a group layer.

Do you bypass group layers in your script?

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

LorindaGilbert — Thu, 19 Sep 2013 18:40:58 GMT

I didn't put anything special into the script to look for a different type of feature class. Here's a slightly modified copy of my script (to protect the innocent :cool: ). I did use parts of other scripts that I found on the forums and on the resources page. I do intent to make this script much more flexible for future use. We have several SDE servers here, so being able to have a flexible script is a must. Hope it helps you.

I also intend to create another script that will go through the layer files that we have saved for general use - next item on my list.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Thu, 19 Sep 2013 19:01:50 GMT

Lorinda:

How does your script handle group layers?

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

LorindaGilbert — Thu, 19 Sep 2013 19:11:31 GMT

Just checked my data driven pages mapbook which has groups within groups, and it appears to have handled them like a champ and changed them to the new server. Of course, when I turn the old database off next week, I may be eating my words 😛 . But the source properties are showing up as I would expect if I had manually changed the data source.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Fri, 20 Sep 2013 15:26:05 GMT

Lorinda:

I just figured out why my script was not handling annotation feature classes. Annotation feature classes are structured similarly to group layers and I had an If statement asking whether the focus layer was a group layer or not. If the layer was seen as a group layer (as an annotation feature class is), the layer would not be processed. This was faulty logic as other conditions would prevent a true group layer from being processed, but still allow an annotation feature class to be processed.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

LorindaGilbert — Fri, 27 Sep 2013 13:19:34 GMT

Grrr...
Has anyone else run into this?
I turned off the old db last night and we attempted to run this script that I had created and NOW it doesn't change anything! Yet it worked very well with the db on prior to this.

Have since turned the db back on and now the script works.

So warning to all that may be looking into this - make sure that it is done with both databases and servers up and running.

If someone has managed to run a python script to replace the data source with the old source off, please let me know how you did because we are likely to run into this again.

Thanks.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Fri, 27 Sep 2013 14:03:45 GMT

Lorinda:

How does your script handle broken datasources? If you do not process broken datasources, then your script will never process connections to the old db if it is off while running the script.

You may also be running into an issue where python is trying to get the old SDE connection properties so it knows where to resource the connection. Since it does not see the old connection properties when the old db is off, it does not know what to do.

I would think you would need to keep the old db around until you are certain that you have successfully processed all of your SDE connections.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

LorindaGilbert — Fri, 27 Sep 2013 14:22:56 GMT

Michael,
I had in the original script to at least let the user know that there are broken links (we still had some mxd's from two and three servers ago!!). It would alert the user that there was a problem with certain data and then continue on.

Once the db was turned off, ALL feature classes were broken links and it wouldn't change anything at all.

I was mainly putting the info on the forum as a warning to others to run these types of scripts before the db is turned off so that it has a better change of running properly. With any luck, in future versions of AG and ArcPy (we are running 10.0) they will handle stuff like this better because sometimes you don't have the choice of being able to turn a db back on - especially if the server died completely and you had to move the db to another server. You also don't always have to option of naming a server the same name.

So for now, I've turned the db back on for a few days to allow for the users to get to the directories with many mxd's (several with over 100) changed over. Any others that are looked at later, will just have to use the repair data source option within ArcMap.

Thanks.

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

MichaelVolz — Fri, 27 Sep 2013 15:04:39 GMT

Lorinda:

How would you be able to resource a datasource whose current properties you cannot access? I'm not sure how ESRI would help in this scenario as the parameters you need in the findAndReplaceWorkspacePath can only be accessed if your SDE layer is not broken.