Latest Contributions by MattWilkie1

For you and anyone else coming across this thread, please see https://github.com/envygeo/arcscripts_archive for an attempt at recovering some of the old ArcScripts content. Currently only 5 items have been archived so the most value of the project so far lies in the content index. And I'm sorry to say, the script you're after Jae Jong is not in the collection yet. Perhaps your post will uncover something though!

‎12-10-2021

Thanks Dan. Using Jpeg-100% is conceptually the same as applying LZW or some other encoding (except the latter is actually lossless instead of maybe-perhaps). All of these methods add a storage increase penalty in order to keep the info unchanged. Perhaps Jpeg-100 will be the least expensive* if there is no choice. I'm looking for a way to copy the existing info as is, especially if the only change of note is the bounding box. * Depending on local circumstance. In a local quick test of a small image Jpeg100 is in the middle between ZSTD and LZW in terms of storage size: 11,626,259 cog-lzw.tif 9,887,223 cog-zstd.tif 10,164,668 jpeg-100.tif

‎12-10-2021

We have a lot of spatial imagery where lossy jpeg compression has been used. This is fine and even the most appropriate format for daily use scenarios where the image is mostly a backdrop to place other information in context. However it is mal-adaptive when used in analytic studies where the typical workflow is crop out the area of interest and/or mosaic with overlapping images in the area of interest. To the best of my knowledge in this event the study needs to choose between: Storing in lossless compression and dramatically increase storage consumption Storing in lossy compression, and lose more values than has already been lost while simultaneously introducing artifacts (false data); Or am I wrong, and there is a way to convert all or a portion of a jpeg image without re-applying jpeg compression encoding? If it's relevant, all of the imagery I'm thinking of here are stored as jpeg-in-geotiff.

‎11-15-2021

Thanks Kory. In that blog post https://www.esri.com/arcgis-blog/products/arcgis-pro/data-management/new-data-types-supported-in-the-mobile-geodatabase/ the link to https://prodev.arcgis.com/en/pro-app/latest/help/data/geodatabases/manage-mobile-gdb/mobile-geodatabases.htm is broken, non-existent domain. Reporting here because there doesn't seem to be a way to do so on blog posts themselves.

‎09-09-2021

Some days it's hard not to be cynical. The geonet forums have posts going back to at least 2013, but somehow the "Support LAZ format" idea has been pulled.

‎07-08-2021

Since depth raster is a required input but this solution does not have means or instructions to create depth rasters it would be good to insert the comment from Gert at https://community.esri.com/t5/3d-blog/flood-impact-analysis-solution/bc-p/899401/highlight/true#M42 into the main post at top. Namely: "See ArcHydro if you need to create depth rasters." This info should also be added to the documentation overview page and the Solutions package.

‎07-05-2021

Yep, Pro is painfully slow for me too and has been for several versions. I have https://pro.arcgis.com/en/pro-app/latest/get-started/pro-performance-tool-overview.htm bookmarked as a I-really-should-go-through-that item for when I'm not overloaded with work and have time and requisite mental space to learn something new.

‎06-29-2021

That bug record says it was fixed in v9.2?

‎06-29-2021

Wow. This one is subtle. It's not a bug, exactly, but it sure as heck isn't not-a-bug either. Prior to the state above I had selected a polygon and used the Explode editing tool. Although I had finished with the tool it was not deactivated. There was no visual indication in the attribute table panel that the edit tool was still active and filtering records non-visually. Said another way: the table panel was still showing me all records, but the allowable set of records that could be operated on were filtered by the still-active Explode tool, which meant that the Select By Attributes tool only saw the subset left exposed by Explode. The fix was to deactivate the editing tool by using the back button in the tool panel and then use Select by Attributes again. How did I figure this out? Later, when I toggled OFF the layer's editability a temporary notification appeared saying "Active Edit tool is filtering the selection. Deactivate tool to restore the selection". At this point I remembered seeing the notification 15 or so minutes earlier when I started editing. So the bug here if there is one is that the notification is temporary. Or that it shows at the wrong time. Or that the table panel does not have an indicator of the filtered record status. Or all of the proceeding. See Esri's page on "active tool is filtering the selection" for more info. Cross posted https://gis.stackexchange.com/questions/402758/arcgis-pro-select-by-attributes-misses-records/

‎06-29-2021

Has anyone had this happen to them? I'm running Select By Attributes on a feature class to select shape area less than 300, but only a fraction of the records are being selected. This screenshot is after the query has been run. I've verified the selection is New Selection and not Reselect from a previous selection. The table is sorted on Shape_Area. It's clear that 20 of 24 visible rows should be selected, but only 13 actually are. I've pressed [refresh table] at bottom right after running the query. I've replicated these bad results several times, but all in this same session (I haven't yet tried closing Pro and trying again). The table is a polygon feature class in a file geodatabase. ArcGIS Pro 2.8.1.

Online Status	Offline
Date Last Visited	a week ago

My Ideas

Latest Contributions by MattWilkie1

Re: Please restore ArcScripts

Re: Clip or export jpeg raster without re-compressing

Clip or export jpeg raster without re-compressing

Re: SQLite as future-proof backend for Personal Geodabases

Re: I have LAZ data and need to convert it to las format.......

Re: Flood Impact Analysis solution

Re: ArcGIS Pro is terribly slow. Even closing takes many minutes

Re: Select by Attributes misses records?

Re: Select by Attributes misses records?

Select by Attributes misses records?