I would set a minimum length of 1. In some localities you'll get a town consisting of just one street, and a street address consisting of a single digit for the house or building number, plus the town and post code:
To approach this from the other side, a length restriction doesn't particularly help you validate your data.
There are 3 possible types of error I can see would apply here:
- User does not enter an address
- User deliberately enters an invalid address ("asdf" or "n/a")
- User enters an invalid address by mistake ("1 Mpain Street")
Length validation can help you with (1) but not with (2) since the user can just enter a longer invalid address nor with (3) since the invalid address will average the same length as the valid one.
By far the best approach to gathering "clean" address data is to check the input addresses in real time against a "address correction/validation/verification" database or API (these are commercial products that vary wildly from country to country). You can even use these to reduce user input - for example, a common design pattern in the UK is to prompt the user for house number and postcode, do an ajax lookup against a PAF database and present the result from the PAF to user for them to correct or add to.
Of course none of these services are perfect (a good one will provide millions of updates and corrections every year) and so you will also require a backup mechanism for the user to enter a non-matching address.
One last thought - if you're looking for location data that does not represent your users home or work address, then an address verification service is much less useful and you get better data if you allow your user to pinpoint the location on a map (like on FixMyStreet for example)