Copy / pasting polygons - Mapinfo seems to create (tiny) errors

[Rob]

Have found Mapinfo behaving rather oddly, maybe someone can help! The
following problem has been observed by a number of colleagues with
different versions of Mapinfo, so not just me (V.9.5 & V10).

Start with a "clean sheet": create a new table, open a map window.
Create a simple polygon.

Then create a second (empty) table. Copy the polygon from the first
table, past it into the second. (This also works in the cosmetic layer
if you want to save a few seconds).

Now adjust the display settings of the two polygons - which appear to
occupy the same space - so that they're both transparent, with
different colour outline lines, and zoom in on one of the vertices. I
mean really zoom in, closer and closer and closer... do you see what I
see? The copied / pasted polygon is not quite in the right place!

I know: the discrepancy is ~0.02mm or something apparently trivial.
But we've been having data standards problems because of this - a
government agency. insists that we return data "snapped" to their data
(in turn, to ensure consistency with other gov. departments), and
because of this it's being rejected!

We're now negotiating for some tolerances to be allowed - but in the
meantime can anyone please:

(a) explain why this is happening, and

(b) suggest a solution (preferably one that doesn't involve any more
lengthy meetings about the importance of microscopic data accuracy!)

Any suggestions greatly appreciated, cheers,

Rob.

[Luka]

when you copy it across it could truncate the coordinates of the nodes
try build a polygon on which has node coordinates with only 1 or 2 numbers in the decimals

my other thought was it could be the size of the window indexing grid but you said you opened two fresh screens so i doubt that. (might be worth looking at, check the bounds of each table, if they are slightly out you will have nodes which snap to slightly different places)

Luke Bassett
GIS officer
Darebin City Council

--

You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To post to this group, send email to mapi...@googlegroups.com.
To unsubscribe from this group, send email to mapinfo-l+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mapinfo-l?hl=en.

--
Luke Bassett
Melbourne Australia

[Peter Horsbøll Møller]

Rob,

 

Do the two tables have completely identical coordinate systems - also when you look at the bounds?

If not that could be the cause of the problem.

You can use the Table Bounds tool to check the bounds of the two tables.

 

Peter Horsbøll Møller
Pitney Bowes Business Insight - MapInfo

 

2009/12/2 Rob <robj...@googlemail.com>

[Rob]

Luke,
Thanks for that. I've looked into the "bounds" possibility before &
don't think that's it, but your first suggestion is interesting,
looking at the nature of the displacement it seems to ring true. I'll
have to figure out how to restrict the no. of d.p's in co-ordinates;
will post back here if it works.

thanks,
Rob.

> > mapinfo-l+...@googlegroups.com<mapinfo-l%2Bunsubscribe@googlegroups .com>
> > .

[David R Sherrod]

To add to Peter and Luka's comments . . .
I vaguely remember a thread long ago (DataDirections hosting days) about the wisdom of using the cosmetic layer when precision is desired.  The concept of identical coordinate systems was part of the crux.  Ever since then, I've always created a separate table (in same coordinate system as the desired table) for purposes of copying and pasting, cutting holes, stuff like that.

I don't know if my method is overkill.  It was merely a habit I adopted after that discussion, in order to remove possible sources of error.  Perhaps my restating it here (or misrepresenting it, as the case may be) may bring further clarification on that matter, too.

Dave Sherrod
-----------------------------------------

From:	Peter Horsbøll Møller <mapi...@horsboll-moller.dk>
To:	mapi...@googlegroups.com
Date:	12/02/2009 01:08 PM
Subject:	Re: [MI-L] Copy / pasting polygons - Mapinfo seems to create (tiny)         errors
Sent by:	p.horsbo...@gmail.com

---

--

You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To post to this group, send email to mapi...@googlegroups.com.

To unsubscribe from this group, send email to mapinfo-l+...@googlegroups.com.

For more options, visit this group at

http://groups.google.com/group/mapinfo-l?hl=en.

[Bo Victor Thomsen]

Rob -

If I was you, I would take a look at the "bounds" problem again.

When MapInfo stores geographic coordinates it will be as integer value pairs. It means that your  (float value based) position will be converted to 4-byte integers, where values can be anything from 0,0 to 2**32, 2**32. The bounds clause determines the conversion factor between the original values for the x,y position and the corresponding integer values.

Normally this distortion doesn't matter, but the default bounds for some of the projections (ex. long/lat proj.) are  -360 degrees to +360 degrees (twice around the globe). Data in this kind of projection  are converted to  integers between 0 and 2**32.  The distortion can then be as large as  1.86 cm (80000  km / 2**32).

AFAIK the cosmetic layer are using a longitude/latitude projection where the bounds clause probably is -360 to 360 degrees for x and -90 to 90 degrees for y

I would suggest to retry your experiment using two tables using the  _same_ projection and _same_  (sane) bounds clause , and see if the error reappears.

You can define bounds clauses with a tool found in the toolmanager.

Regards
Bo Thomsen
Aestas SMBA
Denmark


Rob skrev:

.
To unsubscribe from this group, send email to mapinfo-l+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mapinfo-l?hl=en.



  

[Sue Beetlestone]

Hello Rob

This is a well known phenomenon - we are suffering from it too!

It's the 'MapInfo Cell' issue.

MapInfo relates its data to a grid of cells and the size of these is, I believe, related to the bounding rectangle of the layer and/or the projection. (Others more expert than I am will doubtless know)

My understanding is that MapInfo snaps copied nodes to the corner of the cell and that's how our problem arises.

We share data with the Forestry Commission (who are ESRI users) and we have had lengthy exchanges about the wisdom of allowing some tolerance in the positional accuracy of the data - especially as we are usually talking about a few centimetres at most.

I'd welcome any comments anyone else may have on this subject too.

Sue

Susan D Beetlestone
Uwch Swyddog GIS Corfforaethol ac ALO/Senior Corporate GIS Officer & ALO
O & R BPU IT Systems Support
Cyngor Sir Powys/Powys County Council
Neuadd y Sir/County Hall
Spa Rd East
Llandrindod Wells
Powys
LD1 5LG
Telephone 01597 82 6938
e-mail sus...@powys.gov.uk

--

You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To post to this group, send email to mapi...@googlegroups.com.
To unsubscribe from this group, send email to mapinfo-l+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mapinfo-l?hl=en.

-----------------------------------------
Cyngor Sir Powys County Council
www.powys.gov.uk

Mae'r e bost hwn ac unrhyw atodiad iddo yn gyfrinachol ac fe'i
bwriedir ar gyfer y sawl a enwir arno yn unig. Gall gynnwys
gwybodaeth freintiedig. Os yw wedi eich cyrraedd trwy gamgymeriad
ni ellwch ei gopio, ei ddosbarthu na'i ddangos i unrhyw un arall a
dylech gysylltu gyda Cyngor Sir Powys ar unwaith.

Mae unrhyw gynnwys nad yw'n ymwneud gyda busnes swyddogol Cyngor
Sir Powys yn bersonol i'r awdur ac nid yw'n awdurdodedig gan y
Cyngor.

This e mail and any attachments are confidential and intended for
the named recipient only. The content may contain privileged
information. If it has reached you by mistake, you should not copy,
distribute or show the content to anyone but should contact Powys
County Council at once.

Any content that is not pertinent to Powys County Council business
is personal to the author, and is not necessarily the view of the
Council.

[CDR Group]

It may help all of us to read (or re-read) this helpful article: http://www.mapsbydesign.co.uk/pdfs/boundsclause.pdf

 

As I understand it (and I may well be wrong!) MapInfo's bounds statement defines the rectangle which is the geographical limit of your MapInfo table.  i.e. you cannot draw anything outside of the bounds.  This rectangle may be a representation of the whole world or it may be a much smaller area.  The MapInfo default in Europe is a rectangle covering the whole of Europe.

 

Internally within MapInfo co-ordinates are held as a pair of numbers which you can think of as ranging from 0 to 2,000 million.  The smallest possible separation between two nodes involves a change of 1 in either of these numbers.  So if your bounds covered a rectangle that was 2,000 million metres by 2,000 million metres then two nodes that were not coincident would have to be at least 1 metre apart.  You could not draw a node that was only half a metre away from another node - MapInfo could only place it either on the other node or 1 metre away.

 

Problems arise when data is copied from one table to another if the two tables have different bounds, particularly if the target table has larger bounds than the source table.  The larger bounds mean that the target table is effectively storing co-ordinates with less real-world precision.

 

If you need data to snap accurately to features in another table you must use exactly the same bounds in both tables.

 

Tony Witham

Director

CDR Group
www.cdrgroup.co.uk
www.puredotnet.co.uk
Tel: 01433 621282
Fax: 01433 621292
Specialists in Geographic Information Systems

CDR Group is the trading name of Contract Data Research Ltd.
Registered address Eccles House, Eccles Lane, Hope, Hope Valley, S33 6RW.
Registration No. 1972376
VAT No. GB373 3117 67

----- Original Message -----

From: Rob

To: MapInfo-L

Sent: Wednesday, December 02, 2009 7:40 PM

Subject: [MI-L] Copy / pasting polygons - Mapinfo seems to create (tiny) errors

[Luka]

But when you open up 2 fresh tables do they have different bounds?

[Spencer Simpson]

I'm guessing the problem comes from using the Windows Clipboard to do the copying.   

 

Some experiments to perform:

 

1. With the Map window you're using having the focus, open the MapBasic window (Options->Show MapBasic window) and type

 

Print TableInfo (<srctab>, 29)

Print TableInfo (<desttab>, 29)

Print MapperInfo (FrontWindow(), 17)

 

Where <srctab> and <desttab> are the names of your source and destination tables.  This will print the actual coordinate system clauses of the two tables and the Map window to the Message window, including any bounds clauses.

 

You can use 25, 26, 27, and 28 as the second parameter to TableInfo to get the actual limits of the two tables' coordinate systems.

 

If the tables' coordinate systems and bounds are identical, the problem absolutely has to arise from MapInfo's interaction with the Clipboard.

 

Experiment 2 should present a solution.  3 and 4 will just help give us information as to what's Really Going On.

 

 

2. Select the source objects, then use Table->Append rows to table... to append the Selection table to the destination table.   To copy just the objects and not the attributes, type

 

Insert into <desttab> (obj) select obj from selection

 

in the MapBasic window.

 

 

3. Use Copy/Paste to copy a sample object from the source table back into the source table.  Is the duplicate misaligned?

 

4. Open the source table and the destination table in two Browser windows and close all Map windows.   Select a row in the origin table's browser and use Edit->Copy to copy to the clipboard. Select the destination table's browser and Edit->Paste from the clipboard.  Then create a Map window from the two tables and see if the misalignment persists.

 

If experiment #2 prevents the misalignments from creeping in, then use it for all object copying.

 

HTH

---

Spencer

---

[Spencer Simpson]

I take this back.   Rob's problem has to be bounds-related.  I used the Clipboard to copy data from a table with a nice tight bounds clause and paste into another table saved from a selection from that table (meaning it had exactly the same coordinate system) and the pasted objects' alignments were PERFECT.

 

However, pasting the same objects into the Cosmetic layer produced misalignments.  You should expect this, because a Map window's coordinate system is always unbounded.

 

So:

 

- Do experiment 1 as described below.

- make sure the tables use EXACTLY the same projection parameters and bounds, and match the customer's specified projection and coordinate precision.  

- make sure you're not using the cosmetic layer

- Other data conversion processes (e.g. converting to shapefile) may introduce their own misalignments.

 

PS

 

If the customer is specifying exacting tolerances like this, they need to have a good handle on their own coordinate system standards. That is, they must set a specific projection with a specific precision and the precision has to be reasonable for the projection and study area. If they and the agencies they want to be compatible with don't have compatible standards, there's no way of avoiding misalignments.  It's like demanding that 2+2=5.

 

---

Spencer

---

[Eric Blasenheim]

I have been watching this thread and while I cannot supply an answer
without seeing the tables in question, as just about everyone else has
said, and as the most logical answer is the bounds clause, I am struck
by this comment from Rob (the originator).

Rob's initial post said :the discrepancy is ~0.02mm ! The only way to
get to that kind of accuracy is with some pretty tight bounds which
means you are not likely to have done this from the User Interface.
Most likely a non-earth table or something done via MapBasic, none of
which Rob mentioned. For a world map that precision is about 5000
times above normal full world precision.

So without a bounds clause, rendering at that level would be quite
bogus.
Eric Blasenheim
PBBI (MapInfo)

> Spencer
>
>   _____  

>
> From: Spencer Simpson [mailto:ssimp...@baltometro.org]
> Sent: Thursday, December 03, 2009 10:06 AM
> To: mapi...@googlegroups.com
> Subject: RE: [MI-L] Copy / pasting polygons - Mapinfo seems to create (tiny)
> errors
>
> I'm guessing the problem comes from using the Windows Clipboard to do the
> copying.  
>
> Some experiments to perform:
>

