MapInfo Pro

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick

Hi Nick,

The first point to make is that MapInfo Advanced (what we engineers more sensibly call the "Raster module") does not explicitly provide support for the COG format. I will consider this post as a request for that functionality.

However, a COG is just a TIFF file with internally stored overview levels and a network friendly internal data arrangement. There are two ways to access a COG - either by directly opening the TIFF file in the usual way or by using HTTP GetRange requests. In Pro, we do not have any support for HTTP access to these files. We do allow users to load the TIFF file directly.

Your guesses in the post are mostly correct. We will load a TIFF file via a "Native" TIFF driver, or via a driver using GDAL or via the old Pro raster handlers. The native driver gets first shot at it and it decides the TIFF needs a PPRC (which is really an MRR format raster that contains a complete overview pyramid). If you skip the native driver then the GDAL driver gets a shot at it. I tested this in 17.02 and found that it loads the COG appropriately and does not create a PPRC - it acquires data from the internal overviews in the COG when available and fabricates levels that are not supplied as best it can on the fly.

So, for the upcoming 17.03 patch we could make a change to the native TIFF driver to recognise these COG's and pass over them so that they are loaded by the GDAL driver. This would be a step forward. Support for HTTP access to COG's could be considered for a future release.

Regards,
Sam.

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick

Hi Nick,

The first point to make is that MapInfo Advanced (what we engineers more sensibly call the "Raster module") does not explicitly provide support for the COG format. I will consider this post as a request for that functionality.

However, a COG is just a TIFF file with internally stored overview levels and a network friendly internal data arrangement. There are two ways to access a COG - either by directly opening the TIFF file in the usual way or by using HTTP GetRange requests. In Pro, we do not have any support for HTTP access to these files. We do allow users to load the TIFF file directly.

Your guesses in the post are mostly correct. We will load a TIFF file via a "Native" TIFF driver, or via a driver using GDAL or via the old Pro raster handlers. The native driver gets first shot at it and it decides the TIFF needs a PPRC (which is really an MRR format raster that contains a complete overview pyramid). If you skip the native driver then the GDAL driver gets a shot at it. I tested this in 17.02 and found that it loads the COG appropriately and does not create a PPRC - it acquires data from the internal overviews in the COG when available and fabricates levels that are not supplied as best it can on the fly.

So, for the upcoming 17.03 patch we could make a change to the native TIFF driver to recognise these COG's and pass over them so that they are loaded by the GDAL driver. This would be a step forward. Support for HTTP access to COG's could be considered for a future release.

Regards,
Sam.

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick

Hello, I am relaunching the subject, were you able to move forward on the subject.

I cannot point to a url on the could to open a COG file.

thank you for your help.

Hi Nick,

The first point to make is that MapInfo Advanced (what we engineers more sensibly call the "Raster module") does not explicitly provide support for the COG format. I will consider this post as a request for that functionality.

However, a COG is just a TIFF file with internally stored overview levels and a network friendly internal data arrangement. There are two ways to access a COG - either by directly opening the TIFF file in the usual way or by using HTTP GetRange requests. In Pro, we do not have any support for HTTP access to these files. We do allow users to load the TIFF file directly.

Your guesses in the post are mostly correct. We will load a TIFF file via a "Native" TIFF driver, or via a driver using GDAL or via the old Pro raster handlers. The native driver gets first shot at it and it decides the TIFF needs a PPRC (which is really an MRR format raster that contains a complete overview pyramid). If you skip the native driver then the GDAL driver gets a shot at it. I tested this in 17.02 and found that it loads the COG appropriately and does not create a PPRC - it acquires data from the internal overviews in the COG when available and fabricates levels that are not supplied as best it can on the fly.

So, for the upcoming 17.03 patch we could make a change to the native TIFF driver to recognise these COG's and pass over them so that they are loaded by the GDAL driver. This would be a step forward. Support for HTTP access to COG's could be considered for a future release.

Regards,
Sam.

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick

You can open, display, and process a Cloud Optimised GeoTIFF (COG) raster that is stored on a local or network drive.

However, if the COG file is stored "in the cloud" on some network file system like AWS S3 or Google Cloud then I do not think you will be able to load it in MapInfo Pro.

