Существует ли стандартное или «наиболее используемое» фиктивное значение 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 или генерировать исключения. Таким образом, вы можете обнаружить, что вы все испортили, потому что вы используете фиктивное значение