Re: [Geopriv] Quick review of draft-linsner-geopriv-relativeloc-02

From: Marc Linsner ^lt;mlinsner@cisco.com>
Date: Wed Nov 12 2008 - 09:06:08 EST

Martin,

Thanks for the review.

Comments in-line....

On 11/9/08 7:00 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:

> Hi Marc, Allan,
>
> As with other drafts, I think that this work is useful. It may be a little
> early, but that's not a failure of the draft. My major concerns arise from
> execution. As documented, this draft doesn't have quite enough detail to
> ensure that it doesn't cause problems.
>
> The most important part of this draft is the selection of the reference point.
> Selecting a unique point using something as imprecise as a civic address
> format is difficult.
>
> I find that it is helpful to think of the civic address as defining a series
> of (sometimes non-orthogonal) spatial partitions. The first is the implicit
> partition that identifies the habited portion of the earth. The second is the
> country. Right down to road (which includes all properties that adjoin the
> street), and on to seat. Each label might need to be interpreted with other
> values to provide context. As a value at each level is interpreted, one or
> more partitions at that level are selected, and all other partitions of that
> type are excluded. For non-orthogonal partitions, only the portion of the
> partition that fits within the existing space is selected (this is what
> ensures that George St in Sydney is selected, rather than the George St in
> Newcastle). In effect, each defined element selects a partition of space and
> the resultant location is the intersection of all selected spaces.
>
> This view helps with correlating the civic address with a geodetic position,
> including uncertainty (the selected space is the region of uncertainty). At
> no stage does this select a point, though as spaces get smaller, approximation
> to a point is useful.
>
> Based on this background, I'll outline my concerns:
>
> The reference point AND resultant relative location must be contained within
> the space selected by the rest of the civic address.

Agree. Currently this is in the draft as a SHOULD.

  I'll expand on the
> reference point piece later. For the result, this ensures that if the
> relative elements are not understood, the rest of the civic address isn't
> misinterpreted. This is important for backward compatibility.

Agree. If the location recipient doesn't understand the ref point/offset,
the associated civic data needs to still work. The same is true with 'room
number', it's meaningless outside of the associated civic address.

>
> (The above also applies for if you allow this to be used in a complex with
> geodetic positions, but you would have to define this as relative to the
> centroid and restrict it to the geodetic positions that have uncertainty.)
>
> The resultant relative location is only as good as the specification of the
> reference point. If you specify a door as the reference, the resulting point
> has uncertainty of at least the size of a door. Your corner office example
> still describes a location the size of an office. An observation to this
> effect in the draft might be helpful.

OK. I was under the assumption that human interpretation of civic locations
took this into account. 123 Main St. Room 106 carries with it the
understanding that any point within Room 106 is valid, hence I'm not sure
the whole area covered by Room 106 would/should be considered 'uncertainty'.
We need more discussion on this.

>
> There is another aspect to the definition of the reference point. The
> reference location has local significance, but it's extremely important that
> the entire civic address be unambiguously understood. Using generic reference
> labels (as suggested) can result in different interpretations if one or more
> of the civic address labels is not understood. This means that you need to
> define which set of fields must be understood: all provided, or all 5139/4776
> labels (the difference is significant; I favour the former).

The civic location fields have a hierarchy to them: country; state; city;
street; address; etc. Beyond street address, all supplementary data is
locally significant: floor; room; seat; cubicle; etc. Do you think we need
to update the existing documents (4119, 5139) with this suggestion?

>
> Minor points:
>
> Discussing earth curvature isn't really helpful. If you want to talk about
> getting a very accurate geodetic position, my suggestion is that you be even
> more specific. Convert to ECEF, and use the resultant x,y,z to get a unit
> vector for "up". Then derive the northing vector by calculating the azimuth
> to a point directly north and adjusting for curvature. The cross product of
> northing and the up vector will get an easting vector.

The curvature discussion was added as a response to Carl Reed's comments.
Like you, I don't believe the use case this draft covers needs to be
concerned with earth curvature. I think we were not clear in the use case
in earlier versions of the draft, hence Carl's concern, and we should ask
Carl if this still make sense.

>
> The above is all probably moot since I suspect that people will be using this
> on floor plans. Plot the reference point on the plan, provide a north vector
> (based on survey or a compass) and that's probably enough.
>
> Don't use X, Y and Z. Use EW, NS and UD (or the longer EastWest, NorthSouth
> and UpDown). This is easier to remember and you don't have problems with
> people putting north/south first and stuffing it up.

We offered to do this in earlier discussions to help with confusing this
with geodetic locations. We need more discussion amongst the
authors/contributors.

>
> Don't extend the schema in the same namespace. This doesn't work particularly
> well with the approach adopted by the IETF for XML design. Define a new
> namespace and schema. It doesn't even have to be flat like 5139 - that flat
> schema works well enough when you don't have any better structure, but you can
> potentially use a more GML-like position:
> <relative><to>Elevator-1</to><pos>-20 -31<pos></relative>
>
> You don't want to use ca:caType for EW, NS and UD since those elements are
> numerical and don't require xml:lang.

OK

>
> Don't allow for feet. If people want to use antiquated units of measure, they
> can use the standard formulae for conversion. It's one fewer element to
> define.
>
> Section 9.2 is empty.

OK

-Marc-

>
> Cheers,
> Martin
> ------------------------------------------------------------------------------
> ------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------
> ------------------
> [mf2]
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Wed, 12 Nov 2008 09:06:08 -0500

This archive was generated by hypermail 2.1.8 : Wed Nov 12 2008 - 09:06:21 EST