Once after the move, I had to be puzzled by the search for my post office. In the latest versions of the desktop version 2Gis, fortunately, for most cities there is information about building indexes and ultimately the search came down to choosing a post office at a number equal to the last three digits of the index, but the number of routine operations for this was quite large and wanted at leisure as a warm-up for the mind and for the love of applied algorithms, try to automate this process.
Attempt # 1
First, it was decided to go "on the forehead", that is, to find a way to get the post office address immediately by index. The method was found quite quickly - on the Russian Post site there is a service
Search for postal offices that implements this task. Although the stability and speed of this service leaves much to be desired (for the last few days it has been completely disabled due to maintenance work), quite a few third-party services have been found that mirror this information, for example,
PostPostilka or
Independent rating of Russian post offices . However, another problem arose - the received address could only be fed to the application via the user interface in the universal “Where” field:
However, the API of plugins does not have such an opportunity; the search method needs to be delivered to three separate fields: settlement, street, house. In principle, at this stage it would be possible to try puzzled by biting the address fields from the resulting line, but this task did not seem interesting and it was decided to go around (perhaps now I would return to this option).
Attempt # 2
In addition to the address of the post office, the above services also report its name, which, in general, consists of the name of the settlement and the sequence number of the department if there are several of them. This information, in general, should be enough to search for the directory of organizations (by locality and the name of the department). At this stage, the first working version of the plug-in was implemented, which polls all three of the above services based on their availability (
repository on GitHub ). However, in any case, the response time was unstable and the ideology of the desktop application 2Gis suggests the possibility of full-fledged work in offline mode.
Attempt number 3
After a brief search for the offline database, the
Reference Postal Code Directory of the postal objects was found, which is a DBF file, and also updated with an enviable periodicity. From the 18-megabyte file, only the necessary information was sampled and included in the plugin.
However, at this stage, a number of problems were discovered with the names of post offices and their assignment to settlements. Almost all of them managed to be solved in the current implementation of the plugin (the
current branch on GitHub ).
Below is the main algorithm for generating criteria for finding a post office in the directory of organizations:
There is only a problem with the village of Timiryazevo, officially part of the city of Tomsk - the branch in it is called “Timiryazevsky”, but the village itself is not allocated in the directory as an independent settlement (which it is). It may be worth returning to step 1 and try to work with the address information.
')
Attempt # 4
There was also an assumption that the building in which the post office is located has the same index as the department itself, but this turned out to be wrong, for example, Post Office No. 39 in Prokopyevsk has an index of 653033. In addition, API 2Gis does not allow in
the search criteria of organizations indicate the zip code of the building.
Buns and improvements.
Auto update.
Given the frequency of updates of the reference directory, there is a desire to add the auto-update function of the index database.
Interface.
When the plug-in was conceived, there was a desire to embed its functionality as much as possible into the existing interface, that is, to make the building index in the building information card a hyperlink initiating a search:
However, the staff API does not provide for such a possibility, but a workaround was found with the substitution of the controller for this tab (implemented in the first version of the plugin):
class CustomMainController : IMapInfoController, IControlAppearance, IObjectCustomization { private IMapInfoController _innerController; private IBaseViewThread _pBaseView; private string _currentCity; public CustomMainController(IBaseViewThread pBaseView) { _innerController = ((GrymCore.IMapInfoControllers2)pBaseView.Frame.Map.MapInfoControllers).FindMapInfoController("Grym.MapInfo.Default"); _pBaseView = pBaseView; _currentCity=_pBaseView.BaseReference.Name; ((GrymCore.IMapInfoControllers2)pBaseView.Frame.Map.MapInfoControllers).RemoveController(_innerController); ((GrymCore.IMapInfoControllers2)pBaseView.Frame.Map.MapInfoControllers).AddController(this); PostalInformationServiceManager.Instance.BaseViewThread = _pBaseView; } public bool Check(IFeature f) { return _innerController.Check(f); } ... }
However, this implementation has some problems: the information tab moves to the end of the list and failures occur while simultaneously running several copies of a directory for different cities), so for now the idea was abandoned in favor of a regular customizer mechanism that allows adding custom links to the card footer.
Conclusion
At this stage, the primary tasks of writing a plugin (to solve an interesting puzzle, learn something new, remember c #) seem to be done. In addition, there was an idea of another plug-in that extends the functionality of the "Works Now" filter. Therefore, we must decide what to do next. In this I would like to listen to the opinion of the community - suddenly someone will be interested in this development or there will be interesting ideas for its development.
Download:
Normal plugin version
The version of the plug-in replaces the index of the building on the link (carefully, the version is unstable and can lead to a 2Gis shell fall).