OpenStreetMap
OpenStreetMap - это свободно редактируемая карта всего мира.
Web система сбора данных об ошибках OSM (название проекта - "OSM").
Содержание |
Типовой жизненный цикл вопроса в Mantis
Following is the explanation of what the standard statuses that are shipped with MantisBT
means.
- New - This is the landing status for new issues. Issues stay in this status until they are assigned, acknowledged, confirmed or resolved. The next status can be "acknowledged", "confirmed", "assigned" or "resolved".
- Acknowledged - This status is used by the development team to reflect their agreement to the suggested feature request. Or to agree with what the reporter is suggesting in an issue report, although they didn’t yet attempt to reproduce what the reporter is referring to. The next status is typically "assigned" or "confirmed".
- Confirmed - This status is typically used by the development team to mention that they agree with what the reporter is suggesting in the issue and that they have confirmed and reproduced the issue. The next status is typically "assigned".
- Assigned - This status is used to reflect that the issue has been assigned to one of the team members and that such team member is actively working on the issue. The next status is typically "resolved".
- Resolved - This status is used to reflect that the issue has been resolved. An issue can be resolved with one of many resolutions (customizable). For example, an issue can be resolved as "fixed", "duplicate", "won’t fix", "no change required", etc. The next statuses are typically "closed" or in case of the issue being re-opened, then it would be "feedback".
- Closed - This status reflects that the issue is completely closed and no further actions are required on it. It also typically hides the issue from the View Issues page. Some teams use "closed" to reflect sign-off by the reporter and others use it to reflect the fact that the fix has been released to customers.
Входной контроль сообщения об ошибке
1. Проверить поле "суть", в этом поле должна быть кратко описано место дислокации ошибки и характер ошибки.
Примеры правильного содержимого поля "Суть":
- Липецкая - Элеваторная : не хватает поворота направо;
- МКАД-Алтуфьевское : не хватает разворота;
- Носовихинское --> Суздальская : нет участка дороги метров пять.
Примеры неправильного содержимого поля "Суть":
- Ошибка графа;
- нет проезда;
- я худею дороогая редакция.
2. Проверить поле "Подробности", убедиться, что поля "Суть", "Подробности", а так же, возможно, прикрепленная картинка:
- не противоречат друг другу;
- однозначно описывают ситуацию.
2а. При выявлении несоответствий, противоречий или недостатка информации добавить в поле "Комментарии" запрос к инициатору сообщения с указанием что именно противоречит и каких данных не хватает, переадресовать запрос инициатору, присвоив ему статус "Нужен отклик".
2б. Вопросы связанные с необходимостью внесения изменений в конвертер перенести в подпроект "Конвертер OSM -> PocketGIS".
3. Проверить поле "Версия продукта", убедиться в актуальности вопроса для текущей версии карты.
3а. Вопросы, исправленые в текущей версии карты, перевести в состояние "Отработан" с решением "Действия не нужны" и комментарием об исправлении вопроса в текущей версии карты.
4. Проверить значение поля "Категория", при необходимости привести значение в соответствии полям "Суть" и "Подробности".
5. Проверить соответствие поля "Регион" дислокации ошибки.
5а. При отсутствии нужного региона переадресовать вопрос руководителю проекта, снабдив его комментарием о необходимости добавить регион.
6. Проверить соответствие поля "Тэги" дислокации ошибки, при необходимости заполнить или привести в соответствие. Для объектов в Москве и Санкт-Петербурге поле тэги указать наименование улиц (без статусной части), непосредственно примыкающих к месту дислокации, для объектов в остальных регионах по возможности так же отдельным тегом указать назхвание населенного пункта. Название региона в любом случае указывать не следует.
7. Оценить необходимость выезда на местность для уточнения ошибки. При необходимости провести анализ предыдущих сообщений по району дислокации, искать их рекомендуется по тэгам.
8. Назначить "Примерный срок":
- для очевидно простых правок - 2-3 дня;
- для вопросов с необходимостью выезда на местность в Москве - "до 1 недели";
- для вопросов с необходимостью выезда на местность в Московской области - "до 1 месяца";
- для вопросов с необходимостью выезда на местность в других регионах "более 1 месяца";
- для остальных вопросов - "до 1 недели".
9. На основании "примерного срока" назначить значение поля "Целевая версия".
10. Для регионов, по которым известны "диспетчеры", взявшие на себя обязательство по исправлению ошибок в регионе, назначить ответственного, при этом состояние вопроса автоматически изменится на "назначен".
11. Добавить комментарий "Входной контроль произведен".
12. Если ответственный не был назначен, изменить "Состояние" вопроса на "рассмотрен".
Обработка вопросов
Локализация дефектов связности графа
1. Необходимый признак наличия дефекта связности графа - существование очевидно неоптимального маршрута (заведомо избыточного объезда), прокладываемый в режиме оптимизации по критерию "Короче".
2. Способ локализации - метод половинного деления: маршрут разбивается примерно на две равные части, затем проверяется корректность каждого из подмаршрутов. Для каждого неверного подмаршрута процесс рекурсивно повторяется до тех пор, пока не будет локализован проблемный узел.
3. Обратите внимание, ошибок на одном маршруте может быть более одной.
Отслеживание изменений в OSM
- При закачке изменений в OSM правило - один баг = одна закачка. Исправление нескольких багов в одну закачку не складываем.
- номер бага пишем в описании закачки - легче искать потом будет, что наковыряли
