Latest Contributions by MattWilkie1

We're starting a project to map various flood inundation scenarios in a dozen plus locations. I'm an old hand with GIS tools in and out of the Esri ecosystem but brand new to the world of ArcHydro. I've read through the documents here. Much of the terminology is foreign to me and I don't know what applies to this project and what I can safely ignore learning about (at first). How would you recommend proceeding? What tools do I need to look at first? I've installed the ArcHydro tools for ArcMap 10.7 and Pro 2.4, have access to 3D and Spatial Analyst, and ArcInfo level licensing. Input data available: Bare earth 1m raster elevation models built from Lidar. Waterbodies are flattened but not perfect (some edges push up, have higher elevation from the waterbody centers) Vector stream lines and waterbodies that approximate but do not match the DEM surface closely enough to use as-is (e.g. not suitable for flattening) Area of interest polygons (communities and neighbourhoods potentially at risk). The polys are aribitrary rectangles and don't match any topographical features. Table of flood water elevations/depths scenarios to model (3 to 5 flood levels per community, so up to 75 scenarios total) I anticipate needing to: generate shoreline vector polygons We would prefer not to have to digitize all of them from ortho photos. Is there some auto or semi-auto method of snapping/rubber sheeting the exsiting coarser vectors to the DEM, perhaps using centroids to identify water areas, create polys from the flattish elev, then Reshape Geometry for the parts that need cleaning? re-flatten elevation from new shoreline data This seems straightforward: use the Level DEM hydro tool, but requires the above 1st. generate raster elevation surfaces for each depth level, for each project area Is it a simple "conditional (if DEM < new-Z) then (new-Z) else (DEM)" or is there a more sophisticated tool in ArcHydro to use? Remove areas from previous that wouldn't be part of the inundation area (e.g. sinks that happen to be lower elevation than new-Z but aren't connected to that waterbody) For the cartography near the end, do people prefer using rasters for the various inundations or is it better to take the time to convert to polygons, smooth/generalize and all that? And finally where should the gravity center of the project be: Pro or ArcMap (or both)? Thanks in advance for your thoughts and time. ... View more

Split fromEnable ArcGIS Pro to access ESRI Personal Geodatabases , which has a primary component of "let me read and manipulate MS Access databases from ArcGIS Pro". This idea is to highlight and make distinct the other major part of the thread, "let me have a db storage format that I can use industry standard non-Esri tools to work with".   Why Personal Geodatabases are still needed Selections from the related thread on this distinct idea:   "No, a File Geodatabase is not a suitable alternative or replacement [for mdb].  A FGD is a silo and cuts the data off from most other programs.  It isolates the data and can only be accessed from ESRI programs or GIS programs that have access to it and cannot be read at all by office productivity software or any other database software.  It's not useful to me."   "This discussion is not about speed but of compatibility with products which use the gis data outside of ESRI.  Even though, slower, in the end due to the work effort - you reach your destination much faster."   "Further, FGDBs only support a restricted subset of the SQL language, and some parts of the subset are only accessible through ArcObjects (using their PostFixClause attribute). You can't, for example, use ORDER BY or DISTINCT to select by attribute with an FGDB, but you can with a PGDB. PGDBs aren't perfect, but they do have their uses."   "...my biggest issue isn't so much that "Pro can't read the pGDB" - I could theoretically convert all that data into a FGDB before losing Desktop altogether - but this would not solve my current problem. [...] I'm open to another solution from ESRI - it doesn't necessarily HAVE to be an Access-faced database, but SOMETHING that a non-ESRI-product-owning client can use WHILE IT IS STILL also a GIS database - i.e. the data storage device needs to be editable/accessible/view-able in both spatial format AND tabular format by both ESRI product owners and non-ESRI product owners.    If my clients are forced to own ESRI software to work with my data, then they will chose a different solution and cut ESRI out completely - and I will lose work."   "Pro is a no-go for my users until pGDBs are supported. [...] We run Enterprise GDBs for Enterprise workflows. We have complex workflows at the organizational level that join disparate sources of data and run business units. For that we use and Enterprise Data basing solution. However the majority of our users have no need whatsoever for the level of complexity inherent in enterprise databasing. They want to fire up the software, do some editing, get a result. Wham Bam done.  And for that they use pGDBs because pGDBs are accessible to SQL, outside of ArcGIS. [...] ESRI fGDBs are almost entirely useless as a "data" storage back end.  They can't be accessed by anything other than ArcGIS. [...] Data goes in but you can't get it back out. It's trapped there. [...] Yes pGDBs are 'slow' in I/O.  But they are extremely fast to the finish line for data users who have desktop needs. [...] ESRI could change that paradigm by releasing the full spec on the fGDB and a non-map interface where we can implement the SQL and data analysis workflows that are higher level than map making and what the users want. But they have not. So all we have is QGIS if we want to use fGDB data.   Our users will continue to use pGDBs until Microsoft ends MS Access.  Pro doesn't work with pGDBS, Pro doesn't work for our basic users. The enhancement is necessary in the Pro product before we transition. If it isn't there, we don't transition to Pro. The calculus is really that simple."   Ok, so why SQLite for the format and not accdb or something else?   I submit that a fruitful path forward would be to embrace SQLite as the future Personal Geodatabase format: SQLite db are single files that can be moved and hosted anywhere. There's no chance of breakage because of forgetting a side car file somewhere along the way. ArcGIS already has baseline support for the format via Support for OGC GeoPackage specification in ArcGIS.  SQLite is used under the hood by ArcGIS Collector already anyway - How To: Access offline edits from Collector for ArcGIS directly from an Android or iOS device  The SQL Features That SQLite Does Not Implement list is mercifully short There are ODBC drivers which would allow clients to continue to use MS Access as a front end. In the event there are limitations of this route: There is an actively maintained on all major platforms full featured client in DB Browser for SQLite (there are other clients also) SQLite is as about as future proofed as one can get. It has official authors' commitment through to year 2050 and is recommended by US Library of Congress for digital preservation. See Long Term Support. SQLite is the most rigorously tested application/library/format I've ever read up on, with 711 times as much test code and scripts as feature code. See How SQLite Is Tested.   Note: this suggestion is different from Add support for SQLite/SpatiaLite and PostGIS geodatabases  (which I encourage people to vote for and comment on). What I'm proposing here is "make SQLite-gdb a first class citizen on par with File-GDB", which is more than just "supports", which Esri can argue it does already. (For me 'no editing' means 'not supported'). ... View more

How can I set the default label expression parser in Pro? Either globally or per project. Thanks. ... View more