freeExec, я не знаю, давно или недавно, просто раз зашел разговор о плохих и хороших стилях, его стоило вспомнить, зашел, посмотрел - картинка карты имеется. Даже если бы он не работал сейчас, это никак не умаляет его достоинств.
Могу еще напомнить про стиль openstreetmap.de, который напрямую растет из Мапника, но он все равно лучше. Еще есть http://www.cartotype.com/a-new-style-sheet-osm-neo.html например…
Да, перечисленные стили не отображают абсолютно всех тэгов, не всегда могут служить средством отладки всякого рода неочевидной информации (для которой есть куча слоев ITO, страшных на цвета, но показывающих то, что нужно отдельно от всего остального), но от качественного стиля это, обычно, и не требуется.
На гислабе к примеру нет addr2 и addr:street2 еще addr:quarter если память не подводит. В шейпах нет associatedStreet. Не все name:*. Это по РФ и окрестностям. Во вторых нет зарубежья, тоесть если твой проект не ограничивается ex USSR пилишь сам. На геофабрике в бесплатной версии шейпов вообще нет адрески.
В обоих нет is_in (допустим я хочу его валидировать если уж он есть). Я конечно понимаю что можно попросить Максима что-то из этого на гислаб добавить, но такой путь врядли будет общим.
Мой любимы медиаплеер - vlc, аудио - clementine. Оба они на убунте ставятся быстрее связки постгрешка + постгис. Но это если прикапываться к словам.
Не точто бы пользоваться гислабом - некошерно. Не всегда получается. Не всегда есть нужные данные, не всегда подходит логика работы в случае поломок. Вот допустим кто-то сломал границу. В шейпы она не попадет, как ты это отловишь? Версии будешь сравнивать - это тож не шустрая история. Ну или допустим ты хочешь еще и admin_level <= 4 границы проверять.
Выгрузки planet.sql думаю нет, т.к. не очень понятно под какой формат ее выгружать pg_simple, pg_snapshot или под апишную бд, или аля гислаб. А так если геометрию не надо собирать а просто перегнать в sql - дак это дело 5 минут, только это нафиг никому не нужно, т.к. потом придется в базе собирать линии из точек и т.д.
Еще добавлю, что addr:city и иже с ним - это неплохой falback если кто-то поломал границу крупного города, добавив например самопересечение, большая часть конверторов выдает тыкву вместо полигона города.
Поэтому, хочется проверять соответсвует ли это геометрии - пожалуйста.
Не доверяете этой информации - не доверяйте, не используйте.
Не желаете заполнять - не заполняйте.
Но снос, это борьба с химерами.
Такое использование плохо тем, что оно не будет стимулировать на починку границы - “зачем, и так ведь работает?”. И висят потом эти границы месяцами и годами в поломанном состоянии…
addr:country/add:city и т.п. нужны там где они не выводится из геометрии, например когда она неизвестна или если объект, находящийся за границей считается территорией страны (как всякие посольства). Но в последнем случае это наверное лучше делать не через теги addr:xxx, т.к. эта принадлежность не относится к адресации.
Помоему удаление валидной инфы - это больно круто в качестве меры стимулирующей починку границы.
Кстати какого левела границы висят годами 4- ?
Ну дак их и так мало кто пользует хоть с адресными тегами на городах/домах хоть без них. Та что если поудалять addr:*** быстрее их чинить не станут. Геофабрика по отдельным границам режет, Гислаб хранит последнюю живую версию границы, ситигид конвертится со своими отдельными границами или на основе выгрузок с той же геофабрики. Остальные навики - тоже в основном берут готовую нарезку по регионам.
osm.ru вроде пользует границы областей, но там вроде не используется addr:**** кроме номера дома и улицы, nominatim так же использует только улицу и дом. То что они не используют дополнительные адресные теги, починку границ не ускорило.
Zkir
(Kirill Bon )
86
Я почему-то наблюдаю другое - границы НП находятся в довольно приличном состоянии.
liosha
(liosha)
87
Это потому что нп - самостоятельные объекты, а не лоскутное одеяло.
lenux
(Lenux)
88
Сделайте правильную выгрузку с блекджеком : )
Ну дак я и делаю, использую при этом информацию из addr как фолбэк. Просто ты рассказываешь как легко и приятно работать с геометрией и геометрической вложенностью в осм, хотя это так далеко не в любом случае. Предлагаеш грохнуть избыточные но в общем то валидные данные.
Аргументы в поддержку удаления дублей, можно посмотреть в любой кратенькой статье про нормализацию реляционных бд. Но на практике от полного соответсвия правилам нормализации данных в бд отходят. Читай в любой базе крупного проекта можно посмотреть на дубли и странные вещи в бдшках, а для проектов которые эволюционировали на протяжении некоторого периода избыточность - это вообще 100% факт.
Взять хоть блуждающий нерв у человека - нелепица ведь, но есть куда как более неприятные и актуальные проблемы.
P.S. Ты если просишь обращаться к тебе на ты, дак и отвечай на ты.
lenux
(Lenux)
90
ок : )
Хм… вообще не предлагаю это скорее меня не понимают, или понимают но не правильно. Я лишь предлагаю порассуждать (т.е. не какие-то прямые действия по срочному удалению). Определиться в концепциях и т.п. Ведь АТД (именно о нём мы сейчас говорим) в полной мере соответствует геометрической вложенности, там не будет такого, что какой-то город вдруг случайно вылезает за границы государства или области.
Как тебе вариант osmconvert → csv → psql copy from csv?
Хотя я если честно говоря не очень понимаю про что мы с тобой сейчас разговариваем, если про общие выгрузки, то вроде как xml в текущем виде хоть и ужасен с точки зрения производительности загрузки в БД, но как универсальное решение с горем попалам))) . Если же про частные выгрузки, то я бы скорее говорил про какую-то конкретную реализацию, например для валидации кол-ва НП вполне достаточно шейпов (правда добавить addr2) , а если говорить про какую-то массовую валидацию (например разрывов границ в тех же отношениях областей), то скорее ту нужна полноценная БД.
Так же я сторонник того что если что-то есть, то что можно автоматизировать, это нужно автоматизировать : D . Объясню более простым языком: Сейчас маппер будет тратить неделю своей жизни (условно) на проставление тэгов. А в масштабах крупного проекта годы. И через год появляется инструмент, который позволяет по интересующей схеме (Область/район/нп/ + БД с населением сторонняя) выгрузить, то ради чего он тратил годы, но более надёжно.
Так же , что касается то что называется избыточностью. Формально точки это то же избыточность , т.к. центр НП можно условно приравнять к центру полигона.
ПС БД знаю плохо ,. не давно ими только стал интересоваться(
BushmanK, я не занимался сравнением, ни на что не молюсь и не говорил ещё о чём-то таком, что вам представилось умозрительно 
Хотел лишь сказать слово в поддержку бедного и несчастного мапника 
Всё, чего ему не хватает - наличия хотя бы одного такого человека, как в ваших примерах.
У постгрешки есть такая замечательная штука как
copy table_name from stdin
Самая большая боль - это собрать линии из точек.
Про АДТ - я не знаю случаев когда вложенность границ по документам не соответсвует геометрической вложенности границ, но не возьмусь утвердать что такого не бывает. Ну и есть еще всякие межсельсеонные территории, которые, для меня загадка - толи это отдельный полигон, толи дырка.
Именно поэтому следует использовать osm2pgsql с hstore. Если тебе это реально нужно - ты потратишь чуть-чуть времени на установку, даже если плеер ставится быстрее. Это очень удобно, очень просто и очень многофункционально.
Zkir
(Kirill Bon )
94
Самый толковый коммент в этой теме. Коль скоро технология позволяет и так и так, можно поспорить что лучше)
Область грузануть - меня вполне устраивает osmozis + pg_snapshot + hstore.
osm2pgsql я ставил, помоему довольно таки геморойно, особенно если ты не ярый поклонник перла, не помню уже на каком моменте я плюнул и перешел на osmozis.
На весь мир я границы выдираю сам и гружу через copy, выходит довольно шустро.
Впрочем тема то вроде о другом.
Наличия одного и отсутствия остальных… Есть ведь люди, которые просто мало что делают, или ничего не делают, а есть те, которые не дают делать больше другим. С мапником именно такая история.
Есть такой случай ЗАТО Саров где город лежит в двух областях.
akks
98
Тоже выскажусь:
-
Я за то, чтобы на населённых пунктах addr:всё оставить и проверять валидатором.
Обоснование - быстрый поиск, относительно небольшой объём данных (поддаётся валидации), возможность получения информации без загрузки всего региона.
-
У домов и точек POI add:city, addr:country, addr:hamlet, addr:district …
стоит сносить или хотя бы рекомендовать валидатором к сносу в том случае, если они получаются из текущего состояния геометрии границ Если не совпадает - это либо исключение, либо ошибка (подсвечивать валидатором, сделать тег для валидатора “с адресом всё ОК” )
Обоснование - информации слишком много, чтобы её хранить, поддерживать в целостном виде или хотя бы заполнить для всех домов России.
Чтобы составить список городских автомоек всё равно придётся искать внутри полигона города, от этого никуда не деться (руками дорасставлять недостающие addr:city - это издевательство куда хуже postrgresql и всё равно будет устаревать). Нужен удобный инструмент для непрограммистов, который добавляет адресные теги на дома и POI автоматически для упрощения поиска и табличной обработки. Как osm2mp, только в osm-формат. Такой есть?
Да, на населённых пунктах расставить один раз addr реальная задача даже без методов автоматизации. Меняться они будут не абы как, а только по бюрократическим каналам и исправление этих данных в ОСМ будет гораздо быстрее где то ни было ещё.
С домами же всё куда печальней они растут как грибы, уследить будет невозможно. А наличии всех тегов addr на 30% домах сводит их наличие к нулю, т.к. остальные дома всё равно придётся искать с помощью геометрии.
Плугин для osmosis для этого можно написать за день. Там основная сложность - собрать геометрию нужных полигонов и создать геометрический индекс по ним. В качестве базовой библиотеки удобно использовать geotools/JTS. Дальше всё элементарно.
Ну и можно расширить применение, сделать типа tagtransform с доп. условием по геометрической принадлежности (или вообще модифицировать tagtransform для этого).
