The address lookup in the data table currently focuses on whether the location corresponding to an address is in the polygon. This works well because that is a logical search.
For point and line features, intersecting exactly would mean that the address coordinate would need to fall on exactly a point in the geometry shape, which is unlikely. Consequently, a different approach is needed. A common approach is to specify a radius which can be compared against the distance between the address point and each point in the shape. The distance is calculated simply as sqrt(x^2 + y^2) and as soon as the distance is less than the radius a match is found so no more points in the shape need to be searched. This can also be used with polygons as it will find the polygon that intersects an edge of the radius circle.
Therefore, my suggestion is that a "Radius" choice be added to the find, for use with address search (and currently only with address search). If the radius is specified, it will be used instead of the polygon "inside" algorithm. This will at least put something in place for points and lines that is functional.
One major issue is dealing with the units of the radius. This could be handled by a drop-down choice with values "ft", "miles", "m", "km" (I'm sorting by small to large considering units system). A small radius will "warp" to degrees without too much distortion so just need to do a conversion of units using some library code and should be OK for now. A large radius will not convert to degrees in all directions but for now should be OK.
Once this feature is enabled, it will allow other features such as the "Zoom to" and select colors to be implemented.
The address lookup in the data table currently focuses on whether the location corresponding to an address is in the polygon. This works well because that is a logical search.
For point and line features, intersecting exactly would mean that the address coordinate would need to fall on exactly a point in the geometry shape, which is unlikely. Consequently, a different approach is needed. A common approach is to specify a radius which can be compared against the distance between the address point and each point in the shape. The distance is calculated simply as sqrt(x^2 + y^2) and as soon as the distance is less than the radius a match is found so no more points in the shape need to be searched. This can also be used with polygons as it will find the polygon that intersects an edge of the radius circle.
Therefore, my suggestion is that a "Radius" choice be added to the find, for use with address search (and currently only with address search). If the radius is specified, it will be used instead of the polygon "inside" algorithm. This will at least put something in place for points and lines that is functional.
One major issue is dealing with the units of the radius. This could be handled by a drop-down choice with values "ft", "miles", "m", "km" (I'm sorting by small to large considering units system). A small radius will "warp" to degrees without too much distortion so just need to do a conversion of units using some library code and should be OK for now. A large radius will not convert to degrees in all directions but for now should be OK.
Once this feature is enabled, it will allow other features such as the "Zoom to" and select colors to be implemented.