О постановке на кадастровый учет зон подтопления

Занятный момент обнаружился: оказывается, если какая-либо граница зоны подтопления пересекает урез реки, то при попытке поставить такую границу на кадастровый учет придет отлуп, т.к. с точки зрения валидатора такого не может быть.
Таким образом, типичный в общем-то случай, когда при глинистом ложе реки наблюдается слабая связь между уровнем грунтовых и поверхностных вод (а то и вовсе отрыв уровней и режим «дождевания»), оказывается «вне закона». Фактически приходится фальсифицировать расчетные зоны подтопления для прохождения валидации кадастровой службы.

Вакансия полевого гидрогеолога

В последнее время все чаще возникает необходимость в проведении серьезных гидрогеологических работ в различных отдаленных краях страны. К сожалению, в настоящий момент (и в ближайшем будущем) у меня нет возможности уезжать от цивилизации на длительное время. Та же ситуация у большинства знакомых коллег — дети, работа и вот это всё здорово приклеивают к месту.

Обращаюсь к уважаемым читателям блога, если у вас есть желание, возможность и достаточно квалификации для работы в качестве полевого гидрогеолога, то напишите мне на water+blog@alick.ru.

Работа предстоит тяжелая, но интересная в суровых, но красивых местах: Чукотка, Норильск, Приморье, Камчатка и др. Задачи обычно довольно стандартные: проведение опытно-фильтрационных работ с целью оценки водопритоков в подземные выработки и поиска месторождений подземных вод.

Жду ваши резюме на почте.

ОФР и моделирование

Даже среди умудренных сединами гидрогеологов довольно популярно мнение, что все эти ваши откачки совершенно не нужны при создании модели. Типа все подберем при калибровке. Накидаем «от фонаря» граничных условий (особенно тех, которые 4 рода, т.е. границ с разными фильтрационными характеристиками) и получим идеальный «диагональный график».
Должен заметить, этот подход возник не сам собой и не от хорошей жизни. Когда изыскатели 90% откачек просто рисуют (о художественной ценности этих «произведений» поговорим как-нибудь потом) — тут уж действительно, уж лучше бы их действительно и вовсе не было. Более того, из оставшихся 10%: 5 — проведены или обработаны неграмотно, а 4 — просто неудачные в силу разных обстоятельств. Так и остается 1% нормально проведенных удачных откачек с правильной обработкой. Маловато, прямо скажем. А еще бы с лупой присмотреться на эти откачки, так и вовсе окажется, что они такие удачные потому, что их «рисовал» не инженер-камеральщик, а более или менее грамотный гидрогеолог.
Вот так и получается, что не нужны откачки при моделировании — только проблем лишних создают, т.к. вынуждают потом отдельно объяснять почему принятые при моделировании параметры не совпадают с данными ОФР. И ведь не скажешь, что «ввиду очевидной фиктивности исходных данных, внимание мы на них обращать не будем», как бы этого ни хотелось.
Совсем другое дело, когда и ОФР и моделирование делает один и тот же специалист-гидрогеолог. Тут даже неудачный опыт может дать толику информации. Правда, далеко не все моделисты хорошо разбираются в откачках (чего греха таить, я и сам такой), но уж хотя бы пусть посмотрят. Поэтому я никогда не отказываюсь от приглашения поприсутствовать на реально проводимых заказчиком ОФР.

Уже ничего не стесняются

Совсем народ стыд и совесть потерял. Ребята вообще не палятся.

Крупнейший оползень в Боливии

Учитесь программировать

На днях привалило мне «счастье» - 100 с гаком гигабайтов базы данных. Очень важных и очень интересных. Однако сразу всплыло несколько "но":

1. База создана в Borland Interbase 7.5.
2. Сами важные данные хранятся в виде BLOB-записей в графическом формате.

Сначала пришлось изрядно повозиться только для того, чтоб просто открыть базу, т.к. общедоступный Firebird этого формата не понимает. Потом выяснилось, что ни одна из популярных программ для работы с базами Interbase не умеет в пакетном режиме выуживать из оттуда BLOB-записи и сохранять их в виде файлов. Задача еще усложнялась тем, что мало выудить файл, надо еще его сохранить под правильным именем, которое хранится в отдельном столбце в таблице.
Делать нечего, пришлось экспортировать базу в формат SQLite. В принципе, на этом можно было бы и остановиться, SQLite вполне себе общеупотребимый и удобный формат, но опять проблемы:

1. BLOB-записи из Interbase почему-то сконвертировались в HEX-строки SQLite (хотя тоже в формате BLOB). Т.е. из бинарного вида они превратились в ASCII: "04В458A4C1...". Т.е. напрямую с этими данными работать не получится — придется извлекать, конвертировать в бинарный вид и уже после этого открывать в графическом редакторе. Либо, как вариант, можно пройтись по базе и перекодировать данные.
2. Сама идея хранить файлы в базе данных мне кажется сугубо порочной. Для файлов уже создана отличная база данных и называется она — файловая система.
3. Программы, которые я подобрал для извлечения BLOB-записей из SQLite, отлично работают на маленьких базах, но на больших либо денег просят, либо падают от недостатка памяти при экспорте >1000-й строки (а всего там их около 80 тысяч), а часто и то и другое.

Помог скрипт sqlite-blob-dumper.py. Пришлось его немного модифицировать (о слава тем далеким годам, когда я занимался программированием), чтобы имена экспортируемых файлов брались из базы, а не генерировались на основе номера строки, названия базы и столбца с данными и все заработало. Причем довольно быстро и без проблем с памятью.
Скрипт уже выгрузил 80% базы, когда я понял, что могу сэкономить еще одну итерацию: ведь файлы сохранялись все в том же HEX-виде и для перекодирования в бинарный вид я собирался использовать отдельную программу xxd.exe — хорошую, но медленную под Windows. Тормознул скрипт, модифицировал, добавив в него функцию перекодирования. Теперь файлы сразу сохраняются в нужном бинарном виде — существенная экономия времени и дискового пространства.

P.S.: Для особо прозорливых, кто догадался, что это за база: извините, не моё — не дам.

Халтурщики

Есть у меня один «любимый» заказчик, который из серии — «за копейку канарейку, чтоб басом пела». Ну очень любят на всем экономить. Сначала сэкономили на выборе участка строительства — строят в пойме реки. Потом сэкономили на изысканиях — выбрали таких изыскателей, что не особо утруждаясь нарисовали все без бурения «как попросили» проектировщики. На проект, думаю, тоже денег не много ушло — изыскания то были рисованы под самые простые проектные решения. Насчет строительства я не особо в курсе, но думаю, что и в этом они были верны себе.
Что в результате:

1. Дороги, отсыпанные местным грунтом, не держат строительную технику — грузовики уходят под грунт по самую крышу.
2. Уже построенные корпуса покосились через полгода после окончания строительства.
3. Строят рядом два новых здания: одно с осушением котлована иглофильтрами, другое со «стеной в грунте» из бетона. И тут беда: почему-то бетона на заливку буросекущих свай «стены в грунте» уходит на треть больше. Причем они скорее поверят в барабашку, который ворует под землей бетон, чем в суффозию.

И это они еще через экватор строительства не перевалили. А кто-то еще потом в этих домах квартиры купит. Бр-р.

Зоны подтопления

В последнее время ко мне в почту часто приходят вопросы по поводу федеральной программы по определению зон затопления и подтопления. В крайне невнятном ТЗ от государственного заказчика часто прямым текстом бывает указано, что зоны подтопления определяются на основе архивных данных изысканий. Исполнитель несет отчет в экспертизу и получает логичное замечание о необходимости проведения режимных наблюдений. В особо тяжелых случаях требуют годовой ряд наблюдений, хотя формально можно ограничиться периодом проявления процесса (СП 11-105-97).
В принципе, зоны подтопления можно нарисовать и вовсе без режимных наблюдений — основываясь на параметрах, полученных при откачках. Для этого есть формулы Каменского и Форхгеймера, а можно и вовсе модель сделать. Однако, именно режимные наблюдения есть прямой метод по изучению процесса подтопления и поэтому крайне желательно применять именно их.