Subject: Registration of text/calendar MIME property GEO_BOUNDS

From: Doug Royer <[email-masked]>
Date: Sat, 19 Aug 2000 23:59:57 -0700

Property name: GEO_BOUNDS

Property purpose: To define the geographic bounds of a area.

Property value type: FLOAT

Property parameter: Non-standard parameters can be
 specified on this property.

Conformance: VTIMEZONE plus other components that can use GEO.

Description: GEO_BOUNDS is a list of latitude and longitude
 points (geovalue) that describe a bounding polygon for a
 geographic area. It must consist if at least three points.
 The polygon is closed by a line between the last and first point.
 
 Each point is a geovalue.

Format definition:
  
  geo_bounds   =  "GEO_BOUNDS" bounds-param ":" latlon-sets

  bounds-param = *( ";" xparam )

  latlon-sets  =  geovalue *( "," latlon-sets )

  geovalue     = ; As defined in RFC2445

  xparam       = ; As defined in RFC2445

  float        = ; As defined in RFC2445

Examples:

  GEO_BOUNDS:21.17;157.51,21.18;157.50,21.18;157.11

---

From: Eric Busboom <[email-masked]>
Date: Sun, 20 Aug 2000 17:42:51 -0700 (PDT)

> Property purpose: To define the geographic bounds of a area.

What is the motivation for this registration? Can you give a scenario
where it is required? I can't think of any case where this information
must be in machine readable form?

---

From: Doug Royer <[email-masked]>
Date: Sun, 20 Aug 2000 18:51:16 -0700

> must be in machine readable form?

One of the other things I am working on is time zones.
For a global registry, given you have your location, or
some location. Now you can find your time zone or the
time zone of a location. It is not a required property
for any component.

-Doug

---

From: Rives McDow <[email-masked]>
Date: Thu, 03 Aug 2000 23:00:02 -0700

Dear Doug,

    It has been a while since we corresponded, and when I saw this exchange,
I thought it would be good for us to communicate again.

    Have you thought about the implementation you brought up in the email
below?  I am interested to know if you are planning on developing this
yourself.  I feel pretty certain that I can supply this at a cost below what
you will be able to develop it for, and with several advantages.

    Last week the man who is responsible for Appendix F from IATA came to
meet with me here.  We looked over the requirements of the aviation
industry, and have come up with a plan to implement the methodology used in
GTS to track and publish the time changes for the industry, expanding the
current list based system to a true GIS.  I am in contact with the people at
ICAO and the Reed Travel Group, and am planning a meeting with them later
this year in London.  Our aim is to get everyone on the same page, and with
accurate information.

    You and I had discussed this earlier this year, before one of the IETF
conferences, I believe in Australia.  I didn't hear from you after the
conference, and didn't know that you still have a geo-referenced method in
mind until the email below.  If you want to pursue this yourself so that you
have your own solution, I don't see any difficulty with that, however, I
think that it would make a lot of sense to coordinate our efforts.  I am in
the process of getting all the time zone data from the initiation of time
zones in the 1800's until present in a geo-coordinated database.  This is a
pretty big undertaking, and I don't think that it will be that practical to
implement in the embedded systems that are my primary interest.   However,
it may be something that would interest people using past historical data of
the Olsen archive.  I can't quite follow why the historical data is so
important to anyone but astrologers and insurance adjusters, but I guess
that there is a reason.  Is your interest in historical or current time
zones?  

    Let me know if you are interested in working together to coordinate our
efforts, and how that would best be done.

Sincerely,

Rives McDow

> From: Doug Royer <[email-masked]>
> Reply-To: [email-masked]
> Date: Sun, 20 Aug 2000 18:51:16 -0700
> To: [email-masked]
> Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS
> 
> Eric Busboom wrote:
>>

---

From: Doug Royer <[email-masked]>
Date: Mon, 21 Aug 2000 07:44:03 -0700

Rives McDow wrote:
> yourself.  I feel pretty certain that I can supply this at a cost
> below what you will be able to develop it for, and with several
> advantages.

I have no plans to fill in the data. I am just proposing
a standard way for applications to express the data.

-Doug

---

From: John Stracke <[email-masked]>
Date: Mon, 21 Aug 2000 10:58:21 -0400

Doug Royer wrote:

> time zone of a location.

Most of the time, yes.  Are there any weird cases out there, with
overlapping time zones? For example, a country where some religious
minority doesn't observe DST; then which time zone you want will depend on
the user's religion.

