мапить что это значит

Чернобровов Алексей Аналитик

Big Data Mapping: что такое маппирование больших данных

В этой статье рассмотрено, что такое маппирование больших данных, как это связано с Data Science, когда и как часто выполняется этот процесс, а также, какие программные инструменты позволяют автоматизировать Big Data mapping.

Что такое маппирование данных и где это используется

Представим, что в одной из корпоративных систем сведения о семейном положении сотрудника хранятся так, что «1» в поле «дети» означает их наличие. В другой системе эти же данные записаны с помощью значения «True», а в третьей – словом «да». Таким образом, разные системы для обозначения одних и тех же данных используют разные отображения. Чтобы привести информацию к единообразию, следует сопоставить обозначения одной системы обозначениям в других источниках, т.е. выполнить процедуру мэппинга данных (от английского map – сопоставление). В широком смысле маппирование – это определение соответствия данных между разными семантиками или представлениями одного объекта в разных источниках. На практике этот термин чаще всего используется для перевода или перекодировки значений [1].

Дисциплина управления данными, Data Management, трактует маппинг как процесс создания отображений элементов данных между двумя различными моделями, который выполняется в начале следующих интеграционных задач [2]:

Таким образом, маппирование данных представляет собой процесс генерации инструкций по объединению информации из нескольких наборов данных в единую схему, например, конфигурацию таблицы. Поскольку схемы данных в разных источниках обычно отличаются друг от друга, информацию из них следует сопоставить, выявив пересечение, дублирование и противоречия [3].

С прикладной точки зрения можно следующие приложения маппинга данных [4]:

В Big Data мэппинг выполняется при загрузке информации в озеро данных (Data Lake) и корпоративное хранилище (DWH, Data Warehouse). Чем Data Lake отличается от DWH, рассмотрено здесь. В этом случае маппинг реализуется в рамках ETL-процесса (Extract, Transform, Load) на этапе преобразования. При этом настраивается соответствие исходных данных с целевой моделью (рис. 1). В случае реляционных СУБД для идентификации одной сущности в разных представлениях нужно с ключами таблиц и настройкой отношений (1:1, *:1, 1:* или *:*) [5].

Рис.1. Маппирование данных при консолидации таблиц

В Data Science маппирование данных входит в этап их подготовки к ML-моделированию, когда выполняется формирование датасета в виде матрицы значений для обработки соответствующими алгоритмами. В частности, когда Data Scientist обогащает исходный датасет данными из сторонних источников, он занимается маппингом данных. Проводить процедуру дата мэппинга можно вручную или автоматически с помощью соответствующих подходов и инструментов, которые рассмотрены далее.

Особенности процесса дата мэппинга

На практике трудоемкость мэппинга зависит от следующих факторов [3]:

Облегчить процесс маппирования можно за счет метаданных – сведениях о признаках и свойствах объектов, которые позволяют автоматически искать и управлять ими в больших информационных потоках. В частности, если каждое приложение будет выполнять публикацию метаданных, что позволит создать их стандартизированный реестр, то маппинг будет полностью автоматизированным [2]. Однако в большинстве случаев процесс мапирования данных не полностью автоматизирован и состоит из следующих этапов [4]:

При работе с большими объемами данных выделяют 3 основных подхода к маппированию [2]:

Также стоит упомянуть полуавтоматическое маппирование в виде конвертирования схем данных, когда специализированная программа сравнивает источники данных и целевую схему для консолидации. Затем разработчик проверяет схему маппирования и вносит исправления, где это необходимо. Далее программа конвертирования схем данных автоматически генерирует код на C++, C # или Java для загрузки данных в систему приемник (рис. 3) [3].

Рис. 3. Конвертирование схем данных в процессе мэппинга

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

Инструменты маппирования больших данных

Как и большинство прикладных решений, все средства для маппинга данных можно разделить на 3 категории [6]:

Большинство перечисленных продуктов поддерживают все 3 подхода к маппированию: ручной (GUI и кодирование), data-driven и семантический. Однако, семантический мэппинг требует наличия реестров метаданных, что имеется далеко не в каждом предприятии. А публичные реестры метаданных, такие как национальные, отраслевые или городские репозитории [7] не всегда напрямую коррелируют, например, с задачами построения локального DWH. Но, наряду с открытыми государственными данными и другими публичными датасетами, их можно использовать в исследовательских DS-задачах.

При выборе конкретного инструмента для маппинга больших данных стоит учитывать следующие факторы:

Резюме

Итак, маппирование данных – это важная часть процесса работы с данными, в том числе и для Data Scientist’а. Эта процедура выполняется в рамках подготовки к ML-моделированию, в частности, при обогащении датасетов. В случае одноразового формирования датасета из нескольких разных источников сопоставление данных можно выполнить вручную или с помощью самописного Python-скрипта. Однако, такой подход не применим в промышленной интеграции нескольких информационных систем или построении корпоративных хранилищ и озер данных. Поэтому знание инструментов дата мэппинга пригодится как Data Scientist’у, так и Data Engineer’у. Наконец, сопоставление данных с целью избавления от дублирующихся и противоречивых значений входит в задачи обеспечения качества данных (Data Quality) [4]. В свою очередь, Data Quality относится к области ответственности стратега по данным и инженера по качеству данных. Таким образом, понимание процесса маппирования необходимо каждому Data-специалисту.

Источник

Маппинг данных из реляционной БД

Иногда возникают ситуации, когда решение задачи выборки данных из реляционной БД не укладывается в возможности используемой в проекте ОРМ, например, либо из-за недостаточной скорости работы самой ОРМ, либо не совсем оптимальных SQL запросов генерируемых ею. В таком случае обычно приходится писать запросы вручную.

Проблема в том, что данные из БД (в т.ч. в ответ на JOIN запрос) возвращаются в виде “плоского” двухмерного массива никак не отражающего сложную “древовидную” структуру данных приложения. Работать с таким массивом дальше крайне неудобно, поэтому требуется более-менее универсальное решение, позволяющее привести этот массив в более подходящий вид по заданному шаблону.

Решение было найдено, удобное и достаточно быстрое.

На сколько быстрое

Для оценки скорости работы библиотеки я собрал небольшой испытательный стенд на котором скорость работы моей библиотеки сравнивается со скоростью работы Eloquent. Для замеров использовался пакет phpbench.

Для того чтобы развернуть стенд у себя:

Здесь я использовал инструмент описанный в моей предыдущей статье.

Затем в меню выбираем: 1 Develop, затем: 1 Build, затем 2 Deploy and Up;
Затем запускаем тесты 5. Run tests

В базе 3000 книг. Результаты получились следующие:

benchEloquent — вытаскивает все книги с авторами с использованием Eloquent
benchEloquentId — вытаскивает определенную книгу с авторами с использованием Eloquent (10 раз)

benchProc — вытаскивает все книги с авторами с использованием библиотеки
benchProcId — вытаскивает определенную книгу с авторами с использованием библиотеки (10 раз)

Возможно приведенные тесты недостаточно репрезентативны, но разница заметна, как по времени выполнения, так и по расходованию памяти.

Как это работает

Далее, для примера (крайне простого), представим, что у нас имеется БД книг и авторов со следующей структурой.

Задача — вытащить все книги с их авторами.

Запрос будет выглядеть как-то так:

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

Для этого немного изменим наш запрос:

Здесь мы в секции SELECT задали алиасы: для полей с данными о книгах алиасы с префиксом ‘book_’, а для полей с информацией об авторах с префиксом ‘author’.

Далее преобразуем ответ БД

$rows — ответ БД в виде массива объектов /stdClass()
$config — ассоциативный массив отражающий структуру данных итогового массива

