MapInfo Pro

Hello,

I have a program that takes street centerline data and works to combine however many smaller segments into one single segment.  This is done so that when I go to highlight this segment (using MapXtreme) on the map, I do not have to deal with say 75 segment features, and instead only 1 segment feature.

My issue is that as I process this using MapInfo version 15 (32-bit) I have no issues and the code runs from start to completion without the memory breaking 2GB.  (Keep in mind, I am running this code for over 2,500 towns one-by-one).

Ever since I have tried to use MapInfo 64-bit in any fashion, the memory grows and grows, and eventually the MapInfoPro.exe process ID must be killed and start over in order for my code to work. 

1. I have found that MapInfo Pro (64-bit) v 2021.1 launches process MapinfoPro.exe and uses a base memory of 245,000 K.  
2. Next, as my code begins to process, it seems to be where I am marking the layer to edit, and then combine segments together, where the  memory grows and grows. (The code steps are below):
   
   
   1. SELECT * FROM TownStreets INTO CombineAllThese
   2. Map From CombineAllThese
   3. Set Map Layer 1 Editable On
   4. SELECT * FROM CombineAllThese
   5. Objects Combine Data Streetname=Streetname,Lt_from=sum(Lt_from),Lt_to=sum(Lt_to),Rt_from=sum(Rt_from),Rt_to=sum(Rt_to)Source=Source
   6. Close Table CombineAllThese
   7. Commit Table TownStreets
   8. Pack Table TownStreets data
   9. Close All

I had this memory bug logged by support years ago; however, nothing ever came about with it being fixed.  I am still having it happen when using MapInfo Pro version 2021.1.  Here are my notes below if anyone from Precisely Support reviews this thread:

• They filed an official "bug" (or as they call Issue Number) as: "MCS-5942"
• Greg, the support person on the phone, also gave me another internal MI Tech Support Bug #: "MIPRO-102490"

My goal is to solely use MI Pro 2021.1 (64-bit); however, if I can't rely on it to process data, then I have to keep my MI Pro v15.0 (32-bit) still on my workstation to get the job done.

If anyone else has any insight or help they could offer that I could try, I would greatly appreciate it.  

Thank you for your time.

Hello,

I have a program that takes street centerline data and works to combine however many smaller segments into one single segment.  This is done so that when I go to highlight this segment (using MapXtreme) on the map, I do not have to deal with say 75 segment features, and instead only 1 segment feature.

My issue is that as I process this using MapInfo version 15 (32-bit) I have no issues and the code runs from start to completion without the memory breaking 2GB.  (Keep in mind, I am running this code for over 2,500 towns one-by-one).

Ever since I have tried to use MapInfo 64-bit in any fashion, the memory grows and grows, and eventually the MapInfoPro.exe process ID must be killed and start over in order for my code to work. 

1. I have found that MapInfo Pro (64-bit) v 2021.1 launches process MapinfoPro.exe and uses a base memory of 245,000 K.  
2. Next, as my code begins to process, it seems to be where I am marking the layer to edit, and then combine segments together, where the  memory grows and grows. (The code steps are below):
   
   
   1. SELECT * FROM TownStreets INTO CombineAllThese
   2. Map From CombineAllThese
   3. Set Map Layer 1 Editable On
   4. SELECT * FROM CombineAllThese
   5. Objects Combine Data Streetname=Streetname,Lt_from=sum(Lt_from),Lt_to=sum(Lt_to),Rt_from=sum(Rt_from),Rt_to=sum(Rt_to)Source=Source
   6. Close Table CombineAllThese
   7. Commit Table TownStreets
   8. Pack Table TownStreets data
   9. Close All

I had this memory bug logged by support years ago; however, nothing ever came about with it being fixed.  I am still having it happen when using MapInfo Pro version 2021.1.  Here are my notes below if anyone from Precisely Support reviews this thread:

• They filed an official "bug" (or as they call Issue Number) as: "MCS-5942"
• Greg, the support person on the phone, also gave me another internal MI Tech Support Bug #: "MIPRO-102490"

My goal is to solely use MI Pro 2021.1 (64-bit); however, if I can't rely on it to process data, then I have to keep my MI Pro v15.0 (32-bit) still on my workstation to get the job done.

If anyone else has any insight or help they could offer that I could try, I would greatly appreciate it.  

Thank you for your time.

Hi Nicholas

I looked up the bug in our system and it seems we have fixed several memory leaks in MapInfo Pro v2019.3. But we have also created another task to investigate this further.

I assume that the steps 1 to 9 above are repeated 2,500 times, right? Have you tried using a single SQL Statement to combine the segments instead, either for all towns or one at a time?

Similar to what Stefan suggested with PostgreSQL/PostGIS, you can do the same with MapInfo Pro SQL:

Select Streetname   , Sum(Lt_from) "Lt_from", Sum(Lt_to) "Lt_to", Sum(Rt_from) "Rt_from", Sum(Rt_to) "Rt_to"   , Source   , AggregateCombine(OBJ)From TownStreetsGroup By StreetNameInto Aggr_Streets NoSelect

Hello,

I have a program that takes street centerline data and works to combine however many smaller segments into one single segment.  This is done so that when I go to highlight this segment (using MapXtreme) on the map, I do not have to deal with say 75 segment features, and instead only 1 segment feature.

