Problems with PINs elevation data

[s.zanarello]

Hi all, in my opinion there are 2 issues with elevation data in current release of TPE web

1. in R3 of TPE it was clear and straightforward to see default quotes (values retrieved by web services), assign correction values and see correctd quotes

Anyway, in version 4 it’s not so simple.

In Map window, there is a “button” (belove data field) where I can see default values and (only for Red pin) the corrected value. But, is not possible to see corrected elevation for Black Pin

In Geodetic tab, it,s possible to assign correction values, applied to default values retrieved from web, but here it’s not possible to see original values and corrected values.

In my opinion, in Geodetic tab it’s necessary to add original elevation data and corrects elevation data fields, otherwise deciding and applying elevation data is quite difficult

2. In my opinion there is a second big problem with elavation data. When I save a pin location, it’s saved also the elevation correction (if I corrected the quote, obviously).

The problem is that TPE save correction data, and not the absolute value of corrected elevation. If elevation data web source changes from Map to Visual Search, the correction will apply to different quotes, resulting in errors.

For examples, in Map I use Google map, with Google elevation source, but when I switch to Visual search, Google elevation source is no more available, and TPE switches automatically to AWS Terrarium, so all corrected elevation data are wrong. This is a big problem

[stephen]

Hi @s.zanarello

I think I understand what you’re looking for but a question first: when you say “corrected elevation data”, are meaning (1) corrections to the ground level elevation above sea level; (2) setting the height of a building or other man-made structure above ground level; or (3) a combination of both of these?

Any specific examples you could provide would be very helpful to make sure I have fully understood your use case. Screenshots and links to shot plans are always very informative.

[s.zanarello]

Hi Stephen, I think it’s the same.

I explain how I work:

RED PIN: I correct ground level elevation, since often default values are incorrect

BLACK PIN:

• if black pin is a natural point (es mountain top) I correct elevation (same way I do for red pin).
• If black pin is a building and correct elevation for black pin, since I use tu put it directly on the top of the building, so I hav to correct elevation to obtain the real elevation of this point

But, to me, all cases are the same. Put the pin at a certain height above ground level or corrects (add offset) the ground level is the same thing, The key point is to be able to put pins at specific elevation values.

Regarding my previous post, the keys are 2:

• to be able to see default elevation values, correct them and see corrected values in a straitforward way (as it was in version 3 of TPE - see screenshot attached). I add a second screenshot of V4 Geodetic windows, in wich I suggest to add to fields (original elevation and corrected elevation)

  
  

• to be sure that corrected elevation values, saved in Location, don’t change if TPE change source of elevation data. For this point, a solution maybe could be to add the option to block the elevation in saved location (if this option is delected, the elevation remain fixed even in the case the elevation web source change)

Just an example.

Moon aligned with Superga church, near Turin. I know that exact elevation of the top of this church is 738 m above sea level. Default elevation provided by Google elevation is 682 m, so I add a 56 m offset. The problem is that in version 4, switching in Visual Search, TPE switch from Google elevation service to AWS Terrarium , wich provide a different elevation value, so the resulting correctd value is no more 738 m.

[stephen]

Thanks Stefano. That’s very helpful. Let me think this through some more and I’ll look to make some changes as needed to address these points.

[stephen]

@s.zanarello - quick follow-up question on the Superga church: researching online, I figures I read are +672m for the site and 75m height to the top of the dome, making 747 m above sea level. I’m guessing based on your 738 m number, at least one of those values is wrong? Do you happen to know which, or have a source for the 738 m number?

My instinct is to separate out corrections to ground elevation-above-sea-level from building height corrections. I’m guessing that the 56 m correction you mention above combines those into a single number?

[s.zanarello]

@stephen , yes, the 738 number comes from an external, certain source (a LIDAR survey).

And yes, the 56 m correction is simply determined in order to transform ground level elevation (682 m, using Google elevation source) into the elevation of the top of the building (738 m), where I put the black pin.

But, talking about this specific case (anyway, the same thing applies to other cases), the problem is that the 56 m correction is correct only assuming Google elevation (682 m). Other elevation sources provide, for the same point, differet elevation values (for example, AWS Terrarium provides a value of 666 m asl), so changing elevation sorce the final elevation becames incorrect.

This is the reason because, in my opinion, there is the need to add an option to block the corrected ground elevation or, maybe a better way, add the option to input directly the corrected elevation.

In my opinion, it could be added a tab in Geodetic section, at the left of Photographer tab, for ground elevation correction. See attached screenshot

The important thing, in this case, is that if user input directly the corrected elevation value, this value will remain constant for this point, overriding values froum web elevation sources.

In this way, there will be a separation from ground level correction and the correction for building height.

[stephen]

Hi @s.zanarello – I’m doing some work on this today. It may take me a few more days to get all the required changes done, but please know that it’s in flight.

I’m also working on the building height override functionality too @ronskinner4435 as part of this effort.

More soon!

Stephen