> 1.      With the Map window you're using having the focus, open the MapBasic

> window (Options->Show MapBasic window) and type
>
> Print TableInfo (<srctab>, 29)
>
> Print TableInfo (<desttab>, 29)
>
> Print MapperInfo (FrontWindow(), 17)
>
> Where <srctab> and <desttab> are the names of your source and destination
> tables.  This will print the actual coordinate system clauses of the two
> tables and the Map window to the Message window, including any bounds
> clauses.
>
> You can use 25, 26, 27, and 28 as the second parameter to TableInfo to get
> the actual limits of the two tables' coordinate systems.
>
> If the tables' coordinate systems and bounds are identical, the problem
> absolutely has to arise from MapInfo's interaction with the Clipboard.
>
> Experiment 2 should present a solution.  3 and 4 will just help give us
> information as to what's Really Going On.
>

> 2.      Select the source objects, then use Table->Append rows to table...

> to append the Selection table to the destination table.   To copy just the
> objects and not the attributes, type
>
> Insert into <desttab> (obj) select obj from selection
>
> in the MapBasic window.
>

> 3.      Use Copy/Paste to copy a sample object from the source table back

> into the source table.  Is the duplicate misaligned?
>

> 4.      Open the source table and the destination table in two Browser

> windows and close all Map windows.   Select a row in the origin table's
> browser and use Edit->Copy to copy to the clipboard. Select the destination
> table's browser and Edit->Paste from the clipboard.  Then create a Map
> window from the two tables and see if the misalignment persists.
>
> If experiment #2 prevents the misalignments from creeping in, then use it
> for all object copying.
>
> HTH
>
>   _____  
>

> Spencer
>
>   _____  

>  <http://www.cdrgroup.co.uk>www.cdrgroup.co.uk
>  <http://www.puredotnet.co.uk>www.puredotnet.co.uk

> Tel: 01433 621282
> Fax: 01433 621292
> Specialists in Geographic Information Systems
>
> CDR Group is the trading name of Contract Data Research Ltd.
> Registered address Eccles House, Eccles Lane, Hope, Hope Valley, S33 6RW.
> Registration No. 1972376
> VAT No. GB373 3117 67
>
>
>
> ----- Original Message -----
>

> From: Rob <mailto:robjma...@googlemail.com>  
>
> To: MapInfo-L <mailto:mapi...@googlegroups.com>  

> For more options, visit this group athttp://groups.google.com/group/mapinfo-l?hl=en.

>
> --
>
> You received this message because you are subscribed to the Google Groups
> "MapInfo-L" group.
> To post to this group, send email to mapi...@googlegroups.com.
> To unsubscribe from this group, send email to
> mapinfo-l+...@googlegroups.com

> <mailto:mapinfo-l%2Bunsu...@googlegroups.com> .
> For more options, visit this group athttp://groups.google.com/group/mapinfo-l?hl=en.

>
> --
> Luke Bassett
> Melbourne Australia
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "MapInfo-L" group.
> To post to this group, send email to mapi...@googlegroups.com.
> To unsubscribe from this group, send email to
> mapinfo-l+...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/mapinfo-l?hl=en.

>
> --
>
> You received this message because you are subscribed to the Google Groups
> "MapInfo-L" group.
> To post to this group, send email to mapi...@googlegroups.com.
> To unsubscribe from this group, send email to
> mapinfo-l+...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/mapinfo-l?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Sue Beetlestone]

Hello Eric

These small inaccuracies are only a problem for many of us when we share data with organisations who use ANOTHER GIS system and don't always seem to be able (or maybe willing!) to set tolerances - they expect to be able to verify the accuracy of our data automatically after they have imported it into their system.

I have no understanding of how the OTHER system works in this respect - however, despite not being a very technical person, I am finding the whole problem not only frustrating but also fascinating.

Thank you for shedding more light on it.

Regards

Sue


Susan D Beetlestone
Uwch Swyddog GIS Corfforaethol ac ALO/Senior Corporate GIS Officer & ALO
O & R BPU IT Systems Support
Cyngor Sir Powys/Powys County Council
Neuadd y Sir/County Hall
Spa Rd East
Llandrindod Wells
Powys
LD1 5LG
Telephone 01597 82 6938
e-mail sus...@powys.gov.uk

-----Original Message-----