9681

ИМХО, от самого автора примерно раз в 10 больше шансов получить разрешение, чем от Роскосмоса.

9682

GT21, адресации на чувашском нет, потому чтто ее никто не делал :slight_smile: да и названия улиц на чувашском проставлены от балды и вразнобой, то есть “ураме” (улица по чувашски) то нет, .

9683
  1. почему урамӗ нет?
  2. почему чернышевски, а не чернышевский?
  3. почему от балды и вразнобой?
9684
  1. хз, я name:cv не ковырял ни разу.
  2. глянул в хистори, нынешний name:cv проставил pentile, можешь его спросить.
  3. потому что даже по городу натыкаюсь на name:cv в нескольких различных “стилях” написания.
9685
  1. оригинал документа не нашел, но есть официальный список названий. все эти названия я уже давно проставил в ЯК
    http://comissi.chv.su/ru/node/29
9686

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

9687

и все же - к чему этот разговор про чувашский? это как-то относится к моим косякам?

9688

Удалить может тогда этот way - надоел он мне. Его ни кто не поддерживает толком. У Иртыша riverbank тот же очень сильно меняется с каждым годом

9689

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

9690

вопрос не про контур реки riverbank, а про отдельный way который в некоторых местах выходят за границы riverbank

9691

Вопрос по обозначению POI.
Типичная ситуация - есть контур здания с building=yes, внутри здания есть POI.

Как я понял, есть 2 подхода к обозначению POI:

  1. На контуре здания, если здание целиком занято этим заведением (больница, например).
  2. Точкой внутри контура здания, на точке уже обозначаются теги POI. При этом желательно, чтобы координаты отображали местоположение POI внутри здания. Этот способ не выглядит особенно адекватным для многоэтажных офисных зданий, где точки интереса - офис 306 на 3 этаже.

Почему не используется способ через какое-нибудь отношение вида “POI находится внутри здания” (т.е. обозначаем принадлежность точки к зданию без геометрии)?

Ну, например:


relation:
    type=inside
    container=(way, здание)
    entrance=(point, точка входа)
    position=(point, расположение внутри)
    floor=этаж

    shop=тип магазина
    ...
9692

Как это отношение поможет отобразить два пои в одном месте на разных этажах?

9693

1 POI = 1 отношение, у каждого отношения - свои теги, относящиеся к POI.
Т.е. для здания имеем список отношений, что находится внутри.

Отобразить - например, в навигаторе: клик на здании - “Что внутри?” - список.

Или так не получится?

9694

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

9695

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

9696

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

За счет этого:

  • тег floor выглядит адекватно (отношение жестко привязано к зданию, уточняем - где конкретно).
  • связь с точкой entrance выглядит адекватно (чтобы попасть в POI, нужно войти через точку entrance)
  • если мы хотим (опционально, если это можно адекватно узнать и нарисовать) указать где именно находится POI, то делаем связь с точкой position. Причем для одной точки position может быть несколько привязанных relation’ов (отличающихся тегом floor, например). Если же мы не знаем, как адекватно изобразить местоположение - не указываем. Тогда отношение означает “где-то внутри”.

С аргументом “не будут поддерживать” - не согласен. Например, если добавить в MAPS.ME при клике на здание “Добавить организацию” - это проще, чем выцеливать крестиком точку (особенно при 3D виде). Ошибок “не попал в контур здания” гарантированно не будет.

В целом позиция понятна, спасибо.

9697

Геометрия привязана к зданию так же жёстко :slight_smile: так что floorlevel в любом случае выглядит адекватно.
Связь пои с входом должна обеспечиваться геометрией возможных проходов внутри. Вы же не собираетесь связывать каждый дом в населённом пункте к точке въезда в него. Так и тут в здании должен работать обычный роутинг по коридорам.

9698

Map Nrg
Замечательная статья в тему: http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories
Кратко: не надо создавать отношения если объекты можно выделить поиском по тегам или по геометрическим границам. Это не догма но хороший стиль. Не надо заставлять редактора-картографа дублировать информацию, это неизбежно приведет к ошибкам. Пусть конвертер сам анализирует вхождение геометрий.

Возможно вы не в курсе, многие конвертеры (в частности osm2mp, на котором делается значительное количество карт для навигаторов) переносят теги с внешних контуров на внутренние, например такие адресные данные как Страна, Область, Район автоматически переносятся с полигона place на все внутренние здания и улицы. В свою очередь адресные теги со здания, включая номер дома и улицу, переносятся с контура здания на все попавшие внутрь него POI и т.д. думаю смысл понятен.

9699

Возможно ли “вырезать” GPS трек типа “Каша” из данных GPS на OSM?

9700

Из локального просмотра - можно. В JOSM-е есть фильтр треков.
Из базы - нет. AFAIK.