blog.lexa.ru

Продолжение к вот этой записи, на тему современных веяний:

1. Современные тулзы (свежая версия map2jnx - обязательно, SAS.Planet - опционально) генерируют JNX v4, который в относительно свежих прошивках (я развлекался с 3.90) поддерживается нормально.
2. Для свежих прошивок нужен свежий патчер. Берут отсюда.
3. Рекомендованная в предыдущей записи jnxscale (для установки масштаба) с JNX v4 нормально не работает (получается карта, которую прибор не видит), надо пользоваться JNX Customizer (берут, как и jnxscale, с gpsunderground).

   К сожалению, JNX Customizer не правит существующий файл, а записывает новый. Т.е. быстро поправить масштаб прямо на приборе - нельзя. Неудобно, да. Еще неудобно то, что 3-значные ProductID показываются в 2-значном окошке.

4. Многослойные и многотомные файлы, генерируемые SAS.Planet - технически работают нормально. Масштаб им тоже можно править (каждому слою отдельно), для многотомных - я правил во всех томах (поправить только в одном - не пробовал).
5. Большие многотомные-многослойные файлы на приборе (Garmin GPSmap 62s) тормозят. Сильно тормозят. Почти такие же многотомные и однослойные - тормозят меньше. Они и рекомендуются к использованию. Естественно, им полезно ставить разные ProductID, чтобы независимо включать-выключать.
6. Других проблем с генерацией JNX-ов SAS-планетой не обнаружено. Да, оно генерирует медленно, но стандартный путь (склейка в ecw, конвертация проекции в GlobalMapper, сохранение в GeoTiff, конверсия map2jnx) - еще гораздо медленнее.

   Ну то есть хотелось бы, конечно, ProductID для снимков ставить по своей системе, но и предлагаемый выбор 0-9 вполне удовлетворяет на практике.

7. 32-гиговая карточка в приборе - прекрасно работает.
8. 20 гигов карт (преимущественно снимков, конечно) - прибор медленно стартует. Может и жрет больше, не знаю.
9. Правильный набор растров (при наличии комплектов карт):
   • Обзорный снимок (масштаба z11 или z12)
   • Набор карт от 5(10)-километровки до 500-метровки. Можно и крупнее, наверное, но на планируемый район у меня 25-тысячной нет, сказать не могу.
   • Снимки z16 или (если есть) z17, детальнее, по всей видимости, нужны редко (а места жрут мешок). Более детальные снимки - только на индивидуальные тонкие места.
10. Если засунуть в map2jnx очень большой растр, то он делает не многотомный JNX (как SAS-Планета), а JNX с большими тайлами (512x512 в моем случае). Делает оно это НЕОБЫЧАЙНО медленно. Я ни разу не дождался, быстрее порезать этот растр на куски и сделать отдельные JNX.

У меня внезапно сработала напоминалка о том, что

• У меня счетчики на воду
• 23.05 заканчивается договор на обслуживание
• И надо дойти до соседнего дома и его продлить.

Позвонил туда (отдельное приключение было - найти телефон, сам договор я так и не нашел, только акт приемки-сдачи от него, без координат), да, действительно, надо дойти, продлить и 360 рублей за год заплатить.

Отсюда следующий вопрос:

Я уверен, что у 99.9% сограждан - такой напоминалки в календаре нет и они ничего не продлевают.

Какой сюрприз их ждет в результате? Секут розгами, сажают в долговую яму, глумятся каким-то еще способом? Что будет, если я забью, до соседнего дома не дойду и 360 рублей пожалею?

Вопрос исключительно мАсквичам (наверное) и только тем из них, у кого обслуживание счетчиков не включено в счет за воду.

Update: по единогласным рекомендациям, решил забить.

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

Но в очередной поездке хочу таки попробовать, интересно же (хотя не факт, что фазы луны позволят мне).

Вопрос же у меня, собственно, такой: А экспозиция то какая?

Из общих соображений, казалось бы, ISO ставим в Unity Gain (т.е. 400 для 5D2), диафрагму пошире, а выдержку - такую, чтобы за время экспозиции звезда прошла бы 1-2 пикселя (зависит, соответственно, от снимаемого участка неба и поля зрения объектива). При более длинной выдержке - вроде бы будут дорожки, а не звезды, ну так дорожки я сам поклею потом из многих кадров.