My issue is that as I process this using MapInfo version 15 (32-bit) I have no issues and the code runs from start to completion without the memory breaking 2GB.  (Keep in mind, I am running this code for over 2,500 towns one-by-one).

Ever since I have tried to use MapInfo 64-bit in any fashion, the memory grows and grows, and eventually the MapInfoPro.exe process ID must be killed and start over in order for my code to work. 

1. I have found that MapInfo Pro (64-bit) v 2021.1 launches process MapinfoPro.exe and uses a base memory of 245,000 K.  
2. Next, as my code begins to process, it seems to be where I am marking the layer to edit, and then combine segments together, where the  memory grows and grows. (The code steps are below):
   
   
   1. SELECT * FROM TownStreets INTO CombineAllThese
   2. Map From CombineAllThese
   3. Set Map Layer 1 Editable On
   4. SELECT * FROM CombineAllThese
   5. Objects Combine Data Streetname=Streetname,Lt_from=sum(Lt_from),Lt_to=sum(Lt_to),Rt_from=sum(Rt_from),Rt_to=sum(Rt_to)Source=Source
   6. Close Table CombineAllThese
   7. Commit Table TownStreets
   8. Pack Table TownStreets data
   9. Close All

I had this memory bug logged by support years ago; however, nothing ever came about with it being fixed.  I am still having it happen when using MapInfo Pro version 2021.1.  Here are my notes below if anyone from Precisely Support reviews this thread:

• They filed an official "bug" (or as they call Issue Number) as: "MCS-5942"
• Greg, the support person on the phone, also gave me another internal MI Tech Support Bug #: "MIPRO-102490"

My goal is to solely use MI Pro 2021.1 (64-bit); however, if I can't rely on it to process data, then I have to keep my MI Pro v15.0 (32-bit) still on my workstation to get the job done.

If anyone else has any insight or help they could offer that I could try, I would greatly appreciate it.  

Thank you for your time.

Hello Stefan & Peter,

Thanks for your responses. Unfortunately, I was tied up working on a completely different project until now.  

Are you suggesting then taking MapInfo Pro and MapBasic out of the equation and replacing it by using SQL Server or PostGIS and doing all of the combining work inside of there instead?

Hi Nicholas

I looked up the bug in our system and it seems we have fixed several memory leaks in MapInfo Pro v2019.3. But we have also created another task to investigate this further.

I assume that the steps 1 to 9 above are repeated 2,500 times, right? Have you tried using a single SQL Statement to combine the segments instead, either for all towns or one at a time?

Similar to what Stefan suggested with PostgreSQL/PostGIS, you can do the same with MapInfo Pro SQL:

Select Streetname   , Sum(Lt_from) "Lt_from", Sum(Lt_to) "Lt_to", Sum(Rt_from) "Rt_from", Sum(Rt_to) "Rt_to"   , Source   , AggregateCombine(OBJ)From TownStreetsGroup By StreetNameInto Aggr_Streets NoSelect

Hello,

I have a program that takes street centerline data and works to combine however many smaller segments into one single segment.  This is done so that when I go to highlight this segment (using MapXtreme) on the map, I do not have to deal with say 75 segment features, and instead only 1 segment feature.

My issue is that as I process this using MapInfo version 15 (32-bit) I have no issues and the code runs from start to completion without the memory breaking 2GB.  (Keep in mind, I am running this code for over 2,500 towns one-by-one).

Ever since I have tried to use MapInfo 64-bit in any fashion, the memory grows and grows, and eventually the MapInfoPro.exe process ID must be killed and start over in order for my code to work. 

1. I have found that MapInfo Pro (64-bit) v 2021.1 launches process MapinfoPro.exe and uses a base memory of 245,000 K.  
2. Next, as my code begins to process, it seems to be where I am marking the layer to edit, and then combine segments together, where the  memory grows and grows. (The code steps are below):
   
   
   1. SELECT * FROM TownStreets INTO CombineAllThese
   2. Map From CombineAllThese
   3. Set Map Layer 1 Editable On
   4. SELECT * FROM CombineAllThese
   5. Objects Combine Data Streetname=Streetname,Lt_from=sum(Lt_from),Lt_to=sum(Lt_to),Rt_from=sum(Rt_from),Rt_to=sum(Rt_to)Source=Source
   6. Close Table CombineAllThese
   7. Commit Table TownStreets
   8. Pack Table TownStreets data
   9. Close All

I had this memory bug logged by support years ago; however, nothing ever came about with it being fixed.  I am still having it happen when using MapInfo Pro version 2021.1.  Here are my notes below if anyone from Precisely Support reviews this thread:

• They filed an official "bug" (or as they call Issue Number) as: "MCS-5942"
• Greg, the support person on the phone, also gave me another internal MI Tech Support Bug #: "MIPRO-102490"

My goal is to solely use MI Pro 2021.1 (64-bit); however, if I can't rely on it to process data, then I have to keep my MI Pro v15.0 (32-bit) still on my workstation to get the job done.

If anyone else has any insight or help they could offer that I could try, I would greatly appreciate it.  

Thank you for your time.