Hi Adam, Many thanks for your notes. Your point about GeomOverlayTouchingPar doing more work than necessary for this particular case was the thought that I had arrived at when I started thinking about coincident coordinates. With a little help from my friends, I replaced the first query using GeomOverlayTouchingPar with this approach to achieve this particular goal and it has reduced the process time to ~13 seconds. I then feed the result into your clusters script and I get exactly the result I am after so thank you very much for your cluster solution which is really handy.
VALUE @source_dwg TABLE = [VECTOR MASK Drawing];
CREATE TABLE [COORD]
--INDEX [mfd_id_x] BTREE ([mfd_id]),
INDEX [OID_x] BTREEDUP ([OID]),
INDEX [XY_x] BTREEDUP ([XY]) -- Speeds up grouping
INSERT INTO [COORD] ([XY], [OID])
SELECT [XY], [mfd_id]
SPLIT CALL GeomToCoords([Geom])
SELECT FIRST([OID]) AS [ID1], LAST([OID]) AS [ID2]
GROUP BY [XY]
DROP TABLE [COORD]
CREATE TABLE [TEMP_OUT] ([ID] INT32, [IDCLUSTER] INT32, INDEX [ID_x] BTREE ([ID]))
With regards …
‘We will consider adding a function to check specifically for coincident coordinates - because that's useful.’
It most definitely would be as there are plenty of situations where this test alone would be sufficient. I appreciate that it can be done now, but a function would be neater and easier to understand I think.
‘We will consider extending the decompose option from a simple boolean for decompose / don't decompose to a switch for decompose entirely (like we do now) / decompose but keep branches which are touching each other in the same geom (a new choice) / don't decompose.’
I think this would really useful and a great addition. Many thanks for considering this. It is one of those things that I require on and off but am surprised how often it comes up. If it can simply be added to an existing function as a parameter then that would be a very neat solution.
Landsystems Ltd ... Know your land | www.landsystems.co.nz