Firstly, you would need to direct MapInfo to open the COG using the GDAL driver.

Secondly, you need to specify the GDAL virtual file system you want to use by inserting a string like /vsicurl/ or /vsis3/ into the file name string. In this case, the file name string would be a http:// or https:// URL. You may also need specify credentials for the file system and there are multiple ways to do that and those methods have been evolving.

Thirdly, you would probably need MapInfo Pro to be shipped with the latest version of GDAL as this is an evolving capability in GDAL and they are fixing bugs in it all the time.

With a bit of work, it would be possible. You would have to take this up as a feature request with the MapInfo team.

Hello, I am relaunching the subject, were you able to move forward on the subject.

I cannot point to a url on the could to open a COG file.

thank you for your help.

Hi Nick,

The first point to make is that MapInfo Advanced (what we engineers more sensibly call the "Raster module") does not explicitly provide support for the COG format. I will consider this post as a request for that functionality.

However, a COG is just a TIFF file with internally stored overview levels and a network friendly internal data arrangement. There are two ways to access a COG - either by directly opening the TIFF file in the usual way or by using HTTP GetRange requests. In Pro, we do not have any support for HTTP access to these files. We do allow users to load the TIFF file directly.

Your guesses in the post are mostly correct. We will load a TIFF file via a "Native" TIFF driver, or via a driver using GDAL or via the old Pro raster handlers. The native driver gets first shot at it and it decides the TIFF needs a PPRC (which is really an MRR format raster that contains a complete overview pyramid). If you skip the native driver then the GDAL driver gets a shot at it. I tested this in 17.02 and found that it loads the COG appropriately and does not create a PPRC - it acquires data from the internal overviews in the COG when available and fabricates levels that are not supplied as best it can on the fly.

So, for the upcoming 17.03 patch we could make a change to the native TIFF driver to recognise these COG's and pass over them so that they are loaded by the GDAL driver. This would be a step forward. Support for HTTP access to COG's could be considered for a future release.

Regards,
Sam.

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick

Hello SAM, I found a way to open the file via an url, I simply indicated in the name the url link of the file except that opens it,

but how can I indicate that the string /vicurl/, I tested from the name to add /vicurl/https://.... but it tells me that the file name is not correct.

 thank you for your help.

You can open, display, and process a Cloud Optimised GeoTIFF (COG) raster that is stored on a local or network drive.

However, if the COG file is stored "in the cloud" on some network file system like AWS S3 or Google Cloud then I do not think you will be able to load it in MapInfo Pro.

Firstly, you would need to direct MapInfo to open the COG using the GDAL driver.

Secondly, you need to specify the GDAL virtual file system you want to use by inserting a string like /vsicurl/ or /vsis3/ into the file name string. In this case, the file name string would be a http:// or https:// URL. You may also need specify credentials for the file system and there are multiple ways to do that and those methods have been evolving.

Thirdly, you would probably need MapInfo Pro to be shipped with the latest version of GDAL as this is an evolving capability in GDAL and they are fixing bugs in it all the time.

With a bit of work, it would be possible. You would have to take this up as a feature request with the MapInfo team.

Hello, I am relaunching the subject, were you able to move forward on the subject.

I cannot point to a url on the could to open a COG file.

thank you for your help.

Hi Nick,

The first point to make is that MapInfo Advanced (what we engineers more sensibly call the "Raster module") does not explicitly provide support for the COG format. I will consider this post as a request for that functionality.

However, a COG is just a TIFF file with internally stored overview levels and a network friendly internal data arrangement. There are two ways to access a COG - either by directly opening the TIFF file in the usual way or by using HTTP GetRange requests. In Pro, we do not have any support for HTTP access to these files. We do allow users to load the TIFF file directly.

Your guesses in the post are mostly correct. We will load a TIFF file via a "Native" TIFF driver, or via a driver using GDAL or via the old Pro raster handlers. The native driver gets first shot at it and it decides the TIFF needs a PPRC (which is really an MRR format raster that contains a complete overview pyramid). If you skip the native driver then the GDAL driver gets a shot at it. I tested this in 17.02 and found that it loads the COG appropriately and does not create a PPRC - it acquires data from the internal overviews in the COG when available and fabricates levels that are not supplied as best it can on the fly.

