Конечно, одна из основных проблем модели OSM — отсутствие типа для полигонов. В очередной блогопростыне Jochen Topf напомнил об этом, а заодно дополнил предложение типа данных небольшим комментарием про его использование:

Определим «area» аналогично объектам «way»: список ссылок на точки и набор тегов. Первая и последняя точка в списке должны совпадать. Как будет выглядеть API для редактирования подобных объектов? Пользователь отправляет запрос с bbox для редактирования. Чтобы работать с запрошенной областью, нам нужны все точки внутри этого прямоугольника, плюс как минимум по одной дополнительной точке с краёв линий. Если полигон входит целиком — хорошо, иначе потребуется знать, какая сторона внешняя, а какая внутренняя. Для этого постановим, что все точки должны быть отсортированы по часовой стрелке (можно и наоборот, но чаще сортируют так). Теперь редактор сможет нарисовать многоугольник правильно (внутри загруженной области): с учётом тегов у него будут все требуемые данные.

Далее он утверждает, что если отредактированная таким образом часть полигона корректна, то и весь полигон не поломается. «У меня нет математического доказательства, но буду рад примерам обратного». В блоге, правда, отключены комментарии: интересно, а если просто отразить весь набор точек половины полигона относительно перпендикуляра к границе загруженной области?