Чи є стандартизоване або "найпоширеніше" значення манекена Z?

Створюючи та імпортуючи і 2D, і 3D дані, я не раз стикався з ситуацією, коли у мене немає значення Z для набору координат, що значення координати Z здається поза діапазоном (наприклад, -99, -9999, -inf або подібне ) або що мені потрібно створити фіктивну координату Z.

Я знаю, що відповідь на моє запитання:

"Просто використовуйте значення, яке безумовно є поза діапазоном у вашому випадку."

Але ця відповідь відкладена. Цікаво, чи має спільнота ГІС стандартизоване або найчастіше використовуване значення для манекенової координати Z?

Поточні відповіді всі дають хороші поради. Загальне правило (від наукового обчислювального співтовариства), яке добре працює в тих випадках, коли ви не можете зберігати справжні нулі або NaN, - це використовувати найменше ( найнегативніше ) значення, яке поле буде (дійсно) містити.

Приклади:

• 7,2 десяткового поля може містити значення як -9999,99.

• Цілочисельний растр може містити числа як невеликі, як -32768, але часто (внаслідок відрази до бінарного та спорідненості до бази 10) замість цього використовується значення -9999.

• Поплавок може вміщувати числа в порядку -10 ^ (38). Якщо ви не можете помістити NaN у поле, то знайдіть найменший поплавок, який підходить (що болить), або просто використовуйте щось на зразок -10 ^ (38). Для парних значень -10 ^ (303) працює чудово, але це так -10 ^ (38): він є досить величезним і негативним, щоб служити чітким маркером нульового значення.

Це правило просте запам’ятовування, послідовне, просте у застосуванні, легко документування у вигляді шаблону (за вашими метаданими) і рідко призводить до випадкових помилок (тому що найбільш негативне число зазвичай настільки відрізняється від даних, що його неправильне використання як фактичне значення, а не нульове значення, пошкоджує статистичні зведення та інші обчислення, достатні для підняття прапора, що існує проблема).

Якщо ваші дані знаходяться в базі даних, тоді в ідеалі ви будете використовувати значення NULL :

подання "відсутньої інформації та непридатної інформації"

Однак це може спричинити проблеми з клієнтськими програмами та кодом, і я не вірю, що NULL підтримується в DBF. Яка ця цінність повинна бути, я думаю, різна для різних організаційних умов. Яке б недійсне значення ви не вибрали, переконайтеся, що воно записане у метаданих набору даних.

Якщо жодна з точок для набору даних не має значення Z, то я не бачу, чому 0 не можна було б використовувати, хоча в такому випадку можливо найкраще видалити Z-обізнаність з набору даних, щоб уникнути плутанини.

Більшість растрових я зустрічаю -9999.0 для даних з плаваючою точкою як звичайні умови, і GDAL використовуватиме -dbl_inf, коли ви пишете код для зображення, яке не має значення nodata / dummy. 8-бітний RGB зазвичай використовує 0 0 0 або 255 255 255 або має альфа-або маска-канал.

Покриття GML 3 (для яких наразі немає великої підтримки, але це зміниться, коли буде ратифіковано специфікацію WCS 2) має кілька фіктивних значень, які представлені у вигляді тексту, таких як "відсутні" та "утримуються".

На мій досвід, будь-який за замовчуванням має тенденцію до домену або для постачальника. Якщо ви є виробником даних, а не споживачем, виберіть номер та дотримуйтесь його та переконайтеся, що ваші споживачі будуть про це знати.

Я використовував би NaN, оскільки математичні операції створюватимуть інші NaN або викидатимуть винятки. Таким чином, ви можете виявити, що ви безладно, тому що ви використовуєте помилкове значення