Но сегодня, при работе с населенными пунктами и маршрутами пришло в голову протестить совсем нетипичный для меня Симферополь. Название этого населенного пункта, признаюсь, постоянно напрягает меня орфографией.  Не страдаю безграмотностью, но реально этот продукт греческого языка не уживается в голове.. Все время Симфи, хочется написать , а он то Симферополь. Короче, бесит… необходимость самоконтроля. Бывает…

Но не обо мне речь, а о Гугле, и не о двойственности подхода к ситуации в Украине, как было бы еще ожидаемо, а о решении разработчиков  в стиле «а хер его знает!». В принципе, для неразработчиков поясню, что все запросы и к картам и к сервисам выполяются с локалью, в моем случае это всегда «uk-UA». У Гугла это специфично разбито на два отдельных параметра: язык и регион (language=uk&region=ua), но сути это не меняет. Такой подход позволяет сервисам глобальных компаний отдавать результаты на языке (и часто с учетом политической ситуации вокруг административного деления) клиента. Ожидаемо, чтобы для локали «uk-UA», ответ геокодера был согласно адмінустрою України.

Я уже находил своеоборазные «баги» в OpenStreetMaps в стиле — и вашим, и нашим, когда на разных масштабах Крым то настоящий АР Крим, то фейковый пидорашеский. Но Опенстрит то пока еще не Гугл…

А Гугл  вообще просто викинул все компоненты адреса с административным делением для Симферополя!

Для сравнения, привожу ниже выдачу всех компонент административного устройства для областного центра Донецкой области Украины.

Как видите, Гугл в неопределенности… А значит нужно ему помочь. Механизм жалоб на ошибки на картах уже описан ранее в статье.

Гугл, сука, чей Крым?

нашлось вот случайно…

Нет, речь пойдет не о север-юг, как могло показаться из заглавия. На самом деле очередной картографический ляп это как раз проблема lost in translation, в этом конкретном случае не совсем ясно кто это написал: сам клиент при регистрации своего бизнеса на карте или картслужба гугла (роботы такие роботы!) сделала такую безграмотную транслитерацию.

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

з.ы. а может  все-таки это на самом деле небанальный такой BDSM -клуб для поклонников Буратино? Дубовый гей… Концептуально!

:-)))

Если отбросить незлобный троллинг и внести научно-нормативную составляющую в этот нехитрый пост, то объект на карте должен был быть транслитерирован таким образом: Dubovyi Hai

согласно стандарту (всегда проверить географическую транслитерацию можно по ссылке):

Прийнятий Українською комісією з питань правничої термінології (УКППТ) у 1996 році. В міжнародній практиці застосовується для транслітерації українських назв географічних об’єктів — у вжитку в ООН. Єдиний стандарт транслітерації, що (у спрощеному варіанті) передбачає спрощення подвоєння деяких приголосних (наприклад, Zaporizhzhia → Zaporizhia)

Транслітерація є односторонньою: багато українських слів записуються цим стандартом однаково (наприклад, «дій» і «дії»). У точному варіанті, м’який знак та апостроф записуються апострофом. У спрощеному — апостроф не відтворюється, але вживається для запису м’якого знаку у деяких позиціях.

в одной из предыдущих статей я описал методику проверки изменений внутри одной сети АЗС на основе наборов данных разных лет. Немного ранее я произвел обновление своих данных сетей АЗС OKKO, WOG и, наконец,Shell  на основании публичных бренд-сайтов. И вот теперь, пришло время произвести анализ между сетями. Формально повод такой: при обновлении последней из сетей (Shell) я столкнулся с таким понятем как «АЗС-Партнер». Таким обобщенным именем в файле  Shell network in Ukraine.kml  были названы другие noname станции, входящие в программу ShellCard. Но что же это за станции?

Кроме этого, есть насущная необходимость устранить дублирование, ведь я же не хочу чтобы в одной геграфической точке находились и известные сетевые и noname станции. Итак, назревает очередное «ухо» JOIN с пространственным пересечением.

На этот раз слева в JOIN  у нас новоприбывшие Shell (включая АЗС-Партнер) из общего файла Shell network in Ukraine.kml а справа все стании, которые вообще у меня есть (существенная часть в них это актуализированные в 2016).

Невероятно!161 шт. пространственных пересечений — в колонке bname наблюдается устойчивая тенденция — подавляющее большинство захватов «чужих» станций происходит по сети WOG. Нет, это не случайный захват близко расположенных соседей, не может он быть таким массовым. Получается что почти все из только что добавленных 155 шт. АЗС-Партнер, уже существуют в моей БД АЗС Украины под другими, оригинальными именами!

Ради эксперимента, играемся с радиусом захвата и снижаем его до минимально приемлемого (70м). В ответе по прежнему устойчивое количество 133 шт. пересечений Shell-овских АЗС-Партнеров и WOG-ов.  Чтобы совершенно сомнения развеять, обратите внимание на  то, что адреса в левой и правой части JOIN тождественны (они не идентичны синтаксически, потому как это данные полученые из разных источников разных сетей, но семантически одинаковы!) Добавляю критерий фильтра по «ОККО» и «WOG» чтобы вычислить тенденцию партнерства в чистом виде.

Вот и открытие, своего рода бизнес-анализ :-),  сделанный исключительно путем географического анализа: В сетях WOG и ОККО принимают карточки ShellCard.

примечание: Я сейчас не работаю в компании трейдере в тематике близкой к АЗС, поэтому не слежу и не знаю про какие-либо корпоративые решения, слияния, поглощения или партнерство. Даже новостей не анализирую на эти темы. Поэтому мой вывод, возможно покажется специалистам по торговле нефтепродуктами, немного незрелым или неполным или даже несущественым. Но цель статей по геоинформатике в моем блоге вовсе не создание новостийных поводов или анализ рынка, меня интересуют технологии  и прикладные приемы анализа географически распределенных объектов. Только и всего.

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

Что же касается проблемы дублирования, то решение ее простое — нужно удалить все те новоприбывшие АЗС-Партнер из  Shell-овской сети, которые при этом являются станциями сетей WOG и ОККО. Ну просто потому, что в приорите, конечно же,  данные самих сетей о своих станциях.

