Organizzazione e riordino di più copie dei livelli? [chiuso]


28

Ai tempi in cui ero all'università avevo un problema di "Organizzazione e ordine": ero disorganizzato e tenevo i miei livelli in cartelle diverse senza nomi distinti e quindi avevo più copie di ogni livello.

Da quando ho iniziato a lavorare, sono migliorato molto - tengo cartelle speciali con sottocartelle speciali. Nomino i miei livelli secondo un sistema che mi permette di essere un po 'più pulito, ma poiché devo ancora gestire più copie dei livelli (poiché Autocad e ArcGIS hanno le loro differenze quando si tratta di lingue non latine, devo conservarne una copia adattato per ogni programma), mi piacerebbe ascoltare le tue esperienze e forse imparare alcuni suggerimenti da te:

  1. Come organizzi i tuoi livelli? Come si chiamano? Per nome, data, contenuto, cliente?
  2. Come organizzi o gestisci più copie (più acuto: come aggiorni più copie contemporaneamente)?

Nota: sto parlando dall'analista / DBA POV e non dal POV di uno sviluppatore web / web manager (sto parlando di organizzare i livelli per me stesso e forse altri due lavoratori GIS, non di più).


6
Una buona domanda In realtà non è una domanda, è una ricerca. Una domanda porta a una serie di risposte singole o ristrette e, una volta risolta, è finita. Una ricerca è una cosa in corso, un'avventura che potrebbe non avere mai una fine definitiva, ed è quello che hai qui. Rassegnati alla verità che, indipendentemente dalla convenzione su cui ti poni, non funzionerà completamente o scrupolosamente. Detto questo, ci sono convenzioni che puoi usare per rendere il percorso più agevole e più facile da percorrere. La risposta di Kevin e il seguito dei commenti sono un ottimo inizio in questo senso.
Matt Wilkie,

Risposte:


21

Questo è un problema malvagio . Abbiamo provato vari sistemi, che hanno funzionato tutti in misura diversa per un certo periodo, e alla fine sono cresciuti in modo ingombrante e hanno iniziato a crollare quando si incontrano altri casi limite che non si adattano perfettamente. Detto questo, ognuno dei sistemi che abbiamo usato è molto meglio di niente, dimostrando la massima che qualsiasi sistema è migliore di nessun sistema.

Ecco una panoramica in miniatura della nostra pratica attuale:

Metti tutto tranne i raster in un file geodatabase, meno è, meglio è. Non nidificare le classi di entità geografiche nei set di dati delle caratteristiche a meno che non siano correlate in qualche modo (ad es. Idro> torrenti, idro> laghi, idro> zone umide, ecc.). Questo porta a un lungo elenco in cima a fgdb ma è un male accettabile.

Crea file di livello per tutte le classi di caratteristiche e organizza invece ciò, offrendo così molta libertà di nominare secondo necessità, usando caratteri non supportati ecc. *, E la possibilità di spostarsi e rinominare quando le circostanze cambiano. Consente inoltre la duplicazione senza ridondanza, ad esempio un insieme di livelli raggruppati in base alla scala nominale (50k, 250k ...), un altro per regione (AK, YT ...), un terzo per tema (caribù, uso del suolo, trasporto ...) e un quarto per client mentre lo stesso archivio dati rimane invariato.

Per i duplicati usa le scorciatoie invece dei file dei layer stessi, altrimenti ci sono troppe cose da aggiornare quando le cose cambiano. Configura ArcCatalog per mostrare le scorciatoie: * Strumenti> Opzioni> tipi di file: .lnk (Limitazioni: anteprima e metadati non funzionano, non puoi seguire il collegamento alla sua fonte in ArcCatalog. Puoi rimediare usando i collegamenti simbolici invece delle scorciatoie , vedi Link Shell Extension )

* (suggerimento: aggiungi la cartella Livelli come barra degli strumenti del menu Start in modo che siano sempre a portata di mano.)

Z: \ \ Layers
          Base\
          Tematico\
          Riferimento\
          All Dressed Base (250k) .lyr
          Confini amministrativi (1000k) .lyr
          ...
