Організація та охайність декількох копій шарів? [зачинено]


28

Ще в часи, коли я був в університеті, у мене була проблема "Організація та охайність" - я був неорганізований і зберігав свої шари в різних папках без чітких назв, а отже, мав кілька копій кожного шару.

З того часу, як я почав працювати, я значно покращився - зберігаю спеціальні папки зі спеціальними папками. Я називаю свої шари відповідно до системи, яка дозволяє мені бути трохи більш акуратним, але оскільки мені все одно доводиться керувати кількома копіями шарів (Оскільки у Autocad і ArcGIS є свої відмінності при роботі з не латинськими мовами, я повинен зберігати копію коригується для кожної програми), я хотів би почути ваш досвід і, можливо, дізнатись кілька порад від вас:

  1. Як ви організовуєте свої шари? Як їх називати? За прізвищем, датою, змістом, замовником?
  2. Як ви організовуєте чи обробляєте кілька копій (гостріше: як оновлювати кілька примірників одночасно)?

Примітка: я говорю з аналітика / DBA POV, а не з POV веб-розробника / веб-менеджера (я говорю про організацію шарів для себе і, можливо, ще двох працівників ГІС, не більше).


6
Гарне запитання. Насправді це не питання, це квест. Питання призводить до єдиного або вузького набору відповідей, і як тільки це вирішиться, це закінчиться. Квест - це тривала річ, пригода, яка, можливо, ніколи не має остаточного кінця, і ось що у вас тут. Відмовтеся від істини, що незалежно від того, на якій конвенції ви будете дотримуватися, вона не буде працювати повністю або цілком. З цього приводу існують умови, які можна використовувати, щоб зробити шлях легшим і легшим. Відповідь Кевіна та наступні коментарі - це дуже гарний початок у цьому плані.
matt wilkie

Відповіді:


21

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

Ось мініатюрний огляд нашої сучасної практики:

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

Створіть файли шарів для всіх класів функцій та впорядкуйте, що натомість це дає велику свободу називати за потребою, використовуючи непідтримувані символи тощо. *, А також можливість переміщатись та перейменовувати під час зміни обставин. Він також дозволяє дублювати без надмірності, наприклад, один набір шарів, згрупованих за номінальною шкалою (50k, 250k ...), інший за регіонами (AK, YT ...), третій за темою (карібу, землекористування, транспорт ...), і четвертий за клієнтом, тоді як сам сховище даних залишається незмінним.

Для дублікатів використовуйте ярлики замість самих файлів шару, інакше є занадто багато речей для оновлення при зміні речей. Налаштуйте ArcCatalog для показу ярликів: * Інструменти> Параметри> типи файлів: .lnk (Обмеження: попередній перегляд та метадані не працюють, ви не можете дотримуватися ярлика до його джерела в ArcCatalog. Це можна усунути за допомогою символічних посилань замість ярликів. , див. Розширення оболонки посилання )

* (порада: додайте папку "Шари" як панель інструментів меню "Пуск", щоб вони завжди були під рукою.)

Z: \ Шари \
          База \
          Тематичний \
          Довідка \
          Вся одягнена база (250k) .lyr
          Межі адміністрації (1000k) .lyr
          ...
Z: \ Растр \
          Landsat \
          Ортос \
Z: \ Дані \
        Foo_50k.gdb
        Foo_250k.gdb
        NoScale.gdb

Композиції та результати карти (файли друку, PDF, експорт тощо), які за своєю природою є більш динамічними та змінними, зберігаються та організовуються по-різному десь в іншому місці. Це та частина, яка нам була складнішою. В даний час ми використовуємо спеціальний диск з папками, названими згідно з Job # (робимо це знову, я б замість цього використовував дату, "2010-10-26" ) та підпапками для конкретних даних проекту та результатів / довідок. Індекс електронних таблиць перераховує всі номери завдань (назва папки), відповідні назви карти та клієнта. Наприклад:

W: \ Foo_0123 \
            Foobarmap_001.mxd
            Документи \
                 ReadMe.doc
            Дані \
                 буфери_2000м.шп
                 gps_tracks.csv
            Вихід \
                   Foobarmap_001.pdf
            Продукти

Постійне оновлення індексу - це тертя, люди не люблять це робити, уникати цього і не відповідають імен і т. Д. (Використання бази даних замість електронної таблиці допоможе). Використання цифрової конвенції імені папки також ускладнює карту проекту X без індексу, іншого помітного джерела тертя. В ідеалі індекс - це HTML-сторінка, яку можна натискати, яка автоматично генерується з програми db. Це, однак, цілий проект.

Основні принципи:

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

Я дуже вітаю приклади інших структур, оскільки я сказав, що ми не задоволені тим, що маємо. :)


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