Сделаю это уже использовавшимся ранее приемом: выделю список ID в отдельный запрос, которым можно манипулировать в MS Access. Для этого, просто копирую результат колонки aid (это ID записи левой стороны JOIN , т.е. это Shell-овские АЗС-Партнеры ), вставляю его в Эксель, добавляю там запятую и все это копирую внутрь скобок SQL конструкции IN (…)  Далее можно как физически удалить строки, так и логически сделать их невидимыми/несущественными для алгоритмов работы с АЗС. Но это уже мое внутреннее, не имеющее отношение к процессу анализа решение.

Итак, после  нескольких подходов к актуализации данных 2016 г. ОККО,WOG и Shell, я существенно продвинулся и теперь у меня не только больше АЗС, но и актуальность данных на порядок выше, чем ранее. По-сути, БД АЗС Украины, которую я собирал в 2010-2013 полевым способом, можно выкинуть, разбираться с месивом данных значительно дороже,чем извлекать актуальные данные из бренд-сайтов сетей АЗС.

Думаю, на этом публикации про сети АЗС закончим. Если встречу интересные в технологическом плане решения, напишу о них, но пока все, что так или иначе приходится делать уже изучено и отработано. Мелкие различия несущественны…

в качестве красивой картинки напоследок — температурная карта, использующая COUNT записей при GROUP BY по самопересечениям АЗС в Киеве. Отдаленно это можно интерпретировать как распределение суперплотности АЗС, видны «бензиновые аллеи». Сделал, понравилось..:-)

ранее, при попытке обновить информацию о АЗС сети WOG в собственной пространственной БД АЗС Украины, я столкнулся с трудностями, успешно преодолел часть из них и, дабы не зацикливаться на конкретных ошибках WOG, написал часть анализа данных уже на основе сети АЗС Shell. В отдельной статье.  Тем более, что сетей АЗС в Украине много и нужно равномерно заниматься всеми (или наиболее массовыми из них). Статья про Shell была написан исключительно с методологической целью, ведь уже в середине анализа становиться понятно, что используемые данные Shell  непригодны в том виде, котором они опубликованы самой корпорацией в файлах CSV, GPX.

Пришло время грубой силы в деле обретения порядка!

Методологически, вскрытие Шелла (о! зацените каламбурчик особо не отличается от работы с данными WOGа. Дело в том, что делать бы будем почти тоже самое — искать другой источник информации на том же бренд-сайте.

Поехали! Во-первых находим карту сети ShellCard, с восторгом обнаруживаем, что там не только свои АЗС (Shell), но и АЗС-партнеры, включаем эту опцию.

Обратите внимание, карта сделана прямо в Гугл Мапс (Мои карты) и не является встроенной непосредственно в сайт бренда, напротив, она открывается по ссылке. При этом, параллельно, в сайте бренда есть свой движок с кластерной картой и системой поиска (и даже построения маршрута) но там как раз все сделано «англосаксами», и тут вдруг становится понятно, что к  множествам данных АЗС Shell и сети ShellCard используются разные подходы как по структуре данных, так и по качеству. Ранее, разбирая  сеть АЗС WOG я уже делился этим  своим давнишним открытием: если бренд-сайт в целом это забота маркетологов, то сайты партнерских программ это скорее удел юристов-экономистов. Юристы-экономисты просто вынуждены быть ближе к правде жизни и по крайне мере в списках использовать и украинский язык и правильное написание адресов объектов. Они же договора с этими субъектами заключают. Надеюсь, что не встречу тут АЗС по имени «КОКА-КОЛА»

Как и в случае с WOG-ом, именно на страницах карточных систем (в этом случае это ShellCard) наиболее полная информация, и о чудо! она написана на нормальном украинском языке.

Круто! 136 шт. собственных АЗС  Shell (тут отдельно радуемся,что количество 136 не изменилось, оно было и в прошлом экстракте данных, а значит порядка в Шелле на порядок больше чем в WOG, где ничто ни с чем не сходится) и  156 загадочных АЗС-Партнер. Понятно что АЗС-Партнер — это «собирательный образ», а не конкретная сеть.

Скачать готовый KML просто как 2 Х 2 и даже проникаешься уважением к Shell —настолько их политика в области информации отличается от тугого WOG-a.

Уже вторую серию подряд я не использую профессиональные ГИС для анализа (и обработки) данных, поэтому продолжим решать задачу подручными средствами.

задача: имеем файл Shell network in Ukraine.kml. Как на его основе выполнить апдейт реляционной географической СУБД и проанализировать изменения сети АЗС за прошедшие 3 года?

решение: сразу скажу, что решений  стопиццот  и, что точно я не буду делать, так это сравнивать их. Мне просто захотелось протегать эту статью словами jscript  и T-SQL, поэтому мое решение будет таким:

1. скачать файл Shell network in Ukraine.kml
2. открыть файл средствами jscript, провести парсинг и выдать результат (распечатать в лог) в виде строк пригодных для прямой вставки методом копи-пейст в грид реляционной СУБД. В качестве грида будет выступать вечномолодой  швейцарский нож MS Access с затянутым внутрь внешним источником данных MS SQL Server 2008R2

процесс:

Прежде чем начать программирование в стиле VBA, нужно понимать,что KML это абсолютно честный XML, следовательно его стурктура превращяется в реляционную без проблем. С другой стороны, работая в jscript, органично все-таки оперировать объектами этого языка. Благодаря библиотеке jquery.xml2json.js преобразовать XML в JSON (но фактичеки все-таки в объектную структуру) просто элементарно. Я даже не собираюсь предварительно изучать структуру KML, много лет назад мне хватило этого, а сейчас я сначала преобразую его в объект языка jscript и уже внутри буду выкапывать нужную мне информацию. Да, это действительно программа на 3 строчки (ну почти

В дебаггере Хрома (Ctrl+Shift+i) ставим точку останова в нужном месте и изучаем структуру получившегося объекта. Итак, все просто: в нем есть две папки (Folder) для собствнных и партнерских АЗС сооотвественно, а внутри каждой папки, массив объектов Placemark.

Все ясно, Placemark  — это и есть презентация на карте каждой конкретной АЗС. Осталось только выбрать какие свойства мы распечатываем для формирования итоговой строки .

Я решил,что свойство description содержит все данные которые мне нужны, нужно лишь разбить его на части. С помошью функции split(«<br>») строка значения свойсва description разбивается на массив. Далее дело техники — формируем нужную нам итоговую строку с помощью нехитрых сплитов и конкатенаций с «;» и печатаем в лог, копируем и складываем в Эксель. Два раза, меняя папки Folder(0), Folder(1).

Результаты логов сразу сохраняем в файл с раширением CSV и Эксель его открывает как родной. Осталось для колонки координат выполнить восхитительную в своей простоте функцию «Текст по столбцам»

АЗС-Партнер; Золотоніський р-н, с.Новодмитрівка, тр.Бориспіль-Дніпропетровськ; 49.701176, 31.9795

Все, результат готов:

Кстати: Ура!Ура! у Shell-а есть идентификатор! Уж не знаю насколько ему можно верить в будущем, проверим, но это радостно и поэтому я его сохранил. Думаю, в умозрительном матче Shell : WOG счет примерно  5:0 :lol

Но это все было топорное техно, а самое то интересное впереди! Как все это реально выглядит с точки зрения бизнес-анализа сети АЗС?

Stay tuned … (almost done)

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

А теперь?

Теперь, попробуем искать ошибки как бы у себя, и исправлять их, принимая во внимание, что имеется некоторая информация про АЗС актуальности  2013 г. и теперь пришла пора ее обновить сегодня 12.07.2016.  Что произошло за три года? Чтобы  не потеряться в берегах, сосредоточимся на одном бренде, тем более, что не WOG-ом единым, как говорится…

Возьмемся за Shell!

Shell весьма специфическая компания, как станет понятно ниже по тексту. Самая главная особенность  — транснациональность и всемирный охват. На бренд-сайте утверждается,что имеет самую крупную в мире сеть АЗС, более 40 тыс.(!) Единый подход и огромная БД АЗС нам наруку, к примеру, совершенно без труда нашлись полные списки АЗС Украины в формате CSV, и даже в GPX двух форматов для навигаторов, что гарантировало, казалось бы, всего лишь  3-х минутное развлечение по превращению этих данных в географические и размещение их в пространственную БД. Но, как говорится: не тут то было (или мы простых путей не ищем или их и нет в природе

Главная засада Shell -а в  том, что данные внутри таблиц транслитерированы и/или чудовищно искажены англоязычным интеллектом со словарем  Причем это адский микс из одного и другого, вот например:

KIEV CITY ST. STOLICHNOE MOTORWAY 31/1, ну  умора моторвей…в Киеве-то! KHERSONCITY  AV. SENYAVIN  51 —Херсонсити? Креативно!

VINNITSA CITY  ST. NEMIROFF MOTORWAY  W/N — это что?
KOROSTYSHEV CITY KIEV-CHOPROAD 102 KM, а это вообще непойми-что, Киев-Чоп это трасса, но склеено то с ошибкой.

Все эти роады, моторвеи, сити и совсем уж невообразимое Urban Village (это п.г.т вероятно) намешаны с искаженным названиями улиц, пропущенными буквами или наоборот, склеенными словами. И в любом порядке, и в любом регистре.

У WOG-а таких проблем не было, т.к. его корни украинские и никому  там в голову не прийдет так уродовать язык. Ну на крайний случай, применили бы транслитерацию по стандарту.

Вторая проблема, напротив,  никак не оригинальна, она точно такая же как у WOG-а  — это отсутствие каких либо бизнес-идентификаторов, позволяющих отслеживать изменения экземпляров объектов бизнеса (АЗС) из года в год. Вообще-то у Shell-а весьма оригинальный подход англосаксов — они присваивают имена, вот буквально имена, объектам АЗС.

ALEXANDROVKA,  STOLICHKA 1, \»COCA-COLA\» — это, к примеру, три АЗС с именами собственными, и такие имена имеют все станции. При этом, почему Кока-кола закавычена неясно, ведь это такая же условность как и Столичка1

Я не уверен,что это серьезный идентификатор, понятно что использовать я его не собираюсь, тем более что никогда его ранее не встречал

Смысл идентификатора eSI (electronic Shell Identity ?) мне тоже неясен, но даже если бы кто и пояснил, все равно его нет в данных 2013 года, а потому никак он не может для меня быть ключом для преобразований. И наследовать его тоже пока не хочется — он имеет непонятную структуру кода и что важнее — не покрывает все множество АЗС даже в Украине. Примерно 50% eSI в Украине пустые.

Остается одно — географический анализ, это собственно то, ради чего написана эта статья. Для разнообразия, я не буду использовать ГИС Geomedia Professional, как обычно, а воспользуюсь простешими средствами DBA и всякими офисными трюками. Такой себе аскетизм, ага

Итак,

дано: 41 шт. АЗС Shell образца 2013 г. с практически идеальными написанием адресов и географией. География, ввиду того, что станции Shell весьма примечательны, всегда выгодно расположены, скорее всего выверялась и полевым способом (я сам в этом участвовал). Но 100% гарантии нет, как и всегда.

Из списка на сайте имеем 136 шт. АЗС Shell в Украине. С такими вот жуткими адресами, но полноценной географией в колонках lat,lon.

необходимо: по возможности накатить правильные адреса из набора данных 2013 г. на набор данных 2016 года, при этом выяснить какие изменения произошли в сети АЗС.

изменения бывают:

1. новые станции. Тут все просто, по отношению к исходным этой задачи это все географически новые объекты. Семантику (адреса) к ним мы никак не получим в виде лучшем чем есть*.
2. проданные станции. АЗС Shell , которые выбыли из сети. Семантика адреса может остаться прежней, география точно останется прежней, имя станции необходимо актуализировать.
3.  ошибки. Тут момент тонкий. В начале этой статьи сказано,что теперь я как бы исправляю свои ошибки, это означает, что я априори считаю 2013 г. глючным, а 2016 истинным, но не забываем, что исследования WOG, Shell (а вне рамок этих статей я провел еще дополнительные исследования качества материала) показывают,что ошибки есть и сейчас, их много и они причудливые, поэтому принять какую-либо сторону за основу нельзя. Исправлять ошибки придется по ходу пьесы.

метода:

MS SQL Server.  Язык T-SQL с использованием пространственных функций с типами данных Geography. Будем сравнивать АЗС Shell «сами с собой» на пространственное пересечение. В принципе это классическое «ухо» JOIN, с той лишь особенностью, что критерий пространственный. Еще на разных стадиях анализа нам потребуется как прямой так и инверсный подход, но я не буду использовать строго JOIN синтаксис (хотя эта картинка полезная штука).

Итак, на картинке ниже я получаю результат пространственного соединения старого и нового набора данных. Буквально — буфер в 50 м вокруг АЗС отлавливает точки АЗС, причем для ликвидации «самоотлова» используется условие нервенства ID записей. Я думаю, это базовый прием для сравнения старого и нового в одном наборе данных (точнее при общем хранении данных, наборы данных датируются по-разному).

На картинке ниже скрипт и результат: от старого к новому слева направо, колонки попарно.

Итого получено 61 запись, причем сразу же виден побочный эффект: мы захватили и чужие станции (ОККО, БРСМ Нафта). Можно порассуждать на тему того,что это могут быть «новые» чужие на месте старых своих, но это не так, обратите внимание,что date_point 27.01.2013. Есть такая практика — строить впритык станции АЗС на высоконагруженных траффиком направлениях. Конкуренция.

Поэтому несколько улучшаем скрипт, вводя в него условие ограничивающее левую часть JOIN только старыми данными Shell (27.01.2013) и получаем такое (теперь у нас точно пересечение Shell самих с собой):

Сразу покажу стрелкой основную задачу — перенести данные из колонки с адресом старых данных adescr в аналогичную колонку новых данных bdescr (это будет видно в скрипте ниже). На самом то деле все это одна колонка descr, да и данные у нас находятся в одной таблице, просто в разных строках, поэтому  использутся псевдонимы (aliases) для того,чтобы фраза SQL UPDATE сработала верно. Далее необходимо будет оценить степень переноса данных, отработать выбывшие станции и ошибки и только после этого можно будет удалить старые данные АЗС. Ожидаемо, что новая география поглощает старую. (Однако, если бы в примере были не АЗС Shell, а качество новой географии внушало бы подозрения, просто принять выбор в сторону нового было бы неразумно).

Итак, лишь 29 записей унаследовали  старые адреса, всего же, напомню, была 41 запись в старом наборе. Что же остальные?

Проведем инверсию логики и теперь выберем тех из старого набора, кто не связался:

Ожидаемо, что их 12 шт., что в сумме с 29 связавшимися и дает исходные 41 шт. А по смыслу? По смыслу, эти записи первые кандидаты на выбывшие АЗС и ошибки.

Придется разбираться. Для начала попробуем проверить влияние географического фактора, напомню,что пересечение для JOIN строилось с буфером в 50 метров. Последовательно увеличивая до 70,100,120 метров обнаруживем,что особого влияние это не оказывает, максимальный эффект — уменьшить количество несвязавшихся с 12 до 9 шт. Я бы не рекомендовал устанавливать слишком большой буфер, потому как будет видно чуть ниже, если уж ошибка есть, то она сильно больше чем 50-70 метров. Поэтому вернемся к исходным 50 м.

Вот  на этом этапе  T-SQL, будем считать, отслужил свое и требуется взгляд  специалиста. Буду считать себя таковым — у меня хорошая память на дорожную обстановку, я изъездил Украину достаточно и фиксирую АЗС на «фотопленке» в голове уже бессознательно.

И есть же мой любимый метод! Google StreetView, поэтому помощь нам оказывать будет маленький человечек pegman 

На картинке выше классическая проблема геокодинга — «промзона» (там адреса Богатырская 1Д,1Е и огромная территория, причем по обе стороны от моста). Геокодится только Богатырская 1, причем в местоположение  по факту Богатырская 1Д (Там Глобал Фиш холодильник и адрес этот метровыми буквами на фасаде указан) У меня есть целое исследование (pdf на 50 страниц) о всяких реальных адресных проблемах, например для бизнеса развозки воды (адресных курьеров) в Киеве и пригородах, но сейчас не об этом, т.к. АЗС еще более специфический объект. Они могут быть формально приписаны к адресу, но, естественно, расположены на автодорогах, поэтому их география в 90% это именно уникальная география (lat, lon), а не продукт обратного геокодирования почтового адреса. Если где-то при рождении объекта использовался метод геокодирования, пролет будет почти 100%.

Итак, на картинке выше у нас пролет на почти 500 метров. Я специально выделил этот кейс, потому как тут сразу два резона. 1) на том месте, где я помню станцию Shell (сразу у моста) сейчас АЗС SOCAR, поэтому объект однозначно попадает в категорию выбывших и требует переименования. 2) кроме того требуется коррекция местоположения.

А вот на картинке ниже чистая ситуация — станцию Shell продали другой сети. Для БД АЗС это означает апдейт имени, но коррекция местоположения или адреса не требуется.

Чтобы работать с изменениями в удобном гриде (MS SQL Studio для этого не очень-то пригодна), сольем все проблемы в ID, и построим так называемый queue (в ГИС я бы так и сделал) — очередь для редактирования. Используем MS Access, в который таблица  БД АЗС подключена напрямую. (Через «Внешние данные», ODBC источник).

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

И он поможет! Например в этом случае (картинка ниже), где налицо уход Shell  с площадки. Остатки брендинга еще видны, но станция похоже в плачевном состоянии. Нет никакого нового бренда, поэтому просто переименуем станцию в «АЗС».

Так, худо-бедно, разбираемся со всеми в списке очереди редактирования. Ниже опять пример продажи станции Shell и полного ребрендинга.

Есть и банальные «непонятки», так например станцию по адресу г.Васильков, Тракторная ул., 13 , ID 970 я вообще не нашел. Как она оказалась в старом наборе ума не приложу, а ничего похожего сейчас ни pegman не нашел, ни новый набор данных Shell-а не содержит. Удаляем.

Вот так шаг за шагом и приводим БД АЗС в порядок. Неважно Shell это или WOG, метода сверки старого и нового в общем-то одна: географический анализ, манипуляции на уровне SQL и ручное редактирование, его то никто не отменял.

———————————————————————-

*) ПРИМЕЧАНИЕ: Статья эта написана с методологической целью, в основном для объяснения методик сравнения старого и нового в географическом анализе средствами SQL. Несмотря на то,что все эти действия я в реальности провернул, результат мне конечно же не нравится, хотя он уже работает по назначению и вполне себе является версией. Ведь осталось просто море извращенной англосаксами атрибутики АЗС Shell (в части адресов). Понятно, что я не могу удовлетворится результатом удачного переноса 29 шт (ну пусть даже всех 41 шт. старого набора данных ) в новый, который состоит как минимум из 136 записей. Как и в случае с WOG, я нашел другой способ извлечения данных, потому что точно также, как и в случае с WOG, программисты и сайтоводы это почти всегда разные люди. В публичном доступе на бренд-сайтах сетей АЗС по сути находятся разные наборы данных и согласованы ли они, это еще тот вопрос!

