MapInfo Pro

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------

oRegion is in BNG and MapInfo keeps track of this. At the point where you do the spatial join, MapInfo will notice oRegion and tPoints are different and will perform the needed transformation, before joining.

If you call a function like centroidx(oRegion), the result will come back in lat/long because that is the default coordinate system. If you want to get the BNG coordinates instead, add "set coordsys table tRegions" first.

Consider it like "5 cm + 0.2 meter" = 25 cm or 0.25 meter. Mapinfo magically keeps track of this for you, just with coordinate systems instead of lengths.

------------------------------
Uffe Kousgaard
CEO
ROUTEWARE
Roskilde

Original Message:
Sent: 07-01-2024 12:39
From: Ryan Cook
Subject: What Projection is an object variable?

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------

Thanks Uffe. The inspiration for this question arose from using a spatial query to update a point table with the number of regions a point was within. 

Add Column _tPoints (Num_Regs Integer) From tRegions set to count(*) where contains

A number of points in tPoints sit upon the boundary of the regions, and I am interested in finding these 'boundary points'. The next statement should do this:

Select * From tPoints where Num_Regs > 1 into qBOUNDARY_POINTS

What was confusing me is that I was moving points to snap to region boundaries in order to test the program (which is more extensive than the two lines above), and when I used the boundary select tool I could see these moved points were being selected in the first region, and then the second region (inferring they should be awarded the value "2" and thus end up in the query table qBOUNDARY_POINTS. However, when I ran the program no points were ending up with "2", the query ended up empty and the rest of the program therefore failed.

Checking the projections, tRegions is in BNG and tPoints is in Long/Lat. When I save a copy of tRegions in Long/Lat and run the program, these points DO end up scoring "2" and being selected into qBOUNDARY_POINTS.

My fear is that I work in Long/Lat and frequently populate object variables with regions I use for selection purposes and I am struggling to understand if it will make a difference if the source of these object variables is in BNG. I'm also concerned if my spatial queries (without using object variables) are wrong if I use BNG regions to update/select point tables in Long/Lat. 

Can you elucidate a little on this? Is it right that I will experience three different results if I (a) use the boundary select tool (b) use an object variable and (c) use a table? 

------------------------------
Ryan Cook
ORH LTD

Original Message:
Sent: 07-02-2024 01:56
From: Uffe Kousgaard
Subject: What Projection is an object variable?

oRegion is in BNG and MapInfo keeps track of this. At the point where you do the spatial join, MapInfo will notice oRegion and tPoints are different and will perform the needed transformation, before joining.

If you call a function like centroidx(oRegion), the result will come back in lat/long because that is the default coordinate system. If you want to get the BNG coordinates instead, add "set coordsys table tRegions" first.

Consider it like "5 cm + 0.2 meter" = 25 cm or 0.25 meter. Mapinfo magically keeps track of this for you, just with coordinate systems instead of lengths.

------------------------------
Uffe Kousgaard
CEO
ROUTEWARE
Roskilde

Original Message:
Sent: 07-01-2024 12:39
From: Ryan Cook
Subject: What Projection is an object variable?

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------

Hi Ryan,

Something I always keep in mind when working with projected coordinates is to ensure that the coordinate system of the table I am working with (projected GDA94 or GDA2020 for me, usually) includes a bounds clause.  The accuracy (that is, the number of decimal points) of the coordinate values of the objects within the table is subject to the bounds.  Of course, restricting the bounds does not increase accuracy automatically - you need to ensure accuracy in the first place - but perhaps this is why you are experiencing unexpected results.

You can observe this by zooming in on a node or point, then trying to move this point so that it sits on the boundary.  If your table does not have high-accuracy, you will not be able to make the point stay exactly upon the boundary.  This can also occur if you are snapping - zoom in, and you may find that the snapped points are not exactly snapped - they have a gap between them.

You can check the bounds by using the CoordSys Bounds Manager tool, which comes with MapInfo.

In your case, I would try to make your tRegions table relatively accurate by specifying a bounds that encompasses the area in which you are working. For example, in Victoria, Australia I usually apply bounds that encompass Victoria.

Perhaps there is more to it than this, but this is the first thing I would check.

Thanks Uffe. The inspiration for this question arose from using a spatial query to update a point table with the number of regions a point was within. 

Add Column _tPoints (Num_Regs Integer) From tRegions set to count(*) where contains

A number of points in tPoints sit upon the boundary of the regions, and I am interested in finding these 'boundary points'. The next statement should do this:

Select * From tPoints where Num_Regs > 1 into qBOUNDARY_POINTS

What was confusing me is that I was moving points to snap to region boundaries in order to test the program (which is more extensive than the two lines above), and when I used the boundary select tool I could see these moved points were being selected in the first region, and then the second region (inferring they should be awarded the value "2" and thus end up in the query table qBOUNDARY_POINTS. However, when I ran the program no points were ending up with "2", the query ended up empty and the rest of the program therefore failed.

Checking the projections, tRegions is in BNG and tPoints is in Long/Lat. When I save a copy of tRegions in Long/Lat and run the program, these points DO end up scoring "2" and being selected into qBOUNDARY_POINTS.

My fear is that I work in Long/Lat and frequently populate object variables with regions I use for selection purposes and I am struggling to understand if it will make a difference if the source of these object variables is in BNG. I'm also concerned if my spatial queries (without using object variables) are wrong if I use BNG regions to update/select point tables in Long/Lat. 

Can you elucidate a little on this? Is it right that I will experience three different results if I (a) use the boundary select tool (b) use an object variable and (c) use a table? 

------------------------------
Ryan Cook
ORH LTD

Original Message:
Sent: 07-02-2024 01:56
From: Uffe Kousgaard
Subject: What Projection is an object variable?

oRegion is in BNG and MapInfo keeps track of this. At the point where you do the spatial join, MapInfo will notice oRegion and tPoints are different and will perform the needed transformation, before joining.

If you call a function like centroidx(oRegion), the result will come back in lat/long because that is the default coordinate system. If you want to get the BNG coordinates instead, add "set coordsys table tRegions" first.

Consider it like "5 cm + 0.2 meter" = 25 cm or 0.25 meter. Mapinfo magically keeps track of this for you, just with coordinate systems instead of lengths.

------------------------------
Uffe Kousgaard
CEO
ROUTEWARE
Roskilde

Original Message:
Sent: 07-01-2024 12:39
From: Ryan Cook
Subject: What Projection is an object variable?

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------

Hmm. Thanks for the info on "bounds", its certainly something I will look into. But in reality I'm just trying to perform simple spatial tasks using a region stored in an object variable. I'm disheartened to learn that if the source table of my object is in a different projection, I will first have to save a copy of that table in Long/Lat before executing any tasks with it. Our network drives will double in size with all the tables I am going to be saving copies of! 

Seems utterly daft that you can't change the projection of an object variable. 

Hi Ryan,

Something I always keep in mind when working with projected coordinates is to ensure that the coordinate system of the table I am working with (projected GDA94 or GDA2020 for me, usually) includes a bounds clause.  The accuracy (that is, the number of decimal points) of the coordinate values of the objects within the table is subject to the bounds.  Of course, restricting the bounds does not increase accuracy automatically - you need to ensure accuracy in the first place - but perhaps this is why you are experiencing unexpected results.

You can observe this by zooming in on a node or point, then trying to move this point so that it sits on the boundary.  If your table does not have high-accuracy, you will not be able to make the point stay exactly upon the boundary.  This can also occur if you are snapping - zoom in, and you may find that the snapped points are not exactly snapped - they have a gap between them.

You can check the bounds by using the CoordSys Bounds Manager tool, which comes with MapInfo.

In your case, I would try to make your tRegions table relatively accurate by specifying a bounds that encompasses the area in which you are working. For example, in Victoria, Australia I usually apply bounds that encompass Victoria.

Perhaps there is more to it than this, but this is the first thing I would check.

Thanks Uffe. The inspiration for this question arose from using a spatial query to update a point table with the number of regions a point was within. 

Add Column _tPoints (Num_Regs Integer) From tRegions set to count(*) where contains

A number of points in tPoints sit upon the boundary of the regions, and I am interested in finding these 'boundary points'. The next statement should do this:

Select * From tPoints where Num_Regs > 1 into qBOUNDARY_POINTS

What was confusing me is that I was moving points to snap to region boundaries in order to test the program (which is more extensive than the two lines above), and when I used the boundary select tool I could see these moved points were being selected in the first region, and then the second region (inferring they should be awarded the value "2" and thus end up in the query table qBOUNDARY_POINTS. However, when I ran the program no points were ending up with "2", the query ended up empty and the rest of the program therefore failed.

Checking the projections, tRegions is in BNG and tPoints is in Long/Lat. When I save a copy of tRegions in Long/Lat and run the program, these points DO end up scoring "2" and being selected into qBOUNDARY_POINTS.

My fear is that I work in Long/Lat and frequently populate object variables with regions I use for selection purposes and I am struggling to understand if it will make a difference if the source of these object variables is in BNG. I'm also concerned if my spatial queries (without using object variables) are wrong if I use BNG regions to update/select point tables in Long/Lat. 

Can you elucidate a little on this? Is it right that I will experience three different results if I (a) use the boundary select tool (b) use an object variable and (c) use a table? 

------------------------------
Ryan Cook
ORH LTD

Original Message:
Sent: 07-02-2024 01:56
From: Uffe Kousgaard
Subject: What Projection is an object variable?

oRegion is in BNG and MapInfo keeps track of this. At the point where you do the spatial join, MapInfo will notice oRegion and tPoints are different and will perform the needed transformation, before joining.

If you call a function like centroidx(oRegion), the result will come back in lat/long because that is the default coordinate system. If you want to get the BNG coordinates instead, add "set coordsys table tRegions" first.

Consider it like "5 cm + 0.2 meter" = 25 cm or 0.25 meter. Mapinfo magically keeps track of this for you, just with coordinate systems instead of lengths.

------------------------------
Uffe Kousgaard
CEO
ROUTEWARE
Roskilde

Original Message:
Sent: 07-01-2024 12:39
From: Ryan Cook
Subject: What Projection is an object variable?

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------

Hmm. Thanks for the info on "bounds", its certainly something I will look into. But in reality I'm just trying to perform simple spatial tasks using a region stored in an object variable. I'm disheartened to learn that if the source table of my object is in a different projection, I will first have to save a copy of that table in Long/Lat before executing any tasks with it. Our network drives will double in size with all the tables I am going to be saving copies of! 

Seems utterly daft that you can't change the projection of an object variable. 

Hi Ryan,

Something I always keep in mind when working with projected coordinates is to ensure that the coordinate system of the table I am working with (projected GDA94 or GDA2020 for me, usually) includes a bounds clause.  The accuracy (that is, the number of decimal points) of the coordinate values of the objects within the table is subject to the bounds.  Of course, restricting the bounds does not increase accuracy automatically - you need to ensure accuracy in the first place - but perhaps this is why you are experiencing unexpected results.

You can observe this by zooming in on a node or point, then trying to move this point so that it sits on the boundary.  If your table does not have high-accuracy, you will not be able to make the point stay exactly upon the boundary.  This can also occur if you are snapping - zoom in, and you may find that the snapped points are not exactly snapped - they have a gap between them.

You can check the bounds by using the CoordSys Bounds Manager tool, which comes with MapInfo.

In your case, I would try to make your tRegions table relatively accurate by specifying a bounds that encompasses the area in which you are working. For example, in Victoria, Australia I usually apply bounds that encompass Victoria.

Perhaps there is more to it than this, but this is the first thing I would check.

Thanks Uffe. The inspiration for this question arose from using a spatial query to update a point table with the number of regions a point was within. 

Add Column _tPoints (Num_Regs Integer) From tRegions set to count(*) where contains

A number of points in tPoints sit upon the boundary of the regions, and I am interested in finding these 'boundary points'. The next statement should do this:

Select * From tPoints where Num_Regs > 1 into qBOUNDARY_POINTS

What was confusing me is that I was moving points to snap to region boundaries in order to test the program (which is more extensive than the two lines above), and when I used the boundary select tool I could see these moved points were being selected in the first region, and then the second region (inferring they should be awarded the value "2" and thus end up in the query table qBOUNDARY_POINTS. However, when I ran the program no points were ending up with "2", the query ended up empty and the rest of the program therefore failed.

Checking the projections, tRegions is in BNG and tPoints is in Long/Lat. When I save a copy of tRegions in Long/Lat and run the program, these points DO end up scoring "2" and being selected into qBOUNDARY_POINTS.

My fear is that I work in Long/Lat and frequently populate object variables with regions I use for selection purposes and I am struggling to understand if it will make a difference if the source of these object variables is in BNG. I'm also concerned if my spatial queries (without using object variables) are wrong if I use BNG regions to update/select point tables in Long/Lat. 

Can you elucidate a little on this? Is it right that I will experience three different results if I (a) use the boundary select tool (b) use an object variable and (c) use a table? 

------------------------------
Ryan Cook
ORH LTD

Original Message:
Sent: 07-02-2024 01:56
From: Uffe Kousgaard
Subject: What Projection is an object variable?

oRegion is in BNG and MapInfo keeps track of this. At the point where you do the spatial join, MapInfo will notice oRegion and tPoints are different and will perform the needed transformation, before joining.

If you call a function like centroidx(oRegion), the result will come back in lat/long because that is the default coordinate system. If you want to get the BNG coordinates instead, add "set coordsys table tRegions" first.

Consider it like "5 cm + 0.2 meter" = 25 cm or 0.25 meter. Mapinfo magically keeps track of this for you, just with coordinate systems instead of lengths.

------------------------------
Uffe Kousgaard
CEO
ROUTEWARE
Roskilde

Original Message:
Sent: 07-01-2024 12:39
From: Ryan Cook
Subject: What Projection is an object variable?

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------

I don't believe that saving to Long/Lat helps.  It might appear that your objects are placed correctly for your comparison, but you can't produce greater accuracy out of thin air.  The nodes of your region may shift, but will not be more accurate.  If your regions table is accurate in the first place then you should achieve better results (but perhaps not perfect, as Uffe mentions).

Hmm. Thanks for the info on "bounds", its certainly something I will look into. But in reality I'm just trying to perform simple spatial tasks using a region stored in an object variable. I'm disheartened to learn that if the source table of my object is in a different projection, I will first have to save a copy of that table in Long/Lat before executing any tasks with it. Our network drives will double in size with all the tables I am going to be saving copies of! 

Seems utterly daft that you can't change the projection of an object variable. 

Hi Ryan,

Something I always keep in mind when working with projected coordinates is to ensure that the coordinate system of the table I am working with (projected GDA94 or GDA2020 for me, usually) includes a bounds clause.  The accuracy (that is, the number of decimal points) of the coordinate values of the objects within the table is subject to the bounds.  Of course, restricting the bounds does not increase accuracy automatically - you need to ensure accuracy in the first place - but perhaps this is why you are experiencing unexpected results.

You can observe this by zooming in on a node or point, then trying to move this point so that it sits on the boundary.  If your table does not have high-accuracy, you will not be able to make the point stay exactly upon the boundary.  This can also occur if you are snapping - zoom in, and you may find that the snapped points are not exactly snapped - they have a gap between them.

You can check the bounds by using the CoordSys Bounds Manager tool, which comes with MapInfo.

In your case, I would try to make your tRegions table relatively accurate by specifying a bounds that encompasses the area in which you are working. For example, in Victoria, Australia I usually apply bounds that encompass Victoria.

Perhaps there is more to it than this, but this is the first thing I would check.

Thanks Uffe. The inspiration for this question arose from using a spatial query to update a point table with the number of regions a point was within. 

Add Column _tPoints (Num_Regs Integer) From tRegions set to count(*) where contains

A number of points in tPoints sit upon the boundary of the regions, and I am interested in finding these 'boundary points'. The next statement should do this:

Select * From tPoints where Num_Regs > 1 into qBOUNDARY_POINTS

What was confusing me is that I was moving points to snap to region boundaries in order to test the program (which is more extensive than the two lines above), and when I used the boundary select tool I could see these moved points were being selected in the first region, and then the second region (inferring they should be awarded the value "2" and thus end up in the query table qBOUNDARY_POINTS. However, when I ran the program no points were ending up with "2", the query ended up empty and the rest of the program therefore failed.

Checking the projections, tRegions is in BNG and tPoints is in Long/Lat. When I save a copy of tRegions in Long/Lat and run the program, these points DO end up scoring "2" and being selected into qBOUNDARY_POINTS.

My fear is that I work in Long/Lat and frequently populate object variables with regions I use for selection purposes and I am struggling to understand if it will make a difference if the source of these object variables is in BNG. I'm also concerned if my spatial queries (without using object variables) are wrong if I use BNG regions to update/select point tables in Long/Lat. 

Can you elucidate a little on this? Is it right that I will experience three different results if I (a) use the boundary select tool (b) use an object variable and (c) use a table? 

------------------------------
Ryan Cook
ORH LTD

Original Message:
Sent: 07-02-2024 01:56
From: Uffe Kousgaard
Subject: What Projection is an object variable?

oRegion is in BNG and MapInfo keeps track of this. At the point where you do the spatial join, MapInfo will notice oRegion and tPoints are different and will perform the needed transformation, before joining.

If you call a function like centroidx(oRegion), the result will come back in lat/long because that is the default coordinate system. If you want to get the BNG coordinates instead, add "set coordsys table tRegions" first.

Consider it like "5 cm + 0.2 meter" = 25 cm or 0.25 meter. Mapinfo magically keeps track of this for you, just with coordinate systems instead of lengths.

------------------------------
Uffe Kousgaard
CEO
ROUTEWARE
Roskilde

Original Message:
Sent: 07-01-2024 12:39
From: Ryan Cook
Subject: What Projection is an object variable?

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------

It's not necessarily "accuracy" I'm after; just consistency. If I'm running a spatial query using objects in a table in order to detect and correct problems for a future operation that uses object variables, it's rather unfortunate that there is no consistency between the two. 

I have just tested it. MapInfo gives different results in these cases; I guess the object is being "transformed" as Uffe says, so it is capturing a different amount of points then when I spatially selected points using a table with the same bloody object in it!

I don't believe that saving to Long/Lat helps.  It might appear that your objects are placed correctly for your comparison, but you can't produce greater accuracy out of thin air.  The nodes of your region may shift, but will not be more accurate.  If your regions table is accurate in the first place then you should achieve better results (but perhaps not perfect, as Uffe mentions).

Hmm. Thanks for the info on "bounds", its certainly something I will look into. But in reality I'm just trying to perform simple spatial tasks using a region stored in an object variable. I'm disheartened to learn that if the source table of my object is in a different projection, I will first have to save a copy of that table in Long/Lat before executing any tasks with it. Our network drives will double in size with all the tables I am going to be saving copies of! 

Seems utterly daft that you can't change the projection of an object variable. 

Hi Ryan,

Something I always keep in mind when working with projected coordinates is to ensure that the coordinate system of the table I am working with (projected GDA94 or GDA2020 for me, usually) includes a bounds clause.  The accuracy (that is, the number of decimal points) of the coordinate values of the objects within the table is subject to the bounds.  Of course, restricting the bounds does not increase accuracy automatically - you need to ensure accuracy in the first place - but perhaps this is why you are experiencing unexpected results.

You can observe this by zooming in on a node or point, then trying to move this point so that it sits on the boundary.  If your table does not have high-accuracy, you will not be able to make the point stay exactly upon the boundary.  This can also occur if you are snapping - zoom in, and you may find that the snapped points are not exactly snapped - they have a gap between them.

You can check the bounds by using the CoordSys Bounds Manager tool, which comes with MapInfo.

In your case, I would try to make your tRegions table relatively accurate by specifying a bounds that encompasses the area in which you are working. For example, in Victoria, Australia I usually apply bounds that encompass Victoria.

Perhaps there is more to it than this, but this is the first thing I would check.

Thanks Uffe. The inspiration for this question arose from using a spatial query to update a point table with the number of regions a point was within. 

Add Column _tPoints (Num_Regs Integer) From tRegions set to count(*) where contains

A number of points in tPoints sit upon the boundary of the regions, and I am interested in finding these 'boundary points'. The next statement should do this:

Select * From tPoints where Num_Regs > 1 into qBOUNDARY_POINTS

What was confusing me is that I was moving points to snap to region boundaries in order to test the program (which is more extensive than the two lines above), and when I used the boundary select tool I could see these moved points were being selected in the first region, and then the second region (inferring they should be awarded the value "2" and thus end up in the query table qBOUNDARY_POINTS. However, when I ran the program no points were ending up with "2", the query ended up empty and the rest of the program therefore failed.

Checking the projections, tRegions is in BNG and tPoints is in Long/Lat. When I save a copy of tRegions in Long/Lat and run the program, these points DO end up scoring "2" and being selected into qBOUNDARY_POINTS.

My fear is that I work in Long/Lat and frequently populate object variables with regions I use for selection purposes and I am struggling to understand if it will make a difference if the source of these object variables is in BNG. I'm also concerned if my spatial queries (without using object variables) are wrong if I use BNG regions to update/select point tables in Long/Lat. 

Can you elucidate a little on this? Is it right that I will experience three different results if I (a) use the boundary select tool (b) use an object variable and (c) use a table? 

------------------------------
Ryan Cook
ORH LTD

Original Message:
Sent: 07-02-2024 01:56
From: Uffe Kousgaard
Subject: What Projection is an object variable?

oRegion is in BNG and MapInfo keeps track of this. At the point where you do the spatial join, MapInfo will notice oRegion and tPoints are different and will perform the needed transformation, before joining.

If you call a function like centroidx(oRegion), the result will come back in lat/long because that is the default coordinate system. If you want to get the BNG coordinates instead, add "set coordsys table tRegions" first.

Consider it like "5 cm + 0.2 meter" = 25 cm or 0.25 meter. Mapinfo magically keeps track of this for you, just with coordinate systems instead of lengths.

------------------------------
Uffe Kousgaard
CEO
ROUTEWARE
Roskilde

Original Message:
Sent: 07-01-2024 12:39
From: Ryan Cook
Subject: What Projection is an object variable?

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------

Thanks Uffe. The inspiration for this question arose from using a spatial query to update a point table with the number of regions a point was within. 

Add Column _tPoints (Num_Regs Integer) From tRegions set to count(*) where contains

A number of points in tPoints sit upon the boundary of the regions, and I am interested in finding these 'boundary points'. The next statement should do this:

Select * From tPoints where Num_Regs > 1 into qBOUNDARY_POINTS

What was confusing me is that I was moving points to snap to region boundaries in order to test the program (which is more extensive than the two lines above), and when I used the boundary select tool I could see these moved points were being selected in the first region, and then the second region (inferring they should be awarded the value "2" and thus end up in the query table qBOUNDARY_POINTS. However, when I ran the program no points were ending up with "2", the query ended up empty and the rest of the program therefore failed.

Checking the projections, tRegions is in BNG and tPoints is in Long/Lat. When I save a copy of tRegions in Long/Lat and run the program, these points DO end up scoring "2" and being selected into qBOUNDARY_POINTS.

My fear is that I work in Long/Lat and frequently populate object variables with regions I use for selection purposes and I am struggling to understand if it will make a difference if the source of these object variables is in BNG. I'm also concerned if my spatial queries (without using object variables) are wrong if I use BNG regions to update/select point tables in Long/Lat. 

Can you elucidate a little on this? Is it right that I will experience three different results if I (a) use the boundary select tool (b) use an object variable and (c) use a table? 

------------------------------
Ryan Cook
ORH LTD

Original Message:
Sent: 07-02-2024 01:56
From: Uffe Kousgaard
Subject: What Projection is an object variable?

oRegion is in BNG and MapInfo keeps track of this. At the point where you do the spatial join, MapInfo will notice oRegion and tPoints are different and will perform the needed transformation, before joining.

If you call a function like centroidx(oRegion), the result will come back in lat/long because that is the default coordinate system. If you want to get the BNG coordinates instead, add "set coordsys table tRegions" first.

Consider it like "5 cm + 0.2 meter" = 25 cm or 0.25 meter. Mapinfo magically keeps track of this for you, just with coordinate systems instead of lengths.

------------------------------
Uffe Kousgaard
CEO
ROUTEWARE
Roskilde

Original Message:
Sent: 07-01-2024 12:39
From: Ryan Cook
Subject: What Projection is an object variable?

This may sound like a really stupid question but... what projection is an object variable stored in? 

Example:

Dim oRegion as Object
Fetch First from tRegions
oRegion = tRegions.obj
Select * From tPoints where obj within oRegion

In my example, table tRegions is in British National Grid projection. tPoints is in Long/Lat. But what projection is the object variable oRegion? BNG because that's the source of the object? Or is there no such thing as a projection for an object variable? If there is, how do I change it? 

------------------------------
Ryan Cook
ORH LTD
------------------------------