Давайте я что нибудь из этих регионов возьму что ли на конвертацию? Какие еще не разобрали?
RU-AMU/
RU-CHU/
RU-SVE/
RU-YEV/
Ну коли никто не хочет то забрал себе. Завтра с утра конвертация будет.
Russia_moscow_asia конвертируется без поддержки цветов (метро).
А что пора обновлять конвертор? Завтра с утра надо скачать свежий тогда.
и MOS тоже.
Насколько я вижу, если в OSM есть два вложенных контура, внешний из которых имеет в мультиполигоне роль outer, а внутренний роль inner, и на внешнем проставлены теги, конвертер не переносит теги с внешнего контура на мультиполигон. Например, если на внешнем контуре стоит natural=water, в карте рисуется озеро без дырки, которая должна быть на месте внутреннего контура, имеющего роль inner. Аналогично не вырезаются дырки в зданиях.
Вопрос: корректна ли простановка тегов, которые должны по логике относиться к мультиполигону, не в него, а на контур, имеющий роль outer? Если да, то конвертер ежедневных карт для OsmAnd работает неверно.
Вполне корректна (раз мапник понимает). В былые времена только так и мапили. Эта техника возникла еще на заре отношений, когда не все их понимали, и данных таких в базе должна быть еще куча
В корне не корректна. Теги мультика должны быть на мультике. Теги на аутер линии относяться только к ней.
Описанная ситуация должна интерпретироваться так: мультик без тегов, т.е. ничего не значащий. Теги на внешнем замкнутом контуре - обычный замкнутый полигон и вода к нему никакого отношения не имеет.
Рассмотрите похожую ситуацию, например, с внешним контуром=забор.
Мапник же, ИМХО, рисует эти объекты как осилил, но не связывая их воедино. Нарисовал отдельно по тегам внешнего контура, затем пошел в мультик, внешнего не нашел, ну и черт с ним, внутренний же есть, его и нарисуем водой 
Даже не так. Аутер нарисован как и обычный полигон, он им и является. Мультиполигон мапником прогнорирован, ибо он не имеет тегов. Иннер же, также нарисован обычным полигоном, коим также является. Просто иннеры имеют при прорисовке наименьшие приоритеты, оттого он отобразился поверх аутера, а не наоборот и как следствие виден.
В данном случае мультиполигон - пустышка, не несущая никакой смысловой нагрузки. Либо его стоит удалить, и все будут его обрабатывать как наложение полигонов, либо починить перенеся теги с утер линии на мультик и тогда он станет полноценным мультиком и всеми будет обрабатываться как мультик с дыркой.
RTFM! 
Практика не корректна для пользователей, то есть новых данных, но корректна для программистов, то есть при обработке старых данных.
http://wiki.openstreetmap.org/wiki/Relation:multipolygon
Жирным я выделил то, куда попадает распространенный случай дырок в здании/озере, когда теги на outer, а в отношении их нет вовсе
P.S. Вот живой пример дырки в здании. Мапник, да и все остальные, кроме мапквеста, дырку показывают.
http://www.openstreetmap.org/relation/163959
Хороший софт подстраивается под возможные косяки маперов, однако, с точки зрения корректности мапинга - это не верно. Теги аутер линнии - это теги этой линии и только ее, к мультику они не имеют никакого отношения. Как интерпретировать аналогичную ситуацию с аутер=забор? Площадный забор? Нет, это мультик - пустышка, а забор сам по себе.
Задача делится на две части:
- Где взять теги для пустого отношения? Ответ в цитате выше, то есть это “забор”.
- Что значит “забор” в мультиполигоне? Это уже семантика, это к рендеру - мапник обнес забором и внутренности
http://www.openstreetmap.org/#map=19/56.00436/37.21919 (потом сотру)
Аналогично забору работают же границы - внутренние дырки тоже обводят .
Пустой мультик - пустой мультик и не более. Можно делать предположения, что мапер оставил теги мультика на аутер линии, но это лишь предположение. Скорее всего, в большенстве случаев, оно совпадет с пожеланиями мапера, но это далеко не факт. В итоге подобная интерпретация пустых мультиков может оказаться большим злом, чем добром. И я еще не затрагиваю сложные мультики, в которых на аутерах могут быть свои разные теги, в них как ни старайся, машинно не угадашь, что же имел в виду автор этого мультика без тегов.
Не выдумывайте. Вики утверждает другое. Вот и по-русски
http://wiki.openstreetmap.org/wiki/RU:Relation:multipolygon#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D0.B5_.D1.82.D0.B5.D0.B3.D0.BE.D0.B2
Если все будут интерпретировать по описанию, то проблем с ошибочными пустышками возникнуть не должно.
Ошибка проявится. А если кто-то будет игнорировать, как верно, так и неверное, то ошибки только расплодятся, так как пользователь будет это принимать за нормальное поведение софта.
Такой подход ломает логику мультиков подстраиваясь под частые косяки маперов, да еще и задокументировали как фичу…
Эт оне косяк, а изначальная фича для совместимости. Когда отношения только вводили, не весь софт их понимал, поэтому дырки в домах и озерах как бы были дополнением, которое, если что, не так уж и жалко потерять, в отличие от внешнего контура.
Да и идеология была несколько смещена. Оутер был реальным объектом, а отношение могло добавлять ему дополнительные детали типа дырки.
на этом вопрос предлагается и закрыть в непрофильной ветке))
Да, изначальный вопрос был такой:
“конвертер не переносит теги с внешнего контура на мультиполигон”
Если highway=service является частью мультиполигона amenity=parking, парковка рисуется, а дорога - нет. При этом линия остаётся роутинговой. Вероятно, проблема есть и с другими типами дорог и другими типами мультиполигонов.
Не подтверждается. Так?
https://dl.dropboxusercontent.com/u/4624786/osm/Screenshot%20-%20082514%20-%2021%3A10%3A57.png
https://dl.dropboxusercontent.com/u/4624786/osm/Screenshot%20-%20082514%20-%2021%3A11%3A09.png
мультиполигон - отношение, в первую очередь описывающее взаимозависимости полигонов (а также мультиполигонов между собой), из которых он состоит. Полигоны-участники отношения типа «мультиполигон» совершенно правомерно могут обладать собственными тегами и это естестевенно, логично и понятно. Примеров - тысячи. Простейший: озеро, окружённое лесом. Какие теги в данном случае «должен» иметь мультиполигон, где лес=outer, озеро=inner? Это было и есть, и никто этот подход не отменял.
Причём тут забор? Он всегда по умолчанию был линейным объектом и никаких проблем с заборами не было и нет.
Резюме:
и об этом я сообщал разработчикам дважды, но никакого ответа не последовало.