Stay tuned…

Описана методика извлечения географических данных бизнеса из публично доступных источников (на примере сети АЗС WOG, Украина), а также затронуты проблемы актуализации пространственных баз данных и методы их решения для случаев, когда данные изначально принадлежат не вам, непредсказуемо изменяются качественно и количественно своими авторами и необходимо предпринимать особые усилия по поддержанию консистентности БД.

Прежде чем погрузиться в техническую сторону вопроса, сразу поясню и закрою мнимую искусственность проблематики в постановке вопроса: А зачем собственно что-то хитро извлекать, когда данные публичны? Самая первая картинка статьи (см. ниже) сразу и ответит на этот вопрос. Возможно у меня давно произошла профдеформация, но лично я, когда вижу слово география, то конечно же ожидаю там увидеть координаты, тем более сейчас это давно уже не является технической проблемой. Однако сайтоводы крупного бизнеса (читай — маркетологи ) одарены альтернативно, поэтому понять умом их логику сложно. На специальной закладке ГЕОГРАФИЯ АЗК  географии как таковой и нет.

Справедливости ради, скажу, что был честный способ вообще избежать и повода к данной статье и тем более всех этих действий — я обращался к представителям WOG с просьбой опубликовать gpx и(или) xls с данными сети. Использовал, как мне казалось, единственно понятный «маркетологам» довод: чтобы было не хуже чем у других  Действительно, другая мощнейщая сеть АЗС Украины — OKKO открыто публикует Эксель-документ, примерно такого же формата как и WOG (эксели все эти я еще затрону в последующих статьях), но с настоящими географическими координатам. Что может быть проще? Я даже нашел на просторах интернета архивный файл wog.gpx указывающий на то, что когда-то такие данные были опубликованы. Давно… Но не сейчас. Далее, мне  удалось достучаться до кого-то в WOG понимающего суть вопроса, но моя просьба была отклонена, не помогло даже упоминание того как все это легко и просто у OKKO, не помогло пояснение моих профессиональных устремлений (я знимаюсь АЗС Украины с 2010 года, а в некотором смысле даже еще раньше)

