bonjourno!
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: 24 August 2006 02:12
To: [email protected]
Subject: MapInfo-L Digest, Vol 10, Issue 70
Send MapInfo-L mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MapInfo-L digest..."
Today's Topics:
1. Re: SUMMARY: MI 8.5 Copy/Paste issue (Richard Greenwood)
2. Re: area calculation discrepancies (Richard Greenwood)
3. Re: area calculation discrepancies (Bob Young)
4. RE: SUMMARY: MI 8.5 Copy/Paste issue (Bonwick, Vicky)
----------------------------------------------------------------------
Message: 1
Date: Wed, 23 Aug 2006 16:04:54 -0600
From: "Richard Greenwood" <[EMAIL PROTECTED]>
Subject: Re: [MI-L] SUMMARY: MI 8.5 Copy/Paste issue
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Cc: [email protected],
[EMAIL PROTECTED]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Derek,
Thank you for inviting user comment with regard to the new copy/paste
and "Find Select" behavior.
I suggest that "Find Selection" be completely removed from the
copy/paste operation. It has always been terribly annoying when all
open map windows containing the target layer were panned to the pasted
object. The new behavior is even slightly more annoying.
I think the new 8.5 "Find Selection" behavior which zooms to the MBR
is a big step in the right direction. A couple refinements that I
would suggest:
(1) provide a user defineable minimum zoom size when there is no MBR,
or when the MBR is extremely small due to selecting a very small
object(s)
(2) provied a user defieable MBR buffer. e.g. MBR + 15%
Best regards,
Rich
--
Richard Greenwood
[EMAIL PROTECTED]
www.greenwoodmap.com
------------------------------
Message: 2
Date: Wed, 23 Aug 2006 16:23:36 -0600
From: "Richard Greenwood" <[EMAIL PROTECTED]>
Subject: Re: [MI-L] area calculation discrepancies
To: "COLDREY, Cathy (Bristol)" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 8/23/06, COLDREY, Cathy (Bristol) <[EMAIL PROTECTED]> wrote:
>
>
> Hi List,
>
> Does anyone have much experience in calculating areas of polygons or circles
> in MapInfo?
>
> My problem is this. I have a 1 km radius which has exactly a diameter of
> 2km, meaning a 1 km radius. Now mathematically the area of theis would be
> 3136860 square m. But if I use the update column option the number I get is
> 3118630 square m
> or double click on the object I get 3119000 square m.
>
> I am using British national grid projection.
>
> Can anyone explain to me why I get three differing numbers?
A couple guesses:
(1) MapInfo does not give an area when you double click on an ellipse
object, so I maybe you have converted your ellipse to a region, which
is a series of short tangents (usually 100) which will probably be a
bit smaller in area (and shorter in perimeter length) than a true
circle.
(2) Spherical versus Cartesian areas. Which are you using for your two
operation?
Rich
--
Richard Greenwood
[EMAIL PROTECTED]
www.greenwoodmap.com
------------------------------
Message: 3
Date: Wed, 23 Aug 2006 23:41:18 +0100
From: "Bob Young" <[EMAIL PROTECTED]>
Subject: Re: [MI-L] area calculation discrepancies
To: "COLDREY, Cathy \(Bristol\)" <[EMAIL PROTECTED]>,
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Cathy
I hope the following is of some use, although even taking into account these
factors I get another set of numbers none of which match exactly!
The corrrect area mathematically ( PI * R * R ) is 3,141,593 for a non earth
projection ie as a CAD system would compute it.
You can ask MapInfo to compute either the spherical area or the cartesian area.
If you want to get a "mathematical" match with PI * R^2 then you need to use
cartesian. When using update column use CartesianArea function rather than Area
function (which returns spheroid area). ( This does work accurately for
rectangles and polygons).
There are also two ways you could create the circle. The best result should
come form holding down shift key and drawing an ellipse. I say should because
this would be stored internally in MapInfo as a centre point and a radius, and
so should be able to be computed accurately. If you use this method the double
click does NOT return the area, so I suspect you did not use this method.
The alternative method is to use the buffer command, and set the smoothness to
maximum of 100. A snag with this method is that this is not stored as a true
circle but as a threepenny bit ie with 100 flats. The area will therefore not
be correct. This type of object WILL report its area with a double click.
If you have imported the object from some other system this might also account
for why your area is reported with a double click.
With either type of object, using cartesian ( or spherical ) I cannot get an
exact match but I get closer agreement to the correct cartesian value of
3,141,593 with 3,139,567 for a true circle ( shift key method ) and 3,139,526
for buffer of a point method with maximum smoothness ( both got from update
column and CartesianArea function).
A 1 km square returns exactly the correct answer of 1,000,000 providing you
stick with cartesian. You can set the map window to use cartesian using
Options... off the map menu. You can reset the radius etc by double clicking
when the layer containing the object is editable.
Hopefully someone will throw some light on the 0.07% error on the circle.
Regards
Bob
----- Original Message -----
From: COLDREY, Cathy (Bristol)
To: [email protected]
Sent: Wednesday, August 23, 2006 5:34 PM
Subject: [MI-L] area calculation discrepancies
Hi List,
Does anyone have much experience in calculating areas of polygons or circles
in MapInfo?
My problem is this. I have a 1 km radius which has exactly a diameter of
2km, meaning a 1 km radius. Now mathematically the area of theis would be
3136860 square m. But if I use the update column option the number I get is
3118630 square m
or double click on the object I get 3119000 square m.
I am using British national grid projection.
Can anyone explain to me why I get three differing numbers?
And also how will I find the correct areas of several other polygons that are
not circular?
Thanks for any help you can provide to this mystery.
:) cathy
Cathy Coldrey
Geomatics Specialist, Europe
WorleyParsons Komex
Environment & Water Resources
Tel: + 44 (0)117 9105 124
Fax: + 44 (0) 117 9105 139
3-8 Redcliffe Parade West
Bristol BS1 6SP
Registered No. 2718875
www.worleyparsons.com
Please note: effective immediately my new e-mail address is
[EMAIL PROTECTED]
*** WORLEYPARSONS GROUP NOTICE *** PRIVILEGED AND CONFIDENTIAL ***
"This email is confidential. If you are not the intended recipient, you must
not disclose or use the information contained in it. If you have received this
email in error, please notify us immediately by return email and delete the
email and any attachments. Any personal views/opinions expressed by the writer
may not necessarily reflect the views/opinions of the company."
Thank you.
------------------------------------------------------------------------------
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.directionsmag.com/pipermail/mapinfo-l/attachments/20060823/542226d8/attachment-0001.htm
------------------------------
Message: 4
Date: Thu, 24 Aug 2006 10:52:47 +1000
From: "Bonwick, Vicky" <[EMAIL PROTECTED]>
Subject: RE: [MI-L] SUMMARY: MI 8.5 Copy/Paste issue
To: <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
I think Spencers proposed suggestion of using a toggle button similar to 'S'
for Snap in the Status bar is a very good idea. It is something that may often
need to be changed during a session.
1) A button in the status bar could have two options attached similar the
"Zoom/Map Scale/Cursor Location" button. The default option would be "Pan to
selection", the second option "Pan/Zoom to selection"
2) Copy/Paste needs no extra functions - the user applies "Find Selection" or
Ctrl A if desired which would pick up on the option chosen above.
An added advantage of this is that at a glance you know how MapInfo will react.
If it's hidden away in preferences we'd have to accept that we'd never change
it once set or have to have a very good memory of how we last left it!
I agree the same method would also be great applied to the "move duplicate
nodes" option currently hidden away. If there's not enough room in the status
bar I'd rather see the "Find selection: " options first though.
Regards
Vicky
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED]
Sent: Thursday, 24 August 2006 6:05 AM
To: [email protected]; [EMAIL PROTECTED]
Subject: Re: [MI-L] SUMMARY: MI 8.5 Copy/Paste issue
The following message was sent to me in response to my question. Since the
proposed solution differs from most of what has been discussed here, I though I
would post it to see what others think. Other than this suggestion, what looks
to be useful for many people would be one preference to either perform or not
perform a Find Selection during a paste, and a second preference to perform a
pan and zoom, or only a pan during a Find Selection. Please keep the comments
coming.
Derek:
MapInfo should not make pan/zoom behavior on paste a "preference" as such,
but a global setting accessible by a command button and/or an accelerator
key, similar to "S" for SNAP.
This behavior is one that people will need to change frequently during an
editing session. On occasion, they will need to change it between the copy
and the paste. Sometimes, a MapBasic app will need to change this behavior.
Preferences are difficult to change through the UI and impossible to change
programmatically. This is a Good Thing for most preferences, but
infuriating for the ones which need to change frequently.
An existing preference that suffers from the same problem is the "move
duplicate nodes" preference. I've been begging for that one to change for
years. You will have my eternal gratitude if you can get someone to make
that a global setting rather than a "preference" (which could possibly be
some sort of default value).
Hope this helps
Spencer
Mail List:mapinfo-l-bounces
From: [EMAIL PROTECTED] on 08/22/2006 05:04 PM AST
To: [EMAIL PROTECTED], [email protected]
cc: [EMAIL PROTECTED], [email protected]
Subject: Link
<Notes:///85256450006CF974/12DCCE0BD0474519852564370063F39D/540E26620E7A5B6C8525713100670D39>
Re: [MI-L] SUMMARY: MI 8.5 Copy/Paste issue
As many of you have discovered, there is a change in the way Find Selection is
done in MI Pro 8.5. Some of you have also discovered that Copy/Paste has done
a Find Selection for many versions, and this functionality has picked up the
change made to Find Selection.
The change itself relates to how we treated single objects. In the case of
single object selections and Find Selection, previous to MI Pro 8.5, we
performed a pan operation but not a zoom. It is unclear why it had been done
this way. One thing we do know is that there is no spatial reference to
provide a zoom for a single point object. The fact that find selection did not
work for single objects became a bug in MI Pro 8.5, and was "fixed". Instead
of the single object check, now there is a check to see if the MBR of the
selection is not empty. So, we will pan for point objects or certain other
cases, such as a selection containing multiple coincident points. For all
other cases, we will pan and zoom. I think this fix is valid, since it makes
the Find Selection command more consistent.
But, we understand your pain and we would like to do something to address this
issue. What we are leaning towards is a preference, or perhaps a few
preferences. Concerning how this would look, we would like your feedback.
Here are some options, but please feel free to provide others:
Should we provide a preference to not perform a Find Selection during the
copy/paste operation?
Should we provide a preference to not perform a Zoom, but still perform the Pan
operation of the Find Selection during the copy/paste operation?
Should we provide separate preferences for Zoom and Pan (although we would not
do a Zoom without doing a Pan) for copy/paste? This would provide more complete
control, but also increases the complexity of the preferences dialog and the
accompanying documentation. While the added control may be nice, if it isn't
necessary is it just getting in the way, and not keeping it simple?
Particularly if we have just a "don't zoom" preference, should Find Selection
obey this preference? Should Find Selection have its own preference? Or should
the Query > Find Selection always do a pan and zoom?
One other point. We have a policy in maintenance patch releases of not doing
any UI changes. This relates to localizing MI Pro for different languages -
basically, we don't localize maintenance releases. So, our patches will upgrade
any version of MI Pro, regardless of language. So, we can't add preferences as
such in a maintenance release. To get around this obstacle and make it so you
don't have to wait until the next full release to get this addressed, we can
get these new preferences out of the registry. You add a new specific registry
key, and we will treat it as a preference. The actual UI will be changed
during the next full release of the product. We have used similar schemes in
past development cycles.
Thanks for your input. To help generate discussion, you can reply to
MapInfo-L, as I will monitor the list.
Derek Snyder
MapInfo Corporation _______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
______________________________________________________________________
This communication and any files transmitted with it are intended for the named
addressee, are confidential in nature and may contain legally privileged
information. The copying or distribution of this communication or any
information it contains, by anyone other than the addressee or the person
responsible for delivering this communication to the intended addressee, is
prohibited. If you receive this communication in error, please advise us by
reply email or telephone on +61 3 6216 6700, then delete the communication. You
will be reimbursed for reasonable costs incurred in notifying us.
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.directionsmag.com/pipermail/mapinfo-l/attachments/20060824/c6a8ae87/attachment.htm
------------------------------
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
End of MapInfo-L Digest, Vol 10, Issue 70
*****************************************
***********************************************************************************
This email and any attachments are intended for the named recipient only. Its
unauthorised use, distribution, disclosure, storage or copying is not
permitted. If you have received it in error, please destroy all copies and
notify the sender. In messages of a non-business nature, the views and
opinions expressed are the author's own and do not necessarily reflect those of
the organisation from which it is sent. All emails may be subject to
monitoring.
***********************************************************************************
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
