Take #3: Add MapInfo MRR(Multi Resolution Raster) raster driver #3447
Conversation
Adding Pytests for MRR, test data. MRR options for making windows driver. Create mrr.rst Adding rst documentation for MRR driver Update index for raster doc to include mrr Add MRR entry to configure to ease out optional MRR compile
mrr.rst - reformat and doc syntax fixes gdal/frmts/makefile.vc - reformat gdal/nmake.opt - set MRR_LIB_LINK and add it to EXTERNAL_LIBS
idanmiara
changed the title
|
@idanmiara I believe MapInfo moved their driver to a different repository, as it's an out of tree driver which has absolutely no affiliation with this gdal repo (or maybe they kept it totally private..?). You'll need to take this up with MapInfo themselves, and I'd suggest using it as an opportunity to educate them again as to the utter stupidity of their attitudes towards upstream. |
|
I didn't find any MRR driver repo.
As far as I could find, Their latest SDK is dated 24 August 2020 and includes
almost the same plugin sources as the ones in their previous PR.
https://support.precisely.com/product-downloads/item/mapinfo-mrr-sdk-download/
They didn't bother to put any contact info on the SDK either.
…On Mon, 8 Feb 2021, 23:04 Nyall Dawson, ***@***.***> wrote:
@idanmiara <https://github.com/idanmiara> I believe MapInfo moved their
driver to a different repository, as it's an out of tree driver which has
absolutely no affiliation with this gdal repo (or maybe they kept it
totally private..?). You'll need to take this up with MapInfo themselves,
and I'd suggest using it as an opportunity to educate them again as to the
utter stupidity of their attitudes towards upstream.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3447 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGJBBLNEUGTGRDFBRHQOQJLS6BGXPANCNFSM4XJI3NAA>
.
|
|
@nyalldawson @rouault what's the difference between other closed source gdal drivers, like ECW, and this one? Why they did get accepted? |
|
Because those drivers were introduced a long time ago, at a time when there was compelling reasons for gdal to consume those sources. MRR is such a niche format that the extra burden on the gdal project which comes with an unmaintained, binary dependent driver just isn't justifiable. MapInfo/pb/precisely had multiple opportunities to work WITH the gdal community and contribute value to the project, but they chose to ignore all of the advice and requests made by the community and blunder ahead in their own stubbornness. It's on them to change their mindsets and come back when they are ready to work with us, not against us. |
|
@nyalldawson Maybe you are remembering the debate about making a new MapInfo Extented Tab (vector) driver #1882 instead of implementing it into MITAB library. The MRR driver was in the same PR but perhaps raster side does not have as realistic Open Source alternative. The new raster driver belongs to same context than the brand new JPEG 2000 driver in PR #3449. PR has interesting comments. I personally think that raster drivers based on external libraries, open or not, are welcome if they are built as plugins, especially if they had a maintainer to take care that they build also in the future. But if they don't build then they can be dropped. The template for the new RFC driven procedure for accepting new drivers could consider also these points
|
I don't see why PB would not open their SDK for MRR. It isn't like they're going to sell it. We are an open source project. It is logical that we put pressure so that our dependencies are open too. Anyway that they aren't able to cope themselves to provide binaries for newer GDAL versions isn't a good omen. |
No, I was definitely referring to MRR.
In an ideal world... maybe. But the GDAL project is already overburdened and severely lacking in resources, and all this code comes with a concrete, ongoing cost. There's multiple solutions to this which were suggested to PB in the original thread. including:
They chose 3, and have proven totally useless at maintaining it. Not a huge surprise there! Honestly, I'd ask you in all sincerity to drop this volunteer work which Precisely/PB should be doing themselves and instead use your efforts to pressure them to change their approach and mindsets. By giving your time for free to help Precisely/PB you're teaching them a very harmful message about how open source should work. I realise that's probably hard to hear, and there's no personal offence intended here, but I strongly believe that we need to be protecting the health of the GDAL project as much as possible right now. |
|
The reason for making this PR was as @idanmiara wrote that they "just need MRR support with newer GDAL." Is our advice that @idanmiara does what ever needs to be done outside the main GDAL tree and reverts this pull request? Experiences about refreshing the driver could be reported on a user wiki page for helping other GDAL users who will have the same need in the future. BTW the company behind MapInfo seems to be called Precisely now https://support.precisely.com/products/mapinfo-pro/. |
I've contacted Precisely and also pointed out also to this PR. The people who developed this plugin contacted me and are trying to help. I'm hoping they would do the right thing.
This is the plugin I am using for GDAL 3.0. |
|
Precisely sent me the an updated version of the gdal-mrr plugin for GDAL 3.2 and fixed the bugs that I've reported. "Currently we are supporting it as a Plugin through this location, https://support.precisely.com/product-downloads/item/mapinfo-mrr-sdk-download/ as a stopgap arrangement. Which has latest fixes and necessary source code and binaries to build it as a Plugin. You may review the same and use it. We aim to keep it buildable for all GDAL versions." I'm closing this PR with the hope that they eventually will find the right way to support gdal upstream like suggested above. |
What does this PR do?
I am not affiliated with PB, I just need MRR support with newer GDAL.
As PB only published GDAL 3.0 plugins, I'm trying to rebase #2618 and fix it.
Maybe @miteshpb or someone else from PB would like to help out and make it right this time, as @nyalldawson suggested in this comment.
What are related issues/pull requests?
#2618 ( AKA Take 2)
#1882 ( AKA Take 1)