Итак, что мы имеем? Имеем сайт крупнейшей в Украине сети АЗС WOG на все лады расписывающий мощь и величие этой, собственно, сети, сервисов, системы безналичного расчета, партнеров и т.д. Как и на любом сайте сетевого бизнеса сейчас, есть гугло(яндекс)-карта, но нигде не нашлось способа закачать данные в навигатор и на первый взгляд нет нигде исчерпывающего списка объектов бизнеса.

задача:  получить географические объекты (lat,lng) с текстовым описанием (адресом), именем/дескриптором и по-возможности с идентификатором. Почему «по-возможности»? Потому-что, напомню, «марекетологи» ничего вам не должны, о консистентности вашей БД они не думали и, строго говоря,  не обязаны. Их задача — чтобы на сайте была карта и какие-то плюшки сбоку от нее. Ну так, чисто для вида. Конечно, сам сайт делали программисты, поэтому не все так безнадежно, уж эти то точно без ID жить не могут, но все равно рассчитывать на то, что некий уникальный ID обнаруженный на просторах сайта: во-первых будет как таковой — нельзя, во-вторых  будет  постоянным при апдейтах — нельзя, в-третих будет бизнес-ориентированным (а не технологическим) тем более нельзя.

Я сам активно использую кластерные представления на гуглокартах, поэтому появилась надежда. Предпринял первую попытку и препарировал страницу с картой. Удача сразу идет в руки и кажется, что осталась работы всего на 15-20 минут… (Но не тут-то было!) А пока…на 227 строчке видно начало JSON представления массива данных, используемых для отрисовки кластеров АЗС WOG на карте:

