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

Подскажите, а в чём преимущество разметки зданий кусочками?
Например есть домик с разной этажностью: 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 ? Понятно что в этом случае теряется возможность живой-обновляемой базы, но похоже других вариантов нет.

Тут одно из решений, как делает Макс, на каждый зум создаётся копия базы с упрощённой геометрией.
А что даёт шинковка и как это вообще?

Примерно как тут http://openstreetmapdata.com/data/land-polygons

Ну и как полиш, декодированный из Гармина или Руссы, там тоже нарезка

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

Кажется нашел ST_Subdivide

Про часовые пояса так никто и не подскажет?

Eugene Muzychenko, Такой инструмент наврядли найдешь - очень редкая потребность в нем. только ручками.