Latest Contributions by AndrewThorup

‎04-12-2018

While looking at my code which I wrote over a year ago, I started wondering why I put 'Pre_Dir' in as a field that ocld be used. Then I realized that I already calculated the Pre_Dir in a previous step in the model. I substituted the problem line with the following line: elif Pre_Dir == 'S' or 'W': return ' '.join(prop_location.strip().split()[2:-1])‍‍ It worked like a charm. I obviously started out writing the code block with the intent use Pre_Dir in that fashion, but then forgot when I came to that portion of the code because I'm an airhead. Sincere thanks to Joe, Ian, Balaji, and Joshua. I'm still going to try out the usaddress package and let you know how it works in ModelBuilder.

‎04-11-2018

This looks like it could really be helpful. My code is written in a 'Calulate Field' tool within a ModelBuilder model. This may be a dumb question, but does importing work in that environment? Can I simply import the usaddress package using the syntax above into that environment?

‎04-11-2018

Sure, here are three different types of addresses that should be dealt with in the if statement: 1242 W 8550 S 1242 Bateman Ponds Wy 7726-7728 S 2700 W Thanks for your help, Joe!

‎04-11-2018

I'm getting a "list index out of range" error and I don't know why. I'm parsing an address field to return only the street name. The following line gives the error: elif prop_location.strip().split()[1] == 'S' or 'W': return ' '.join(prop_location.strip().split()[2:-1] According to the error log, the issue seems to be with the elif statement. This code has worked fine for a long time, but the last several times I've run it it has given me this error. I have checked the feature class for addresses that have a W or S with an index greater than 1, but I haven't found any. There are some records that are blank, and others without a 'W' or 'S', but they shouldn't be a part of this if statement. I'm not sure how to fix the code. Here is the all the code for context (problem statement is line 12). The error notification is added as an attachment: def getStreetName( prop_location, Pre_Dir ): if prop_location is None: return None elif prop_location == ' ': return None elif " #" in prop_location: head, sep, tail = prop_location.partition(' #') if head.strip().split()[1] == 'S' or 'W': return ' '.join(head.strip().split()[2:-1]) else: return ' '.join(head.strip().split()[1:-1]) elif prop_location.strip().split()[1] == 'S' or 'W': return ' '.join(prop_location.strip().split()[2:-1]) else: return ' '.join(prop_location.strip().split()[1:-1])‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

‎10-17-2012

Thank you Tim and Chris, your answers were very helpful. I realized what I was doing wrong and I hope my explanation makes sense: When I put an * in the bearing field and entered the radius and arc length, it would automatically populate a chord bearing in the same direction as the previous line (I had the bearing field set to chord bearing). For example, it would calculate a chord bearing of S56�?30'30"W. I needed the chord to be pointed in the NE quadrant, so I simply changed the SW to NE, which did not work. What I did not realize is that I wasn't shifting it 90 degrees like I was supposed to. N56�?30'30"E is not a 90 degree shift from the same coordinate in the SE quadrant. When I properly subtracted 56�?30'30" from 90 degrees and entered N33�?29'30"E, the curve took the form of what is showed in the plan. So it is possible to calculate the radial, chord, or tangent bearing based off of two geometry parameters by placing an * in the bearing field and doing the proper conversion (if required) to the desired quadrant.

‎10-15-2012

Jay, from that plat it looks like all the curves are assumed tangent. You can either set the plan properties to reflect this or use the * symbol in the bearing field to set it to tangent (type the radius and arclength). Maybe I'm missing something, please let me know if I'm not understanding. Chris, thank you for your response. I tried creating a curve by entering an * in the bearing field, then typing the radius and arc length. When I do this, a value is entered into the bearing field for the curve as well as for the next line segment. Neither of these values create a bearing that places the curve as it appears in the plan. I have a couple of additional questions based on your post: 1. How does one come to the conclusion by looking at a plat that all curves are assumed tangent? ( I did not see this written anywhere on the plat itself) 2. From the documentation I have read, when you place an * in the bearing field, the value that gets populated is the tangent bearing from the previous line. The value that gets populated in the bearing field for the next line segment is the exit tangent to the curve just created. Is that correct or am I way off? 3. Is there any way to calculate the degrees, minutes, and seconds for a tangent, radial, or chord bearing given the values I listed in my previous post? Any input would be extremely helpful.

‎10-09-2012

I am having the exact same problem. I am trying to edit a parcel in parcel fabric. The plan I am working off of gives the following values: Delta: 70°39'45" Radius: -45 Tangent Length: 31.90 Arc Length: 55.50 Using the "Curve Calculator", I also have calculated the Chord Distance (52.049') and the Chord Height (8.289'). All of this information is great, but I do not have values for either the Chord, Radial, or Tangent Bearing. Is it possible to calculate a bearing from the given values? I realize I could find the end points by saving the curve as the final piece of the parcel, but some parcels have two or three curves in them, making that a flawed approach. I have attached a copy of the plan I am working with for reference. Danny - Have you figured out a way to deal with the issue? Tim - Any advice given the values presented? I do not mean to hijack this post, and if this would be better off as it's own post, let me know and I will create one. Thanks, Jay

‎09-05-2012

Robert, It's fixed, thank you very much for your help. Once I included the YPNO field as part of the fields tag, it started showing up in the url. I was unaware that the field had to be in the fields tag. Thanks again!

‎09-04-2012

Robert, Great job on this fantastic widget. I am having an issue with the link functionality on one of my viewers. There is supposed to be a url string with the parcel number (YPNO field) attached at the end to comlete the link. Here is the code I have used in the eSearch.xml file: <links> <link includeinresults="true" alias="Lyon Co Assessor Parcel Search"> <![CDATA[http://www1.lyon-county.org:403/cgi-bin/asw101?Parcel={YPNO}]]> <icon><![CDATA[assets/images/i_table.png]]></icon> </link> </links> When the link is clicked in the viewer, the url appears in the address bar without the attached YPNO number. I know I am supposed to wrap the field name in curly braces, and this same method works on all of the other viewers I have created for other counties. I have had this problem for this viewer using versions 3.0.6, 3.0.7, and 3.0.8. I have confirmed that YPNO is indeed the correct name for the field by checking at the rest endpoint. I have also tried making the link work as a text field as well as a number field. So far I have had no success.

Online Status	Offline
Date Last Visited	‎11-11-2020 02:23 AM

My Ideas

Latest Contributions by AndrewThorup

Re: "List index out of range" error when parsing an address field.

Re: "List index out of range" error when parsing an address field.

Re: "List index out of range" error when parsing an address field.

"List index out of range" error when parsing an address field.

Re: Dealing with missing traverse information in COGO

Re: Dealing with missing traverse information in COGO

Re: Dealing with missing traverse information in COGO

Re: Enhanced-Search-Widget-for-FlexViewer Part II

Re: Enhanced-Search-Widget-for-FlexViewer Part II

Re: Dealing with missing traverse information in C...

Re: "List index out of range" error when parsing a...