specify spatial reference for ExportToPNG

953
2
Jump to solution
01-23-2013 05:23 AM
LarsHuttar
New Contributor III
Hi,
We're using ExportToPNG() to export an image from a data frame, but we're also separately and "manually" writing out coordinates to HTML image maps. (By "manually", I mean we're not using a builtin package tool such as "ExportToHTMLIMageMap().")

Our problem is that the two don't align; the projection is apparently different. E.g. North America is "taller" (more stretched) in the exported HTML coordinates. Here is a screenshot in browser; the black outline shows the HTML image map coordinates:

[ATTACH=CONFIG]20995[/ATTACH]

When we export the coordinates to HTML, we're doing an explicit projection (Project_management()), specifying the spatial reference of the data frame (df.spatialReference).

But when we export the image using ExportToPNG(), there seems to be no way to specify a projection or spatial reference. Does anybody know how ExportToPNG() decides what projection to use, or how we can influence it? In ExportToLayoutGeoTIFF() you can supply a data frame for the spatial reference, but not in ExportToPNG().

Ideas we have currently...

  1. Set it in the environment, e.g.: arcpy.env.outputCoordinateSystem = df.spatialReference

  2. Tell ExportToPNG() to output a georeferenced world file, then try to examine the world file to see what "pixel scale information and real-world coordinate information" it contains (how do we examine it?)

  3. Before ExportToPNG(), do an explicit Project_management() with the data (as we do before the HTML coordinate export), allowing us to specify the spatial reference. Repoint layers that use this data to use the new, projected data. I believe I was told that data frames (data view) show data in geographic coordinates, not projected coordinates, so I don't know if this would have any effect, or is even coherent.

Any suggestions would be appreciated.
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
JeffMoulds
Esri Contributor
We have a bug where any arcpy.mapping Export function that writes a world file or geotiff tags results in distorted images when brought back into ArcMap. This applies to data frame export scenarios only. This is most likely the issue you are hitting. For your records, the tracking number is NIM070025. We have already fixed it and the plan (subject to change) is to include it the next service pack/release.

The workaround is as follows: In the arcpy.mapping.ExportToPNG function, specify a resolution parameter and match the df_output_height and df_output_width parameters with the height and width auto calculated in the ArcMap data view user interface at File > Export Map dialog (Save as type: PNG) for the given resolution. For example:
arcpy.mapping.ExportToPNG(mxd, 'foo.png', df, 2122, 1553, 300, world_file=True)


In the code sample above, your heights and widths may be different based on screen resolution, so make sure you check in the user interface for acceptable values.

Tip: in the dialog, you can change the resolution and get acceptable widths and heights that will work in the ExportToPNG function.

View solution in original post

0 Kudos
2 Replies
JeffMoulds
Esri Contributor
We have a bug where any arcpy.mapping Export function that writes a world file or geotiff tags results in distorted images when brought back into ArcMap. This applies to data frame export scenarios only. This is most likely the issue you are hitting. For your records, the tracking number is NIM070025. We have already fixed it and the plan (subject to change) is to include it the next service pack/release.

The workaround is as follows: In the arcpy.mapping.ExportToPNG function, specify a resolution parameter and match the df_output_height and df_output_width parameters with the height and width auto calculated in the ArcMap data view user interface at File > Export Map dialog (Save as type: PNG) for the given resolution. For example:
arcpy.mapping.ExportToPNG(mxd, 'foo.png', df, 2122, 1553, 300, world_file=True)


In the code sample above, your heights and widths may be different based on screen resolution, so make sure you check in the user interface for acceptable values.

Tip: in the dialog, you can change the resolution and get acceptable widths and heights that will work in the ExportToPNG function.
0 Kudos
LarsHuttar
New Contributor III
We have a bug where any arcpy.mapping Export function that writes a world file or geotiff tags results in distorted images when brought back into ArcMap. This applies to data frame export scenarios only. This is most likely the issue you are hitting. For your records, the tracking number is NIM070025. We have already fixed it and the plan (subject to change) is to include it the next service pack/release.

The workaround is as follows: In the arcpy.mapping.ExportToPNG function, specify a resolution parameter and match the df_output_height and df_output_width parameters with the height and width auto calculated in the ArcMap data view user interface at File > Export Map dialog (Save as type: PNG) for the given resolution. For example:
arcpy.mapping.ExportToPNG(mxd, 'foo.png', df, 2122, 1553, 300, world_file=True)


In the code sample above, your heights and widths may be different based on screen resolution, so make sure you check in the user interface for acceptable values.

Tip: in the dialog, you can change the resolution and get acceptable widths and heights that will work in the ExportToPNG function.


Jeff, thanks for this helpful answer. We're not bringing images back into ArcMap, so I'm not sure that this bug is related to the problem we were seeing.

However, I'm happy to report that our problem has been resolved. The problem in our case apparently was not with the image exported by ExportToPNG(), but with the HTML coordinates. We had been exporting those with an older, VBA script that (if I understand correctly) didn't properly project the coordinates before writing them out. Our newer, Python version of the script uses Project_management() before exporting the coordinates, and those coordinates do align properly with the image coming of ExportToPNG().

So my original question was inaccurate... At the time, I thought that our newer, Python script had the same problem, but it turned out not to be the case.
0 Kudos