How to calculate trench lenght

[Björn Schaefer]

Hi everybody.

Using 5.2.5 Pro:
Is there any known possibility to calculate automatically the trench length from a given utility net, (i.e electricity) within an analysis?
(Not necesserally a smallworld database)

Small example:
I'd like to calculate the measured length from situations like this and sum up those calculated lengths within a given area like an village.
My target is to deliver an amount per area.


My first attempt was to ease the given geometries, but this will not shorten the lenght in general, cause existing, overlaying geometries are still present.
My second attempt was to build a buffer around the given geometries, i.e. 1m wide. This will work properly, but i found no solution to calculate the length from the (not exisiting) buffers middle line, there is just the buffers area...

any more ideas?

sorry for my english, german native speaker ;-)

 

[kenkorsmit]

Interesting question. One could try to use the skeleton function in order to obtain a line again from the merged buffers. You will get 'artifacts' at the ends. (The line will be wobbly there.)

Another possibility would be, if the buffer is 1m (each side, so 2m total), to divide the area by 2. In the latter case, begin in the same trench is a bit more 'fluid,' i.e. the trench length becomes bigger when cables are further apart. I don't know if this is desired/acceptable.

The last approach that comes to mind is to try to direct all cables into sections, e.g. of just a 3 meters long (but I have never done that *). Then make a perpendicular line of the centre point 1m to each side. Group the perpendicular lines. Sum up 3m for each group.

(*) Probably by cross joining with a table having all desired distance, e.g. 1.5, 4.5, 7.5 etc as records. Then take the point 'along the cable.'

 

[Björn Schaefer]

Hi Kenkorsmit
Thanks for your ideas
Skeleton: found that Option later on, could be a step forward, i will test this.

Area / 2: I'm not sure, if this is correct. but i had something likely in mind: Calculate Buffers, unite them and calculate the circumference from Buffer.union.area.
The circumference divided by 2 could be a good result to work with. Unfortunatly i couldn't find a function to calculate the circumference.
small example from such a Situation (red surrounded Areas)


divide geometries in parts: I do not know about a function like this… or is there any possibility, to create a persistant grid with configurable grid-width within GSA, wich can be used to intersect given geometries?

 

[Björn Schaefer]

further results / Problems:
Situation like this: 3 Elements are shown here:
first:

second:

third:


the measured length is About 660m


the resultlist Shows something like this:


ungefähre Länge (Graben) = (union.area / 2).toInteger()
This is pretty nice but None of those columns would deliver a seriously sum up nearby to 666m, so I'm not able to verfiy this result as "good enough"

any further hints?

 

[kenkorsmit]

Hi Björn,

>The circumference divided by 2 could be a good result to work with. Unfortunatly i couldn't find a function to calculate the circumference.
You can use the .perimeter property. By the way, the .boundary property yields the circumference as a line. I think that will make the results much better.

> divide geometries in parts: I do not know about a function like this… or is there any possibility, to create a persistant grid with configurable grid-width within GSA, wich can be used to intersect given geometries?
Yes, this is done via a feature source called "Map Grid". You can great a rectangular or hexagon grid.

I think the 'ungefaehre laenge' buffer should be created with special ends (may be you do this already), and corrected for the buffer (which is -4m per cable).
So:
1) Buffer(10, 0.1, LineCapStyle.Flat).union()
2) ungefähre Länge (Graben) = (union.perimeter - 4) / 2)

Just a tip: you can round by the round() function, or even better, do not round but format the field with format({0:n0}) function
A bit advanced maybe, but each field can have a formatted. (Check out the C# format function on internet). It will tell you that n0 is a number with no decimals.

 

[Björn Schaefer]

Hi Björn,

>The circumference divided by 2 could be a good result to work with. Unfortunatly i couldn't find a function to calculate the circumference.
You can use the .perimeter property. By the way, the .boundary property yields the circumference as a line. I think that will make the results much better.

Cool, I will check this out!

> divide geometries in parts: I do not know about a function like this… or is there any possibility, to create a persistant grid with configurable grid-width within GSA, wich can be used to intersect given geometries?
Yes, this is done via a feature source called "Map Grid". You can great a rectangular or hexagon grid.

Perfect! Thanks for this hint!

I think the 'ungefaehre laenge' buffer should be created with special ends (may be you do this already), and corrected for the buffer (which is -4m per cable).
So:
1) Buffer(10, 0.1, LineCapStyle.Flat).union()
2) ungefähre Länge (Graben) = (union.perimeter - 4) / 2)

you're Right, didn't think About that yet

Just a tip: you can round by the round() function, or even better, do not round but format the field with format({0:n0}) function
A bit advanced maybe, but each field can have a formatted. (Check out the C# format function on internet). It will tell you that n0 is a number with no decimals.

 

[Björn Schaefer]

Keep on trying....
this is what I've done now:

• build a buffer (1m wide, End flat) for each "Schutzrohr"
• simplify all buffer objects ("Schutzrohr.Buffer") to one single object
  
• defining a skeleton on this single objekct [V Leerrohr Ne3 Buffer Easy].[Easy Buffer].Skeleton()

Creating some styles to view the result optically: (green = Buffer Easy, yellow dotted = skeleton)


I don't know, what's wrong, i expected, that the skeleton line covers the buffers area as kind of middle line...

 

[kenkorsmit]

Hi Bjorn,
I'm sorry to react so late; my schedule is swamped.
About the skeleton: It is inside the buffer, but at the end its starts getting wobbly; I call these 'artifacts' and I don't know what to do about them. Do they distort the computation too much?

Would it be possible for you to create a zip file containing a test project and some sample data (e.g. in a GeoPackage database or some GeoNotes?
Note that it will take a while before I can look into it.
It looks like your data follows a certain pattern, that might make the task easier.

Best regards,
Ken

 

[Björn Schaefer]

Hi Bjorn,
I'm sorry to react so late; my schedule is swamped.
About the skeleton: It is inside the buffer, but at the end its starts getting wobbly; I call these 'artifacts' and I don't know what to do about them. Do they distort the computation too much?

Would it be possible for you to create a zip file containing a test project and some sample data (e.g. in a GeoPackage database or some GeoNotes?
Note that it will take a while before I can look into it.
It looks like your data follows a certain pattern, that might make the task easier.

Best regards,
Ken

Thanks for your support, I've made a shape, see attachment. I guess, that this may be helpfull enough to rebuild the problem without our projectfile, the objects within are reduced to Name + geometry

 

[PeerBittner]

Hello everybody,

a few month ago I faced a similar problem: Our Assetmangement wanted to know what is the potential trench area, if we had to replace certain parts of the electricity net.

Initially I attempted to solve the problem in a similar way to Björn’s. To be honest, I always had the problem of “self-intersection”. Then, when time was of the essence, I changed my approach.

So here is what I did (the short version):

1) Create a Map Grid

(https://documentation.geospatialana...0/en/89853cd7-4924-40ea-9336-eb4563de6e37.htm)

Cell Size is 1x1 meters. I know it is a very small cell size. You properly have to play around with the grid coverage a bit! But it worked for me – especially if you import it in a PostGIS-DB.

2) Intersection Map Grid / power line geometries (https://documentation.geospatialana...0/en/725a91b6-d559-4330-a526-0e91f73b737b.htm)

Business Object 1: power line / Business Object 2: Map Grid

This basically returns all the cells from the input grid that have a power line running through them. If you sum up those “affected cells” it gives you an estimation of the trench area.

I know, this approach won’t solve the problem regarding the trenchlength, but maybe it’s a workaround regarding the self-intersection problem.
This is what it looks like:


Cheers,
Peer

 

[Björn Schaefer]

Hello everybody,

a few month ago I faced a similar problem: Our Assetmangement wanted to know what is the potential trench area, if we had to replace certain parts of the electricity net.

Initially I attempted to solve the problem in a similar way to Björn’s. To be honest, I always had the problem of “self-intersection”. Then, when time was of the essence, I changed my approach.

So here is what I did (the short version):

1) Create a Map Grid

(https://documentation.geospatialana...0/en/89853cd7-4924-40ea-9336-eb4563de6e37.htm)

Cell Size is 1x1 meters. I know it is a very small cell size. You properly have to play around with the grid coverage a bit! But it worked for me – especially if you import it in a PostGIS-DB.

2) Intersection Map Grid / power line geometries (https://documentation.geospatialana...0/en/725a91b6-d559-4330-a526-0e91f73b737b.htm)

Business Object 1: power line / Business Object 2: Map Grid

This basically returns all the cells from the input grid that have a power line running through them. If you sum up those “affected cells” it gives you an estimation of the trench area.

I know, this approach won’t solve the problem regarding the trenchlength, but maybe it’s a workaround regarding the self-intersection problem.
This is what it looks like:
View attachment 85

Cheers,
Peer

Hi Peer
Nice idea... I did not understand, why you're using intersection, 'cause you do not use the intersection length afterwards, to sum up.
For counting affected gridcells it should be sufficient, to join via grid.area touches powerline.curve.

Anyway: the result may give an idea about the trench length. So far so well, but I faced the problem, that there is a limit by creating "enough" gridcells:


the marked blue square shows the desired area for the Grid, configured within the feature source. The yellow (left half) area shows the generated cridcells. It seems like this is the limit 1million datasets.

I guess, that this is not the final solution ;-) I will test this with some different configurations regarding gridwidth

so far...

regards
Björn