var pointsJSON = ‘[{«id»:»26262″,»lat»:49.252001,»lng»:28.474383,»id_station»:»3316″},{«id»:»26249″,»lat»:49.027797,»lng»:28.045092,»id_station»:»3309″},{«id»:»26266″,»lat»:49.22523,»lng»:28.431556,»id_station»:»3315″},{«id»:»26289″,»lat»:50.368633,»lng»:25.098212,»id_station»:»1648″},{«id»:»26269″,»lat»:49.2302,»lng»:28.507201,»id_station»:»3318″},{«id»:»26253″,»lat»:49.736506,»lng»:28.680325,»id_station»:»3308″},{«id»:»26292″,»lat»:51.202652,»lng»:24.045445,»id_station»:»1634″},{«id»:»26271″,»lat»:49.230849,»lng»:28.512905,»id_station»:»3317″},…

Первое впечатление хорошее: есть какой-то явно уникальный id, есть загадочный id_station, и конечно же есть координаты. Огорчает, что нет адреса, ведь не хотелось бы заливать безымянные точки. Поэтому, продолжаем искать по сайту…

Нахожу ту саму страницу картинка которой открывает эту  статью, она формально уже не  в бренд-сайте, а в подсайте посвященном системе безналичного расчета по карточкам в сети oilcard.wog.ua/ukr/azs/. По опыту знаю, там обычно наиболее ценная, хотя и часто противоречивая информация.

Надо сказать, что бизнес WOG  простирается на несколко стран, но меня интересует только Украина, поэтому использую фильтр, выдающий в итоге страницу oilcard.wog.ua/ukr/azs/regions/100/

Попутно нахожу файл xls якобы с полным перечнем сети АЗС и партнеров. С файлом все плохо, его конечно же делали не программисты и даже уже не маркетологи. Его делали «юристы-финансисты», только этим можно пояснить тот бардак, который в нем находится. У меня коллекция подобных файлов разных лет от WOG и других сетей АЗС и прямо скажу — сделать нормальнее реляции очень трудно, зачастую невозможно, потому как все эти xls это изначально внутренние документы предприятий вынесенные наружу. А без контекста предприятия четко отследить полеты мысли авторов сложно. Это банально «додатки до договорів» т.е. печатные формы в Экселе.

Вот файл свежачок, от 23.06.2016

А вот файл от 27.01.2014, время во многом трагическое в связи с аннексией Крыма и потерей обширного бизнеса и партнеров на востоке Украины. Поначалу я попытался отфильтровать все красное, потом все «обслуговування тимчасово припинено», потом понял что «юристы-финансисты» не дружат и с грамотностью (опечатки). Если пытаться сравнивать файлы, то конечно же можно найти динамику изменений сети 2014-2016 г.г., но эту задачу я пока отложил для второй части и другой статьи. Самое главное — никакого ключа для осуществления реляции между географией и описательной частью (адреса, имена) АЗС найти не удается. Хотя очень хотелось верить, что номерочки в третьей колонке что-то да означают, но увы — они никак не линкуются с другой инофрмацией на сайте, в некоторых местах (см. картинку с файлом 2016 г. 6,12-я строки Экселя) откровенно нереляционны (не образуют ключ) Поэтому пойдем другим путем…

На странице oilcard.wog.ua/ukr/azs/regions/100/  виден неплохой перечень, как минимум содержащий визуально: имя (бренд) и адрес АЗС. По прежнему нет никакого ID и  даже порядкового номера, поэтому понять, как соотносится этот список с картой и географией или с xls-файлом склепанным «финансистами» невозможно. Но мы то знаем, что программисты не могут без ID жить, а также знаем,  что видимая информация не всегда равна исходной, поэтому…

Препарируем страницу и находим такой блок информации :

Ага, вот оно! Таблица видимая на странице  отрисована с помощью элементов <div> в каждом из которых находится ровно одна строка искомых нами данных для каждой АЗС. Внутри каждого  <div> в первом элементе находится <a> гипертекстовая ссылка, содержащая линк на страницу детализации данных по АЗС и очевидно уникальный идентификатор столь безуспешно искомый в других частях сайта, например вот так: http://oilcard.wog.ua/ukr/azs/276/280/, внутри ссылки есть два элемента <span> в первом из которых хранится имя(бренд), а во втором адрес.

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

На общей странице сайта oilcard.wog.ua/ukr/azs/ есть другая карта «Географія АЗК» и препарируя страницу видим все тот же (а тот ли?) знакомый JSON что и на Карті мережі (рус. карта сети). 

Почувствуйте нюансы смысла: на верхнем бренд-сайте была «Карта сети»(вероятно только своей), а тут «География АЗК»(вероятно не только своих). Почувствовали?

Итак,

var pointsJSON = ‘[{«id»:»/ukr/azs/276/227″,»lat»:48.710544,»lng»:27.542814,»id_station»:»276″},{«id»:»/ukr/azs/276/380″,»lat»:48.374030,»lng»:29.509302,»id_station»:»276″},{«id»:»/ukr/azs/276/23″,»lat»:49.027798,»lng»:28.044747,»id_station»:»276″},{«id»:»/ukr/azs/276/155″,»lat»:49.736328,»lng»:28,»id_station»:»276″},{«id»:»/ukr/azs/276/13″,»lat»:49.239756,»lng»:28.39973,»id_station»:»276″},{«id»:»/ukr/azs/276/399″,»lat»:49.222664,»lng»:28.552149,»id_station»:»276″},…

структурно он такой же как и в «Карте сети», но совершенно другой по содержанию параметров id и id_station, очевидно что это технологический трюк программистов, теперь в id  хранится относительный путь на страницу детализации (и очевидно, это сделано для обспечения реакции перехода на клик по маркеру АЗС на крате), а в  id_station вообще не пойми что (на самом деле это код эмитента пластиковой смарт-карточки, но он для нашей задачи не нужен и зачем он тут вообще, кстати, тоже мало понятно).

Теперь готова концепция решения задачи по объединеню данных географии и описательной части — нужно склеить pointsJSON и данные таблицы построенной на <div> в рамках единой собственной страницы HTML, после чего выполнить внури этой страницы jscript создающий реляцию между элементами массива географических точек и «табличных» строк по общему ключу, например id :»/ukr/azs/276/380″. Будем использовать jquery для написания простейшей программки в стиле VBA

Приступим,

1 ) два раза копи-пейст и страница готова! Вся программа с гордым названием WOG Parsing Sample App   доступна по  ссылке //jsfiddle.net/geoden/te1hp9hy/7

2 ) в программной части нужно обеспечить цикл по всем строкам «таблицы». К счастью оказалось, что она имеет от рождения (хотя ничто не мешает вам руками наделить ее чем угодно, ведь это уже ваш файл) отличительный признак class=»pr4″, поэтому цикл по всем «строкам» таблицы крайне прост:

var table = $(«.pr4»);
table.each(function(){

…

})

3 ) внутри цикла происходит поиск по ключу в массиве pointsJSON, точнее говоря — в его  представлении  jscript как массива объектов geopoints. Соответственно,  момент поиска реализован так:

var res = $.grep(geopoints, function(e){ return e.id === key; });

ну, и другая  «начинка» весь смысл которой состоит в различных конкатенациях строк с целью получить искомый результат, например, строку вида:

WOG;Жмеринський р-н, с Коростівці, вул Шевченка, 1-а, перехрестя а/д Виступовичі-Овруч-Могилів-Подільський (км 346+200м ліворуч) та Жмеринка-Чернятин-Бар(1+50м ліворуч);49.027798;28.044747

4) сначала я хотел после активации кнопки Run эффектно выбрасывать новую реляционную таблицу в страницу чуть повыше  исходной таблицы, но потому подумал, что единственным зрителем этого «эффекта» буду я сам :-), а посему надо быть скромнее:  ограничился простым логированием результата в консоль. Да и копировать из консоли проще. Открыть консоль в браузере : Ctrl+Shift+I (в Хроме) или F12 в браузере IE11.

