Latest Contributions by RichardFairhurst

Hello Amazing MapMan: I would prefer for you to provide me with the data, rather than send the tool to you in its current state.  I have realized that the sample data I have tested so far has not dealt with a wide array of spatial reference projections or measurement unit types.  I also am interested to see how it behaves with the wider buffer distance.  Being able to work with the results produced by your data directly will let me catch any unexpected behaviors much more quickly and will assist me with any debugging and retesting I may need to do So in many ways your data would help me make sure my code will work internationally and find out how to best design it to meet needs like yours.  Also, it would be much better than any international data I would otherwise come up with for testing.  See my profile to contact me directly offline so that we can make further arrangements for sharing your data. ... View more

So any interest in the tool I demonstrated?  The tool itself ran in under 1 minute and total preparation time spent to create my demo than was less than 15 minutes.  Given that you are seeing results on data and a use case that I had never tested before and did not have in mind when I designed the tool, I think it did an excellent job.  In fact, the results are so good, I expect to resume testing of this tool on an entirely new set of data focused on the border/coastline buffer issue to see what refinements can be made specifically to handle that use case. ... View more

Since you can see the python code I used with the coastline problem, which is yours to adapt or apply as you see fit, I assume your question about the cost or open source availability of my tool is related to the line buffer tool.  I have never sold my tools, but I have not yet published the add-in or source code for the line buffer tool at this point, because I have so far only focused on getting the core functionality to work.  As a result, the line buffer tool currently only works when I set up the inputs to match my test data layer names.  So, while I can set it up and use it with many different data inputs, it is still much too unfriendly for the average end user to use. From the discussions on the line side buffer tool you can see there are several issues involved in using the base ArcObjects methods, and the problems grow as the side buffer distance and the geometry complexity increases.  I had to do extensive troubleshooting over several days just to develop subroutines that would let the methods accept my input geometry without the potential to trigger a catastrophic crash of ArcMap.  The Bug that crashes ArcMap affects the Edit->Copy Parallel option for Left handed offsets and occurs with a some line inputs that contain curves made up of highly densified line segments of 1/2 foot or less.  Esri recommends using the Smooth Line tool in the Generalization toolset of the Cartography toolbox prior to using that Edit option as a workaround. So far all of my tests have been done using roadway networks as inputs, which is my primary use case.  The tool works best with relatively simple geometry, such as with a grid roadway network.  It even works very well with roadways that have broad flowing curves and some pretty complex intersections.  My tests also have been limited to very small buffer distance of only 30 feet.  The ArcObjects method may create other issues I have not yet encountered when I significantly increase the buffer distance. How large of a buffer distance are you thinking of using?  Even if the method does not introduce a whole new set of problems when I increase the buffer distance that I have yet to encounter, the tool result does not really attempt to resolve issues that arise when the input line length is shorter than the buffer distance.  The tool expects the line lengths to always (or at least predominantly) be longer than the buffer distance, and when input lines are shorter than the buffer distance it leaves overlaps in the buffer geometry. The tool also becomes less predictable when the input lines include a lot of small zigzags, wiggles, bends and sharp angle changes, like those found where jurisdictional boundaries follow natural features like the bank of a river or a ridge line.  That kind of input should not crash my tool, but probably they would create issues that my tool would include in its error log.  Without doing further tests I am not completely sure what results my tool would produce with a line input like the German border broken where the subarea boundaries meet using a very large buffer distance as an input.  But I think it would be worthwhile to test it so I could find out what practical uses the tool actually supports and better inform users of any known limitations. I performed an experiment on my City boundaries.  To prepare the polygon data for use with my tool I did the following geoprocessing first: 1.  I ran the Polygon to Line tool with the option to identify and store the neighboring polygon information.  I ran this for all Cities, but for Germany you would first select just the German subareas to exclude all surrounding countries prior to running the tool. 2.  I selected the set of output lines where the LEFT_FID equaled -1 (no adjoining City).  If you excluded all surrounding country polygons this should represent the set of lines at the outer German boundary. 3.  Then I ran the Dissolve tool with the LEFT_FID and RIGHT_FID fields checked as my Dissolve Fields, and used the Unsplit Lines option.  This step is necessary, because the polygon perimeter may close at a location that does not meet an adjoining polygon boundary and I want only want line breaks where a change in the City occurs (or the subarea in your case). 4.  I created an polygon feature class that included the fields from my Cities and added a Long field named ORIG_OID and a text field with a length of 5 called LINE_SIDE. I then ran my tool with a 300 foot buffer. After the tool completed I set a definition query on the polygon layer to only show the LINE_SIDE values that were 'Left'. Overall I consider the results to be very good, but there were issues that would need some manual attention.  In fact the tool actually helps to expose some topologically incorrect geometry in my source data.  The pictures below show the results and some issues that can be expected and possible fixes: ... View more

