Fencer_Silver писал(а):Естественно, верю на слово. Только несколько вопросов
1. Для чего высота МОЖЕТ задаваться в метрах (кроме четко описанных в МПС мануале)?
Поскольку польский формат позволяет содержать высоту в метрах - то этим удобно воспользоваться.
При создании карты используются наши растровые карты например, а там все высоты в метрах, и вводить данные удобно в метрах, а не пересчитывать каждое значение в футы.
Fencer_Silver писал(а):
Я имею ввиду - это глюк МПС, или это глюк навигатора или просто недоописаный момент в мануале к МПС?
Нет это не глюк, это давно известный способ задания высот (через суффикс), который широко использовался при создании карт с помощью cGPSMapper, и данный способ аналогичным образом работает и в МПЦ, просто в мануале к МПЦ он не документирован. Хотя и в официальных картах Garmin, данный прием широко используется.
Fencer_Silver писал(а):
2. Все ли навигаторы должны иметь это в футах?
Да, все высоты во всех навигаторах должны быть в футах, за исключением поля "Height=" (HGT_DP) у морских объектов и зданий, для которых еденицы задаются в специальном поле: "HeightUnit=" (HGT_DP_FMT).
Fencer_Silver писал(а):
Для чего вопросы: если это особенность каких - либо навигаторов или глюк, считаю ЛОГИЧЕСКОЙ ошибкой поддерживать принудительный перевод всех высот в футы!!!
Нет, это не особенность каких отдельных моделей, так работают все навигаторы и весь Гарминовский софт (MapSource, BaseCamp и прочее).
Fencer_Silver писал(а):
Есть инструмент - можно перед конвертированием перегнать. А лучше карту делать в тех единицах, в каких требует данный навигатор.
Да, абсолютно согласен, можно воспользоваться этим инструментом. Содержать в единицах которые требует навигатор - не удобно при вводе данных и внесении исправлений, потому как в наших источниках данные обычно в метрах. А поскольку для указанных объектов высота в шейпах должна быть только в футах, то при экспорте есть смысл конвертировать в футы автоматом. А
если конвертировать высоты, то делать это для всех объектов, содержащих высоты в поле Label (а их перечень известен),
либо не делать конвертирования вообще. Конвертировать только часть высот - не логично и не имеет ни какого смысла.
Ну и понятно, что часть объектов должны содержать в поле label только числовое значение высоты и ни чего более - это горизонтали, изобаты и точки 0х6200 и 0х6300. А другой части типов, высота может задаваться только через суффикс. Если суффикса нет, то поле label считается текстовым, и даже если оно содержит только цифры, то с ними ни каких действий выполняться не должно - это типы точек 0х64** - 0х66**.
Fencer_Silver писал(а):
Имхо - это то же самое, как разрешить переопределять стандартные типы.
Аналогия уместная, но применена не верно.
А именно. В польском есть HEX ID, в шейпах - GRMN_TYPE. В польском могут быть высоты в метрах, в шейпах высоты только в футах. При экспорте в шейпы все HEX ID преобразуются в GRMN_TYPE, по жесткой таблице. А все высоты при экспорте преобразуются из метров в футы по однозначной жесткой формуле: 1 м = 3.28 ft - такой подход - верный.
А вот когда часть высот преобразуется в футы а часть нет (как сделано сейчас), это все равно, что часть типов преобразовать в GRMN_TYPE, а часть оставить как есть - HEX ID. А это, согласись, не правильно.
Fencer_Silver писал(а):
Если это не глюк, а недоописанный момент МПС и так все и останеться в последующих версиях - значит поддержим.
Нет это не глюк, а недоописанный момент в мануале МПЦ.
Добавлено спустя 8 минут 25 секунд:
Fencer_Silver писал(а):Дима, десток страниц выше, если помнишь, мы обсуждали этот вопрос. 0x4b - надо проверять отдельно! Так как он пересекается АБСОЛЮТНО со всеми полигонами карты!
Если я правильно понял, речь идет не о проверке пересечения с другими полигонами - из этой проверки полигон 0х4b действительно можно исключить. Речь идет о само пересечениях, джитерах и дубликатах узлов в самом полигоне 0х4b, и эти ошибки, на мой взгляд, обнаруживаться должны.
В Notepad++ их уже нет!
Всегда где-то рядом. Если что — найдём решение.