Ого. Яка наскрізна система подачі заявок (я прочитав її вже чотири рази, і ще не впевнений, що все це отримав). Два коментарі, які виділялися для мене як користувача AutoCAD та ArcGIS: 1. як мені вписати в цю систему зберігання DWG? 2. GeoDatabase - це чудовий спосіб організованості. Єдина проблема, яку я маю - це те, що карта AutoCAD не бачить GDB, а лише формули. Але дякую, я
підкажу

майте на увазі, що ця система зростала такою протягом 15 років і так, і вона адаптована до того, як ми працюємо. Хоча мають бути деякі портативні елементи. Що стосується сумісності з CAD, продовжуйте справу ESRI, щоб шанувати їх зобов'язання опублікувати відкритий API для файлової бази даних .
matt wilkie

1
Дітто на наборах даних про функції. Це свого роду непотрібна функція, за винятком ArcCatalog. Вони повинні групувати шари загального користування та просторові довідники, але програміст ніколи не бачить набір даних про функції, поки він не перешкоджає прокручуванню шарів у робочій області. При використанні різних проекцій окремі бази даних здаються кращими, ніж набори даних.
Тім Рурк

1
@Tim Я вважаю, набори даних Feature є концептуальним елементом покриття ArcInfo, а саме вони повинні бути засобом групування різних типів геометрії, які описують загальну "річ" в єдиний кошик. Таким чином, ви можете мати, наприклад, водотоки (лінії), водойми (багатокутники) та скелі у воді (точки) разом. Я не знаю, чому вони не представлені безпосередньо програмісту.
matt wilkie

6

Якщо інші люди отримають доступ до даних у вашій системі, ви не можете зробити схему організації важливою лише для себе; ви повинні пам’ятати про їх використання системи. Якщо ви їх не враховуєте, ви витратите багато часу, відповідаючи на запитання, такі як "де є дані про землекористування" та "чому я не можу знайти тут [вставити набір даних]?"

Підтримуючи таку систему протягом багатьох років, я виявив, що люди не можуть знайти дані, якщо вона вперше організована за джерелом, наприклад, c:\CensusBureau\Roadsта c:\ESRI\Countries. Натомість я рекомендую перераховувати дані спочатку тематично, потім за джерелом, якщо у вас є кілька джерел, наприклад, c:\Roads\CensusBureauта c:\Roads\LocalGovt.

Так само я б не розділяв растри та вектори на різні каталоги. Однак, можливо, буде потрібно розділити їх на різні фізичні або логічні накопичувачі, якщо у вас є багато растрових даних, які не підходять до одного диска.

Я рекомендую таку структуру каталогів. Тема \ SourceYear, де Theme є тематичним шаром, Source - це скорочена назва джерела даних, а Year - рік, який дані представляють на місцевості. У цьому сценарії дороги TIGER з Бюро перепису населеного пункту розташовуватимуться \Roads\Census00та \Roads\Census10(або замінятимуть "Перепис" на "TIGER").

Майте на увазі, що певні розширення в ArcGIS не працюють з іменами файлів довше 13 символів. Я не можу згадати, яке розширення, я просто пам'ятаю, що це проблема.


Дякую Кевін, а як щодо конвенції імен файлів? Я думаю про таке рішення, як <Object> _ <Location> _ <Range> _ <Date> _ <FileFormat> _ <Resolution>. .76N_0090201.23E_2011_tiff.zip. Як ви вважаєте, це правильна ідея?
Нефрит

5
Ці назви файлів можуть стати дуже громіздкими для використання в командному рядку або в програмі. Вони також призвели б до дуже широкого змісту та / або легенди в ArcMap (принаймні за замовчуванням). Я б вибрав короткі назви файлів, наприклад, просто об'єкт або об'єкт та дату, і використовував би стандартні метадані або принаймні файл readme для передачі іншої інформації. Просто моя думка.

4
Я згоден з Кевіном. У моїй теперішній компанії встановлено спадщину конвенції імен файлів (що я перебуваю в процесі зміни), яка наказує назви файлів loooong, і це дуже громіздко лише з причин, згаданих Кевіном. Дві додаткові думки 1) Більшість того, що ви маєте в імені файлу, можна розділити на папки та відсортувати у структурі файлу - не ім'я файлу hte; 2) кілька періодів / крапок (.) У назві файлу можуть спричинити проблеми доступу до файлів через певне програмне забезпечення та / або програмно. Зазвичай символи після (.) є розширенням файлу, а не додатковими компонентами імені файлу.
hgil

2

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

datadir \ cad \
cadastre.dgn
datadir \ srv \ goriva.dgn datadir \ srv \ sewerage.dgn
datadir \ map \ base.dgn
datadir \ map \ printsets.dgn
...

то кожен файл має рівні / шари / функції, названі ідентифікатором
sewPipe
sewManhole
sewPit
...

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

Рівні GIS сортуються за назвою функції з ідентифікаторами та подібним компонуванням папок, щоб дозволити сортування.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.