Вопросы новичков (Part 1)

Я думаю про дома, ибо первоначально звучало как соседствующие с адресом. А это уже потом привели ошибки JOSM про адресные теги на place.

Коллеги, подскажите каким образом люди общаются через mailing list, какой софт нужен чтобы смотреть и поддерживать общение через подобные рассылки https://lists.openstreetmap.org/pipermail/tagging/2015-January/thread.html#20946

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

Понятно, я просто думал что технологии ушли дальше BBS, оказывается всё по-старинке.
Там подпишешься - потом спамом завалит. Странно что это основной источник обсуждений, в т.ч. deprecate тегов без голосования и вообще непонятно по каким причинам.

Это отсеивает несерьезную молодежь, привыкшую к чатикам.

Подскажите, а в чём преимущество разметки зданий кусочками?
Например есть домик с разной этажностью: 1 - 10 этажей, 2 - 16 этажей

---------------
|  1   |   2  |
---------------

Сейчас как я понял нужно делать как с границами областей:

  1. 3 линии - перемычка, три стороны первого, три стороны второго
  2. 3 мультиполигона - общий контур с адреской, П-образный кусок 1-го+перемычка для этажности и П-образный кусок 2-го+перемычка

Почему нельзя сделать так:

  1. 2 линии - отдельно первая часть дома и отдельно 2-ая часть дома, у них будут общие координаты в области перемычки
  2. 1 отношение - в которого входят эти 2 линии с ролью part

Вместо 3-х отношений и 3-х линий всего 1 отношение и 2 линии. Во втором случае получается меньше информации в базе хранится, проще обрабатывать - загрузил сразу 2 площади, вместо того чтобы грузить границы и потом собирать их, надеясь что контур замкнут?

Соответственно чем больше участков, тем больше отношений будет в первом случае: 5 частей у дома → 12 линий / 6 мультиполигонов вместо 5 площадей и одного отношения. И когда куча отношений загружается в списке (JOSM) очень сложно сооринтироваться где нужные.

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

Обнаружил, что часовой пояс MSK+3 (Omsk Time, отношение 3563727) простирается на восток аж за пределы Томской области, не говоря уже о Новосибирской, где давно опять MSK+4.

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

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

Большинство использует osm2pgsql и он это делает на этапе импорта прозрачно для пользователя, поэтому об этом надо задумываться в последнюю очередь.

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

так почему нужно обозначать первым случаем - это исторически так сложилось или ещё по каким-то другим причинам?
как по мне, это усложняет редактирование данных, да и тратит дополнительные ресурсы того же osm2pgsql на их обработку и склейку
я так “упростил” несколько десятков домиков у себя в районе, их обратно лучше откатить?

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

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

Лучше вернуть как было.

Я так полагаю если ничего не поломалось - можно не откатывать, а подождать и посмотреть что из этого выйдет, в частности с адресом здания и точек POI внутри отдельных building part. По идее ничего плохого случиться не должно. В таких простых случаях, как вы привели в примере, действительно мультиполигон излишен - сложнее в отрисовке, сложнее ловить косяки.

PS: под фразой “сложнее” я имею в виду - “потратить (значительно) больше времени”.

при уточнении геометрии инструментом W склееные полигоны остаются склееными, т.е. создаются общие точки. Это не проблема.

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

Как пример https://www.openstreetmap.org/way/160455990
На самом деле это должны быть два разных building:part, между которыми есть технологический (усадочный ? температурный ?) проем сантиметров 30-50, невидимый на спутнике.

В том-то и проблема, надо чтобы одна часть частично отделилась, вот такой каламбур.

Тоже выступаю за возврат.

Есть ли поиск по форуму . Около месяца назад консультировался по этому обьекту.
https://www.openstreetmap.org/way/475674403/history#map=19/50.76569/29.23951

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

Коллеги, тестируя локальный рендер MapSurfer.NET столкнулся с тормозами при отрисовке больших полигонов воды, таких как Ладожское озеро, Рыбинское вдхр., Балхаш, Иссык-Куль и другие огромные водоёмы.

  1. Как этот вопрос решается в мапнике - полигоны загоняются целиком и он их переваривает ?
  2. Чем можно “нашинковать” в квадраты помельче в базе PostgreSQL+PostGIS ? Понятно что в этом случае теряется возможность живой-обновляемой базы, но похоже других вариантов нет.