This content has been marked as final. Show 3 replies
If you expect the parallel line to be reasonably close to your feature, then you could try buffering your feature and then look for other features which have a long (i.e. much more than twice your buffer) intersection with your buffer polygon. If so, then they might be approximately parallel.1 person found this helpful
It really depends on what you're trying to determine using your data. I noticed you included "street" in your tags. Are you trying to relate street-centerlines to frontages, utilities, or parcels?
If you use buffering as John suggested, get a count for how many target features your buffer interacts with. In some cases (say street intersections) where you'll get multiple hits, you could compare angles/slopes to identify the more parallel one.
Note that buffering a line will produce a Cheeto (eh, rectangle with well rounded corners). The Cheeto may interact with more than 1 target feature if your buffer is too large and the target features are connected tip-to-tail -- and each of these targets may be parallel with your line. If that's a problem, you could compute distances to your targets and pick the closest one. You'll probably still have to compare slopes to weed out false-positives at intersections.
To support geocoding, I once related parcels to adjacent streets and tried the above approaches and found they didn't have sufficient accuracy at cul-de-sac bulbs or corner-bulbs. Instead I used the rotation value of parcel-labels (always placed perpendicular to the street) to generate search features to intersect adjacent streets. These search features had variable length depending on the street-type. There were still some false-positives due to data errors (e.g., streets incorrect typed, label misplacement, etc.), but few enough to throw a body at.
Beautiful. Thanks. Though John solution is good enough at this time, I will also combine Noel's street/intersections experience and additional slope/angle.
Thanks to both of you.