Or suppose you're at sea, on a course that takes you in and out of
international waters.  In international waters, there won't be any
authority issuing time zone rules; in national waters, there will be, but
you won't really care; you'll want to keep a consistent clock (particularly
if you're going more or less north-south).  So what time zone you follow
will probably be up to the captain of the ship.  (Extra Bonus
Complication: consider nations such as Libya, which claim sovereignty out
to 100 miles, even though nobody listens.  The borders reported by your
timezone registry may have to be localized depending on what nation the
user is in.)

I suppose those can be handled by returning multiple values, though, and
letting the user pick.  We just need to make sure that nobody builds a
VEVENT which contains a LOCATION but no TZID, and expects the recipient to
look it up by location.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Te audire no possum. Musa sapientum fixa est in|
[email-masked]|aure.                                          |
\================================================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 21 Aug 2000 09:15:11 -0700

John Stracke wrote:
> overlapping time zones? For example, a country where some
> religious minority doesn't observe DST; then which time zone you
> want will depend on the user's religion.

Correct time zones can overlap. If you get > 1, choose.

> authority issuing time zone rules; in national waters, there will
> be, but you won't really care; you'll want to keep a consistent
> clock (particularly if you're going more or less north-south).
> So what time zone you follow will probably be up to the captain
> of the ship.  (Extra Bonus Complication: consider nations such as
> Libya, which claim sovereignty out to 100 miles, even though nobody
> listens.  The borders reported by your timezone registry may have
> to be localized depending on what nation the user is in.)

I have not made an assertion that everyplace on earth
has a time zone. I have no idea if it is true or false.

> I suppose those can be handled by returning multiple values,
> though, and letting the user pick.  We just need to make sure
> that nobody builds a VEVENT which contains a LOCATION but no TZID,
> and expects the recipient to look it up by location.

Correct - I have not proposed anything of the kind.

I assume you meant GEO and not LOCATION, as LOCATION is TEXT.
The rules for when to use TZID will not change.

I do expect in the future that when someone builds a VEVENT
they will be able to pick a TZID given the GEO before
sending out the VEVENT.

-Doug

---

From: John Stracke <[email-masked]>
Date: Mon, 21 Aug 2000 17:54:23 -0400

> Correct time zones can overlap. If you get > 1, choose.

[...]

> has a time zone. I have no idea if it is true or false.

Looking back, I think I read it into "Now you can find your time zone or
the time zone of a location."--but that wasn't part of the actual
registration.

> I assume you meant GEO and not LOCATION, as LOCATION is TEXT.

Yes, sorry.

> The rules for when to use TZID will not change.

Right; I didn't see any text that would change TZID--but it could be
thought to be a logical next step; I just wanted to forestall it.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |Dave Barry for President! He'll Keep Dan Quayle.|
[email-masked]|(OK, it's old)                                  |
\=================================================================/

---

From: "JR" <[email-masked]>
Date: Tue, 22 Aug 2000 11:36:59 -0700

I don't have a strong opinion about your idea of a GEO_BOUNDS format, but
it's
not clear whether all the factors have been carefully considered.  I would
suggest the following as necessary points of discussion:

A. When you say "as defined in RFC2445", I presume you mean that the
   values are to be interpreted as decimal degrees, as described for
   the GEO property of iCalendar?  I would strongly recommend making
   this more clear, perhaps by saying something more like "decimal
   degrees, as defined in RFC2445".

B. I trust that everyone is aware that the LAT/LON coordinates of  RFC2445
   are NOT cartesian (i.e. not strictly rectangular), but refer to a points
on a
   sphere.  So a simple rectangular "point in polygon" algorithm would be
   inadequate for comparing a location to a timezone polygon.  Not a huge
   problem, but it typically requires some GIS-type capabilities to
calculate.

C. There are also plenty of accuracy issues unless the provided polygon
   includes a huge number of LAT/LON coordinates.  It typically takes at
least
   several hundred coordinates to define a single geographic region with any
   reasonable accuracy.  If you reduce the provided number, the overall
   accuracy of comparisons goes down accordingly.

D. How do you define regions that are made up of multiple distinct polygons?
   Given the political fragmentation of our fine planet, there are likely
time zones
   with holes in the middle, or broken into several distinct pieces.  (GIS
folks
   refer to these as lakes and islands.)  It doesn't look to me like the
current
   proposal has any way of addressing this issue.

I don't have the bandwidth to track closely with all this discussion, but I
would
strongly recommend that you work with some experienced GIS folks to better
understand all the issues.  Just be sure you know what can of worms you are
opening up...

Hope this helps,
- JR

---

From: Doug Royer <[email-masked]>
Date: Tue, 22 Aug 2000 11:58:39 -0700

JR wrote:
> 
> I don't have a strong opinion about your idea of a GEO_BOUNDS 
> format, but it's not clear whether all the factors have been
> carefully considered. 

Delighted to get input!

> I would suggest the following as necessary
> points of discussion:
> 

Yep - I'll do that.

> B. I trust that everyone is aware that the LAT/LON coordinates of
> RFC2445 are NOT cartesian (i.e. not strictly rectangular), but refer
> to a points on a sphere.  So a simple rectangular "point in polygon"
> algorithm would be inadequate for comparing a location to a timezone
> polygon.  Not a huge  problem, but it typically requires some GIS-type
> capabilities to calculate.

Yea I knew that. I was not sure how to say that.
I had not proposed (at this time) any solution to that problem. When
this gets worked out, I plan on sending out a draft that describes
how GEO_BOUNDRY should be used by a CS and a CUA to find a VTIMEZONE.

>    includes a huge number of LAT/LON coordinates.  It typically takes
>    at least several hundred coordinates to define a single geographic
>    region with any reasonable accuracy.  If you reduce the provided 
>    number, the overall accuracy of comparisons goes down accordingly.

Yes.

A CUA does not need to download the GEO_BOUNDRY in order to
QUERY for a valid VTIMEZONE. So not all CUAs will need to keep
the data.

> D. How do you define regions that are made up of multiple distinct

Multiple GEO_BOUNDRY entries in the VTIMEZONE. I'll add that.

>  time zones with holes in the middle, or broken into several distinct
> pieces.  (GIS folks refer to these as lakes and islands.)  It doesn't
> look to me like the current  proposal has any way of addressing this
> issue.

I had not thought of the hole in the middle problem.

Would something like "GEO_BOUNDRY_EXCEPTION: <sets-of-points>" do?
It would describe holes.

> I don't have the bandwidth to track closely with all this discussion,
> but I would strongly recommend that you work with some experienced GIS
> folks to better understand all the issues.  Just be sure you know
> what can of worms you are opening up...

As to working with the experienced GIS folks - any volunteers?

-Doug