Но что я не учел?

Update. Нашел у Рейхмана (спасибо за 600 rule, так проще искать):

For all the anal compulsives out there, here's the scientific formula for calculating star trail exposure times as quoted from Sky & Telescope...

The length l of a star's trail on the film in millimeters can be calculated from the formula

l = [tF cos (delta)]/13,750,

where t is the exposure time in seconds, F the focal length of the lens in millimeters, and delta is the north or south declination of the star.

Happy?

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

Отвечаю сам себе, вдруг кому-то еще интересно.

1. Из всех просмотренных книжек больше всего показалась Learning Modern 3D Graphics Programming, потому что она от fixed pipeline полностью отвязана. Только OpenGL 3+, только хардкор (хотя CoreProfile в Qt и не работает нормально, текстуры не аплоадятся).

   PDF-ная версия и примеры берутся отсюда.

   Буду теперь ея читать.

2. Вообще, оно (OpenGL) отвратительное. Вот, например:
   glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject);
   glEnableVertexAttribArray(0);
   glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 0, 0);
   И теперь надо запомнить, что glVertexAttribPointer() работает с тем буфером, которому сделали Bind() последнему. Как-то это не так, неправильно.

   Отчего в glVertexAttribPointer не передается идентфикатор буфера?

3. Отвратительно оно и в частности. Более всего меня потрясло, когда Qt-шный пример с крутящимися кубиками (и текстурами с цифрами 1-6 на гранях) я запустил на WinXP под VMWare. Кубики крутились, но грань у кубиков была одна, последняя (с шестеркой), предыдущие пять текстур куда-то подевались. Это не OpenGL3 (на VMWare только 2.1). На Win7 в той же VMWare - у кубиков по 6 граней, но отображается на всех - только одна текстура, первая. Смеялсо.

Отсюда вопросы:

• Оно вообще с совместимостью как? Можно ли рассчитывать, что OpenGL-приложение вообще работает (на случайно отобранной системе), или это сильно как повезет?
• Сужая предыдущий вопрос: если требовать OpenGL 3+, то не будет ли с совместимостью лучше (на тех системах, естественно, где этот самый 3+ есть)?
• Ну и чего я лишаюсь, требуя 3+ (т.е. оборудование класса DX10, как я понимаю)? Ну вот я сам накопал: Mac OS 10.6 и старше, интеловская встроенная графика старше SandyBridge, а еще что?

Ввиду повышенного интереса к теме картографии, хочу сообщить следущее:

1. Любимый Poehali.org, похоже, скурвился приказал долго жить. Перебрасывает на mapstor.com, где только за бабло (хоть и небольшое). Скачать по листику, получается, неоткуда.
2. По счастью, на rutracker есть несколько раздач (2010-го года), которые представляют собой достаточно полный (а может и совсем полный) слепок с poehali.org на какой-то момент.
3. Если вы, как я, качали подобные же торренты давно (я это делал в 2008-м или 2009-м году, судя по датам файлов), то советую докачать. Там стало сильно больше, мой архив был 52G, а теперь - 92G (и, например, километровый лист N46 /западная Монголия/ сейчас есть, с виду, весь и даже с избытком /148 листов из 144, что-то с дублями/, а было только 100 листов из 144).
4. Ну и если будете докачивать, то обратите внимание, что раскладка по каталогам изменилась: листы p-s были склеены по два (P01_02 и так далее), а листы T-U - и вовсе по 4 (T37_38_39_40 и так далее), а в новых раздачах эти листы, как и более южные, попилены по одному (а миллионные карты лежат, соответственно, по номенклатуре самого западного листа из 2/4).

   Как следствие, если хочется поэкономить 11G трафика, вас ждут увлекательные полчаса-час пересортировки файлов.

Качество POEHALI всегда было условным, вот собрал лист 100k M45 (Алатй), вижу что одна карта из 144 обрезана (есть дырка), листы разных лет, есть ч-б варианты, часть листов надо перепривязывать, но дареному коню....

В любом случае, черно-белый лист - лучше отсутствия листа.