So, for the upcoming 17.03 patch we could make a change to the native TIFF driver to recognise these COG's and pass over them so that they are loaded by the GDAL driver. This would be a step forward. Support for HTTP access to COG's could be considered for a future release.

Regards,
Sam.

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick

Hi Hugo,

Sorry, but I am not able to help you any further because this is a job for the engineering team and you need to raise it with them.

You could create a TAB file that points to the URL like this (real example) - 

!table
!version 300
!charset WindowsLatin1

Definition Table
  File "/vsicurl/https://oin-hotosm.s3.amazonaws.com/5e4108fb56992d0006e589e2/0/5e4108fb56992d0006e589e3.tif"
  Type "RASTER"
  (0,1) (0,0) Label "Pt 1",
  (1,1) (1024,0) Label "Pt 2",
  (1,0) (1024,1024) Label "Pt 3",
  (0,0) (0,1024) Label "Pt 4"
  CoordSys Earth Projection 1, 104
  Units "degree"

The coordinate information and coordinate system in the TAB will get overridden by the information in the raster so it doesn't matter what it is. All that matters is the File declaration.

This could work, but it doesn't. The raster library in Pro is doing checks on the file name and it is not aware of the /vsicurl/ feature, so it finds the file does not exist, the file name is not valid or well-formed, etc. If the engineers could overcome all of these failure points then the file name would get through to the GDAL driver and then you would have a chance of loading the raster.

Hello SAM, I found a way to open the file via an url, I simply indicated in the name the url link of the file except that opens it,

but how can I indicate that the string /vicurl/, I tested from the name to add /vicurl/https://.... but it tells me that the file name is not correct.

 thank you for your help.

You can open, display, and process a Cloud Optimised GeoTIFF (COG) raster that is stored on a local or network drive.

However, if the COG file is stored "in the cloud" on some network file system like AWS S3 or Google Cloud then I do not think you will be able to load it in MapInfo Pro.

Firstly, you would need to direct MapInfo to open the COG using the GDAL driver.

Secondly, you need to specify the GDAL virtual file system you want to use by inserting a string like /vsicurl/ or /vsis3/ into the file name string. In this case, the file name string would be a http:// or https:// URL. You may also need specify credentials for the file system and there are multiple ways to do that and those methods have been evolving.

Thirdly, you would probably need MapInfo Pro to be shipped with the latest version of GDAL as this is an evolving capability in GDAL and they are fixing bugs in it all the time.

With a bit of work, it would be possible. You would have to take this up as a feature request with the MapInfo team.

Hello, I am relaunching the subject, were you able to move forward on the subject.

I cannot point to a url on the could to open a COG file.

thank you for your help.

Hi Nick,

The first point to make is that MapInfo Advanced (what we engineers more sensibly call the "Raster module") does not explicitly provide support for the COG format. I will consider this post as a request for that functionality.

However, a COG is just a TIFF file with internally stored overview levels and a network friendly internal data arrangement. There are two ways to access a COG - either by directly opening the TIFF file in the usual way or by using HTTP GetRange requests. In Pro, we do not have any support for HTTP access to these files. We do allow users to load the TIFF file directly.

Your guesses in the post are mostly correct. We will load a TIFF file via a "Native" TIFF driver, or via a driver using GDAL or via the old Pro raster handlers. The native driver gets first shot at it and it decides the TIFF needs a PPRC (which is really an MRR format raster that contains a complete overview pyramid). If you skip the native driver then the GDAL driver gets a shot at it. I tested this in 17.02 and found that it loads the COG appropriately and does not create a PPRC - it acquires data from the internal overviews in the COG when available and fabricates levels that are not supplied as best it can on the fly.

So, for the upcoming 17.03 patch we could make a change to the native TIFF driver to recognise these COG's and pass over them so that they are loaded by the GDAL driver. This would be a step forward. Support for HTTP access to COG's could be considered for a future release.

Regards,
Sam.

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick

thank you for your feedback, I will open a ticket with them hoping that they can include native support for COG files in the application.
Thanks again for your help.

Hi Hugo,

Sorry, but I am not able to help you any further because this is a job for the engineering team and you need to raise it with them.

You could create a TAB file that points to the URL like this (real example) - 

!table
!version 300
!charset WindowsLatin1

