More efficient way to create hex grids?

[EricEagle]

I'm using the Generate Tesselation tool to create a hex grid over a large amount of point data.

The problem is that the data does not fill the majority of the extent, so Generate Tesselation ends up creating a whole bunch of pointless grid cells over area that I don't care about.  And because Generate Tesselation is a single-threaded, single-core affinity, IO bound process, it's already slow to begin with.

Here is a simple illustration of the problem:

Is there a way for me to be able to create hex cells only in the hull around the cluster?  In other words is there a way to create cells by mask and not by Extent?  Python solutions are fine.

[DanPatterson_Retired]

https://www.arcgis.com/home/item.html?id=ddb2deec9b5e4a09affe60de68f5ff4e 

The generation of the hex's is fast (numpy), the slowness is  bringing back into Pro and creating the arcpy geometry, but worth an experiment or send me a copy of the file if you want me to have a look.  It still works to an extent and requires clipping after

[EricEagle]

Thanks for the reply, Dan, I'll take a look.  I am summarizing points within the grid, so would definitely want to minimize the grid to the point clusters before counting.  It introduces a bit of a conundrum.  I don't want to spend time having to count 0's in every cell, and then dropping them, but I don't know which cells to drop without doing the summarize-within first.

I feel like I'm going to end up creating a Generate Grid by Mask script before this thing is done...

[DuncanHornby]

A possible speed improvement if you have the latest version of ArcPro is to write the output to the "memory" workspace as an intermediate step then select and delete out the hexagons you are not interested in? So with the latest version you can now write data to memory\testdata instead of c:\temp\test.shp or in_memory\test.

[EricEagle]

Thanks Duncan,

At least on our configuration, I have found the 'memory' space to be fundamentally unstable once you get outside of the most simple use cases (for example memory-to-memory dataset comparison).  One of the tools I'm using, Summarize Within, throws an error when one tries to output it to memory.

I am running a 36 core, 128gb RAM Dell Precision 5820 - plenty of resoures.  But putting things in memory, for whatever reason, causes Pro 2.3 to ungracefully crash to desktop constantly.  So I basically have to do a bunch of duct-tapey stuff writing out intermediate datasets, and then crawling the project geodatabase to delete them afterwards.  super lame

[DuncanHornby]

Eric,

Interesting you say that, I've being using the new memory workspace today for quick and dirty spatial joins and summarising the data. That in itself seemed to run OK with out issues but I too have found that it seems to "unhinge" ArcPro and performance particularly creating layouts crawls to a snail pace to the point it all becomes unusable and I have to crash out of Pro.

So my experience with using the new memory workspace is that it upsets other functionality in Pro to the point it becomes unusable. Can't say, if anyone else is reading this,that I can replicate this or it's a consistent issue, but this has been today's joyous experience! 

I still think the memory workspace is good for geoprocessing, I guess just don't expect to use Pro for anything else until ESRI iron out all the bugs...