I know this may be a snowball in hell, since you are already in alpha stage, but I think I should give it a try before 3.0.0 is out :)
The Address model class, is actually defined to use "named" administrative level, so It has the following methods:
final class Address {
// [...]
public function getCounty()
public function getCountyCode()
public function getRegion()
public function getRegionCode()
// [...]
}
The names seems ok at first and may be comfortable for some locations, but is pretty weird in many situation. A full table can be found on Wikipedia, but here some example:
As you can see, using Region and County as subdivision is really weird in many situation. In China for example, the County is the 3rd admin level, but to be consistent across all Providers, if I use the method getCounty on a Chinese result I will get a Prefecture.
Also there is no benefit in having named division. The only affected user is the developer (since is at API level), but since this naming convention apply only to a very small subset of countries, it is not perceived as a feature (IMO). When a developer user geocoding it may be more comfortable with an interface which have "first admin level sub-division", "second level subdivision" and so on, so it simplify the process of creating hierarchies.
This is how is implemented by GoogleMaps and Geonames, as you can see from the Provider implementations.
If the interface is changed in this way, the classes Region and County are no longer needed and can be replaced by a single class "AdminLevel" (or many Admin1, Admin2, Admin3...). Also, providers can be implemented so that an array of Admin level returned which may improve the results generated by the Providers: in the current implementation there is no way of returning the 3rd and 4th admin level of a result in China, but If an array is returned there is no limit.
PS: I can create a PR, but first I'd like to hear your feedback.
I know this may be a snowball in hell, since you are already in alpha stage, but I think I should give it a try before 3.0.0 is out :)
The Address model class, is actually defined to use "named" administrative level, so It has the following methods:
The names seems ok at first and may be comfortable for some locations, but is pretty weird in many situation. A full table can be found on Wikipedia, but here some example:
As you can see, using Region and County as subdivision is really weird in many situation. In China for example, the County is the 3rd admin level, but to be consistent across all Providers, if I use the method getCounty on a Chinese result I will get a Prefecture.
Also there is no benefit in having named division. The only affected user is the developer (since is at API level), but since this naming convention apply only to a very small subset of countries, it is not perceived as a feature (IMO). When a developer user geocoding it may be more comfortable with an interface which have "first admin level sub-division", "second level subdivision" and so on, so it simplify the process of creating hierarchies.
This is how is implemented by GoogleMaps and Geonames, as you can see from the Provider implementations.
If the interface is changed in this way, the classes Region and County are no longer needed and can be replaced by a single class "AdminLevel" (or many Admin1, Admin2, Admin3...). Also, providers can be implemented so that an array of Admin level returned which may improve the results generated by the Providers: in the current implementation there is no way of returning the 3rd and 4th admin level of a result in China, but If an array is returned there is no limit.
PS: I can create a PR, but first I'd like to hear your feedback.