Definition Table
  File "/vsicurl/https://oin-hotosm.s3.amazonaws.com/5e4108fb56992d0006e589e2/0/5e4108fb56992d0006e589e3.tif"
  Type "RASTER"
  (0,1) (0,0) Label "Pt 1",
  (1,1) (1024,0) Label "Pt 2",
  (1,0) (1024,1024) Label "Pt 3",
  (0,0) (0,1024) Label "Pt 4"
  CoordSys Earth Projection 1, 104
  Units "degree"

The coordinate information and coordinate system in the TAB will get overridden by the information in the raster so it doesn't matter what it is. All that matters is the File declaration.

This could work, but it doesn't. The raster library in Pro is doing checks on the file name and it is not aware of the /vsicurl/ feature, so it finds the file does not exist, the file name is not valid or well-formed, etc. If the engineers could overcome all of these failure points then the file name would get through to the GDAL driver and then you would have a chance of loading the raster.

Hello SAM, I found a way to open the file via an url, I simply indicated in the name the url link of the file except that opens it,

but how can I indicate that the string /vicurl/, I tested from the name to add /vicurl/https://.... but it tells me that the file name is not correct.

 thank you for your help.

You can open, display, and process a Cloud Optimised GeoTIFF (COG) raster that is stored on a local or network drive.

However, if the COG file is stored "in the cloud" on some network file system like AWS S3 or Google Cloud then I do not think you will be able to load it in MapInfo Pro.

Firstly, you would need to direct MapInfo to open the COG using the GDAL driver.

Secondly, you need to specify the GDAL virtual file system you want to use by inserting a string like /vsicurl/ or /vsis3/ into the file name string. In this case, the file name string would be a http:// or https:// URL. You may also need specify credentials for the file system and there are multiple ways to do that and those methods have been evolving.

Thirdly, you would probably need MapInfo Pro to be shipped with the latest version of GDAL as this is an evolving capability in GDAL and they are fixing bugs in it all the time.

With a bit of work, it would be possible. You would have to take this up as a feature request with the MapInfo team.

Hello, I am relaunching the subject, were you able to move forward on the subject.

I cannot point to a url on the could to open a COG file.

thank you for your help.

Hi Nick,

The first point to make is that MapInfo Advanced (what we engineers more sensibly call the "Raster module") does not explicitly provide support for the COG format. I will consider this post as a request for that functionality.

However, a COG is just a TIFF file with internally stored overview levels and a network friendly internal data arrangement. There are two ways to access a COG - either by directly opening the TIFF file in the usual way or by using HTTP GetRange requests. In Pro, we do not have any support for HTTP access to these files. We do allow users to load the TIFF file directly.

Your guesses in the post are mostly correct. We will load a TIFF file via a "Native" TIFF driver, or via a driver using GDAL or via the old Pro raster handlers. The native driver gets first shot at it and it decides the TIFF needs a PPRC (which is really an MRR format raster that contains a complete overview pyramid). If you skip the native driver then the GDAL driver gets a shot at it. I tested this in 17.02 and found that it loads the COG appropriately and does not create a PPRC - it acquires data from the internal overviews in the COG when available and fabricates levels that are not supplied as best it can on the fly.

So, for the upcoming 17.03 patch we could make a change to the native TIFF driver to recognise these COG's and pass over them so that they are loaded by the GDAL driver. This would be a step forward. Support for HTTP access to COG's could be considered for a future release.

Regards,
Sam.

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick

Hi Hugo

Are you still using MapInfo v16?

Lots of change since then....

thank you for your feedback, I will open a ticket with them hoping that they can include native support for COG files in the application.
Thanks again for your help.

Hi Hugo,

Sorry, but I am not able to help you any further because this is a job for the engineering team and you need to raise it with them.

You could create a TAB file that points to the URL like this (real example) - 

!table
!version 300
!charset WindowsLatin1

Definition Table
  File "/vsicurl/https://oin-hotosm.s3.amazonaws.com/5e4108fb56992d0006e589e2/0/5e4108fb56992d0006e589e3.tif"
  Type "RASTER"
  (0,1) (0,0) Label "Pt 1",
  (1,1) (1024,0) Label "Pt 2",
  (1,0) (1024,1024) Label "Pt 3",
  (0,0) (0,1024) Label "Pt 4"
  CoordSys Earth Projection 1, 104
  Units "degree"

