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

Кто-то обрисовал трек, как дорогу. Возможно, это трек от лодки.

Всё там правильно, это зимник.

лол.
Может по льду? В тех краях, наверное, с дорогами не густо, так что даже сезонная за tertiary сойдёт.

Как строится индекс Nominatim: http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Indexing_.2F_Address_Calculation

кстати, relation type=street тоже поддерживается nominatim?

Судя по


if (!strcmp(type, "associatedStreet") || !strcmp(type, "relatedStreet"))
   {
      Options->mid->relations_set(id, members, member_count, tags);
      return 0;
   }

из http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/output-gazetteer.c - обрабатываются только associatedStreet и relatedStreet. Странное решение, relatedStreet встречается всего 2903 раз, а street 9779 раз.
Надо написать им в багтрекер об этом.

http://trac.openstreetmap.org/ticket/3691 - создал вроде как, посмотрим, что из этого будет :slight_smile:

я тут весь свой город недавно перевел на street вместо associatedStreet, волнуюсь…

ponzu
Nominatim в России работает хреново, по той простой причине, что он не поддерживает нормально мультиполигоны. Вернее как-то их поддерживает в одном единственном случае - для схемы boundary & admin_level. Всякие мультиполигоны place соответственно идут лесом. Многие несоответствия в поиске идут как раз от этого. Ну и кроме того, там в общей базе, похоже, данные испорченые - оттуда принадлежность США и лезет. Автору либо не до того, либо ваяет новую версию, а старую забросил. Вот так и живём. :slight_smile:

Larry0ua
Может это слишком рано было делать?
Я нашёл ещё такой код:


LOOP
          -- At the moment we only process one type of relation - associatedStreet
          IF relation.tags @> ARRAY['associatedStreet'] AND array_upper(relation.members, 1) IS NOT NULL THEN
            FOR i IN 1..array_upper(relation.members, 1) BY 2 LOOP
              IF NEW.parent_place_id IS NULL AND relation.members[i+1] = 'street' THEN
--RAISE WARNING 'node in relation %',relation;
                SELECT place_id from placex where osm_type='W' and osm_id = substring(relation.members[i],2,200)::integer 
                  and rank_search = 26 INTO NEW.parent_place_id;
              END IF;
            END LOOP;
          END IF;
        END LOOP;      

--RAISE WARNING 'x1';
        -- Is this node part of a way?
        FOR way IN select id from planet_osm_ways where nodes && ARRAY[NEW.osm_id::integer] LOOP
--RAISE WARNING '%', way;
        FOR location IN select * from placex where osm_type = 'W' and osm_id = way.id
        LOOP
--RAISE WARNING '%', location;
          -- Way IS a road then we are on it - that must be our road
          IF location.rank_search = 26 AND NEW.parent_place_id IS NULL THEN
--RAISE WARNING 'node in way that is a street %',location;
            NEW.parent_place_id := location.place_id;
          END IF;

          -- Is the WAY part of a relation
          FOR relation IN select * from planet_osm_rels where parts @> ARRAY[location.osm_id::integer] and members @> ARRAY['w'||location.osm_id]
          LOOP
            -- At the moment we only process one type of relation - associatedStreet
            IF relation.tags @> ARRAY['associatedStreet'] AND array_upper(relation.members, 1) IS NOT NULL THEN
              FOR i IN 1..array_upper(relation.members, 1) BY 2 LOOP
                IF NEW.parent_place_id IS NULL AND relation.members[i+1] = 'street' THEN
--RAISE WARNING 'node in way that is in a relation %',relation;
                  SELECT place_id from placex where osm_type='W' and osm_id = substring(relation.members[i],2,200)::integer 
                    and rank_search = 26 INTO NEW.parent_place_id;
                END IF;
              END LOOP;
            END IF;
          END LOOP;

в http://svn.openstreetmap.org/applications/utils/nominatim/sql/functions.sql. Значит обрабатывается только
associatedStreet.
PS: как-то обсуждение вышло за рамки темы. Можно его перенести или выделить в другую тему?

iONiX

переносить в другую тему - это наверно к модератору…

поднять баг надо все равно, вдруг пофиксят хоть сколь-нибудь быстро? а переименовывать отношения видимо да, рано было

Я про баг. Видимо править надо не http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/output-gazetteer.c , а http://svn.openstreetmap.org/applications/utils/nominatim/sql/functions.sql . Хотя, может одно от другого зависит. Добавил соответствующий коментарий.

Спасибо, что не послали в сорс :slight_smile: Изучаю.

