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:
