A bridge above water? I think would be measured "above sea level as there is no terrain unless it is underwater.
The point being that sea level for a variety of applications should be a separate category than over terrain, or above ground level. Being below sea level is another issue….but can be handled with sea level minus etc… Also different countries will, according to its topology will have different regulations, so being prepared is wise, including the x mile of ocean that is not international waters. Cruise ships coming into port for instance…will the staterooms using WS devices be above or below sea level, or will everything be WS and Slave devices if such is a use case that could apply? A DB provider could serve WS devises in such a manner. IMHO Sincerely, N On Oct 11, 2012, at 1:21 PM, Benjamin A. Rolfe wrote: > I find few circumstances where a bridge being below sea level would be a > desireable thing (perhaps in the Salton Sea of southern California?). In > general if the antenna is below sea level on the bridge we hope the > monitoring system has already sent it's alerts! Now the idea of whitespace > device on submersibles, though, is really interesting :-). > > The question really is about how we specify altitude (antenna guys call it > "height", while navigators call it "altitude"). The terms Above Ground Level > (AGL) and Height Above Average Terrain are actually quite different things. > Each must be expressed in units like feet or meters relative to some > reference. Mean Sea Level is a commonly used reference that defines an > ellipsoid approximating the level of the oceans, but of the actual level of > oceans around the world varies over time and location. MSL is just the well > defined reference point. It happens to be the reference used by GPS and most > other navigation systems used on earth. Two common ways to measure altitude > (height) are with barometric pressure (baro-altitude) and GPS, both typically > give a value relative to MSL. > > HAAT is technically very different than AGL. AGL is defined as the elevation > above a specific point on the surface of the earth. HAAT is an averaged > elevation over an area. Computing altitude AGL is simple subtraction if you > have a geo database that contains the elevation of a particular lat/lon. If > you have for example your measured GPS altitude, and the elevation of the > point on the surface at teh same lat/lon, you subtract one for the other and > viola, height above the ground. Or, for a fixed system, put in the height of > the tower or mast you put the antenna on top of (assuming the bottom of the > tower is attached to the ground firmly enough the tower remains orthogonal to > the ground - a very useful feature of towers ;-). > > HAAT requires you define a specific area and integrate the elevation values > of a number of points within that area. This means (pun intended) you have to > define an integration method, interval and pattern for selecting the points > to integrate, and so on. The FCC has done this, at least twice, as the > latest MO changed the HAAT definition used. So it'd be a bad idea to > capture a particular method for computing HAAT in the standard and I don't > see why we would, we just need the protocol to support carrying the > information around. > > Of course in your shipboard example when out to sea I'd expect AGL and HAAT > to resolve to the same value, the average terrain being wet and flat. The > same would be true in Florida too I suppose. > > From a radio point of view, HAAT can be more useful in predicting radio > propagation. FCC picked it for that reason I suspect. We can deal with the > complexity. OfCom has picked to use AGL for device antenna height in their > requirements. A protocol that doesn't support HAAT can't support databases > certified by the FCC, and if you can't support AGL you can't support > databases certified by OfCom. I don't think it takes much, as I suggested, if > we know the regulatory region we can know what form of altitude we need to > give or get. > > Hope that helps....yes I have spent a lot of my life thinking about my > position on the earth :-). > > B > > >> Also, there are different possible use cases that would need HAAT etc, and >> some where it could be above sea level if WS devices are used aboard a ship >> or boat or attached to >> a flotation device of some sort for monitoring in the future. Or >> infrastructure monitoring on a bridge lets say, that would be above sea >> level I assume. >> >> OF course this would be applicable to local regulations allowed. >> So having the ability to comply with all, in the original protocol and may >> be something to be discussed by the WG. >> Just a thought, I am not married to it. >> >> Sincerely, Nancy >> >> On Oct 11, 2012, at 10:19 AM, Benjamin A. Rolfe wrote: >> >>> I would not suggest specifying a method to resolve HAAT, as there are many >>> methods which may be used and I would not bet on every regulatory region >>> agreeing on a single method. For each Height (altitude) provide a way to >>> indicate what it is as suggested bellow and a way to identify the reference >>> model or regional method (like regulator ID?). >>> >>> At the moment, FCC specifies the location is of the device, while OfCom >>> specifies the location is of the antenna. The later makes more sense to >>> a radio guy worried about interference footprint. The first seems to >>> assume the device and antenna are close enough to each other (within the >>> allowed uncertainty which is currently +-50m). OfCom and FCC currently >>> specify WGS84. This may change in the future if the as the WGS model has >>> been and will be updated from time to time. OfCom gives specific >>> requirements for how accuracy is specified (and a 95% confidence level). >>> Where antenna height is required by OfCom it is specified as above ground >>> level. FCC has specified HAAT and has already revised at least once how >>> HAAT is to be determined (and I expect it to change again). >>> >>> OfCom identifies other antenna characteristics that may be communicated >>> between a device and the database as well including directionality and >>> orientation, polarisation (I am quoting OfCom here), and if the antenna >>> location is indoor or outdoor. >>> >>> Hope this helps >>> >>> Ben >>> >>> On 10/11/2012 5:40 AM, Peter Stanforth wrote: >>>> Agreed. >>>> We need to be able to resolve AGL, HAAT, location and maybe other criteria >>>> based on the regulators methods. I am not sure a single 3D location will >>>> be acceptable. >>>> >>>> On ThuOct/11/12 Thu Oct 11, 6:07 AM, "Rosen, Brian" >>>> <[email protected]> wrote: >>>> >>>>> We need both I think, because of the way the regulations are written. I >>>>> don't think there is a simple way to convert that would be acceptable. >>>>> In theory, if we knew the terrain height at the location accurately >>>>> enough, we could calculate what we need, but that is an onerous >>>>> requirement I think. >>>>> >>>>> Brian >>>>> >>>>> On Oct 11, 2012, at 12:53 AM, Vincent Chen<[email protected]> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> The various versions of the proposed drafts of the PAWS protocol tended >>>>>> to distinguish between "device location" and "antenna height". >>>>>> >>>>>> I think we should combine them into a single 3-D location of the >>>>>> radiation center of (the antenna of) the device. >>>>>> >>>>>> Does that sound right? >>>>>> >>>>>> The proposed draft-vchen-paws-protocol-00 defines the following >>>>>> parameters for location and height: >>>>>> >>>>>> latitude >>>>>> longitude >>>>>> locationUncertainty >>>>>> locationConfidence >>>>>> >>>>>> height >>>>>> heightType >>>>>> heightUncertainty >>>>>> >>>>>> This is very close to the fields defined by RFC 6225, which has the >>>>>> parameters: >>>>>> >>>>>> latitude >>>>>> latitudeUncertainty >>>>>> longitude >>>>>> longitudeUncertainty >>>>>> altitude >>>>>> altitudeUncertainty >>>>>> altitudeType >>>>>> >>>>>> Should PAWS reference RFC 6225 and list the following differences? >>>>>> >>>>>> - The "altitudeType" should be "above means sea level" (WGS84) or >>>>>> "above ground", instead of the ones defined in the RFC. >>>>>> >>>>>> - Add confidence values along each axis. >>>>>> >>>>>> If this acceptable, then we can think about defining JSON encoding of >>>>>> RFC 6225 for use by PAWS. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> -vince >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> _______________________________________________ >>> paws mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/paws >> >
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
