(уже не актуально, большинство проблем решено)

Что нам пригодится:

1. легальный источник в виде растрового изображения у которого есть полезное применение
2. любимый JOSM https://josm.openstreetmap.de/josm-latest.jar
3. дополнение PicLayer (рекомендую BuildingsTools для зданий, imagery_offset_db чтобы не рисовать в разнобой а с одним смещением на город, UtilsPlugin2) и measurement чтобы проверять пропущенность объектов если в оф. документах указаны “ГА” (тег area:ha=*) и “метры” .

Примечание: смысл этой статьи сохраняется если заменить “снимок Bing/Mapbox” и “обычную подложку” на “сырые данные из OSM”.

Что делаем:

1 Открываем JOSM, но лучше запустим его дав побольше памяти (“java.exe” -Xmx4096M -jar “josm-latest.jar”)

2 создаём слой (ctrl+N)

3 в меню JOSM: Imagery > New picture from file. Растр должен загрузится в отдельном слое. На 4мб растр у меня скушал 1,6Гб.

Чтобы выровнять растр нам нужно сделать слой растра активным: если “глазик” это видимость слоя, то зеленая стрелочка - активный слой.

Если растровый слой не видно, значит он “ниже” в списке слоёв: можно либо полностью отключить глаз у вышестоящих слоёв. Либо изменить прозрачность (ч/б градиент). Либо просто поменять местами слои.

4 Делаем нужный растровый слой активным и используем простые инструменты (PicLayer scale, Piclayer rotate, Piclayer move) до тех пор пока растр не будет “где-то здесь”:

Далее нам нужно уменьшить альфа канал чтобы было проще искать точки привязки. Точки привязки нужно три, советы:

• как можно дальше друг от друга на растре
• не на одной прямой, площадь треугольника из маркеров лучше увеличивать насколько это позволяет качество растра
• проверяемы на земле если у вас не будет спутниковых снимков (рельсы, монументы, фонтаны, памятники, неизменяемые реки, неизменяемые пересечения узких улиц, любые не изменяемые десятилетиями объекты)

Если нажать инструмент с зеленой стрелкой то вам отобразятся все текущие точки и их местоположение. Изначально их ноль.

Точки можно удалять отдельным инструментом. Зеленая стрелка перемещает точки только на растре. Красная используется для подгонки маркера уже на основном слое: она трансформирует растр или просто перемещает его если точек мало

5 Найдём сначала на растре (красный квадрат), а потом и снимке (розовый квадрат) точки по которым будем совмещать растр и обычную подложку.

6 Добавим первый маркер. Выбираем зеленую стрелку (инструмент называется PicLayerMove) кликнув в зону красного прямоугольника на растре. Теперь нам нужно соответсвие на карте. Выберем красную стрелку (PicLayerTransform) и поставим первый маркер в розовый прямоугольник.

7 Отлично, первый маркер готов. Повторяем этот процесс три раза и получаем привязку.

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

Почему такое может быть?

• произвольно искажённые снимки Bing/Mapbox
• сильно искажённый растр

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

9 Калибрацию нужно сохранить, потому что после закрытия JOSM она потеряется (даже в режиме сохранения сессии). Для этого нужно щелкнуть правой кнопкой мыши по нужному нам растру (не космоснимкам) и выбрать “Save Picture Callibration…”.

Если калибрация сохранена в ту же папку и с именем которое предлагается по умолчанию, то она будет загружена при повторном открытии растра автоматически

(далее нужно вводить данные как обычно и использовать оффсет из imagery_offset_db)

