Once again, guys...it is a present tense hypothetical. The sign is WHERE
YOU ARE, the distances on the sign have NO meaning.
John Haynes
Director
Geodata Consultants, Inc.
1-800-838-6661
www.geodataconsult.com
----- Original Message -----
From: "Warren Vick, Europa Technologies Ltd." <[EMAIL PROTECTED]>
To: "Bill Thoen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, April 24, 2001 1:27 PM
Subject: RE: MI-L A Mapping Puzzle for Savants
> Hello Bill et al,
>
> Having a good world map product at my disposal, I tried true radii around
> the city centroids and found that there seemed to be no place where they
all
> intersect. Although a quick glance of the first two locations suggests
> somewhere in North America, some of the distances do not reach (even if
you
> go via 180 degrees). From a scientific point of view, I would next explore
> the notion that the point is not on the Earth's surface. i.e. it is below
> the surface or up in space. I cannot think of non-brute force method to
> calculate the puzzle if it is what it seems.
>
> I noted that the distances given increment is more-or-less similar amounts
> and wonder if this is a clue. Perhaps it is a word puzzle (rather than a
> "world" one) and the names, increments or order are clues.
>
> You're right about MapInfo buffers... it one of the things I really hate
> about Pro. I first found this problem several years/releases ago when
> calculating ETOPs circles - the range an aircraft can fly when an engine
> fails. Although the distance tool uses a great circle calculation, buffers
> do not use true 3D geometry and I have seen huge errors on many occasions.
> The problem is very serious because users do have faith in MapInfo's
> output - after all, it is a "Professional" product and has the maturity of
> many releases. The problem has also cost me dearly... specifically a five
> figure dollar sum where one of my clients gave erroneous figures to the
> financial market community and I spent a long time unpaid clearing up the
> mess. That one bug cost me more money than I have ever made reselling
> MapInfo software (fortunately not from data too). I recall that a -L'er
once
> reported that they had to go to court to explain that a construction(?)
> error was down to spherical rather than Cartesian area calculations. A
> misunderstanding of coordinate systems is one thing but this is even worse
> because it explicitly says "Spherical Buffer"... and that it is not.
>
> The problem seems to root from Pro using a single sample point to convert
> the required distance to a unit in degrees. While this may be fine for
> latitude units, it's no good for longitude as a unit in this direction
> changes with latitude (diminishing to zero at the poles). The errors can
be
> most seen with "latitude-rich" polygons... try using a polygon for the
> country of Chile in tests. The error is the reason why buffers are always
> circular/oval and do not spread out towards the poles. The lack of support
> for 180 degrees is also a problem... Pro treats -180 and +180 longitude as
> "a world apart".
>
> The solution I used was to develop true 3D geometry for radii and, for
> shortest paths, a proper Great Circle/Arc utility. I took the publicly
> available PROJ4 code (fixed using WGS-84 datum) and made a MapBasic
callable
> DLL out of it. Great circle paths and radii are now no problem. I now make
> large buffers by creating radii around each point in an object and
combining
> the results.
>
> I'll intrigued to know the answer to the problem. I'm sure we will all
kick
> ourselves.
>
> Regards,
> Warren Vick
> Europa Technologies Ltd, U.K.
> http://www.europa-tech.com
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Thoen
> > Sent: 24 April 2001 16:15
> > To: [EMAIL PROTECTED]
> > Subject: Re: MI-L A Mapping Puzzle for Savants
> >
> >
> > Bill Huber wrote:
> > > ... As the problem is phrased, there is no fast, simple
> > procedure to get a practicably accurate answer.
> >
> > You may have put your finger on a clue here. I bet Jacques' observation
> > about units was also a hint. Hendry Flavio is on target too. Stanley Ng
> > also gets a nod for thinking outside the box (but I don't think "right
> > in front of you" is the answer.) I don't believe it's in space, nor at
> > the north pole. I think you can get the answer with simple deduction. I
> > see two clues that eliminate everywhere else but one place.
> >
> > I think the answer Vos Savant is looking for is how you might deduce the
> > location if you didn't have MapInfo (or Arc/Info, etc.) My guess is that
> > "where" may not necessarily be precise. We'll just have to wait until
> > she reveals the answer next Sunday.
> >
> > But I'm surprised that with all the GIS mapping power held by this group
> > that few have tried the obvious: map the cities, and draw circular
> > buffers around them at the specified distances. The precise place is the
> > one place where all the circles intersect. Right? But it doesn't work in
> > MapInfo because the distances are large ...which reveals a subtle
> > "Gotcha" that is lurking in MapInfo and probably most other mapping
> > packages.
> >
> > The "circular" buffers are not what you may think they are when they
> > would cross a pole. They compress, but this is not simple distortion due
> > to map projection. Load in the following table and create points on the
> > Lon/Lat columns with the "projection" set to Lat/Lon WGS 84. Then open
> > just the cities in a map window. Select Paris and create a 4658 mile
> > buffer around it. All the radii you can measure to the south are 4658
> > miles, but to the north they are all short, with due north being the
> > worst.
> >
> > City Lon Lat Distance
> > Paris 2.432778 48.881389 4658
> > Moscow 37.938056 55.764167 5438
> > Tel Aviv 34.480000 32.050000 6681
> > Victoria (Hong Kong) 114.177222 22.274167 7878
> > Sydney 151.028056 -33.889722 8746
> > Johannesburg 28.004167 -26.178889 9092
> >
> > Begs the question, "What's the work-around?" I've also asked MI Tech
> > Support.
> >
> > - Bill Thoen
> > ------------------------------------------------------------
> > GISnet, 1401 Walnut St., Suite C, Boulder, CO 80302
> > tel: 303-786-9961, fax: 303-443-4856
> > mailto:[EMAIL PROTECTED], http://www.ctmap.com/gisnet
> > ------------------------------------------------------------
> >
> >
> >
> > _______________________________________________________________________
> > List hosting provided by Directions Magazine | www.directionsmag.com |
> > To unsubscribe, send e-mail to [EMAIL PROTECTED] and
> > put "unsubscribe MapInfo-L" in the message body.
> >
>
>
>
> _______________________________________________________________________
> List hosting provided by Directions Magazine | www.directionsmag.com |
> To unsubscribe, send e-mail to [EMAIL PROTECTED] and
> put "unsubscribe MapInfo-L" in the message body.
>
>
_______________________________________________________________________
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, send e-mail to [EMAIL PROTECTED] and
put "unsubscribe MapInfo-L" in the message body.
