Filter out bad array formulations when importing bicycle tag data about pybna HOT 6 CLOSED

Do you think it's worth leveraging a floor to round the values instead of completely filtering out the values? e.g., if quote(s) exist and first two characters are numbers, use those values. If I'm reading this code correctly, this adjustment would preserve more information

from pybna.

@Bikingman I like that approach - we'd probably want to retain the next character after the initial number(s) to allow interpretation of units, and just toss out the rest of the field in the identified cases of more numbers immediately following the unit signifier.

from pybna.

Yea, that makes sense to avoid misinterpreting a few inches as a few feet. Does the width attribute on the resulting ways table up as a integer value? Wondering if there are any issues in retaining the right side unit character

from pybna.

These fields get mapped to tf_bike_infra_width and ft_bike_infra_width, which along with the roads width field are all reals.

The interpreter looks for 'ft' or 'm' unit characters (see

1. replace single quotes with ' ft' and scrap the rest of the field
2. toss out any field entirely where the first-from-left unit signifier is a double quote, because inches doesn't make sense

from pybna.

Also I think we only need to do this with fields that are typically numeric, not all of them

from pybna.

Yea, that sounds good to me to preserve as much information as possible while not over estimating width estimates.

from pybna.