Є кілька можливих варіантів:
- Без мультиполігона. Три будівлі з однаковими теґами
addr:housenumber=1але з різнимиaddr:unit=корпус 1,addr:unit=корпус 2,addr:unit=корпус 3. - З мультиполігоном. Один «основний» обʼєкт з теґом
addr:housenumber=1, три «підпорядковані» з різнимиaddr:unit=корпус 1,addr:unit=корпус 2,addr:unit=корпус 3 - Теґ
addr:housenumberна полігон який позначає територію організації, різні теґиaddr:unit=*на різні корпуси.
У першому варіанті основний недолік — дублювання однакових теґів addr:housenumber на трьох будівлях. На це скаржаться валідатори в редакторах і, мабуть, не всі рушії пошуку вміють вирішити такий конфлікт. Проблему повинні вирішувати розробники написанням алгоритму який крім addr:housenumber враховує також різні теґи addr:unit.
У другому варіанті основний недолік — «зайвий» мультиполігон, четверта будівля якої не існує. Невелика перевага — немає проблем з валідаторами бо не дублюється теґ addr:housenumber, працює принцип вкладеності при визначенні адреси.
Третій варіант підходить для організацій де корпуси розташовані на якійсь одній земельній ділянці. Як і в другому випадку також працює принцип вкладеності при визначенні адреси. Недолік — у додатку до Порядку чітко написано що адреса не присвоюється земельним ділянкам. Також підхід не працює для, наприклад, житлових будівель які мають один номер і різне позначення корпусів, але за якими немає організації якій підпорядкована територія. Простіше — немає полігону з name=*, amenity=* на який можна було б «повісити» addr:housenubmer.
Всі три варіанти мають якісь свої недоліки й переваги. Мені більше до вподоби перший.