сравнение площадей

0 голосов
спросил 04 Авг, 05 от Гость (210,080 баллов) в категории Программные продукты Esri

Столкнулась с какой-то чепухой при элементарном сравнении площадей полигонов и не могу разобраться в чем тут дело. Может кто-то сталкивался с чем-то подобным? Подскажите, пожалуйста.

Создаю поле 10.4 из area/10000, чтобы отсечь лишнюю значность.Выделяю по определенному признаку, получаю суммарную площадь группы (2 записей порой достаточно), хоть по statistic. Сравниваю непосредственно это число (забиваю его в программу для теста) с вновь посчитанной в программе площадью группы, выводятся одинаковые числа с одинаковой значностью (10.4), но проверка на равенство порой дает отрицательный результат!image

Если бы area, то понятно, там реальная значность теряется в сумерках..., но я-то ее вроде бы обрезала!

Стала изощряться: умножать обе части на одинаковый множитель, так чтобы они стали целыми, потом еще truncate, round к ним применяла... Только round дает всегда правильный ответ. Но писать это нагромождение при каждом сравнеии... Это бред просто. Где я заблудилась?

Текст не привожу -длинно получится, и, поверьте, я знаю как писать if, и переменные все 10 раз проверила. Но если кто захочет, то нет проблем.

 

 

49 Ответы

0 голосов
ответил 16 Сен, 05 от Гость (210,080 баллов)

Как уже говорил наш коллега, формат dbf хранит числа с плавающей точкой в формате Double (и не важно сколько знаков после запятой вы указали при определении поля), а он (это достаточно известный факт) имеет погрешность. Не стоит валить вину на AV (а я согласен - она долека от совершенства), ведь не компания ESRI придумала формат Double. .

Хочу сказать, что хотя с AV я и 2х лет не работаю (да еще отвлекаюсь часто на другие языки), но с форматом DBF я до того проработала около 15 лет и НИКОГДА ничего подобного не видела и не слышала. imageИ, по крайней мере у меня (при весьма интенсивном программировании!), подобных проблем не было. А с таблицами работала постоянно. Уж как хотите, но такой факт имеет место быть. И ясности он мне не добавляет.image

0 голосов
ответил 16 Сен, 05 от Гость (210,080 баллов)

Кстати, еще о форматах!image

Создаю таблицу в AV. Из числовых форматов тут есть только Number. Ну его и выбираю, 16.4 как всегда. Ну чего-нибудь набираю. Есть! В некоторых случаях в независимости от формата где-то в глубине появились некие странные числа! Сохраняю все. Выхожу.

Открываю эту таблицу  в  типичном пакете, работающем с DBF - FoxPro. Все как всегда отлично открывается! Смотрю формат чисел - Numeric!  Хотя тут же есть и Float, и  Double ! Значит формат AV создает совсем не Double!!!!image

Далее пытаюсь прочитать глубинные разряды этой самой таблицы - увеличивю значность дробной части. Читаю. ЧИСТО!!!!!! Нет никаких непонятных добавок!!!!  

Числа именно те, которые я вводила! Значит дело совсем не в DBF  и не пудрите мне мозги.image

И когда я начинаю работать с этой таблицей в FoxPro, то все отлично! Значит дело именно в AV. Ха-Ха-Ха. Обсуждаем, господа, дальше?

0 голосов
ответил 17 Сен, 05 от yumakaev (5,140 баллов)

Проблема осталась - уж не знаю удастся ли мне убедить поставщиков покрытия использовать везде ROUND, но проблема эта не из легких. И боюсь, что этот форум им не указ.image  И пошлют они меня...Они мне уже говорили, что у них все работает правильно.

Вопрос, ЧТО ИМЕННО у них "работает правильно"? Если поставщики пока не наткнулись на подобную проблему, то это может значить, что они просто не решали задач, сходных с вашими.

Погоняв Яндекс и Google на эту тему, и поболтав с коллегами, действительно обнаруживаешь, насколько распространённый характер имеет проблема, и что выходит она далеко за пределы ArcView и dbf.

0 голосов
ответил 17 Сен, 05 от yumakaev (5,140 баллов)

И когда я начинаю работать с этой таблицей в FoxPro, то все отлично! Значит дело именно в AV. Ха-Ха-Ха. Обсуждаем, господа, дальше?

Обсуждаем. Вот сравнение характеристих dBase II, III, IV: http://www.clicketyclick.dk/databases/xbase/format/dbase_spe c.html

Обратите внимание на Size of floating point и Size of decimal values in numeric в форматах III и IV. ArcView умеет читать dBase III и IV (упоминания об этом можно найти в хелпе там и сям), а вот какой формат она пишет? Уж не III ли? Для какой-нибудь обратной совместимости с чем-нибудь.

Следует предположить ежупонятное, что FoxPro обладает более расширенными возможностями обработки dbf, и всё там будет отлично... до какого-то момента! Так как исчерпать предел точности и в FoxPro не составит труда, если задаться целью.