Источник

Практичные способы маппинга данных в Kotlin

Маппинг данных – один из способов для разделения кода приложения на слои. Маппинг широко используется в Android приложениях. Популярный пример архитектуры мобильного приложения Android-CleanArchitecture использует маппинг как в оригинальной версии (пример маппера из CleanArchitecture), так и в новой Kotlin версии (пример маппера).

Маппинг позволяет развязать слои приложения (например, отвязаться от API), упростить и сделать код более наглядным.

Пример полезного маппинга изображен на схеме:

Для примера модели упрощены. Person содержит Salary в обоих слоях приложения.

В настоящем коде, если у вас одинаковые модели, возможно, стоит пересмотреть слои приложения и не использовать маппинг.

Метод №1: Методы-мапперы

Самый быстрый и простой метод. Именно он используется в CleanArchitecture Kotlin (пример маппинга).

Такой код быстрее писать и проще модифицировать – объявления полей и их использование находятся в одном месте. Не надо бегать по проекту и модифицировать разные файлы при изменении полей класса.

Еще проблема может возникнуть если по требованиям архитектуры слои приложения не могут знать друг о друге: т.е. в классе Src слоя нельзя работать со слоем Dst и наоборот. В этом случае такой вариант маппинга использовать не получится.

В рассмотренном примере слой Src зависим от слоя Dst и может создавать классы этого слоя. Для обратной ситуации (когда Dst зависим от Src ) подойдет вариант со статическими методами-фабриками:

Маппинг находится внутри классов Dst слоя, значит эти классы не раскрывают все свои свойства и структуру использующему их коду.

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

Резюме метода маппинга:

+ Быстро писать код, маппинг всегда под рукой
+ Легкая модификация
+ Низкая связность кода
— Затруднено Unit-тестирование (нужны моки)
— Не всегда позволено архитектурой

Метод №2: функции-мапперы

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

Резюме метода маппинга:

+ Простое Unit-тестирование
— Затруднена модификация
— Требуются открытые поля у классов с данными

Метод № 3: Функции-расширения

При этом стоит учесть, что функции расширения могут приводить к неожиданному поведению из-за своей статической природы: https://kotlinlang.org/docs/reference/extensions.html#extensions-are-resolved-statically

Резюме метода маппинга:

+ Простое Unit-тестирование
— Затруднена модификация
— Требуются открытые поля у классов с данными

Метод №4: Классы-мапперы с интерфейсом

Относительно маппинга в функции у этого примера только один недостаток – необходимость писать немного больше кода.

Резюме метода маппинга:

+ Лучше типизация
— Больше кода

Как и функции-мапперы:

+ Простое Unit-тестирование
— Затруднена модификация
— требует открытые поля у классов с данными

Метод 5: Рефлексия

Метод черной магии. Рассмотрим этот метод на других моделях.

В данном примере EmployeeSrc и EmployeeDst хранят имя в разных форматах. Мапперу нужно только составить имя для новой модели. Остальные поля обработаются автоматически, без написания кода (вариант else в when ).

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

Большая проблема возникнет, например, если вы добавите обязательные поля в Dst и его случайно не окажется в Src или в маппере: cлучится IllegalArgumentException в runtime. Также рефлексия имеет проблемы с производительностью.

Резюме метода маппинга:

+ меньше кода
+ простое Unit-тестирование
— опасен
— может негативно сказаться на производительности

Выводы

Такие выводы можно сделать из нашего рассмотрения:

Методы-мапперы — наглядный код, быстрее писать и поддерживать

Функции-мапперы и функции расширения – просто тестировать маппинг.

Классы мапперы с интерфейсом — просто тестировать маппинг и яснее код.

Рефлексия – подходит для нестандартных ситуаций.

Источник

Свой mapper или немного про ExpressionTrees