A Basic or Standard license just makes this process nearly impossible to automate or model.  I've programmed this in Python with the use of Advanced license tools.  See this discussion on the problem of just buffering a coastline, which is the identical problem you face (buffer coastline only is just another name for buffer external boundary only).  There is a python code file that shows the Advanced tools that you would need and snap shots of the problem areas I found in the results shown in post number 8.  However, post number 9 shows a snap shot of the more typical good results I got. I have recently created an ArcObjects add-in that does left and right hand buffers of lines without overlap and that would work with a Basic license.  That tool came about as a result of this discussion and I have resolved most of the technical problems since my last post to that thread.  At this point, the took works but I have yet created a universal user interface so it is user friendly enough to publish the tool. You would still need a way to extract just the outer boundary of Germany as lines.  That can easily be done with Advanced license tools, but not with a Basic license.   At a minimum, I would have to write ArcObjects code to replicate the Features to Line tool functionality to make it work with a Basic license.  Since that would take several days to do, I would only offer to have you send me your polygons and I would just run the Advanced license tool to get you those boundaries in under 5 minutes. Unfortunately, really wiggly lines will cause severe problems with the buffering methods I used in the Add-in, but there are alternative buffering options that can avoid most of those problems. At the same time, your illustration is for all practical purposes impossible to program, since you are using a normal angle to your boundary lines that considers the overall line trend and avoids inlet pockets.  You drew lines that are not straight to cut the separations between the German subareas, which is illogical other than to avoid inlet pocket obstacles or to follow another country's boundary.  Nothing can really do what you drew other than the human brain or a monster program.  For practical and performance reasons geometry can only consider a limited set of points and line segment angles to come up with a normal angle to the wiggly boundaries of Germany. Also, do you care about the boundaries of the adjoining countries?  The buffer you drew could cut in and out of multiple adjoining countries across the lines separating each of your subareas. Anyway, this need comes up all the time and I am having some real success at tackling it for several scenarios.  But I do not believe you can come up with anything using Python and/or ModelBuilder that will do what you want under a Basic or Standard license only.  If you really want to do this level of work, a Basic or Standard license is just not adequate and you either need to buy an Advanced licence or partner with someone who has an Advanced license. ... View more

Unless you have an attribute to distinguish sidings from mainline railroad tracks there is no way to make that distinction other than to select the lines and encode them manually or delete the unwanted lines.  All 3+ way line intersections like you showed in your picture will prevent your line from unsplitting until you can separate the mainline railroads from the sidings. I would normally assign a subtype to the sidings and mainline railroad lines so I could select just the mainline railroad lines and use that selection with the Dissolve tool.  The subtype approach is non-destructive so that you can easily recover in case you find out you need to restore a line you mistakenly selected and incorrectly categorized, whereas if you delete lines recovery may not be possible after saving the layer,  As long as only the mainline railroad lines are selected the dissolve will ignore the sidings and unsplit the mainline railroads the way you want them.  After doing your best to do the mainline selection, unsplit the lines, assign railroad names and retest for continuity by looking for lines that still had unassigned names.  That will show you where two or more mainline railroads actually intersect, which you have to process manually no matter what technique you use, or it will show where you missed a siding. You can always use the geoprocessing results tab to easily open a tool you ran previously so that you can rerun the tool without having to reconfigure it.  So redoing the steps in an iterative approach is not that hard. Frankly, from my perspective 3500 features is well within my tolerance for assigning a two category subtype attribute manually and I see no benefit for looking for an automated approach to avoid that step, unless I knew that I would have to repeat that process more than once.  Since that relatively minimal level of effort would let me automatically assign 100s of unique railway names I would consider that a very acceptable trade-off. ... View more

No, that only means they touch the edge.  Look at the sketch properties of two lines that should meet end to end.  If they have the exact same coordinates in the matching ends of the line then they would meet end to end.  If they are off by a fractional amount, they don't meet. Also, did you confirm that no attributes were generated by the Dissolve tool other than the ObjectID and Shape?  If you had any other field in the output that is not a summary field (Sum, Mean, Min, Max, etc) that will prevent lines that touch end to end from connecting if the value in the other fields do not exactly match. Dissolve with the Dissovle_Lines option and no attributes should merge everything together into one feature, not multiple features if done properly. Screenshot your Dissolve setting screen if you want to let us verify that all of the inputs are correct. Here are my results on a topologically correct line layer (I use an actual topology layer with rules that identify dangles and line ends touching the interior of another line as errors to ensure that only cul-de-sacs and stub roads are allowed to not meet end to end) with different Dissolve tool inputs. Original Input lines: 2496 line features. Dissolve with no attributes, no summary fields, create multipart features, and using the Dissolve_Lines option: 1 line feature created.  When the create multipart features option was unchecked the process failed to complete. Dissolve with no attributes, no summary fields, create multipart features,  and using the Unsplit_Lines option:  2,039 line features.  Separate line features are created at every intersection of 3 or more lines.  The unsplit lines option only works if just two lines meet end to end when no attributes are considered.  The create multipart feature option had no effect on the unsplit lines process. Dissolve using a Street Name attribute to control the dissolve, no summary fields, create multipart features, and using the Dissolve_Lines option:  980 line features were created.  Only one line feature was created for each unique street name.  The create multipart feature option had an effect on the dissolve process and created 18 additional features when the multipart option was unchecked for a total of 998 features. Dissolve using a Street Name attribute to control the dissolve, no summary fields, create multipart features, and using the Unsplit_Lines option:  998 line features were created.  There is one line minimum for each unique street name, but where any lines did not meet end to end additional features with the same street name were created for each line gap.  Therefore only 18 gaps existed in my line data when the street name was considered.  Intersecting roads with other street names had no effect on the unsplit process.  The create multipart feature option had no effect on the unsplit lines process.  However, the results were the same whether I unchecked the multipart feature option and used Dissolve_Lines or I used the Unsplit_Lines option. ... View more

The answer to question 1 is that any field that has to be compared using the if/then logic or that has to be used to build your concatenated return value must be in the parentheses in both section.  So if you want to concatenate field1, field2 and field3 in the calculation, all 3 must be in the method parentheses.  The actual field from the field list must be used in the list in the expression portion, but any variable name that represents that field can be used in the def method in the code block. The concatenation expression can include literal strings and field values in exactly the way you have shown.  Python considers single quotes and double quotes to be equivalent (as long as they are used in pairs to open and close the string).  So field1 + "-" + field2 + "-" + field3 and field1 + '-' + field2 + '-' + field3 work the same. ... View more

One-to-many relationships are not supported by table joins.  So the definition query based on that kind relationship won't work reliably by design.  The Make Query Table tool is designed to deal with one-to-many relationships and is how you should set this up.  One to many relationships in ArcGIS require you to do things that are not practical, but they are necessary to make it work. If you export the join without a definition query the features will be duplicated to create 3 copies of the counties joined to each one of the 3 rows. Alternatively dividing the one table into 3 tables and using 3 separate joins would also work. ... View more

Actually, I meant to say use Dissolve with the Unsplit lines option as you have mentioned.  I have not used it very often, so some of my recollections on how it behaves may not be entirely correct, but in general the way I described it should be correct.  Using the Multipart to singlepart tool  may not apply, but more often than not I have to use that tool after using Dissolve. ... View more

You could first Merge all line segments together without attributes and require that lines must join end to end in order to merge.  Calculate a long field named Parts with the following Python calculation to get a part count for each merged line: !Shape.partCount!  If no crossing lines exist and the lines actually meet end to end, then a single line will be created for all contiguous original line segments in a linear sequence and they will have a single part.  A spatial join of your original lines that actually have a name to the merged lines would show if more than one name was associated to the merged line (use One-to-One with the Join Merge Rule for the name field and a semi-colon delimiter).  If only one name exists for the line, you can spatial join the original lines to that merged line and transfer the name attribute to all of the segments that make up that line. If for some reason more than one name is associated to a merged single line that is a single part line, the Name field would have a semi-colon in the name list.  You would have to determine where the name changed manually based on other information or further research. Where more than two segments meet end to end to form branching lines the part count will be 2 or more.  The spatial join I recommended would tell you if only one name was associated to the branching line set, and in cases where that is true you could transfer the name attribute the same as if it was a single part line with one name. However, if more than one name was associated with a branching line set, use the Multi-part to single-part tool to divide the merged line into single part lines.  While I could write a program to get the bearing of the line segment at each line end to determine the lines that probably should join, you probably still should manually evaluate these lines that intersect no matter what to determine which alignments actually should join together through the intersection.  Once you get a single part line assembled, then find the named segment associated with it and you can use it to transfer the name to the original lines.  The intersections will complicate this, so you may have to buffer these lines and only transfer the attribute to original lines that can be selected using the rule that them must entirely fit in the buffer. ... View more

You do not need to concatenate every character or word separately in a string.  You wrote: + ' ' + 'acres' + ' ' + '-' + ' ' + You should have written: + ' acres - ' + Or you wrote: + ' ' +  '-' + ' ' + You should have written: + ' - ' + ... View more

It can be done with Python, but I don't know if I understand the end result you are looking for.  Your way of describing what you want is very confusing.  Here is what I think you want: 1. For any given point in A (shape) find the distance to the closest point in B along with the point B ObjectID (Attributes). 2. Sort the points in A by the distance to B in descending order so that the furthest distance point in A is at the top of the list. Is that correct?  Or perhaps rule 1 should be : For any given point in A find the distance to the furthest point in B along with the Point B ObjectID. This assumes you want the point shape from A and just the attributes from B.  But your description could mean that you want the to keep the point shape in B and attribute it with the distance and ObjectID of a point in A.  Or do you want a table with the coordinates of both points that meet your rule 1 so that you could make an XY point layer based on either the location in A or the location in B? So basically at the end should there be 9000 records (one for each point in A) or 500 records (one for each point in B). ... View more