Subject: [Sipping] RE: comments on rosen-dns-sos

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Feb 2004 15:08:41 -0500

Thanks for the comments.  I'll include most of them as you suggest.
The proposal copies the "datum" code from the DHCP draft.  I'd welcome
any suggestions for what to advise clients to do when two entries use
different datums and they are trying to determine inclusion.  I wondered
if just saying "its WGS84, convert on entry" isn't the right way, but
so many other folks have flamed out trying to fix the datum that I
gave up on it.

The Floor problem is solved I think.  The DNS entry would have a floor as
one of the levels, which would presumably have the correct geos with
altitude in meters.  There is also the floor count format of the data,
also copied from the DHCP draft.  Agree I need text on how to describe the
polygons for floors.

Brian

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 10:57 AM
> To: Brian Rosen; [email-masked]'
> Subject: comments on rosen-dns-sos
> 
> 
> 
> One small nit on polygons. Need to specify that the vertexes are in
> clockwise order. Failing to do this caused endless arguments 
> in air traffic
> control specifications of airspaces. Probably needs a way to 
> deal with what
> geographic coordinate grid is being used or fix it. Should 
> warn implementers
> that polygon will include the poles and the vertex may even 
> be a pole. Polar
> flights have caused more than one geographic information 
> system to crash.
> Many systems translate the 3 tupple coordinates into 4 tupple 
> coordinates
> for all calculations to avoid the singularities that a 
> spherical coordinate
> system introduces. Probably need a header format that allows 
> an arbitrary
> number of vertexes -  the top level polygons are going to be 
> big. I don't
> like the implied additive subtractive form of the poly. I 
> would prefer poly
> explicitly identify as additive or subtractive with the 
> region covered being
> formed by taking the union of all the additive then 
> subtracting each of the
> subtractive polygons. Points on a vertex or edge would be 
> considered in the
> region for additive polygons and out for subtractive 
> polygons. None of the
> polygons forming a region are allowed to share an edge. The 
> altitudes need
> to be altitude ranges to specify a volume that can be 
> clipped. Seems like
> you need this to figure out which floor in a building I am 
> on. Recommend
> that min alt is include in the volume but max alt is outside 
> the volume. The
> specification of points on the surface of the volume being in 
> or out is
> important or users can, excuse the pun, fall thought the cracks.
> 
> I was not sold on DNS to start with but your arguments about 
> the pleasures
> of forming a new global root convinced me DNS is right if it 
> will work. More
> text explaining it would work would make me feel warm and fluffy.
> 
> Cullen
> 
> 
> 
> 
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP