Add a separate street number using field 'sub premise' (with a new plugin)

Attached patch is a straight copy of OP's file, in git format.
See also the related issue.

Attached patch is a rework of OP, which was a nice job. It re-uses more code from the address.inc plugin.
It doesn't need the extra level 'inline-block'.
Functional differences:
- the premise is now back at the end of the street block (were it was before);
- the sub_premise now has a space as prefix, avoiding concatenation with thorougfare(street 1);
- as a side effect, in the edit form, street 2 is now also on the same line. It goes automatically to the next line if needed.

To make this complete, we need to add a 'sub_premise' Views field. (and generally search & copy for 'premise' to'sub_premise'

What problem? I use it because an ecommerce PSP requires the house number. The new field is interfaced. Do you use subpremise for other purposes?
[EDIT] I found the commerce_paypal_wpp.module, and indeed it only sends the premise as a complete line.
In any case, the usage of sub_premise for housenumber seems to be a typically north-west-european thing, and may not apply for all websites/regions. This is reflected in the title of the format plugin.
Also, the format plugin may need some country-specific data: some countries have house number after, some before the street name.

fwiw, xNAL doesn't actually support street numbers as a sub premise. The sub premise is actually more like an apartment or suite number. From the specification:

"Specification of a single sub-premise. Examples of sub-premises are apartments and suites. Each sub-premise should be uniquely identifiable. SubPremiseType: Specification of the name of a sub-premise type. Possible values not limited to: Suite, Appartment, Floor, Unknown Multiple levels within a premise by recursively calling SubPremise Eg. Level 4, Suite 2, Block C Type: SubPremiseType may be Apartment, Lot, etc SupplementaryInfo:Any additional info helpful to identify the location."

That's not to say you can't do this if you know you want it, but I don't believe it would be right for us to support that in the Address Field module itself, given its desire to adhere to the standard.

This is just a re-upload of #2, which contains a wrong issue number in the file name.
I also created #2151903: Make sub_premise whole as a follow-up.

I've looked at below xNAL example. Indeed, the usage of subpremise as house number doesn't adhere to the standards.
Instead, (to get a separate house number), we need a splitted Thoroughfare, like what we are doing with the redundant FullName and first+Last name fields.
(It's impossible to separate street + number out of 1 field, also since house numbers may have additions/extensions.)

I guess, the changes of getting ThoroughfareName + Number in Addressfield are low, so using sub-premise is the next-best thing.
[EDIT: it also requires a mean hack in geocoder.widget.inc, to geocode the address. :-( ]

    <Locality>
     <LocalityName>Chatswood</LocalityName>
     <Thoroughfare Type="Street">
      <ThoroughfareName>Archer Street</ThoroughfareName>
      <ThoroughfareNumber>67</ThoroughfareNumber>
      <Premise Type="Building">
       <BuildingName>Egis</BuildingName>
       <SubPremise Type="LEVEL">
        <SubPremiseNumber>12</SubPremiseNumber>
       </SubPremise> 
      </Premise>
     </Thoroughfare>
     <PostalCode>
      <PostalCodeNumber>2067</PostalCodeNumber>
     </PostalCode> 
    </Locality> 

I don't like the way this is going....
I'm happy to provide a patch using ThoroughfareName+Number, if there is any chance it gets in. It would add those 2 subfields to the table and follow the same pattern as FirstName/LastName.

Thanks for the work done and comments so far.

I needed a working solution now, with street name, number and suffix field... and since it isn't clear to me if/when there would be consensus on how to store the data, I decided to go for an option that stores all 3 fields in the 'thoroughfare' field.

This needs FormAPI handling; I packed everything up into a module available in a sandbox. This could work for some people, until there's a decision on Addressfield's direction.

As proven, the attached patch does not follow the standard and can't be committed.

ThoroughfareName+Number is a valid approach, but I don't want to commit it to addressfield because we have no way of making it bulletproof (some countries place the number before the street, some after, some don't care about the number at all). That's why I think that should live in a separate module.

Hi,

I also needed a separate street number (Belgium) and I have installed the sandbox from roderik from #10 and it works great.

Thanks!

Hi,
sandbox from roderik from #10 helped me at the part of collection the right data from the webshop clients, especially to force the customer to fill in the street number (before #10, some clients forgot to enter there street number during checkout and only entered their street address)

Now I need te create a CSV export to feed my shipping system and also there I need to have the street name / street number as separate fields...(using Views data export)

At the moment, it is not possible to separate the fields again for display inside Views.
... does anyone has another idea?

Hi,
Pleating for getting Addressfields streetaddress + number into addressfield module.
Right now I have to use location module to show streetaddress and number to users, but for other purposes I need addressfield...not optimal..
greetings, Martijn

Hi,

May be a generic formatter based on this one is the solution https://www.drupal.org/project/addressfield_estonia ?
Anyone please?

greetings,
Martijn