Еще вот тут на веселые картинки с Эльбрусом взгляните, для общего образования http://forum.openstreetmap.org/viewtopic.php?pid=419475
Интересный момент, вот данные крайней точки в GPS треке:
Longitude: 77.036548
Latitude: 43.024600
Altitude: 4290.021 meters
Последняя SRTM горизонталь 4250м. Прибавляя погрешность, получается 4291м!!!
Расчет погрешности верен, но высота все равно не совпадает с эллипсоидом Крассовского (Балтийской системы высот), разница в 26м.
Нет, так считать нельзя, как вы это сделали. Во-первых, SRTM, по причине сравнительно низкого разрешения, вообще не обязан содержать в верхней точке высоту, которая совпадала бы с высотой пика, потому что, очевидно, он там содержит некое среднее значение для области размером порядка 100х100 метров. Во-вторых, вы и значение с советской топографической карты не считайте, пожалуйста, эталонным. Ровно как и то, что показал ваш приемник - у него по высоте погрешность гигантская.
К большому сожалению, NASA пока не опубликовали SRTM 1-arcsecond на регион, покрывающий южную часть России и Ближний Восток, так что посмотреть, как выглядит там что-то кроме Памира - пока нельзя.
Если бы трек был записан на вершине в течение какого-то времени - показания GPS хорошо пробились бы с официальным значением. У некоторых туристических гарминов GPS-высота смешиватся с показаниями барометра, требуется некоторое время чтобы высота стабилизировалась.
Также в этом гармине могла быть установлена система координат не WGS-84, а какая-то иная (туристы любят менять, чтобы плоские координаты хорошо совпадали с Генштабом). И тогда прощай все наши расчеты EGM96, балтийской системы высот и т.д.
Я исходил из соображений, что если нет еще одной горизонтали, значит там высота (усредненная) не выше 10м
Спасибо конечно за емкий ответ, только что мне делать? Вписывать высоты из справочников? На WGS84 - это будет считаться враньем…
Пересчитывать? Каким образом?
Есть мысли?
Они, судя по всему были какое то время там… пока фотографировались… и т.д… В треке 2 точки на вершине и в них высота не сильно отличается.
На сколько я понимаю, хранение данных у приемника всегда в одном формате, все датумы это пересчет “на лету”… Плюс, на сколько помню, при сливе в MapSource координаты автоматом в датум карты (WGS-84) конвертят. Или ошибаюсь?
Установка пользовательской системы координат в навигаторах не должна влиять на содержимое треков в GPX (потому что он предполагает WGS84), но хрен их, конечно, знает.
Для сколько-нибудь значимого усреднения нужны периоды в десятки минут, тут об этом речи не шло.
А что вообще за вопрос “что делать” - если что-то - неизвестно, или непонятно, как интерпретировать источник, мы это просто не вносим в базу. Вас кто-то заставляет все это внести?
Не надо ничего пересчитывать. Одновременно используются два разных датума - для плоских координат и для высоты.
Высоты в Балтийской системе очень мало отличаются от высот модели EGM96 - метр или полтора, не более.
А эллипсоидальная высота WGS84 не используется нигде кроме как внутри приёмника или геодезическом софте т.к. она не совпадает с уровнем моря.
http://forum.openstreetmap.org/viewtopic.php?pid=378406#p378406
Что касается координат в гарминовском треке - гармин записывает трек в пользовательском датуме, поэтому если установлен пересчет на СК-42 - трек будет хорошо ложиться на генштаб и плохо на спутниковые снимки. По Казахстану часто встречаются старые треки, лежащие в стороне от дорог.
(added)
Резюмируя - официальная высота пика определялась нивелированием, т.е. очень точно гнали ходы “от уровня моря” в Балтийской системе высот. Эта высота является эталоной, надо к ней подгонять горизонтали SRTM, а не наоборот. Недаром на многих вершинах стоят геодезические пункты.
Это уже внесено до меня.
chnav, я тебя понял.
Мне кажется или oneway=yes к рельсам вообще неприменимо?
https://www.openstreetmap.org/way/315715873
Для рельс выдумали такое. Но вообще в России я не видел реальных примеров где действительно так. По двухколейкам поезда ходят в обе стороны. Ну разве что на трамваи можно повесить.
Именно.
Аналог oneway для ж/д - railway:bidirectional=possible, означающий, что движение отличиное от направления вея возможно только с полным закрытием перегона и отключением сигнализации.
скажите -= знатоки - а второй альбом- АТЛАС и последующие… :(типа как у Новитела)- в ОСМАНДЕ сварганить можно и если да то как ,??? и где можно подобрать карты для ОСМАНДА -1.8.3=для другого АТЛАСА :(уж больно много сейчас 5.6гиг):D==???===:rolleyes: Можно ли создать на СД папку - в которую скопить – нужные файлы ОБластей–СКАЖИТЕ ТОЛЬКО =OBF=файлы нужны или еще какие.??? Затем в дериктории указать путь к этой папке ну типа -ДРУГОЕ=storage1/sdcard=ПАПКА- и все да???
Вопрос по границам. Увидел в вики, что кроме того, что теги границ есть в мультиполигоне, они же могут накладываться и на сами линии. НО одна и та же линия используется для нескольлких административных единиц. Админ левел тогда указывается наименьший на линии? Или лучше стереть с линии теги границ?
И с этим связанное. Часто несколько регионов, сельских поселений объединяются. Остается старая граница. Какова практика, как с ней поступить? Удалить? префикс какой-то типа abonded;?
Мне кажется надо указывать самый старший админлевел, непонятно из каких соображений в вики пишут про наименьший. Ошибка пользователя таких данных будет особенно опасна в случае госграницы.
По-моему они там не нужны. На свои не ставлю, где есть — специально не удаляю, со временем сами отомрут при уточнении границ.
Сложившейся практики по-моему нет. Я сейчас делаю boundary=historic + historic:admin_level=XXX. Ну и end_date можно. Как-то так: http://www.openstreetmap.org/relation/1378469
Наименьший — это и есть старший.
По-моему корни растут ещё в потланчера, где показывалась линия без тега, и чтобы по ошибке её не удаляли на неё вешали хоть какие-то теги. В современном мире они(теги) там мало полезны.