Здравствуйте уважаемые форумчане!)
Подскажите пожалуйста где на форуме можно найти специалиста по настройке openstreetmap-website или в каком разделе можно разместить запрос о помощи для настройки openstreetmap-website.
Нужно настроить openstreetmap-website (https://github.com/openstreetmap/openstreetmap-website). Или помошь в настройке , либо собрать в декер.
База данных PostgeSQL с необходимыми расширениями
Для генерации карты из БД использовать mod_tile (https://github.com/openstreetmap/mod_tile) или аналогичный софт
Улилиты загрузки\выгрузки из .OSM файлов в PostgreSQL и обратно (osm2pgsql, osmosis)
Поддержка кэширования тайлов (tilecache или аналог)
Заложить возможность изменения стилей генерируемой карты (написать инструкцию)
Разобраться с возможностью компресии тайлов
Поиск по базе используя Nominatim
Прокладка маршрутов используя OSRM
Всем ещё раз привет. Последние несколько дней пытался сделать упрощенную карту границ рф и регионов. Использовал qgis, но стандартный simplify работает не как надо:
(видимо регионы в отдельные полигоны делает и их уже упрощает, поэтому линии накладываются)
пробовал Grass, но он намертво зависает, ощущение будто слишком большая территория для него
Не знаю даже что можно ещё придумать. Может у кого-то есть уже упрощенная карта в osm? Или ещё может что-то есть, что мне поможет?
Вопрос по поводу зданий, у которых в середине находится более высотная часть, чем с краёв - как это правильно описать в терминах building:part?
Пример: https://www.openstreetmap.org/way/575588259
По вики у меня получается, что внешний контур должен одновременно быть и building:part, и просто building, так как он и outline и part одновременно. Это нормально?
Второй вопрос тоже про здания. В случае использования building:part для обратной совместимости предлагается отдельно внешнюю границу помечать классическим тегом building=. Означает ли это, что использование building= на самих частях является ошибочным (т. к. тогда мы не сможем отличить, какая из них действительно образуют “наружный” контур) и для них тип надо прописывать в виде building:part=roof, а не building:part=yes + building=roof?
Тут требуется немного пространственной магии в голове. Можно такую фигуру разделить на две части, сделав: 1) горизонтальный разрез: получится плоский блинчик внизу и цилиндр на нём 2) вертикальный разрез: получится кольцо внизу и цилиндр внутри него
building= и building:part= в любом случае будут совпадать в каких-то местах, потому что частями здания (building:part) нужно покрывать всю площадь самого здания (building). В данном случае, да, они будут совпадать полностью по внешней границе.
Означает. Здание как было одно, так и должно остаться одно. Все свойства здания также остаются на здании. building:part-ы задумывались сугубо для 3д рендеров, других смыслов в них не вкладывали, потому они лишь дополняют.
Alexander-II, благодарю за ответы. Пока сделал без магии, просто оба здания пометил как building:part, на внешнее навесил building, всё собрал в отношение type=building - соответственно, внешнее вошло дважды с ролями part и outline.
Вопросы появились такие:
Чем плох вариант “по-няковски” (кроме предупреждения в JOSM): на оба здания повесить building, и не связываться ни с building:part, ни с type=building?
Если building:part предназначен только для рендерера, то вообще корректно ли с его помощью обозначать часть здания, отличающуюся типом от основного (магазин, пристроенный к жилому дому)? Не два ли отдельных мультиполигона-building’а должны быть с общим участком контура?
тем что это будут два неправильно затегированных здания, соотвественно рендер данных должен решать как енто пересечение и вложенность разрешать.
ошибка, к примеру, при импорте - два раза один и тот же набор или часть данных влился повоторно или ошибка человека дорисовал на неполностью загруженной карте или еще чтото - тогда надо что-то откидывать что-то оставлять.
при вложенности алгоритм может откинуть вложенности и обработать систему, то при пересечених решение не алгоритмизируемо и т.д.
в данный момент building:part отдельный объект с отдельным четко описанным тегом, никак не пересекающийся по тегам с обычными зданиями. если рендер его не знает, то он его исключает из дальнейшей обработки, и в конечную карту уходит “правильное” полноценное здание.
почему нет ?? имеется правило что что значение building:part обрабатывать также как и обычное здание и он ему следует. и все правильно отображает. если он не умеет building:part он его не отображает.
вытаскивал список населенных пунктов, так Нью-Йорк вытащился в виде точки без admin_level и потерялся среди мелких городов. У столиц других штатов тоже самое (да, Нью-Йорк не столца, а особый случай, но речь не об этом).
admin_level, прежде всего, к административным границам.
Потом некторые ставят на административный центр того, что охватывает административная граница, шоб на карте поярче виднелось.
Но если центр один у нескольких admin_level, то будет ерунда.
Правильнее для этого смотреть таки admin_centre в отношении административной границы
Все эти admin_level не на boundary=administrative от лукавого. По возможности лучше на них не обращать внимания.
place и admin_level на прямую не очень-то связаны, да и связь не однозначна.
Да и в разных странах эта каша намаплена по-разному.
Ясно, спасибо. Но как в таком случае предложите получить список населенных пунктов с каким-нибудь параметром, отвечающим за “старшинство”? Чтобы если они окажутся рядом, знать, какой из них обязательно рисовать, а какой можно и скрыть если не поместился.
Тут вроде ответили уже, но повторюсь
В реальности здание будет одно, а в ОСМ — два. А если у здания есть адрес, то как его поделить на два объекта в ОСМ?
type=building хоть и рекомендован, но я почти перестал с ним связываться. Его тяжело поддерживать актуальным, если приходить перерисовывать здание (отчасти это неудобство программы-редактора).
Не уверен, что где-то расписано, что считается отдельным зданием, а что его частью. Так что как здравый смысл подсказывает. Я привык считать объект с одним адресом — единым зданием.
в Америке Вашингтон по рангу выше Нью-йорка и по населению очень сильно ниже
вхождение в боундари в виде члена admin_centre, по максимальному admin_level из подключенных отношений
Capital в много"республиканской" стране бессмыслененн. Казань так-то тоже столица респблики Татарстан. так что на ентот атавизм можно не смотреть.
Так capital это не yes/no, а число, обозначающее уровень (страна/область/…), такой же как admin_level. Фактически это аналог admin_level для столиц-точек.
Короче, я возьму place, admin_level, capital, population и напишу какую-нибудь формулу, которая учтет все эти поля.
А еще как-нибудь сяду и проставлю capital всем столицам субъектов РФ.