Z: \ Raster \
          Landsat \
          Orthos \
Z: \ Data \
        Foo_50k.gdb
        Foo_250k.gdb
        NoScale.gdb

Composizioni e output delle mappe (file di stampa, pdf, esportazioni, ecc.) Che per natura sono più dinamici e variabili vengono archiviati e organizzati in modo diverso altrove. Questa è la parte che è stata più dura per noi. Al momento utilizziamo un'unità dedicata con cartelle denominate in base al Job # (facendo di nuovo utilizzerei invece la data, "2010-10-26" ) e le sottocartelle per dati specifici di progetto e risultati / deliberabili. Un indice del foglio di calcolo elenca tutti i numeri dei lavori (nome della cartella), i titoli delle mappe corrispondenti e il client. Ex:

W: \ Foo_0123 \
            Foobarmap_001.mxd
            Documenti \
                 ReadMe.doc
            Dati\
                 buffers_2000m.shp
                 gps_tracks.csv
            Produzione\
                   Foobarmap_001.pdf
            Risultati finali

Mantenere aggiornato l'indice è un punto di attrito, alle persone non piace farlo, evitarlo e non sono coerenti con la denominazione ecc. (L'uso di un database invece del foglio di calcolo sarebbe di aiuto). L'uso di una convenzione di nome di una cartella numerica rende anche molto difficile la mappa per il progetto X senza l'indice, un'altra notevole fonte di attrito. Idealmente l'indice sarebbe una pagina html cliccabile che viene generata automaticamente da un'applicazione db. Questo è comunque un altro progetto.

Principi chiave:

  • separare le cose che cambiano lentamente e spesso riutilizzate da quelle dinamiche e variabili e trattarle in modo diverso
  • Non duplicare inutilmente, utilizzare file di livello e collegamenti / collegamenti ove possibile.
  • non cambiare i sistemi troppo frequentemente, provalo a fondo.

Accolgo con grande favore esempi di altre strutture, poiché ho detto che non siamo contenti di ciò che abbiamo. :)


Ieri ho castigato leggermente qualcuno per aver pubblicato qualcosa di troppo lungo e lungo, e qui vado a fare la stessa cosa, solo senza le foto. Cosa ne pensi, è meglio presentare un insieme coeso o spezzare le cose in pezzi modulari, che possono ciascuno votare su / giù per i propri meriti, ma possibilmente rompere o nascondere la loro integrazione con gli altri?
Ne