The coordinate information and coordinate system in the TAB will get overridden by the information in the raster so it doesn't matter what it is. All that matters is the File declaration.

This could work, but it doesn't. The raster library in Pro is doing checks on the file name and it is not aware of the /vsicurl/ feature, so it finds the file does not exist, the file name is not valid or well-formed, etc. If the engineers could overcome all of these failure points then the file name would get through to the GDAL driver and then you would have a chance of loading the raster.

Hello SAM, I found a way to open the file via an url, I simply indicated in the name the url link of the file except that opens it,

but how can I indicate that the string /vicurl/, I tested from the name to add /vicurl/https://.... but it tells me that the file name is not correct.

 thank you for your help.

You can open, display, and process a Cloud Optimised GeoTIFF (COG) raster that is stored on a local or network drive.

However, if the COG file is stored "in the cloud" on some network file system like AWS S3 or Google Cloud then I do not think you will be able to load it in MapInfo Pro.

Firstly, you would need to direct MapInfo to open the COG using the GDAL driver.

Secondly, you need to specify the GDAL virtual file system you want to use by inserting a string like /vsicurl/ or /vsis3/ into the file name string. In this case, the file name string would be a http:// or https:// URL. You may also need specify credentials for the file system and there are multiple ways to do that and those methods have been evolving.

Thirdly, you would probably need MapInfo Pro to be shipped with the latest version of GDAL as this is an evolving capability in GDAL and they are fixing bugs in it all the time.

With a bit of work, it would be possible. You would have to take this up as a feature request with the MapInfo team.

Hello, I am relaunching the subject, were you able to move forward on the subject.

I cannot point to a url on the could to open a COG file.

thank you for your help.

Hi Nick,

The first point to make is that MapInfo Advanced (what we engineers more sensibly call the "Raster module") does not explicitly provide support for the COG format. I will consider this post as a request for that functionality.

However, a COG is just a TIFF file with internally stored overview levels and a network friendly internal data arrangement. There are two ways to access a COG - either by directly opening the TIFF file in the usual way or by using HTTP GetRange requests. In Pro, we do not have any support for HTTP access to these files. We do allow users to load the TIFF file directly.

Your guesses in the post are mostly correct. We will load a TIFF file via a "Native" TIFF driver, or via a driver using GDAL or via the old Pro raster handlers. The native driver gets first shot at it and it decides the TIFF needs a PPRC (which is really an MRR format raster that contains a complete overview pyramid). If you skip the native driver then the GDAL driver gets a shot at it. I tested this in 17.02 and found that it loads the COG appropriately and does not create a PPRC - it acquires data from the internal overviews in the COG when available and fabricates levels that are not supplied as best it can on the fly.

So, for the upcoming 17.03 patch we could make a change to the native TIFF driver to recognise these COG's and pass over them so that they are loaded by the GDAL driver. This would be a step forward. Support for HTTP access to COG's could be considered for a future release.

Regards,
Sam.

Hello all,

I have a lot of raster imagery in cloud-optimised geotiff format.

https://www.cogeo.org/

I am running MapInfo v16.0.3 (64-bit) on Windows 7 (64-bit)

When I open a cloud-optimised geotiff for the first time, MapInfo generates a .pprc file. Which is a pyramid index.

I understand that a pyramid index is useful for the old-style geoTifs, which use LZW compression. But a cloud-optimised geotif should not require pyramid layers. The image format is designed to not require pyramid layers. (When the image is read, it only returns those pixels that are appropriate for the user's zoom and extent).

I looked at the Preferences for MapInfo Raster | Raster Formats and GeoTiff Image is both in the list of Native Formats and GDAL Formats. But there is no distinction made between the old-style geoTiff (LZW compression) and this new cloud-optimised geoTiff. My suspicion is that the old-style geotiff is in the list "Native Formats" and the cloud-optimised geotiff is in the list "GDAL Formats". However, if either one of these is ticked (Enable Display ticked) then a pprc is created next to the cloud-optimised geotiff.

Cloud-optimised geotiff ought to display very quickly and should not need a pprc created.

Thanks,

Nick