я использую разделитель «;» для последующего удобного импорта в Эксель. В табличном представлении Экселя удобно охватить взглядом весь результат и исправить мелкие огрехи (а они бывают всегда), модифицировать апостроф (в украинской топонимике его навалом, а sql видит в нем строковый ограничитель ), там же я добавлю колонку с датой актуализации, да и вставлять в реляционную СУБД данные я буду не громоздкими sql insert, а простым копи-пейстом в один клик.

Совет: всегда смотрите на данные глазами, никогда не доверяйте только единообразию алгоритма их породившего, особено когда работаете с парсингом строк. Пригодится.

Я, например заметил ошибку программистов WOG, думаю больше никто и не знает о ней в Экселе она элементарно бросается в глаза, а попробуйте углядеть ее в исходном JSON.

во второй записи по какой-то неведомой причине произошло усечение координаты долготы до целого числа, и попытка восстановить хотят бы до 28.0 (что крайне неправдоподобно по сути) привело в нас.пункт, где никакой АЗС WOG конечно же нет. Пришлось прочитать описание адреса (вот почему он крайне важен!) и сделать интеллектуальный обратный геокодинг А кстати, я там был, на этом перекрестке, и помню это место — мотопутешествия не проходят бесследно  и огромные масивы визуальной информации закачиваются в мозг

Так-что, дарю поправочку №1:

WOG Козятинський р-н, с. Комсомольське, перехрестя а/д Кременець-Біла Церква та Житомир-Вінниця, км 243+580 49.736328 28.680265

Итак, задача практически выполнена: на белый свет извлечено 392 записи географических объектов сети АЗС WOG, они загружены в БД и начали трудится на благо моих клиентов, которые заправляются на заправках АЗС WOG.

За кадром остался один нюанс: мы то уже знаем, что «юристы-финансисты», а иже с ними и «маркетологи» как могут рулят миром и сливают программистам любой шлак для реализации. Программисты, в свою очередь, не склонны проводить анализ сверх необходимого и если за данные отвечает кто-то другой, с радостью опубликуют информацию любым доступным им способом. Но что же все-таки происходит в сети АЗС WOG? Растет она или сокращается? Почему меняются (и меняются ли) АЗС?

Спокойно, без паники — сеть АЗС WOG действительно мощнейщая, и она конечно же развивается, причем под единым брендом и вполне целеустремленно. Вообще, процессы в сетях АЗС сложны, это: слияния и поглощения сетей, ребрендинг, открытие новых площадок, «столбление» участков на будущее (в т.ч. и для перепродажи) и т.д. В 2010-11 году я работал по контракту в ТНК-БиПи как раз над созданием, верификацией и полевым исследованием БД АЗС Украины и Беларуси и не понаслышке знаю о сложностях, особенно когда даже документально нет единой БД с уникальными бизнес-идентификаторами объектов этого самого бизнеса. В свою очередь, ИТ-решения, как ни крути, всегда опираются на документную базу предприятия. Поэтому то, что выглядит как красивая кластерная карта АЗС на сайте бренда (любого, ей-богу!) на на самом деле лишь верхушка айсберга, целиком и полностью стящего на костылях и подпорках.

Поэтому, как минимум (для этой статьи и чтобы ее уж закончить поскорей), найдем еще одну лажу связки «юристов-финансистов» и программистов, хотя я склонен в этом конкретном случае повесить ее на программистов полностью. При построении реляций необходимо не забывать и о случаях НЕ построения реляций, т.н orphan records. Это только в идеальном мире все сходится, у нас же не сходится почти ничего и почти никогда (без приложения особых профессиональных усилий). В программе WOG Parsing Sample App  за распечатку таких orphan records отвечает блок закоментированный ниже строки

// orphan addresses
// console.log («key «+ key +$this +» not found»);

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

Но можно и попросту сравнить количество строк в «таблице» с адресами и географических объектов в JSON на карте, это можно сделать прямо в режиме отладки. Забавно, что т.к. никаких порядковых номеров в таблице на сайте нет и общее количество АЗС WOG нигде не рекламируется вы даже и не подозреваете об проблемах.

Вот тут открывется вся суть костылей и подпорок в айсберге красивого сайта WOG : 472 адреса в таблице против 403 геопоинтов в карте, при  392 итоговых реляциях . Это означает,что orphan records (потеряшки) имеются в обе стороны: есть адреса не имеющие географии, а также есть география не нашедшая себе адреса!  Непростительная лажа…

выборочный анализ потеряшек  вскрывает и просто баги, теперь уже соверешнно очевидные баги связываемости, вот например: http://oilcard.wog.ua/ukr/azs/276/820/ приводит с дублированию информации на странице. Именно поэтому, это все-таки прежде всего ошибка программистов.

В качестве итога, дарю поправочку №2:

66 шт. АЗС с адресами со страницы oilcard.wog.ua/ukr/azs/regions/100/ не имеют географической презентации на карте!

При том напомню: чтобы ни означало это загадочное /regions/100/  получили мы его путем выбора целой Украины в списке стран в которых работает WOG.

Особенно удивительно, что среди не имеющих географии находится 29 шт. собственных АЗС WOG!

в следующей серии углубимся в географический анализ и попытаемся исправить баги WOG-a.

Stay tuned!

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

В воде, как и в вине ( Appellation d’origine contrôlée) имеет значение место происхождения , по-сути именно оно и продается. Место — это и есть 80% маркетинга минеральной воды. Думаю, при современных технологиях замутить нужную минерализацию искусственно не составляет большого труда в любом месте. Однако ж потребитель ожидает от воды определенного происхождения  узнаваемого вкуса. Поэтому кроме химии, в этой коммерции процветает и география.

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

Я с удовольствием вчитываюсь в этикетки минеральных вод: там можно обнаружить интереснейшие вещи.
Например, рекомендую обращать внимание на место разлива и место непосредственно выдобутку, иногда вас ждут сюрпризы. Иногда прикольно купить две бутылки разной воды, добытой в одном месте, из разных скважин (разными производителями обычно), например №4 и №7 и сравнить.

Однако вернемся к героям заметки, вот они:

от уровня моря, это «снизу». На картинке же изображена глубина скважины, это как бы «сверху»

