OSM2GarminGUI - создание TOPO карт

Отзовитесь, плз, кто использует эту утилиту для создания Гарминовских карт - ТОПОГРАФИЧЕСКИХ !!!.
Судя по описанию на WiKi - уникальная вещь: и скачивает и обрезает и компилирует и рельеф “понимает” - Srtm2osm.
Мало того - с графическим интерфейсом (на мой взгляд, командная строка - очень сложна в понимании для начинающих - это и Osmosis и Splitter и mkgmap и т.д.).

Вот только как ее запустить?
Я так понимаю она требует больших ресурсов компа, поэтому нужны какие то настройки JAVA-машины.
Спасибо

А зачем оно? “для начинающих” есть готовые сборки. Россия представлена аж в 3.5 вариантах, по миру тоже готовое всё есть.

SRTM под Россию для гармина есть готовое, раздаётся Лёшей на рутрекере. Для заграниц готового не видел, но процесс конвертирования многократно описан (с картинками, это нивелирует сложность командной строки).

Просто если захочется что-то как-то настроить, всё равно придётся долго и упорно ковыряться. И командная строка осмосиса - это не самое страшное :slight_smile:

Если вам нужны топографические карты, то OSM тут не при чем. Наличие горизонталей, сделанных в духе “пачки беломора” не делает карту топографической.
http://forum.openstreetmap.org/viewtopic.php?id=18839 - почитайте, на сколько бесполезен SRTM. Лучше подумайте над тем, как засунуть в навигатор растры ГГЦ, например…

Приличной ТОПО ! карты (естественно для Гармина), например, острова Валаам я не встречал.
Может, конечно, плохо искал:) Но ищу не один год.

SRTM - это только “точка отталкивания”.
OSM проект тем и хорош, что сегодня “белое пятно”, а послезавтра - хорошая карта.
Главный принцип - не только качай, но и что-то ДАВАЙ.
Только поэтому и спрашиваю, только потому и “заморачиваюсь”.

Кстати, насколько я понял, в “чистом виде” изогипсы проектом не поддерживаются.
Или я понял не правильно?
Спасибо.

В OSM нет типов для множества объектов, которые являются частью любой топографической карты. Недавно вон только для горной топографии кое-что добавили (хребты, перевалы…), а так - ни яму, ни холм, ни овраг толком не нарисовать, кроме как суррогатным типом “насыпь”, что есть абсолютно неправильно.

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

Прозрачная карта под Garmin из SRTM есть, как вам уже написали, и к OSM отношения не имеет. Можете пользоваться уже сейчас.

Чем хорош и чем плох проект OSM - я в курсе.

2BushmanK
Я не хотел Вас обидеть, а тем более рассказывать Вам, что тут плохо.
Собственно, мой вопрос был о том, как запустить OSM2GarminGUI на нетбуке с 2 гигами оперативки - возможно это или нет?

Работать на нетбуке оно будет, если виртуальная память не кончится, только я не уверен, что у вас хватит терпения дождаться, когда оно отработает.

А вот это мне всегда было непонятно - зачем с таким упорством отстаивалось, что возвышению не место в базе? Так бы насобирали статистику и можно было бы и о рельефе задуматься. Правда, в треках должна быть полезная информация.

Не изогипсам не место в базе, а чудовищно кривым данным не место.
Я бы сам и холмик и ров нарисовал бы с удовольствием (когда их легко точно измерить). А когда это плюс-минус валенок - к черту такие данные.
С водой проще - эхолотом намерять можно. А элементарный холм будет похож черт знает на что, если его построить интерполяцией по трекам, снятым бытовым навигатором. Это легко обнаружить, если пойти на любой сайт шаринга треков, найти пару горных треков из США и сравнить их с высотной моделью хорошего разрешения, которая там имеется. Будет чуть лучше, чем SRTM в плане детализации, но в смысле точности - такое же дерьмо.

В работе с каждой из утилит по отдельности mkgmap, splitter, osmosis нет ничего сложного, это очень простые утилиты, у них максимум по полтора десятка параметров. srtm2osm давно и безнадёжно устарела, она даже формат выдаёт в лучшем случае api-v0.5. А вот завести это всё в комбайне OSM2GarminGUI я не осилил. Проще научить козу на клавиатуре от бояна писать на питоне, чем этот гуй заставить работать, так что я буду первым в очереди кидать табуреткой в того, кто скажет, что оно “для начинающих”.

Спасибо всем откликнувшимся. Резюмирую.
Изогипсы (возможность определения крутизны склона) - не тема OSM (возможно - пока)
А посему и утилиты для их обработки - не актуальны.

Так как считается, что “тематические” данные вроде DEM или landcover только сильно мешают
редактировать аттрибуты POI и линейных объектов.

Опять же нужны данные о высоте уреза воды, соглашение о системе высот и
методика пересчета из одной системы в другую.
Я уже приводил пример:
http://www.openstreetmap.org/browse/node/1722812340/history
Человек (скопировавший цифру 80,2 м и name из ГШ) врядли сможет рационально
объяснить ее происхождение.