их компьютер - ничто против нашего лома!

0 голосов
ответил 17 Сен, 05 от yumakaev (5,140 баллов)

Кстати, об обработке огородов в ГИС.  Есть книга GIS and Land Records: http://gis.esri.com/esripress/display/index.cfm?fuseaction=d isplay&websiteID=80&moduleID=0

Интересно, затрагиваются ли в книге всплывшие проблемы?

0 голосов
ответил 17 Сен, 05 от Гость (210,080 баллов)
Вопрос, ЧТО ИМЕННО у них "работает правильно"? Если поставщики пока не наткнулись на подобную проблему, то это может значить, что они просто не решали задач, сходных с вашими.
Говорят, что решалиimage.

Погоняв Яндекс и Google на эту тему, и поболтав с коллегами, действительно обнаруживаешь, насколько распространённый характер имеет проблема, и что выходит она далеко за пределы ArcView и dbf.
  Я тоже могу любую фигню сочинить и запихнуть ее в Интернет. Могу даже много всяких разных фигней насочинять.image
0 голосов
ответил 17 Сен, 05 от Гость (210,080 баллов)

их компьютер - ничто против нашего лома!

Вот это правильно! image

В общем я эту дискуссию породила - я ее и убиваю. В том смысле, что можете, конечно, продолжать, но я сие заведение покидаю. image Беседа была небесполезной.image

Всем спасибо за внимание. В ситуации я теперь окончательно разобралась, Who is who, так сказать, выяснила. Дерзайте дальше на выбранном поприще. 

0 голосов
ответил 18 Сен, 05 от yumakaev (5,140 баллов)

я сие заведение покидаю. image 

image

Прощщщайте навседа!  image 

imageimageimage

0 голосов
ответил 19 Сен, 05 от dindzilin (4,160 баллов)
Даааа, ну чтожжжжж..... Раз уж мы тут "тааакие все проограммииисты", взглянем на это дело как программисты.
Для начала приношу свои извинения по поводу сказанного мной, что dbf хранит числовые данные в Double. Конечно-же
ещё и в Integer, и в Float и т.д... но, вот тип Numeric, (кстати, в переводе с английского - числовой) насколько я понимаю, является лишь указанием на то что в данном поле хранятся числовые значения (кстати, в FoxPro под хранение числа Numeric выделяют столько же памяти сколько и под Double - 8 байт). Кроме того, тип Numeric в FoxPro не является типом данных полей таблиц, он просто является типом данных( http://vfp.narod.ru/Vfp/help/fox01230.htm ).
Теперь исследуем ту таблицу, которые мы создавали в AV. Ради эксперимента можете создать таблицу в которой есть числовые поля с различным количеством знаков после запятой. Теперь откроем данную таблицу в MSAccess (к сожалению не имею инсталляции FoxPro) в режиме конструктора таблиц и смотрим - ВСЕ числовые поля имеют тип ЧИСЛОВОЙ (он же Numeric), а вот размер у полей, которые имеют хотя бы один знак после запятой, стоит - Двойной точности (он же Double), так что когда я говорил что dbf хранит свои числовые данные (не целочисленные) в формате Double, я имел в виду dbf создаваемую в AV.
Теперь непосредственно о программировании (я имею в виду программирование на нормальном языке типа С, ну может быть Delphi, ведь я надеюсь, никто не тешит себя мыслью, что при работе AV проц напрямую выполняет команды Avenue)... Какого-бы типа вы создавали переменную, для чтения значений из поля таблицы? Скорее всего такого же, что и само поле. А где вы встречали в нормальных языках что-нибудь подобное функции SetFormat() для переменной числового типа, которая бы возвращала числовой же тип?.. Вот и я что-то не припоминаю. И вообще, приведите мне пример численного типа который бы хранил строго m знаков до и строго n после запятой (m и n задается произвольно), ни байтом больше ни байтом меньше?!. Так что если вам отвели 4 байт под Float и 8 под Double, никуда вы от них не уйдете!!! И при любых вычислениях c вещественными числами вам прийдется пользоваться переменными типа Float или Double (кстати, все вещественные типы имеют погрешность, только одни больше, другие меньше), а вот погрешности при работе с ними связаны с представлением числа в вашем дорогом компьютере, если быть более точным - при преобразованиях из десятичной в двоичную, так что даже операция сравнения может давать погрешность... Но это уже другая тема и уж ей-то уделено немало внимания, если не в Inete (как показывает практика ему не все доверяют, да и я, наверное, скоро задумаюсь над этим вопросом, если все подряд будут писать всякую фигню),то в приличной на ваш взгляд библиотеке я думаю что-нибудь найдется. Ну вот наверное и все что, я еще хотел бы от себя добавить! Всем удачи!
Добро пожаловать на сайт Вопросов и Ответов, где вы можете задавать вопросы по GIS тематике и получать ответы от других членов сообщества.
...