Очевидна ошибочка, и совершенно теперь непонятно с какой глубины взята вода. Непонятно? А ну-ка мы проверим…

обратим внимание, что подножье горы Шаян находится на абс.высоте 225 м (относительно моря). Где общедоступный бювет и находится.

Из этого легкого исследования с помощью Google Earth ситуация становится забавной — ошибка на этикетке имеет и такое прочтение: водичка берется из бювета Ибо глубина «от уровня моря» в этом конкретном месте Закарпатья означает  прямо у твоих ног. Ты че, считать не умеешь? (звонок друга). Какое сверху, какое снизу? Ты напутал все: если считать что глубина 250 м от моря, то от поверхности подножья г. Шаян это вообще под 500м! (225+250)

Каюсь, каяюсь, но друг таки прав! Словосочетание глубина от уровня моря настолько непривычно и сбивает с толку, что я даже придумав этот пост, в итоге и ошибся. Что правда не отменяет сути ереси, вынесенной маркетологами на этикетку.

Замутили совсем воду, эти черти девучки-маркетологи!

Но мы этикетки читаем…

з.ы. Спасибо этому случаю, теперь я точно поеду туда весной покататься вокруг Карпат. Посмотрите (Шаян — google it!) какие там гостиницы

Да как поправил, браво!

Итак,

тут наконец поправили, но многострадальные «Жуляны» не исчезли, а.. перенеслись

по версии гугля, аэропорт «Жуляны» (международный!) перенесся на авиазавод Антонова.

Вообще же, даже на сайте самого предприятия его название вызывает у меня отторжение: Аеропорт Київ «Жуляни», тут. Про международный они как то упускают, видимо и сами пока поверить в это не могут. Ну или редактора у них нет для сайта.

(По закону распространения энтропии, я тут же проверил Гостомель,  в предвкушеньи, так-сказать, но..хм… туда ничего не перенеслось, а то ведь как славно то было бы: ведь там как раз Аэропорт «Антонов» находится. Этого Гуглю еще на 5 лет хватило бы разгребать.

А собственно, чего же от Гугля то хотеть? Нас, идотов много, а он гуголь один. На всех его не хвататает.. пыхтит как дизель в заполярье, но не справляется

Но речь о другом:

на картинке лажа Яндекса, найденная случайно: топоним образованый от имени нас.пункта видоизменен непонятным образом. Это не Астана, а Останино, соответственно вдхр. никак не может быть приязано к столице Казахстана. Видимо была какая то полу-автоматичиская процедура перевода-верификации всех топонимов по списку. (рус/укр). Очень интересен реальный источник такой ошибки. На 100% уверен, что на карте никогда небыло ине могло появиться в результате какой либо ошибки оцифровки название Астанинское. Ну никак!

лажа Яндекса: Астанинское вдхр. восле с. Останино

А случилось мне заблукать на мотоцикле в тех краях: Керч-Чистополье-Белинское-Песочное-Щелкино —  проехав Песочное, я попал в сплошные лесополосы и песок :-), мотоцикл увязал, дороги кончились. Примерно представляя себе лесоустройство, я выбрал какую-то противопожарную канаву и ехал по ней увязая в пол-колеса в мягком песке, в надежде выехать на дорогу между просеками (ведь кудато же выехал распахивающий трактор!). Ехал-ехал, пока не застрял окончательно: не технически, а эмоционально — перестал верить в скорое избавление от этого кошмара и решил сменить тактику. Я оставил мотоцикл в песке и пошел пешком разведывать дорогу, попутно пытаясь считать количество шагов и направление.  После 5-ой посадки, чередующейся канавами я сбился. Слегка запаниковал: связи нет, приборов нет, вода кончилась, воздух 40, солнце и ни тучки на небе. Где-то в песке 200 килограммовый мотоцикл, который даже не развернуть в колее.

Примерно прикинув способ проезда вдоль-поперек посадки/вырубки с глубокими волнами и торчащими пнями (рисковано, ибо не видно грунта вообще под растительностью высотой по пояс) я стал возвращаться. А нет мотоцикла, нет и все тут!

Итак, жара, воды нет, мота нет. Направление потеряно. Где-то в 10-15 км город, но от этого не легче. Вокруг абсолютно пустнынная и непросматриваемая местность. И однообразная до невозможности!

приазовский лес на мягком песке

в окрестностях с. Песочное, в лес я еще не въехал

скважина в окрестностях с. Песочное, вода отдает сероводородом

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

Минут через 40 я нашел борозду со следом, пошел по ней и нашел мотоцикл. Заметить его не было никакой возможности, вплоть до подхода в упор. Уфф.. Теперь нас двое, и это несколько легче

Газу, газу.. и пофиг что «волны» +- метр глубиной/высотой..выбрался в степь, но помятуя об Акташском озере не радовался раньше времени. Каково же было мое удивление — озера НЕТ. Оно полностью высохло, полностью!

ранее тут было Акташское озеро, по совместительсву пруд-охладитель Крымской АЭС

ЛЭП на горизонте служили мне целью — я точно знал куда они ведут, нужно было только добраться до них и ехать вдоль. Раньше они стояли в озере, но все равно это был четкий ориентир для меня.

По дну озера выбрался к  каналу сброса охладителя АЭС…там был какойто фестиваль «Белый ветер», негры на входе :-), билеты, куча народу в некогда пустныных местах. Печалька

Добрался наконец на берех Татарки в полностью обезвоженом состоянии, залез в море и не вылазил час. Пить нечего, но как  это клево! После стресса и полного высыхания, ощущать спасительную воду, пусть и не пресную. Не мог заставит себя уехать… лежал как рыба на берегу. Забил на все планы (в это время я уже должен был быть на выезде  из Крыма)

Татарка — моя старая любовь

з.ы. в сильно замосковившемся Щелкино поимел околокультурный шок бумс-не-забывай-где-ты живешь в местных магазинах при попытке купить воды  (ну, минералка нужна для восстановления водно-солевого баланса, а не говно типа Оболони), попутно заметив что ничего не изменилось

з.ы.ы. полтора литра Моршинской ушли в меня как в песок без остатка менее чем за 5 минут. Со стороны это выглядело забавно, наверное. 

и много красивого и странного на http://esquire.ru/photo/highways