Сегодня мы поговорим про то, как написать свой AutoMapper. Да, мне бы очень хотелось рассказать вам об этом, но я не смогу. Дело в том, что подобные решения очень большие, имеют историю проб и ошибок, а также прошли долгий путь применения. Я лишь могу дать понимание того, как это работает, дать отправную точку для тех, кто хотел бы разобраться с самим механизмом работы «мапперов». Можно даже сказать, что мы напишем свой велосипед.

Отказ от ответственности

Я ещё раз напоминаю: мы напишем примитивный mapper. Если вам вдруг вздумается его доработать и использовать в проде — не делайте этого. Возьмите готовое решение, которое знает стек проблем этой предметной области и уже умеет их решать. Есть несколько более-менее весомых причинам писать и использовать свой вело-mapper:

Что называют словом «mapper»?

Это подсистема, которая отвечает за то, чтобы взять некий объект и преобразовать (скопировать его значения) его в другой. Типичная задача: преобразовать DTO в объект бизнес слоя. Самый примитивный mapper «бежит» по свойствам (property) источника данных и сопоставляет их со свойствами типа данных, который будет на выходе. После сопоставления происходит извлечение значений из источника и их запись в объект, который будет результатом преобразования. Где-то по пути, скорее всего, нужно будет ещё создать этот самый «результат».

Для потребителя mapper — это сервис, который предоставляет следующий интерфейс:

Подчеркиваю: это наиболее примитивный интерфейс, который, с моей точки зрения, удобен для объяснения. В реальности мы, скорее всего, будем иметь дело с более конкретным маппером (IMapper ) или с более общим фасадом (IMapper), который сам подберет конкретный mapper под заданные типы объектов входа-выхода.

Наивная реализация

Ремарка: даже наивная реализация mapper’a требует элементарных знаний в области Reflection и ExpressionTrees. Если вы ещё не прошли по ссылкам или ничего не слышали об этих технологиях — сделайте это, прочтите. Обещаю, мир уже никогда не будет прежним.

Впрочем, мы с вами пишем свой mapper. Для начала давайте получим все свойства (PropertyInfo) того типа данных, который будет на выходе (далее я буду называть его TOut). Это сделать достаточно просто: тип мы знаем, так как пишем имплементацию generic-класса, параметризированного типом TOut. Далее, используя экземпляр класса Type, мы получаем все его свойства.

При получении свойств я опускаю особенности. Например, некоторые из них могут быть без setter-функции, некоторые могут быть помечены аттрибутом как игнорируемые, некоторые могут быть со специальным доступом. Мы рассматриваем самый простой вариант.

Идём далее. Было бы неплохо уметь создавать экземпляр типа TOut, то есть того самого объекта, в который мы «мапим» входящий объект. В C# это можно сделать несколькими способами. Например, мы можем сделать так: System.Activator.CreateInstance(). Или даже просто new TOut(), но для этого вам нужно создать ограничение для TOut, чего в обобщенном интерфейсе делать не хотелось бы. Впрочем, мы с вами что-то знаем об ExpressionTrees, а значит можем сделать вот так:

Почему именно так? Потому что мы знаем, что экземпляр класса Type может дать информацию о том, какие у него есть конструкторы — это весьма удобно для случаев, когда мы решим развить свой mapper настолько, что будем передавать в конструктор какие-либо данные. Также, мы ещё немного узнали про ExpressionTrees, а именно — они позволяют налету создать и скомпилировать код, который потом можно будет многократно использовать. В данном случае это функция, которая на самом деле выглядит как () => new TOut().

Теперь нужно написать основной метод mapper’a, который будет копировать значения. Мы пойдем по самому простому пути: идём по свойствам объекта, который пришёл к нам на вход, и ищем среди свойств исходящего объекта свойство с таким же названием. Если нашли — копируем, если нет — идём дальше.

Таким образом у нас полностью сформировался класс BasicMapper. С его тестами можно ознакомиться вот тут. Обратите внимание, что источником может быть как объект какого-то конкретного типа, так и анонимный объект.

