Здавалося б, у чому проблема?
Excel розуміє формат DBF, повинен, в усякому разі. З іншого боку, DBF - це рідний формат ArcView, саме в ньому зберігається атрибутика для шейп-файлу. Створюй собі файл в Ексель і передавай в ArcView. Однак на цій "доріжці" маса ям і канав, та таких, що навіть досвідчені користувачі часом спотикаються. Чому так просходит і що робити? Створюємо таблицю, наприклад, з номерами точок, назвами, координатами.
Так, Ексель здатний записати дані відразу в DBF, але. завантаживши таблицю в ArcView, ви відразу зіткнетеся з тим, що в ній:
1. Загублені знаки у чисел "після коми";
2. переплутані типи даних в колонках;
3. спотворюючи кодування російських букв і т.п.
Повозившись трохи, ви зрозумієте, що винен в цьому не ArcView, а саме Ексель. Чому так відбувається і як же бути? Перші дві проблеми пов'язані з тим, що Ексель - простий табличний процесор, а не система баз даних, ось він і не вміє дбати про типах даних. А DBF - це не проста таблиця, це файл саме бази даних, і в ньому є сувора структура - вона зафіксована в заголовку DBF. Для баз даних в складі MS Office призначений Access, і він щось правильно пише DBF, приймає його майже як рідний формат, працювати з DBF там "правильніше". Проблеми 1 і 2 там практично відсутні. Але багато, проте, люблять обчислення в табличному, Привільному стилі! Доріжка в Ексель потрібна! Як же її протоптати?
типи даних
Розберемося спочатку з типами даних. Ексель визначає типи даних для кожної колонки по верхніх рядках, тому, складаючи таблицю, робіть так:
- Верхній рядок відведіть під заголовки колонок, як показано на першому малюнку. Краще якщо назви будуть без пробілів, латинські і не більше 10 символів - це вимоги формату DBF.
- Перевірте, чи правильно написані ваші дані, особливо у верхніх рядках. Якщо числа мають невірний десятковий знак-роздільник, або букву "О" замість нулів, Ексель оголосить їх текстом, і колонки в DBF придбають текстовий тип з усіма витікаючими наслідками.
- Якщо у верхніх рядках в деяких колонках немає даних, чи вони не показові для колонок (наприклад, колонка текстова, а у верхніх рядках попалися, як на зло, одні цифри), то відведіть другий рядок спеціально під зразки значень: так споконвіку хитрили досвідчені DBF щик. Цей рядок потім адже нескладно буде видалити з DBF, ну, вже в ArcView.
кодові сторінки
Вищеописані заходи, проте, допоможуть приборкати лише типи даних. Питання з російськими буквами хитріше. Вони "злітають" через те, що Ексель вперто пише DBF в старовинній Dos-кодуванні (вона ще називається ASCII, чули, напевно). Він, схоже, вважає формат DBF дуже давнім, чисто ДОСовскіх спадщиною. ArcView ж за замовчуванням вважає DBF віндовсовскім форматом, і читає його як ніби він в Windows-кодуванні (вона ще називається ANSI). Так і стоять ці дві програми, як два бичка, упершись лобами :)
Спробуємо розібратися, в чому тут фокус. Секрет криється в заголовку DBF. У ньому споконвіку є місце, де зберігається вказівка на кодову сторінку. ArcView "знає" про це, і, якщо DBF-файл "правильний", тобто кодування позначена вірно, то ArcView його зрозуміє і прочитає як слід. Розробники Microsoft про це геть забули, і в Ексель ці зайві кодові подробиці не увійшли. Мало того, він обнуляє вказівку на кодову сторінку начисто, як тільки до нього добереться.
Як вирішити проблеми файлу Excel з типами даних і кодуваннями через SQL-з'єднання, розказано тут.
Як йдуть справи в ArcMap? А точно так же. Таблиці DBF не читаються без зусиль, і всі вищеописані рекомендації актуальні. Точно так же виправлення кодової сторінки виробляє звично-чарівний ефект: