Latest Contributions by ChrisDonohue__GISP

‎11-06-2015

Ah, so that is why the result was different. If i sees Null as non-existing, so no join (and therefore no substitution text of 'None'). Makes sense. Chris Donohue, GISP

‎11-06-2015

Thanks Dan, that works. I'm going to play with it a bit to try to get a better handle on it. I was puzzled by the space " " in front of the join - I realized it was a separator to keep all the text from running into each other in the combined string but was worried it would add a space in front of the result, but it does not. The "If i" is interesting. Sort of like For-Next in other languages. I wonder why the .join method treats Nulls differently than the .format method does.... Chris Donohue, GISP

‎11-06-2015

I have some addressing data that I would like to update and one of the tasks is to concatenate a new full street address field [ADDR1] by combining several of the component fields. I know how to do this in VBScript, but figured this would be a good example to work out in Python, as I don't use Python often and have alot to learn. My programming background is FORTRAN and BASIC, and in the years since those were popular hack and slash adapting code for AML/Avenue/VBA/VB.Net - so assume I know little about Python. What is desired (psuedo-logic): ADDR1 = STRNUM + STRNUMSUF + STRPREDIR + STRNAME + STRTYPE + STRSUFDIR I'm using ArcGIS 10.2.1 and the data shown here is test data in a File Geodatabase feature class. After poking around various Help articles, it appears that in Python the .format method in would work. However, when I run it in Field Calculator the result looks good except "None" gets concatenated as text if the original field value was NULL (this issue doesn't come up with VBScript). I'd like any values of NULL to instead just be blank - i.e. ignore them entirely. For example, for the first record the desired outcome in ADDR1 is "224 D N CHURCH ST" not "224 D N CHURCH ST None". One of the Python articles I found mentions the NULL issue: Source: Concatenating field values using Calculate Field | ArcGIS Blog Is there a different way to do the concatenation in Python to achieve the desired outcome? I'm trying to wrap my head around how Python approaches this, particularly in regards to using it in ArcMap in Field Calculator. I noticed some articles suggested casting all the fields to string to resolve the NULLS. However, I haven't had any luck adding in str() in with the fields in the format statement shown. It would just error out. Would this need to be a separate line to do the casting? Would a better approach be to use the Codeblock to run some sort of process to convert NULLS to blank before running the format method? For example, adapt a process similar to this? Source: arcgis desktop - Calculate Field tool to calculate on null fields - Geographic Information Systems Stack Exchange Lastly, can you recommend a good guide for beginners that explains how to use Python for these sort of issues? Thanks, Chris Donohue, GISP

‎11-05-2015

The spatial location on the Identify readout is based on the Data Frame coordinate system, not the coordinate system of the layer that you are using in the Identify. You can test this by changing the spatial reference of the Data Frame, then using the Identify tool. Chris Donohue, GISP

‎11-05-2015

Send the beer to Darren Wiens - he responded with the essential issue identified first (though I am assuming he drinks beer, if not I will take it ). Or at the very least, mark Darren's answer here as Correct so others who do a search on the same type of issue will know an answer was found. Chris Donohue, GISP

‎11-05-2015

If it turns out the input is indeed in a Geographic Coordinate System, the Near (Analysis) Tool Help offers this advice: The distances calculated by this tool are in the unit of the coordinate system of the input features. If your input is in a geographic coordinate system and you want output distances to be measured in a linear unit (as opposed to decimal degrees), you must first project your input to a projected coordinate system using the Project tool. For best results, use an equidistant projection or a projection intended for your study area (UTM, for example). ArcGIS Help 10.1 Chris Donohue, GISP

‎11-05-2015

I think Darren Wiens has a good guess. Check the input feature's coordinate system to see what the units are. It's probably a Geographic Coordinate System, so decimal degrees. From the Near (Analysis) Tool Help: NEAR_DIST—Stores the distance from the input feature to the nearest feature. The value of this field is in the linear unit of the input's coordinate system. ArcGIS Help 10.1 Chris Donohue, GISP

‎11-03-2015

I've used a couple of workarounds in the past to deal with this. Not the most elegant solutions (I suspect there may now be easier options), but workable. One workaround is to alter the display extent for that page so that their is enough space for the overlapping legend to display without covering up the data. In Data Driven Pages, use the Data Drive Scale option and enter an appropriate scale that works for the maps that are in issue. However, this can be "hit or miss", as doing so may cause surrounding areas to be "missed" as the series is created, so check the output. See the Optional Settings (Map Extent) section in this link: ArcGIS Help 10.1 Another option is to alter the grid you are using as an index so that the pages will automatically be sized as you want to accommodate the legend issue. This will require manually editing the grid, which can get messy if you have many grid polygons surrounding the one you want to change. Two further options for this approach - one is to "overlap" the problem grid (so the legend covers up information displayed on the previous page). Another option is to expand or shrink the grid for the problem one(s). What works best will depend upon your data and how it displays. Be aware that if you use any of these options, it will impact how the viewer sees the results. It may entail having to take extra steps like calling out to the viewer that the "problem" map is of a different scale or extent than the others in the series. So unfortunately no easy "one step fix" solutions. Chris Donohue, GISP

‎10-30-2015

If I understand correctly, you are trying to find a line route that would be the least visible in your extent. One question that arises is visible from where? Viewed from a specific location? Viewed from every location in your extent? How are you defining where the viewer is for this analysis? Chris Donohue, GISP

‎10-30-2015

One possibility is the coordinate system the mxd is using may not be complete. To check this, I would start by seeing what coordinate system is in the Data Frame of your mxd, as it inherits the coordinate system of the first layer you added. It may be that it picked up a partial or incomplete coordinate system from earlier work you did in the mxd. Chris Donohue, GISP

‎10-30-2015

Here's a quick example of the visibility/symbology issues that can come up with overlapping polygons: 1. 3 polygons were digitized. This is what is visible when it is just simple fill. Note only 2 of the 3 polygons are visible. A viewer would not even realize that there is another polygon here. 2. Breaking out the polygons by a year using fill symbology looks better, but still can only see two of the three polygons. Note also that the "missing" polygon is the one that was drawn first and the 2015 polygon (blue) was drawn last, thus the 2015 is on top of the green polygon. 3. Symbolization with a hollow fill. 3 polygons visible, but the linework can can potentially confuse a viewer as to the extent of each poly unless you color code the linework or use other cartographic methods. I labelled the year here, but as you can see that is not the best way to go to help the viewer figure out which extent is which. Definitely potential for confusion. Usually folks avoid using overlapping polygons, as they can cause issues like this. Also, as Darren Wiens mentioned the overlapping can cause major headaches when one does geoprocessing on the layer if the user is not aware that they polys are overlapping and does not adjust for that. Now, that said, I have seen some folks who do use overlapping polygons. The two topics that come to mind are Fire and Plant/Animal specie datasets. For example, I've seen Fire datasets of polygons for many years of burned-area in one poly layer for Fire. For Plants, sources like the California Natural Diversity Database (CNDDB), which have years and years of polys for Sensitive Species overlapping each other California Natural Diversity Database Home . So ultimately it comes down to what you want to do with it, realizing that going forward with overlapping polygons has several potential issues, which will require some consideration and maybe some tradeoffs. Chris Donohue, GISP

‎10-30-2015

It depends. Some issues that may come up: 1. Are they differentiated by a year attribute? How will the user tell the the polygons apart? 2. The order the overlapping polygons were drawn can affect whether they are visible at first glance. For example, if a small polygon is overlaid by a larger polygon and a fill is used, a viewer may not even realize it is there as they won't see it. This is because the draw order is affected by the order the polygons were drawn (not by attributes like years). Chris Donohue, GISP

‎10-28-2015

Another possibility is to use some of the Cartography tools, like Merge Divided Roads or Collapse Dual LInes to Centerlines: ArcGIS Help 10.1 ArcGIS Help 10.1 One caution - I would definitely check the output closely, as I found found at times both tools to occasionally produce small areas of bizarre results for no apparent reason. As one example, on a long curve it created a centerline that cut across one of the input curve line segments - a "shortcut" - instead of between the curved segments as expected. Chris Donohue, GISP

‎10-27-2015

There also is an older post that seems to address what you are looking for by using the ArcHydro extension: Water drop trace? Edit - another discussion, this one mentioning: 3D Analyst methods (Steepest Path Tool) The former Spatial Analyst Shortest Path tool which has been replaced by Cost Path Modelbuilder suggestion to accomplish this ArcHydro Flow Path Tracing tool Shortest path tool/ Raindrop trace equivalent in Arc 10? Chris Donohue, GISP

‎10-27-2015

The Spatial Analyst Extension has a hydrology toolset that could be used for what you have in mind. ArcGIS Help 10.1 If I remember correctly there also is a tool that allows you to place a point and it will then directly show the flow path. However, big assumption here, I assume you are talking about surface runoff, not groundwater flow. Chris Donohue, GISP

Online Status	Offline
Date Last Visited	‎08-03-2022 01:39 PM

My Ideas

Latest Contributions by ChrisDonohue__GISP

Re: Concatenating Strings with Field Calculator and Python - dealing with NULLS

Re: Concatenating Strings with Field Calculator and Python - dealing with NULLS

Concatenating Strings with Field Calculator and Python - dealing with NULLS

Re: When you identify a feature what coordinate system does the location result ticker use?

Re: NEAR Results?

Re: NEAR Results?

Re: NEAR Results?

Re: Map Book legends

Re: visibility analysis using a polyline

Re: Base map not displaying

Re: Are overlapping polygons an acceptable means of displaying archive data?

Re: Are overlapping polygons an acceptable means of displaying archive data?

Re: CENTER LINE BETWEEN TWO POLYLINES

Re: Flow direction

Re: Flow direction

Re: ArcGIS 10: Graphics won't display in Data View

Re: Can't set output as intermediate data

Re: Addressing - Plus Code or What3Words (W3W)

Re: How to label "_, Mount" as "Mount _" ?

Re: Raster/Vector Land use Analysis

GIS Jobs

Esri Certified Individuals

GeoMentors

Address Points

Addressing