Производительность и boxing

Reflection отличная, но медленная штука. Более того, её частое использование увеличивает memory traffic, а значит нагружает GC, а значит ещё больше замедляет работу приложения. Например, только что мы использовали методы PropertyInfo.SetValue и PropertyInfo.GetValue. Метод GetValue возвращает object, в которой завернуто (boxing) некое значение. Это значит, что мы получили аллокацию на пустом месте.

Mapper’ы обычно находятся там, где нужно превратить один объект в другой… Нет, не один, а множество объектов. Например, когда мы забираем что-то из базы данных. В этом месте хотелось бы видеть нормальную производительность и не терять память на элементарной операции.

Компилируемый mapper

На самом деле, всё относительно просто: мы уже делали new с помощью Expression.New(ConstructorInfo). Наверное вы заметили, что статический метод New называется точно так же, как и оператор. Дело в том, что почти у всего синтаксиса C# есть отражение в виде статических методов класса Expression. Если чего-то нет, то это значит, что вы ищите т.н. «синтаксический сахар».

Вот несколько операций, которые мы будем использовать в нашем mapper’e:

К сожалению, код получается не очень компактный, поэтому предлагаю сразу взглянуть на имплементацию CompiledMapper. Я вынес сюда лишь узловые моменты.

Для начала мы создаем объектное представление параметра нашей функции. Так как она принимает на вход object, то и параметром будет объект типа object.

Далее мы создаем две переменные и список Expression, в который будем последовательно складывать выражения присваивания. Порядок важен, ведь именно так команды будут выполнены, когда мы вызовем скомпилированный метод. Например, мы не можем присвоить значение переменной, которая ещё не объявлена.

Далее мы точно также, как и в случае с наивной имплементацией, идём по списку свойств типов и пытаемся их сопоставить по имени. Однако, вместо того, чтобы немедленно присваивать значения — мы создаем выражения извлечения значений и присваивания значений для каждого сопоставленного свойства.

Важный момент: после того, как мы создали все операции присваивания нам нужно вернуть результат из функции. Для этого последним выражением в списке должно быть Expression, содержащее экземпляр класса, который мы создали. Я оставил комментарий рядом с этой строчкой. Почему поведение, соответствующее ключевому слову return в ExpressionTree выглядит именно так? Боюсь, что это отдельная тема. Сейчас я предлагаю это просто запомнить.

Ну и в самом конце мы должны скомпилировать все выражения, которые мы построили. Что нам тут интересно? Переменная body содержит «тело» функции. У «обычных функций» ведь есть тело, верно? Ну, которое мы заключаем в фигурные скобки. Так вот, Expression.Block — это именно оно. Так как фигурные скобки — это ещё и область видимости, то мы должны передать туда переменные, которые там будут использоваться — в нашем случае sourceInstance и outInstance.

Почему не будет boxing? Потому что скомпилированный ExpressionTree это настоящий IL и для runtime он выглядит также (почти), как и ваш код. Почему «скомпилированный mapper» работает быстрее? Снова: потому что это просто обычный IL. Кстати, скорость мы можем легко подтвердить с помощью библиотеки BenchmarkDotNet, а сам бенчмарк можно посмотреть тут.

В колонке Ratio «скомпилированный mapper» (CompiledMapper) показал очень неплохой результат, даже по сравнению с AutoMapper (он baseline, т.е. 1). Впрочем, давайте не будем радоваться: AutoMapper обладает значительно большими возможностями по сравнению с нашим велосипедом. Этой табличкой я лишь хотел показать, что ExpressionTrees значительно быстрее, чем «подход классического Reflection».

Резюме

А что mapper? Mapper — отличный пример, на котором всему этому можно научиться.

Источник

Мапить что это значит

