|
POST
|
Thanks for taking the time to respond Amnoy. Re #1, tying to a single network isn't a problem here, probably even an advantage and not a limitation, but I'm glad to have this aspect drawn out of the background detail. Re #2, could you expand on what this means please? What 3 applications?
... View more
04-23-2018
01:41 PM
|
0
|
0
|
4004
|
|
POST
|
Yes, I should have said I've gone through those pages. Thanks. I didn't notice anything that looked like "with concurrent you won't be able to ..." but I wanted to give people a chance to point something out in case I've overlooked something.
... View more
04-23-2018
10:35 AM
|
1
|
1
|
4004
|
|
POST
|
We use Concurrent Use licenses to manage our ArcMap usage. We intend to do the same for ArcGIS Pro so all of our Desktop top users, Pro and Map, are managed in the same system and the same server. Is there any reason not to convert all of our Named licenses to Concurrent? Meaning, should I keep one or two back because there’s thing X that can’t be done unless a Named license is in effect?
... View more
04-23-2018
09:36 AM
|
1
|
14
|
5613
|
|
POST
|
In past we've had some workstations not able to find a given license manager because of IPv4 and v6 issues, with v4 always working and v6 only for some machines. I didn't to get to the bottom of it. My hunch is a general network config issue and not specifically Esri's.
... View more
04-23-2018
09:30 AM
|
0
|
0
|
3627
|
|
IDEA
|
@chris_fox-esristaff the first part of the idea is display only the selected records, but the second part is the ability to later inspect that selection and possibly alter it, as well save and share it. Copying the selection into a definition query would allow that, while creating a layer from selection does not. Also in my experience the redraw performance of def-query layers is markedly faster than selection-set layers, especially for image services.
... View more
04-19-2018
01:37 PM
|
1
|
1
|
3282
|
|
POST
|
There is an Idea asking Esri to add a LAZ driver, please go vote it up: Support LAZ format
... View more
11-14-2017
11:18 AM
|
2
|
1
|
8864
|
|
IDEA
|
This would be possible via https://community.esri.com/ideas/13916 , if implemented
... View more
09-05-2017
03:43 PM
|
2
|
0
|
830
|
|
POST
|
Now an Idea, https://community.esri.com/ideas/13916
... View more
09-05-2017
03:21 PM
|
0
|
0
|
1349
|
|
DOC
|
Addition to the list: arcplus/uninstall-ALL-ArcGIS-products.md at master · envygeo/arcplus · GitHub (up to date for 10.6 though some products could be missing; contributions welcome. Better yet, Esri distribute their own tool that does same.)
... View more
08-29-2017
11:22 AM
|
0
|
0
|
3613
|
|
DOC
|
Thanks Laurene. It's the first link from Curtis's opening post above too.
... View more
08-29-2017
11:15 AM
|
0
|
0
|
3613
|
|
POST
|
This is useful Shaun, thanks. Do you have or are you aware of a location where useful arcpy patterns like this are collected? (hopefully curated?)
... View more
08-28-2017
12:21 PM
|
0
|
1
|
3996
|
|
POST
|
This presentation from Software Carpentry on Data Management is excellent even if it is for a different field: http://v4.software-carpentry.org/data/mgmt.html It exposes a way of thinking about the problem that I'm finding useful, if not quite yet fruitful (for us).
... View more
07-05-2017
11:34 AM
|
2
|
0
|
10181
|
|
POST
|
That's nearly identical to our current best layout! 😉 It is reassuring to see your project folder structure match ours so closely. It helps validate the thinking that got us this far. The pain points we have with it: Doesn't address shared data among related projects (e.g. "ProjectBBB\maps\composition.mxd" using a feature class from "ProjectDDD\data\Results.gdb\trails_2015") New versions/Archiving: It's 2017 and we need to run new series of maps first created in 2015. "2015\ProjectAAA" and "2017\ProjectAAA" - mega data duplication. Definitely easiest to see what is most current though, and is highly portable. "ProjectAAA\maps\2015\" and "ProjectAAA\maps\2017\" - Pretty clear for maps, but gets internally complicated for data layers (are you sure you remembered to change source from "base_2015.gdb\trails" to "base_2017.gdb\trails"?), and very difficult to share. Having mxd's in a subfolder became a real pain after the introduction of the 'Home Folder' concept, wherein you can't just click your way to the parent folder to get at Scratch and Source, but putting them all at the top quickly gets out of hand too. I could never figure out the best place for SomeCustom.tbx. (tried "Tools" and "Tools\scripts" subfolders for awhile, but is a navigation pain and leads to much extra typing) There are 500+ and growing top level "ProjectXXX" folders in my work unit alone. It's hard to track what's in what. (We're using a spreadsheet as index, which was great for a few years, but it's collapsing under it's own weight, and won't survive merging with other work units.) I like the concept of Map and Layer Packages combined with a Check-out and Check-in to storage central workflow, but it doesn't work well when there are numerous data layers which shouldn't be wrapped up that aren't stored in an SDE. (Sure would nice if one could say "Exclude all layers in folder or drive X".). I've considered spawning one or more pre-corporately-managed GDB instances to address this, but the internal flat nature of GDB (all feature classes and tables stored at same level) means we'd need a dozen or more, which makes me leery. Thank you for your contribution to this exploration.
... View more
07-05-2017
11:28 AM
|
0
|
1
|
10181
|
|
POST
|
The GIS Data Administration topic on the GIS.com wiki is an excellent high level overview of the various server level strategies available and in what situations to apply them. I’m looking for something similar with a focus on personal and small workgroup beast practices for local file and folder management. So one level below the server GIS data admin. Our server level spatial data management is pretty good (albeit with ample room for improvement!). However we still have gigabytes to terabytes of GIS data and projects scattered throughout various offices in the organization that is effectively useless to a wider audience without the individual who created them present to interpret the file and folder arrangements. What guidelines can we give people starting new projects that will minimize unnecessary local variation while still being adaptive to local circumstance and make it easier for new staff to pick and run with an existing project (because structure is predictable) to distinguish intermediate working and in-progress stuff from the polished and ready to go stuff (like milestones and deliverables) data administrators to float the useful data to the top (to the corporately managed geodatabases) share externally Listed more or less in order of priority. Our organization operates within a 90% ArcGIS Desktop ecosystem, though some other platforms are used here and there as well. My question is broader than just how to store the geometry files and attribute tables. A typical project also uses and produces MXDs, (aprx for Pro), input data, external reference data, interim data, output data, python scripts, toolboxes, models, output files (pdf, jpeg, …), raster imagery, layer files, word docs, text docs, … in addition to file-gdb and shapefiles. In a well managed project, where does all this stuff go and how is it named?
... View more
06-28-2017
02:54 PM
|
8
|
6
|
19850
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 05-15-2025 10:32 AM | |
| 1 | 04-14-2025 09:22 AM | |
| 1 | 12-04-2024 09:11 AM | |
| 1 | 01-24-2019 11:57 AM | |
| 1 | 05-21-2019 12:44 PM |
| Online Status |
Offline
|
| Date Last Visited |
2 weeks ago
|