Во всяком случае, одно небольшое озеро в средней полосе можно в конкретный период промерять и получить данные, которые не похожи на задницу, а хотя бы отображают состояние озера на этот момент с точностью, достаточной для рыбалки. Что рыбаки и делают. А с холмиком аналогичных размеров уже, скорее всего, получится значительно хуже. Да и не особо он кому нужен (сравнивая с озерцом), а спрос таки рождает предложение.

Кстати, а всё-таки, относительно чего считает высоту GPS-навигатор?

Относительно эллипсоида WGS84.
http://www.esri.com/news/arcuser/0703/geoid1of3.html

Ссылка правильная, а объяснение неправильное - высота в навигаторе должна быть относительно уровня моря (MSL), а не относительно эллипсоида WGS84. Хотя бы потому что стандарт NMEA - морской, и высоту принято измерять относительно MSL.

см. поля 9 и 11:

GGA - Global Positioning System Fix Data
Time, Position and fix related data for a GPS receiver.

        1         2       3 4        5 6 7  8   9  10 |  12 13  14   15
        |         |       | |        | | |  |   |   | |   | |   |    |
 $--GGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh<CR><LF>

 Field Number: 
  1) Universal Time Coordinated (UTC)
  2) Latitude
  3) N or S (North or South)
  4) Longitude
  5) E or W (East or West)
  6) GPS Quality Indicator,
     0 - fix not available,
     1 - GPS fix,
     2 - Differential GPS fix
     (values above 2 are 2.3 features)
     3 = PPS fix
     4 = Real Time Kinematic
     5 = Float RTK
     6 = estimated (dead reckoning)
     7 = Manual input mode
     8 = Simulation mode
  7) Number of satellites in view, 00 - 12
  8) Horizontal Dilution of precision (meters)
  9) Antenna Altitude above/below mean-sea-level (geoid) (in meters)
 10) Units of antenna altitude, meters
 11) Geoidal separation, the difference between the WGS-84 earth
     ellipsoid and mean-sea-level (geoid), "-" means mean-sea-level
     below ellipsoid
 12) Units of geoidal separation, meters
 13) Age of differential GPS data, time in seconds since last SC104
     type 1 or 9 update, null field when DGPS is not used
 14) Differential reference station ID, 0000-1023
 15) Checksum

Процедура следующая. Внутри приемника координаты считаются в картезианских XYZ, затем переводятся в геодезические LLH (Lat-Lon-Height) на эллипсоиде WGS84. Затем по таблице в firmware приемника вычисляется разница между геоидом и эллипсоидом (значение Geodetic Separation) и эллипсоидальная высота корректируется до MSL. Эта высота выдается по протоколу NMEA в поле 9, а корректировочное значение в поле 11.

Если всё-таки нужна оригинальная высота над эллипсоидом WGS84 (чему сложно найти объяснение, разве только для того чтобы посчитать обратно ECEF XYZ), то нужно смотреть Geodetic Separation и делать соответствующую коррекцию.

В древних приемниках (или их старых прошивках) могло не быть встроенной таблицы геоида, в этом случае действительно высота была эллипсоидальная, в нарушение стандарта NMEA. Узнать это легко - нужно посмотреть поле 11 в GGA, если нам нули - значит высота не по стандарту.

Вот кстати онлайн-калькулятор для geodetic separation. Можете сравнить с GGA, поле 11 должно совпадать с точностью до десятых.

Центр Москвы +14.5м: http://geographiclib.sourceforge.net/cgi-bin/GeoidEval?input=55.75N+37.6E&option=Submit
Челябинск, -12.8м: http://geographiclib.sourceforge.net/cgi-bin/GeoidEval?input=55.15N+61.4E&option=Submit
Тюмень -18.4м: http://geographiclib.sourceforge.net/cgi-bin/GeoidEval?input=57.1N+65.55E&option=Submit

dimonster
Подводя итог - высота в навигаторе обычно идет относительно уровня моря даже в древних навигаторах на Атласе-3 (проверено), но можно убедиться просмотром сообщения GGA или замерами около моря.

В таких случаях использую паралельно несколько карт, а понять свое место на “обычной” карте вполне можно визуально по точноотрисованной жпс-карте, чем ОСМ обычно и является.
Через саспланету скачиваю генштаб-500, ГГЦ-250, спутник-фота, росреестр и т.д. на нужный район. сливаю в большую картинк, нарезаю под фотоаппарат и “в поле” имею максимум информации под руками. удобно и подготовка добра занимает пару вечеров.

Хм, а высота отображаемая gps тоже относительно MSL ??

Да. Она должна очень неплохо совпадать с генштабом (в пределах точности приемника, естественно).

Все ОСМ треки загружены в формате .gpx
Согласно GPX спецификации в gpx тэге находится высота над WGS84 эллипсоидом:


GPX uses the following conventions: all coordinates are relative to the WGS84 datum.

Для вычисления высоты “относительно MSL” есть (опциональный) тэг
но где те программы/устройства которые его используют ?