Compute the area of a layer inside a PCell instance from the callback

It is rather unclear what you did and what want to achieve.
e.g. you ask for how to run the 'Area and Density Calculator' from skill to calculate the area of a polygon, but then you state that you already have skill code for area calculation, which makes the previous passages and the polygon details obsolete.

So I'm rather guessing now.
First, you mean "CDF callback" when you use the term "callback".
Second, you have a cell with a layout pcell view. The other views, symbol/schematic/cdl/simulation model/etc. are not relevant for the rest.
Third, you want a CDF parameter (you call it 'field') that should contain the area of specific shapes from the corresponding layout pcell view in order to display this area value e.g. on the instantiated symbol and/or on the properties form.
This area CDF parameter shall be readonly (created with '?editable nil'); having this editable, so the user can specify the area, would make it more complicated.
And last, the area CDF parameter shall be updated, when the user edits whatever other CDF parameters you have for the layout pcell. So you added a CDF callback on these other CDF parameters, which is called whenever the user edits these values.

If that is true, than the answer is no, you cannot access an evaluated layout pcell instance and the contained shapes from the CDF callback, because the layout does not necessarily exist when the CDF callback is invoked. The CDF callback is e.g. also executed, when you place the symbol of the cell in a schematic and change the parameters there, no layout is involved in the process.
Inside the CDF callback, you only have the cdfgData, which is the source for later evaluation of the layout pcell. You cannot access the end product at the beginning.
Although, it might be possible to create a temporary layout cellview, instantiate the layout pcell there, set the parameters from the current cdfgData on the instance, so the pcell instance is evaluated (CDF callbacks are not invoked here) and then access the shapes, but this is guesswork and quite some overkill.

More realistic is to just call the code pieces that generate the layout shapes from the CDF callback with the arguments from the current cdfgData. Though, it would require to put this part of the pcell code in a separate procedure in order to call it from both the layout pcell code and the CDF callback; or have this code replicated on both places.

You also need to consider that the source parameters can be controlled by ADE design variables or expressions (e.g. pPar/iPar) so the actual parameter values may be unknown when the CDF callback is invoked. The result in the area CDF parameter should still be reasonable in that case.

You may also have a look at the articles 'The dangers of CDF callbacks' and 'Component Description Format (CDF) - Quick Reference to Basics and Frequently Referred Solutions', the latter has some examples, but if you already have experience with pcell development, this is maybe nothing new.

It is rather unclear what you did and what want to achieve.
e.g. you ask for how to run the 'Area and Density Calculator' from skill to calculate the area of a polygon, but then you state that you already have skill code for area calculation, which makes the previous passages and the polygon details obsolete.

So I'm rather guessing now.
First, you mean "CDF callback" when you use the term "callback".
Second, you have a cell with a layout pcell view. The other views, symbol/schematic/cdl/simulation model/etc. are not relevant for the rest.
Third, you want a CDF parameter (you call it 'field') that should contain the area of specific shapes from the corresponding layout pcell view in order to display this area value e.g. on the instantiated symbol and/or on the properties form.
This area CDF parameter shall be readonly (created with '?editable nil'); having this editable, so the user can specify the area, would make it more complicated.
And last, the area CDF parameter shall be updated, when the user edits whatever other CDF parameters you have for the layout pcell. So you added a CDF callback on these other CDF parameters, which is called whenever the user edits these values.

If that is true, than the answer is no, you cannot access an evaluated layout pcell instance and the contained shapes from the CDF callback, because the layout does not necessarily exist when the CDF callback is invoked. The CDF callback is e.g. also executed, when you place the symbol of the cell in a schematic and change the parameters there, no layout is involved in the process.
Inside the CDF callback, you only have the cdfgData, which is the source for later evaluation of the layout pcell. You cannot access the end product at the beginning.
Although, it might be possible to create a temporary layout cellview, instantiate the layout pcell there, set the parameters from the current cdfgData on the instance, so the pcell instance is evaluated (CDF callbacks are not invoked here) and then access the shapes, but this is guesswork and quite some overkill.

More realistic is to just call the code pieces that generate the layout shapes from the CDF callback with the arguments from the current cdfgData. Though, it would require to put this part of the pcell code in a separate procedure in order to call it from both the layout pcell code and the CDF callback; or have this code replicated on both places.

You also need to consider that the source parameters can be controlled by ADE design variables or expressions (e.g. pPar/iPar) so the actual parameter values may be unknown when the CDF callback is invoked. The result in the area CDF parameter should still be reasonable in that case.

You may also have a look at the articles 'The dangers of CDF callbacks' and 'Component Description Format (CDF) - Quick Reference to Basics and Frequently Referred Solutions', the latter has some examples, but if you already have experience with pcell development, this is maybe nothing new.

Thank you for you detailed and informative answer.

I understand that my way of working was wrong and i will reconsider it using the cdf parameters at my disposal.