Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add MapInfo MRR(Multi Resolution Raster) raster driver. #2618

Closed
wants to merge 14 commits into from

Conversation

miteshpb
Copy link

What does this PR do?

Add MapInfo MRR(Multi Resolution Raster) raster driver. This driver will not be enabled as default compile. It could be enabled as Plugin(autoload) driver, or standard driver as needed.

This driver depends on MapInfo Raster runtime binaries. These binaries are free to download and use. Documentation on obtaining the runtime binaries for various platforms has been updated with PR.

What are related issues/pull requests?

Tasklist

  • ADD YOUR TASKS HERE
  • Add test case(s)
  • Add documentation
  • Review
  • Adjust for comments
  • All CI builds and checks have passed

Environment

Provide environment details, if relevant:

  • OS:
  • Compiler:

@nyalldawson
Copy link
Collaborator

Reiterating my thoughts from #1882

I'm extremely disappointed to see that you persist with the closed source SDK approach. You are doing your users a great disservice with this approach. It's a shortsighted, paranoid and frankly outdated approach. I would strongly recommend that you reconsider this if you intend for your formats to be widely used outside of MapInfo itself.

Update mrr.rst
Update index for raster doc to include mrr
Removed Tabs. Fixed initialization warnings.
noExplicitConstructor fix
Updated doc comments.
Add MRR entry to configure to ease out optional MRR compile, Fix typo.
Reverting MRR entry. It was not intended to be there.
@rouault
Copy link
Member

rouault commented Jun 2, 2020

Note: I don't think pushing commits in this PR makes sense while you haven't adressed the fundamental remark of #2618 (comment)

@carypeebles
Copy link

We understand and share the desire to open the source for this format but are unable to do so at this time. However, we wish to provide our clients who already have their data in the MRR format and who already have the SDK the ability to share the data in the broadest suite of technology possible.

@nyalldawson
Copy link
Collaborator

We understand and share the desire to open the source for this format but are unable to do so at this time. However, we wish to provide our clients who already have their data in the MRR format and who already have the SDK the ability to share the data in the broadest suite of technology possible.

In that case I would strongly suggest that the GDAL project maintainers close this PR as a "wontfix".

In its current form this PR offers absolutely nothing to the project, except for added maintenance burden. You are trying to push work onto the GDAL project and offering them absolutely nothing in return. Basically, what you are trying to do is legitimise your proprietary, patent-encumbered MRR format by being able to say that it's supported by GDAL.

I think we have an obligation to our users to protect them from this. The MRR format offers nothing of real value that isn't available through other alternative, and OPEN or STANDARDS BASED formats. GDAL (and open source geo in general) should NOT be encouraging anyone to use this format -- it's a trap. (I'd even go as far as to say that we have a moral obligation to make it as hard as possible for people to use this format, so that they are forced to use the open formats instead).

If you're set on the current approach and want to see this work land in gdal, then you need to build up social capital with the project first BEFORE trying to sling selfish work like this onto the project. There's heaps of ways you could do this! Some suggestions:

  • financially support the project with large, ongoing sponsorship
  • contribute to the open Mapinfo TAB driver, and submit fixes for that.
  • provide the missing documentation relating to MapInfo's datum tables and the correct way to map these to standard EPSG codes (see e.g. Mapinfo: list of CRSs #2614)

These are all easy ways for your company to show your commitment to the GDAL project in advance, and show that you are willing to work with GDAL. Do that first, build your reputation, prove your worth, and THEN come back with generally undesirable changes like this one. You'll find you get a much more receptive response from the community...

@ianturton
Copy link
Contributor

I gave a talk about this sort of thing at FOSS4G - you can watch the video if you want to get a better idea.

@stale
Copy link

stale bot commented Jul 1, 2020

The GDAL project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 21 days and is being automatically marked as "stale". If you think this pull request should be merged, please check - that all unit tests are passing - that all comments by reviewers have been addressed - that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes
  • add a description of workflows which this pull request fixes
  • add screenshots if applicable
  • that you have written unit tests where possible In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request. If there is no further activity on this pull request, it will be closed in a week.

@stale stale bot added the stale label Jul 1, 2020
@stale
Copy link

stale bot commented Jul 8, 2020

While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 28 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the GDAL project can do to help push this PR forward please let us know how we can assist.

@stale stale bot closed this Jul 8, 2020
@idanmiara
Copy link
Collaborator

I think we have an obligation to our users to protect them from this. The MRR format offers nothing of real value that isn't available through other alternative, and OPEN or STANDARDS BASED formats. GDAL (and open source geo in general) should NOT be encouraging anyone to use this format -- it's a trap. (I'd even go as far as to say that we have a moral obligation to make it as hard as possible for people to use this format, so that they are forced to use the open formats instead).

@miteshpb
As one of your clients, I would HIGHLY APPRICIATE you add native GeoTiff input/output support in your software (in addition to your NWT_GRD and MRR formats) using GDAL for maximum compatibility.

Until that happens and/or until your contribution to GDAL is accepted by the community, please regularly update your MRR-GDAL plugin to the latest released GDAL version.
Currently it only supports GDAL 3.0 and makes it hard for us to upgrade to newer GDAL versions.

Thanks!

@idanmiara
Copy link
Collaborator

Hi @miteshpb!
In case you are still working on project, please note:
#5128

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants