Боже, как я устал отбиваться от вопросов: «а какую нейросеть вы используете?».

Я работаю в лаборатории «Интеллектуальные технологии городского планирования» Университета ИТМО, и мой основной профиль — различные аспекты процедурной генерации в урбанистике. Мы делаем алгоритмы, способные проектировать самостоятельно или помогать проектировать живым людям разные штуки — парки, пешеходные дорожки, районы жилой застройки. Там, где у мясных мешков уходят месяцы на рисование генеральных планов в автокаде, наш алгоритм может сгенерировать результат за минуты окей, это наш рекламный слоган, в реальности все сложнее, но так тоже иногда получается.

И все, буквально все задают нам вопрос про то, какую нейросеть мы используем для генерации.

Никакую, блин! Нет у нас нейросетей. Шок! Сенсация!

На самом деле это очень больной вопрос. ИИ технологии сейчас захайпаны так, что бизнес готов к себе тащить что угодно, лишь бы поставить значок «содержит ИИ» на свой товар. Но вот представление о сфере у этого бизнеса зачастую очень примитивное. ИИ = нейросеть, и все тут.

Масла в огонь еще подливают студенты и разные исследователи‑дилетанты. Обычно это люди с программистским бэкграундом, но без опыта в урбанистике и городском планировании. Они привыкли любую проблему решать в духе: «ща быстренько данных в ML модельку накидаем и она нам всё сделает». И каждый раз объяснять им, почему в урбанистике у них вряд ли из этого выйдет что‑то практически применимое, поднадоело. Так что я решил описать ключевые проблемы тут, на Хабре.

Итак, почему же не удается (и не удастся в обозримом будущем) засунуть в какую‑нибудь ИИ‑ML‑DeepLerning‑%еще N хайповых слов%‑модель карты и проекты существующей застройки и заставить ее сгенерировать вам хоть новый квартал, хоть новый город?

Иногда в жизни программиста возникают интересные задачи. Например, как перенести полученную ML модель, созданную в Python, на Android смартфон. Потому что этот самый смартфон пристегнут к параплану, висящему в километре над землей, а модель должна помогать пилоту лучше искать восходящие потоки.

Интернета в полете при этом обычно нет, так что вариант с доступом к удаленному Python-серверу по API отпадает. Ноутбук с запущенным Jupyter с собой тоже не возьмешь.

На помощь приходит промежуточный формат ONNX, созданный для обмена ML моделями между разными системами. Под катом описание того, как сконвертировать модель в этот формат и как загрузить и использовать ее в Android приложении.

Довелось мне обучать одного знакомого, желающего войти в ИТ (привет, Саша!). Человек он упорный, прошел разные курсы, стажировки, упорно продолжает идти вперед и уже вполне тянет на уровень джуна и решает прикладные задачи. Но иногда внезапно задает такие вопросы, из которых я понимаю, что у него огромные дыры в базовых знаниях и представлениях. На курсах этому, видимо, не учат.

Один из последних вопросов был про устройство сборки, непонимание того как исходный код собирается в исполняемый и запускается. Начинающим обычно говорят в духе «вот создаешь Gradle‑проект, в IDE жмешь кнопочку запуска и все работает». Но как только возникает необходимость что‑то в этом простом процессе усложнить, или понять — начинаются проблемы.

Gradle/Maven при этом представляются таким черным ящиком, в котором есть кнопка сборки и запуска, а внутри — магия, превращающая исходный код в запущенную программу.

В этой статье я пробегусь по основам того, как в Java работает компиляция, а также покажу, как по шагам прийти от компиляции отдельных файлов вручную к идее необходимости системы сборки, и как написать свою простенькую систему. Ведь лучший способ понять, как что‑то устроено внутри — сделать это самому.

На Хабре время от времени появляются статьи про различные веб-сервисы и приложения, так или иначе анализирующие городскую среду. Такие сервисы, по задумке авторов, должны помогать жителям принимать какие-то решения - куда пойти, где купить жилье, где комфортнее жить и гулять.

Однако раз за разом авторы сталкиваются с одними и теми же проблемами: где взять исходные данные для своих моделей. В комментариях пользователи постоянно просят одни и те же нереализуемые фичи (например, информацию по социальной инфраструктуре) и предлагают одни и те же неработающие или имеющие множество подводных камней решения (типа кравлинга соцсетей или вытаскивания несуществующей информации из OSM).

В этой статье я постарался сделать обзор тех данных, которые можно использовать в урбанистически-айтишных сервисах в России. Что с их помощью можно сделать, что - нельзя, какие там есть подводные камни и типичные проблемы. Надеюсь, этот текст поможет как будущим авторам таких сервисов (чтобы не тратить время на то, что сделать не получится), так и для их пользователей (чтобы понимать, почему эти сервисы работают именно так, как работают, и не могут работать лучше).

Мы тут в ИТМО занимаемся созданием всяких ГИС на заказ. И вот пришел к нам заказчик и попросил сделать демку, умеющую генерировать и отображать различные градостроительные планы и схемы и делать по ним кое-какую аналитику.

И все бы ничего - взяли стандартные средства для работы с изображениями, отрендерили в текстуру по шаблону сгенерированный текст, пунктирчиком разметили границы участков и показали пользователю в браузере. Но тут всплыла такая штука как ЗОУИТ - Зоны с особыми условиями использования территории. Это могут быть всякие зоны защиты инженерных сетей, водоохранные зоны и т.п.

И вот тут-то началась засада. У каждого ЗОУИТа есть свой стиль для отображения, описанный в 10 приказе Минэкономразвития (вообще порадовало, что оказывается есть цельный отдельный приказ, где прописано все в деталях, от RGB цветов линий до названий и значений полей с данными). И стили эти все достаточно непростые.

Если простую линию или пунктир нарисовать через стандартные механизмы AWT просто, для этого есть класс BasicStroke, то вот рисовать что-то такое этакое, с галочками, крестиками и прочими закорючками в разрывах или вдоль линии, из коробки в джаве не получится. При этом документация и примеры в сети довольно скудные - везде обычно пишут, как нарисовать пунктир тем же стандартным BasicStroke и на этом успокаиваются. А что делать с более сложными видами линий - нигде не сказано. Пришлось осваивать это самому.

Под катом - описание того, как сделать свой собственный Stroke, позволяющий рисовать произвольные шейпы вдоль контура фигуры.

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

Вот только процесс работы с ними в какой-то момент начал меня утомлять. Чтобы вытащить данные по какому-то нетривиальному запросу, нужно или изучать язык запросов Overpass, или писать скрипты и ковыряться в OSM XML формате.

Проделывая эти манипуляции в сотый раз, я задумался о создании какого-нибудь более простого и удобного инструмента. И вот он готов — https://yourmaps.io, визуальный редактор описаний экспорта OpenStreetMap. В редакторе можно мышкой натыкать граф, каждый узел которого будет представлять операцию или фильтр над потоком OSM объектов, а затем скачать результат в GeoJSON.

Вот пример графа, который выбирает все школы в границах заданного муниципального округа, и затем строит 300-метровые буферы вокруг них:

В результате работы получим вот такой набор полигонов в GeoJSON формате, которые затем можно импортировать в QGIS или еще какой-либо софт.

Под катом — немного про функционал сервиса, а также мой опыт работы с библиотекой Rete.js, которая позволяет легко вставлять визуальное программирование и редактирование графов в свой веб-проект.

От переводчика: в ходе моей работы в нигерийском финтехе пришлось мне создавать с нуля одну платежную систему. Я тогда ничего толком не понимал в вопросах бухгалтерии, в том как именно лучше хранить платежи и балансы. Но было подозрение, что примитивный вариант с одной циферкой баланса в аккаунте пользователя слишком прост, чтобы быть правильным.

Разобраться и избежать кучи граблей в этом деле мне помогла данная статья. При этом информации по теме "как сделать свою платежную систему" довольно мало, а в учебниках по бухучету программисту сходу разобраться не так просто (и очень нудно). Надеюсь, этот материал окажется полезным тем, кто только собирается что-то такое делать.

Сразу извиняюсь за возможные неточности в русскоязычных финансовых терминах — я все-таки программист, а не бухгалтер, и с русской терминологией в этой сфере недостаточно знаком.

Введение

Многие компьютерные системы, использующие реляционные БД, хранят в них какую-то финансовую информацию о балансах и транзакциях. При этом при проектировании и разработке такой БД часто встает вопрос, а как именно хранить эту информацию. Обычно выбор стоит между дешевой "простой записью" и более сложной "двойной записью".

Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи

В системе с "простой записью" числовые значения записываются только один раз. В системе с "двойной записью" каждое значение записывается дважды, как кредит (положительное значение) и как дебет (отрицательное значение). При этом есть набор правил, определяющих связь между этими значениями. Эти правила вам легко опишет любой опытный бухгалтер, хотя он может и не представлять, как именно они могут быть представлены в реляционной БД.

Основные правила таковы:

В прошлой статье я описал алгоритм, позволяющий строить более интересные (в противовес более коротким, как делают всякие яндексы-гуглы) пешеходные маршруты между двумя точками. Алгоритм загружал достопримечательности, парки и прочие приятные и интересные для пешеходов объекты из Open Street Map и прокладывал маршрут через них. В итоге путь мог оказаться на 10-20% длиннее, но гораздо живописнее и интереснее.

Фото города — Alex 'Florstein' Fedorov

В комментариях многие написали, что кроме маршрутов между двумя точками им интересно было бы строить круговые маршруты, которые бы начинались и заканчивались в одной и той же точке и укладывались в заданный лимит времени. Например, если у вас есть два часа до поезда или до встречи с друзьями, съездить куда-то далеко вы за это время не успеете, а вот погулять и посмотреть красоты поблизости вполне можно.

После некоторого количества экспериментов я сочинил генетический алгоритм, который строит достаточно неплохие (для меня) маршруты в такой ситуации. Под катом описание принципа работы и несколько примеров.

У большинства обитателей рунета слово "урбанистика" если с чем и ассоциируется, то наверное только с известным кудрявым блоггером. А еще с ненавистью к автомобилистам и борьбой с многоэтажками. В последнее время эта тема стала набирать популярность, и вот уже появилось множество людей, которые уверены что познали суть урбанистики, почитав пару популярных блогов.

Однако на деле урбанистика — это наука, причем наука довольно интересная и междисциплинарная, содержащая внутри себя множество различных направлений. Сейчас очень много сил вкладывается во всякие Smart City и в попытки сделать городское проектирование и управление прозрачнее, проще и технологичнее. Поэтому в последние десятилетия важнейшую роль в урбанистике начали играть информационные технологии, именно благодаря ним стали доступны новые виды исследований, новые технологии сбора данных и новые возможности проектирования.

В этом году исполнилось 30 лет международной конференции CUPUM — Computers in Urban Planning and Urban Management. Конференция эта проходит раз в два года, является A-rank по классификации Core, и в этом году она собрала исследователей городского проектирования в Китае, в городе Ухань. Туда я и поехал представлять свой родной университет ИТМО и входящий в его состав Институт дизайна и урбанистики. Рассказывал я там про развитие своих исследований пешеходного моделирования, которые когда-то начались с этой статьи на Хабре.

Под катом выдержки из показавшихся мне интересными докладов на урбанистическо-айтишную тематику, некая попытка анализа трендов ну и немного фоточек Китая, куда уж без них.

Не кажется ли вам, что наши чиновники несколько оторваны от реальности? Что недостаточно смотреть на подконтрольную территорию исключительно из окна кабинета в центре города? Что городскому главе неплохо бы время от времени гулять по городу лично, общаться с людьми и отвечать на вопросы в режиме живого общения?

Вот и известному блоггеру Илье Варламову тоже так показалось, поэтому он запустил крутейший проект c вызывающим названием БДСМ, а имеенно "Большая Дорога С Мэром" (ссылка на анонс):

Хватит гулять по российским городам в одиночестве – пора приглашать мэров, губернаторов, сити-менеджеров.

Правила просты.

Компьютер случайным образом выбирает два адреса в вашем городе. После этого мы отправляемся на прогулку от одного адреса к другому. Условие одно: нельзя пользоваться автомобилем. Только ноги, велосипед, общественный транспорт, самокат, собачья упряжка. Никакой подготовки, никаких согласований маршрута. Иногда прогулки будут длинные, через весь город, иногда придётся пройти всего несколько кварталов по центру. Это главное условие: без показухи, без подготовки.

В процессе прогулки мы вместе с главой города изучаем инфраструктуру, общаемся с жителями. У чиновника будет уникальная возможность рассказать на всю Россию про свой город, объяснить тонкости городского управления, стать ближе к народу!

Кадр из первого видео проекта, с участием моего сервиса для выбора случайных точек

При чем тут Хабр, спросите вы? А все дело во фразе про случайный выбор адреса начала и конца маршрута. Не такая это простая задача, если вы не хотите в итоге очутиться в дебрях какой-нибудь промзоны или заблудиться среди бесконечных заборов частного сектора. Простое тыканье в карту с завязанными глазами тут не сработает!

О том, как я эту задачу решал и какие открытия преподнесли мне такие города как Иваново или Киров — под катом.

Можно долго спорить на тему, стоит ли давать маленьким детям доступ к планшетам и смартфонам. Кто-то говорит что это вредно для глаз или для психики, кто-то — что родителям надо бы самим играть и читать с детьми, а не пытаться отгородится от них гаджетами. Что характерно, чаще всего такое говорят люди, у которых своих детей нет. И которые не знают, какое это блаженство — когда чадо замолкает хотя бы на полчаса, перестает крушить все вокруг, спокойненько лежит на диване и смотрит мультики. Есть и еще один аргумент — дети чутко все повторяют за родителями, если родители непрерывно сидят уткнувшись в телефон, то очень сложно объяснить детям, почему родителям можно, а им — нет.

В общем можете закидывать меня тухлыми помидорами, но мой сын, которому сейчас без пары дней три года, время от времени лежит с планшетом на диване и смотрит мульики на ютубе.

К сожалению, я очень быстро уяснил, что детский ютуб — это просто АДОВЫЙ ТРЕШ. Про это даже на Хабре уже был перевод статьи. Детские каналы — это какие-то бездонные клоаки, наполненные вырвиглазными видео типа "разворачиваем сто киндер-сюрпризов", "дурацкие стишки с убогой 3д графикой под крикливую музыку" и "гоняем машинки в Beam NG под дурацкие комментарии". По какой-то причине все это является очень привлекательным для маленьких детей, которые бросаются кликать на такие видео как только увидят их в рекомендованных. А YouTube не позволяет управлять рекомендациями. Даже дав своему сыну планшет с включенными "нормальными" мультиками, я уже через пару минут наблюдаю, как он за два клика по рекомендациям опять находит эти чертовы шоколадные яйца и снова начинает в них залипать.

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