Wow. Che sistema di archiviazione attraverso (l'ho già letto quattro volte e non sono ancora sicuro di averlo ottenuto). Due commenti che si sono distinti per me, in quanto utente di AutoCAD e ArcGIS vincolante: 1. come posso inserire in questo sistema la memorizzazione di DWG? 2. GeoDatabase è un ottimo modo per organizzarsi. L'unico problema che ho è che AutoCAD map non vede GDB ma solo shapefile. Ma grazie, prenderò consigli dal tuo sistema completo ...
Jonatr

tieni presente che questo sistema è cresciuto fino a diventare così nel corso di 15 anni circa ed è adattato al nostro modo di lavorare. Dovrebbero essere presenti alcuni elementi portatili. Per quanto riguarda l'interoperabilità con CAD, continuate sul caso ESRI per onorare il loro impegno a pubblicare un'API aperta nel file geodatabase .
matt wilkie,

1
Idem sui set di dati delle caratteristiche. È una sorta di funzione inutile tranne che in ArcCatalog. Dovrebbero raggruppare i livelli di uso comune e riferimento spaziale, ma un programmatore non vede mai un set di dati delle caratteristiche fino a quando non riesce a passare in rassegna i livelli in un'area di lavoro. Quando si usano proiezioni diverse, database separati sembrano migliori dei set di dati delle caratteristiche.
Tim Rourke,

1
@Tim Credo che i set di dati delle caratteristiche siano i decidenti concettuali delle coperture ArcInfo, vale a dire che devono essere un mezzo per raggruppare diversi tipi di geometria che descrivono una "cosa" comune in un singolo cestino. Quindi puoi avere ad esempio corsi d'acqua (linee), corpi idrici (poligoni) e rocce nell'acqua (punti) insieme. Non so perché non vengano presentati più direttamente al programmatore.
matt wilkie,

6

Se altre persone accederanno ai dati nel tuo sistema, non puoi rendere lo schema organizzativo significativo solo per te stesso; devi tenere presente il loro uso del sistema. Se non li consideri, passerai molto tempo a rispondere a domande come "dove sono i dati di landuse" e "perché non riesco a trovare il [inserire il set di dati qui]?"

Nel mantenere un sistema di questo tipo per molti anni, ho scoperto che le persone non sono in grado di trovare dati se vengono prima organizzati per fonte, ad esempio c:\CensusBureau\Roadse c:\ESRI\Countries. Invece, ti consiglio di elencare prima i dati tematicamente, quindi per fonte nel caso in cui tu abbia più fonti, ad esempio c:\Roads\CensusBureaue c:\Roads\LocalGovt.

Allo stesso modo non separerei raster e vettori in diverse directory. Tuttavia, potrebbe essere necessario dividerli su unità fisiche o logiche diverse se si dispone di molti dati raster che non si adattano a un'unità.

Raccomando la seguente struttura di directory. Tema \ FonteAnno, dove Tema è il livello tematico, Fonte è un nome abbreviato per l'origine dati e Anno è l'anno in cui i dati rappresentano sul campo. In questo scenario, TIGER Roads dell'ufficio del censimento verrebbe localizzato \Roads\Census00e \Roads\Census10(o sostituirà "Censimento" con "TIGER").

Tenere presente che alcune estensioni in ArcGIS non funzionano con nomi di file più lunghi di 13 caratteri. Non riesco a ricordare quale estensione, ricordo solo che questo è un problema.


Grazie Kevin, per quanto riguarda la convenzione sul nome del file? Sto pensando a una soluzione come <Object> _ <Location> _ <Range> _ <Data> _ <FileFormat> _ <Risoluzione>. <ext> coast_eu_340509.76N0080201.23E_350509.76N_0090201.23E_2011_shp.zip box_e3_50_250_250_250_350_350_350_350_5050 .76N_0090201.23E_2011_tiff.zip. Pensi che sia un'idea valida?
Giada,

5
Quei nomi di file potrebbero diventare molto ingombranti da usare su una riga di comando o in un programma. Porterebbero anche a un sommario molto ampio e / o legenda in ArcMap (almeno per impostazione predefinita). Opterei per nomi di file più brevi, ad esempio solo oggetto o oggetto e data, e utilizzare metadati standard o almeno un file readme per inoltrare il resto delle informazioni. Solo la mia opinione.

4
Sono d'accordo con Kevin. La mia attuale azienda ha una convenzione di nomi di file legacy (che sto cambiando) che impone nomi di file troppo lunghi ed è molto ingombrante solo per i motivi citati da Kevin. Due pensieri aggiuntivi 1) Molto di ciò che hai nel nome del file potrebbe essere suddiviso in cartelle e ordinato nella struttura del file, non nel nome del file; 2) i punti / punti multipli (.) Nel nome del file possono causare problemi di accesso ai file attraverso determinati software e / o programmaticamente. in genere i caratteri dopo un (.) sono l'estensione del file e non i componenti aggiuntivi del nome file.
hgil,

2

Lavoriamo a livello di progetto per i file cad supponiamo che dipenda da come è impostato il tuo particolare flusso di lavoro, abbiamo il nostro progetto di lavoro principale quindi prepariamo eventuali archivi di dati aggiuntivi da questo in uno script di esportazione al termine della sessione di modifica.

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

quindi ogni file ha livelli / livelli / caratteristiche nominati con un identificativo
sewPipe
sewManhole
sewPit
...

Esportiamo quindi tutto su SQL spaziale invece di leggere i nostri file di progetto di lavoro in cui viene visualizzato all'utente tramite Mapguide o qualsiasi app GIS necessaria.

I livelli GIS sono ordinati per nome della funzione con identificatori e layout di cartella simile per consentire l'ordinamento.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.