Не забывайте про теги [source=](http://wiki.openstreetmap.org/wiki/RU:Key:source) и source:date= у пакета правок

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

На сайтах муниципалитетов и других источников можно найти схемы, но актуальность данных всегда должна проверяться. В них могут быть начерчены объекты никогда не имеющие воплощение в реальном мире. Это же “План …” и нужно им понимать как планы, а не реальный мир.

(Please forward this text to right person or place)

There are a lot of problems outside En community when it comes to OSM guideline “just watch Taginfo for popular values”. This approach work more or less for EN community, but users outside English-speaking world faced with the challenge to realize the word, not local word with similar letters\sounding.

I do Russian translation at wiki\ID\communicate with ru community and many ru users do no realize that reading tag values by letters in Taginfo doesn’t work without meaning of the word. it may sound absurd, but it is not written anywhere. Instead we (English speaking world) promote “just watch the most popular values in Taginfo “. This is serious issue outside GB, USA, Canada, Australia. We have way more countries. Even more if OSM want to grow.

1. Promote OSM wiki instead of Taginfo across all non-English languages. Possibly notice should be given at langcode:main page@wiki or every single wiki guide/content should be rewritten.
2. Not Taginfo fault, but Taginfo can fix this. Just add feature to Taginfo to directly show wiki-translated page based on “Accept-Language” header. Force this behavior by default for not-English languages. Yes, ‘'’force displaying wiki pages parallel to previous Taginfo interface’’, but let users switch language (and disable this feature).
3. Everything for English-speaking world stays the same, since this is main language/tagging convention, there no need in changes for GB/USA/Canada/Australia.

Ни один другой картографический сервис или карта не предоставляют пользователям такой возможности.

• Google Maps - нет возможности, вы смотрите только то, что Google вам скажет
• Yandex Карты - нет возможности, вы смотрите только то, что Yandex вам скажет
• Wikimapia - ограниченный функционал и только часть данных.
• <любой коммерческий="" справочник="" с="" претензией="" на="" карту=""> - кто такие вообще?

В OpenSteetMap это есть для рядовых пользователей. Всё, что требуется пользователю, это зайти на http://overpass-turbo.eu/, ввести по желанию теги объектов которые вам интересны в помощнике:

Нацелить экран на любой участок на планете и нажать “Старт”.

Так вы получите только самые последние данные. Чтобы просмотреть данные на любой момент времени нужно добавить к запросу

[date:"2011-01-01T12:00:00Z"]

т.е. 12:00 1 января 2011 либо другой момент времени и вы увидите что было отмечено несколько лет до этого:

Данные OSM всегда принадлежат пользователям.

Любые нужные вам данные.

За любой период.

Всегда.

Идиоты обрисовыющие дороги по Bing у военных объектов и позволяющие прямой роутинг по ним.

http://www.openstreetmap.org/#map=14/52.9451/158.4059

пиздец

пиздец прямо сейчас

Теги “addr:country”=* и “addr:city”=* внутри указанного полигоном города это атавизм. Они реально не нужны и информации в себе не несут. Реально они нужны только для объектов которые находятся вне границ населённых пунктов. Т.е. вне полигона, в таком случае они действительно нужны, ибо официальную границу нельзя просто так взять и “перетянуть” на один дом или посёлок. Либо наоборот, когда внутри города есть объекты которые причастны к другому городу по какой-то причине.

В OSM катастрофически боятся (не умеют) пространственными запросами к БД. Это вводится почти в культ:

- почему мы отмечаем addr:country и addr:city 
- да потому что все так делают
 (типичный диалог пользователей OSM на любом языке за последние N лет)

Одним из доводов указывальщиков “addr:country” и “addr:city” это “потом просто выбирать любые объекты без нужды в гео-пространственных функций”. Возникает вопрос: зачем тогда в OSM есть PostGIS и OverpassAPI (для пользователей)? Зачем все эти заморочки с GPS? Писали бы себе преспокойно в OSM.txt и ничего не нужно было себе усложнять?!!

Выбирать любые объекты внутри именованных закрытых путей и мультиполигонов через OverpassAPI это просто элементарно. В Overpass IDE (http://overpass-turbo.eu/) для запросов сгенерированных помощником достаточно поменять

<bbox-query {{bbox}}/> на 

<area-query ref="XXXXXXXX"/>

Где XXXXXXXX это OSM идентификатор закрытого пути (way) либо мультиполигон плюс константа. Для мультиполигонов нужно прибавить 3600000000. Для закрытых путей 2400000000. area-query ref работает не для всех объектов (детали здесь), а для тех, у которых есть name=*. В случае городов это всегда-превсегда так, т.е. боятся нечего и отговорок быть не может.

Вот так выглядит запрос для поиска всех действующих фонтанов в Саратове (отношение мультиполигон 3955288). Попробовать можно здесь.

<osm-script output="xml" timeout="25">
  <union>
    <query type="node">
      <has-kv k="amenity" v="fountain"/>
      <area-query ref="3603955288"/>
    </query>
    <query type="way">
      <has-kv k="amenity" v="fountain"/>
      <area-query ref="3603955288"/>
    </query>
    <query type="relation">
      <has-kv k="amenity" v="fountain"/>
      <area-query ref="3603955288"/>
    </query>
  </union>
  <print mode="meta"/>
  <recurse type="down"/>
  <print mode="meta" order="quadtile"/>
</osm-script>

На самом деле всё еще проще: вам нужно указать в помощнике http://overpass-turbo.eu/

amenity=fountain in "Саратов"

И он сам найдёт первый самый подходящий результат через Nominatim и будет использовать его в качестве area-query.

Всё.

An infographic of the accuracy of the GPS running watches. The top right corner represents the most accurate watches. (This graphic uses ISO 5725 terminology.) Source: GPS Accuracy of Garmin, Polar, and other Running Watches

Sensor Fusion on Android Devices @ Google Tech Talk August 2, 2010

Текст перенесён в вики. Все изменения будут происходить там.

Эта запись со временем будет удалена, просьба исправить ваши ссылки и закладки.