Рекомендованным редактором является JOSM. Он может показаться сложноватым, но в нём всё делается эффективней и быстрее. Также JOSM содержит в себе валидатор правок, который предупреждает о распростарнённых ошибках. По JOSM можно посмотреть видео-урок.

Внимание. Если вы пришли в проект на уже нарисованную карту, то скорее всего объекты нарисованы по правильным координатам. Поэтому перед редактированием подвиньте подложку. НЕ ДВИГАЙТЕ ОБЪЕКТЫ ПОД СМЕЩЁННУЮ ПОДЛОЖКУ. В случае сомнений, смотрите GPS треки, или спрашивайте на форуме. Бинг регулярно обновляет карты, и подложка может сильно (или не сильно) «прыгать».

Добавление улиц
Если вы не знаете названия улицы, а оно должно быть, лучше указать highway=road, чтобы было понятно, что улица не закончена.

Если улица не имеет названия, а служит для проезда, то highway=unclassified

Дворовые проезды обозначаются highway=service, living_street=yes.

Подъезды к частным домам, закрытые дороги на предприятиях, т.е. дороги ограниченного пользования highway=service, service=driveway.

Что касается остальных улиц, то принято Соглашение о классификации дорог. Очень важно ему следовать. В частности, уже на территории Украны запущен валидатор, проверяющий связность дорог на основании принятой классификации. (См. также Звʼязаність дорожнього графа)

Именование улиц

Об именовании улиц и объектов можно почитать больше на Вики.

Если переулок/проезд нумерованый, ставим нумерацию вначале: «2-й Петренковський проїзд».

Если слов несколько, то с заглавной буквы в украинском и русском названиях пишется только первое слово, за исключением имён собственных. Равно и топоним (улица, проспект и т.п.) пишется с маленькой буквы.

Если улица несёт чьё-то имя, то порядок такой: «Имя Фамилия», либо «Титул/звание Имя Фамилия»: «Короля Фрідріха Великого проспект», «Надії Крупської провулок». Сокращения имён также не допускаются за исключением тех случаев, когда они наличествуют на табличках домов.

Также планируется запуск робота для автоматической генерации английских названий улиц, поэтому лучше оставить тег name:en (не name:eng!) пустым, и он заполнится автоматически через некоторое время. Если же всё-таки хочется это сделать, то необходимо следовать официальному стандарту транcлитерации, и что необходимо использовать title case, т.е. каждое слово записывать с заглавной буквы.

Нумерация домов

Для высотных домов, нарисованных замкнутой линией, выбираем линию, и добавляем тег addr:housenumber, где ставим номер дома. Если номер дома с буквой, не забываем, что она в кириллице, не в латинице. Проставлять addr:street в дом не нужно. Также не нужно добавлять отдельную точку с номером.

Для частных домов ставим точку, либо если есть желание, рисуем многоугольник поменьше. Последовательности домов можно отмечать по схеме Карлсруэ. Примеры есть в Большой Рогани.

Буквы в номерах домов пишем в нижнем регистре, без дефисов и пробелов. Например, «5б».

Добавление домов в улицу (для JOSM)

Выделяем все веи для улицы, выделяем все дома. Для схемы по Карслруэ важно выделить также и отрезки с тегом addr:interpolation.

Жмём на «добавляем новое отношение» (relation). Оно изображено в виде шестерёнки с плюсом

Прописываем следующие теги для отношения:

type=associatedStreet

В нижней части добавляем все веи и ноды в отношение

Как найду время, сделаю инструкцию со скриншотами (на украинском здесь).
Ещё рекомендую для упрощения работы пользоваться плагином relation toolbox.

Школы, детсады и больницы

Больше информации об учреждениях можно найти на Вики.

Назначаются на всю территорию, не на здание. Добавляем многоугольник, очерчивающий территорию школы. Если территория огорожена забором, то добавляем отдельный многоугольник с тегом barrier=fence.

Территория обозначается таким образом (список не полон):

