On 21/12/2020 15:48, Mark Goodge wrote:
One of the reasons there are so many fields is that each field only ever contains a single type of data. There are no multi-purpose fields. So there are separate fields for name and number. And "number" is defined internally as an integer value, precisely in order to make it impossible to put anything other than a number into it. Which means, therefore, that something like 7A, or 7-11, has to go into the name field as the database simply won't allow it to go into the number.
...
There's absolutely no need to replicate that complexity on a non-PAF database, such as OSM. For almost all practical purposes, name/number can be a single field.
In fact I'd suggest the using a separate integer field for a purely numeric house number, and a string field for an alphanumeric house number (which may after all have a name as well) is bad design. Normally-numeric identifiers aren't really numbers. That's the sort of bad design that we should only be copying blindly if absolute compatibility is required.
Many people here will, I'm sure, have seen this non-exhaustive list of "Falsehoods Programmers Believe about Addresses", but for those that haven't, it illustrates some of these issues (and some we escape in the UK) quite nicely: https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
Chris _______________________________________________ Talk-GB mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-gb