Верьте, в США работает не лучше - просто волосы дыбом. Во-первых, если коряво размечен объект в OSM, Nominatim это усугбляет. У меня есть пример, когда один и тот же замкнутый вей разметили и как place=city, и как admin_level=8 (что есть уродство, конечно). Добрый Номинатим при импорте создал для этого вея два разных объекта и раздал им детей как бы наобум.

Во-вторых, даже если объекты нарисованы размечены более или менее продуманно (как уже не раз упоминавшаяся схема “полигон для границы + точка для метки”, он умудряется так раздать им детей, что поиск и адресация выглядят довольно случайно. И это при том, что все мультиполигоны нормальные.

Точки вообще не должны иметь детей, если есть полигон. Они их имеют только потому, что однажды в дремучую пору были только точки.

Но ребята действительно по слухам работают над v2. Может, там все это решено. Может, не париться? Я все жду, когда мне дадут этот совет. Пока пытаюсь дать его сам себе, но не получается.

По исходникам новой версии (если это оно - http://svn.openstreetmap.org/applications/utils/nominatim/nominatim/) не совсем понятно, собираются они выкидывать код gazetteer-а или нет. Собсно вся проблема с мультиполигонами лежит в исходниках именно gazetteer-а.

Что такое gazetteer, и с чем его едят, мне еще предстоить узнать. Но мне хватило того, как я погряз в Номинатиме. Воистину, чем меньше знаешь, тем крепче спишь. Мапил бы и мапил. Контур нарисовал, отношение создал, админ_level выбрал, place-точку поставил, admin_centre добавил, следующий.

А ведь кстати, на мой вопрос новичка так никто не ответил. Я, правда, не жалуюсь, поскольку беседа получилась более чем увлекательная. Ничего, если я повторю? Нумерую специально, чтобы можно было ответить на любой из пунктов, если не на оба.

  1. Можно ли заставить рендерер (любой, хотя я 99% смотрю на Мапник) нанести название места (города, области и т.д.) на карту, если не использовать для этой цели точку place? (На этот вопрос, по-моему, даже не пробовали отвечать).

  2. При наличии полигона – правильно нарисованного и правильно размеченного как place или boundary=administrative – есть ли причина вдобавок ставить точку place, обозначающую то же самое поселение, кроме как в целях отображения названия этого поселения?

Попытка ответа на последний вопрос свелась к указанию очевидной разницы между поселением и административным образованием и быстро увела в дебри, поскольку началось обсуждение схемы boundary=administrative и в скором времени Номинатима. Поэтому лучше про административный и другие центры не повторять. Для этого, как мы выяснили, есть роли admin_centre и label.

Если бы я отвечал на эти вопросы, я бы сказал:

  1. Нельзя. В самом лучшем случае Мапник пишет name полигона (как бы круто он ни был размечен) на его границе и мелкими буквами вне зависимости от ранга. Т.е. полигон области и полигон города при низких Z вообще не будут иметь названий, а при высоких эти названия буду написаны одинаковым мелким шрифтом в случайно выбранном месте на границах. Новую роль label в отношении boundary они либо проигнорировали, либо она работает только для точек place, а в таком случае на фиг она нужна, они и так рисуются. Все это установлено опытным путем с использованием всевозможных схем разметки, кроме использвоания точки place. Может, я не попробовал какую-то из схем, или что-то непрорендилось вовремя, но не думаю.

  2. Не знаю, но подозреваю, что иной причины нет.

Но это только мои догадки, поэтому я и пришел учиться мат части у самой продвинутой и активной фракции OSM. Благодарю за теплый прием, кстати.

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

Пробую. Размечаем, полагаю, мультиполигон? Или добавить члена, размеченного как place?

Попробовал. Вы не ошибаетесь, но не совсем правильно поняли вопрос. Задача не в том, чтобы среденрить имя полигона, это не так сложно, но и не так интересно. Задача в том, чтобы срендерить название place в соответствующем стиле. Если область - то крупными буквани, и видно с низких Z. Если город, то поменьше. Дервеня, субурб, гамлет - у всех свой размер фонта и критерии Z.

А то, что я с вашей подачи протестировал, это просто навание area, заключеной в полигоне. Того же результата можно было добиться, задав полигону (или мультиполигонному отношению) landuse. Фонт вне зависимости от ранга place один и тот же и виден только на высоких Z.

До ли дело, если рядом поставить точки place=county, place=city, place=town, place=suburb, place=hamlet. Сразу видна разница.

Пока моя теория подтверждается. А хотелось, чтобы опровергли.

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

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