name=Школа №17 (короткая, понятная надпись, которая будет видна на карте)

official_name=Спеціалізована середня школа І-ІІІ ступенів №17 (полное официальное название как в документах)

name:en=School 17 (короткое название по-английски, символ нумерации не ставится)

name:ru=Школа №17 (короткое название по-русски)

Для учебных заведений нового типа:

name=Багатопрофільний ліцей (учебное заведение типа «ліцей» только одно)

name=Гімназія №4 (в городе несколько «гимназий», у этой нет профиля образования)

Адресация (тег addr:housenumber и членство в отношении) задаются отдельно на все корпуса школы/детсада/лицея, которые имеют свой адрес.

Ещё хорошо затем объединить все постройки и границы в relation=site, name=название учреждения. Пример.

Рисование домов (для JOSM)

Для того, чтобы было легче рисовать дома, установите плагин buildings_tools. Он существенно облегчает жизнь.

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

1. Рисуем дома, параллельные улице.

У такого здания уже автоматически проставлен тег building=yes

2. Рисуем дома сложной формы

Чаще всего такие дома состоят из нескольких квадратов, ориентированных одинаково, либо под углом. Длинные «колбасы» домов соединены меньшей ширины перемычками, часто в этих перемычках находятся тоннели.

Иногда после объединения, особенно в случае сложных конфигураций, здание целиком или его часть, пропадает. Это глюк «объединялки». Отмените операцию (Ctrl+z), выделите только часть прямоугольников, и объедините. Затем объедините получившиеся более сложные многоугольники, т.е. проведите операцию в несколько этапов.

Также часто после объединения создаются лишние точки на прямых. Их лучше удалить.

Иногда дом выглядит кривовато, без прямых углов. Выделяем такой дом, и жмём ‘q’ (Orthogonalize shape). Дом будет выровнен.

Часто в микрорайонах есть несколько школ, садиков или даже групп домов одинаковой конфигурации. Не забывайте о буфере обмена (Ctrl+C/Ctrl+V), и поворачиваем здание, если нужно (Ctrl+Shift+drag)

POI (Points of Interest, точки интереса)

Этим термином называются все объекты, которые люди могут искать по именованию или назначению. К примеру, кафе, памятники, магазины, учебные заведения и т.п.

Если POI находится целиком в одном здании, то задаём все теги именно на этом здании. Отдельно дублировать точками не нужно.

Если в здании находится несколько POI, то на здании наносится только основное назначение, остальные же добавляются в виде точек. К примеру, театр, в помещении которого есть кафе. Ставим «театр» на здание, «кафе» на точку. Пример.

В виду того, что уже доступны высококачественные снимки, хорошо по ходу нарисовать и само здание, и POI расставить там, где они примерно находятся. Особенно если, к примеру, есть длинное здание, и магазин находится на каком-то из его концов.

Если POI занимает несколько зданий, то добавьте многоугольник для всей территории, и проставьте теги на нём. Т.е. см. пункт выше, про школы и детсады.

edit: Уточнил информацию по школам
edit2: Добавлена секция про POI, исправлена грамматика
edit3: Добавлена информация по смещению домов на подложках и даны ссылки на стандарты именования
edit4: Добавлена информация о building:levels, улучшено форматирование
edit5: Уточнил теги для улиц
edit6: Добавил про буквы в номерах домов
edit7: Добавил про двигание подложки
edit8: Обновил правила добавления отношения для связи улица-дом.
edit9. Добавил ссылку на соглашение о классификации дорог и валидатор связности
edit10: Уточнен тип отношения для адресации
edit11: Убрано упоминание josm megapack, добавлена ссылка на видео
edit12: Больше ссылок на Вики
edit13: Виправлено посилання на валідатор; додано посилання на повідомлення про «Зв’язаність дорожнього графу»

Last edited by andygol (2016-12-23 14:18:25)

Источник