Самый лучший способ определить, пользуется ли кто-то вашими сервисами – взять и отключить эти сервисы. Сразу после этого можно производить экспресс-оценку того, нужны ли вы кому-нибудь.
Те, кто пользовались нашими выгрузками данных OSM в формат Shape и собранными проектами на базе QGIS возможно обратили внимание, что примерно треть данных не открывается.
?стория как мы улучшали PostGIS (точнее pgsql2shp).
Началось все с того, что для автоматического создания POLY-файлов потребовалось использование функции ST_Split, которая как сказано в документации доступна в PostGIS версии 2.0.0. Так как на сервере был установлен PostGIS 1.5, то было принято решение обновиться из SVN. Проблемы вылезли сразу же и связаны они были с тем, что вместе с PostGIS был автоматически обновлен и конвертер данных PostGIS в Shapefile pgsql2shp. При любой попытке его использования выдавалось сообщение «column “gid” does not exist», о чем было сообщено разработчикам. Реакция была незамедлительной и в тот же день баг был устранен, после чего на первый взгляд pgsql2shp заработал как положено.
Однако, при следующей выгрузке вылезла еще одна особенность нового pgsql2shp – при выгрузке данных из пустой таблицы (например, когда заданным условиям не соответствует ни один геометрический объект) создавался .dbf файл (как и раньше), но при этом его размер был всегда разный. В старой же версии pgsql2shp этот размер был всегда одинаков, что и использовалось в качестве проверки в скрипте выгрузки. Снова обратились к разработчикам, на что получили ответ, что использовать в качестве условия размер файла – неправильно и следует вместо этого задействовать exit code. Однако, для данного случая exit code в pgsql2shp был не предусмотрен и разработчики снова не оставили на в беде – добавили и эту возможность .
Наконец последнее нововведение pgsql2shp, поломавшее наши выгрузки связано с тем, что если в таблице содержатся геометрии разных типов (а у нас именно такая ситуация), например, POLYGON и MULTIPOLYGON, POINT и MULTIPOINT, то pgsql2shp выдает ошибку, в предыдущих версиях такого не было. Попросили разработчиков добавить в pgsql2shp возможность отключения проверки геометрий, но пока ответа не последовало. Таким образом, на данный момент единственным выходом из сложившейся ситуации является применение ко всем таблицам базы функции ST_Multi, чего бы не хотелось, так как это замедляет выгрузки часа эдак на 3, либо откат до предыдущей версии pgsql2shp.
Мораль басни, наши сервисы самые лучшие будут ломаться и в будущем. Добро пожаловать.
Не ломается только у тех, кто ни чего не делает… )