Subject says it all. I have installed all of Kyngchaos packages, but
gdalinfo --formats
does not list ECW or MrSid formats. Could someone else with Mountain Lion try if they can get any JP2 driver installed into GDAL?
-
(I always get the tumbleweed badge. :( Am I so weird? ;)– K.-Michael AyeOct 6, 2012 at 23:34
-
did you installed the ERDAS ECW/JP2 SDK Desktop Read-Only ??– Gago-SilvaJan 12, 2013 at 11:03
-
I'm using kyngchaos for years, never had to do this for the, I believe , statically linked binary plugins. (I'm not compiling anything) And, this requirement is not mentioned on the website, but then again it does not officially support Mountain Lion. So is this something that recently became a requirement?– K.-Michael AyeJan 12, 2013 at 19:13
Add a comment
|
1 Answer
1.- Install Homebrew
2.- Download the ECW/JP2 SDK from ERDAS and install on /usr/local
3.- Install gdal using formula:
brew install gdal --enable-unsupported --complete
Enjoy.
By the way, if in addition you want other things like filegdb, the steps are similar (i.e step 2.5 would be to download and install the filegdb SDK to /usr/local)
To clarify about the reasoning of why you don't see ecw/mr sid (or oracle client or filegdb or arcobjects driver etc etc) is because those drivers rely on proprietary SDKs. It has nothing to do with technical feasability and everything to do with licensing. When you download the SDK, you are agreeing to different proprietary licenses and those steps should not be legally skipped. That is why to get access to those drivers you need to compile them.
Your options are:
1.- to get the exact version of gdal used by kyngchaos (along with the dependencies - everything available different links from the kyngchaos site) and compile the ecw plugin as an external plugin. Then you would need to drop those binaries in the gdal-plugin folder (this is in fact what we used to do before utilities like homebrew existed). You can continue using the rest of the kyngchaos binaries.
2.- To get the binary from somebody that does all of 1.- and give you that binary. Highly unlikely since there are legal implications for redistributing something that you have not agreed to (depends on license terms). They would be legally involved/liable at that point if you violate the license in some way (for example, reverse engineering).
3.- Wait for the creator of the SDK (Erdas, ESRI, etc) to do this.
4.- Compile it yourself with something like Homebrew.
Personally, knowing this, I usually opt for . In the past, I used Kyngchaos a lot (and still do). Nevertheless, mixing kyngchaos binaries and homebrew can get you in trouble that is hard to debug/fix if you don't know what you are doing.
Update: realized it was not necessary to manually tweak the formula, so I made the steps shorter
Update 2: added explanation about licensing
answered Jan 15, 2013 at 12:03
-
-
@JayLaura what kind of other pain? I have completely replaced all my kyngchaos binaries with homebrew formulas since now you have one for everything Jan 15, 2013 at 15:33
-
if you are running EPD,multiple virtualenv, python installs outside homebrew,64bit wxPython, etc. it can be a pain to get everything setup to communicate properly. It requires some modifications to .bashrc or .bash_profile. Also wouldn't mix homebrew with MacPorts or Fink (in case the poster runs either). +1 as your solution will solve the OP problem. Jan 15, 2013 at 15:52
-
@JayLaura you are right about multiple virtualenv. But outside frameworks can potentially have the same problem :(. Personally, what I do is create a "main" virtualenv that I activate when I do homebrew, so that one gets all the python libraries. When I need to "install" a library there, I soft link the packages that I need to the virtualenv's site-packages. Not ideal because of the extra steps, but works well with pip Jan 15, 2013 at 16:01
-
It is the soft linking that find can be problematic. In virtualenvs where I know I will need multiple relatively static packages (numpy, scipy, pandas) I create with the system site-packages and then override with
pip install xxxyyy=version. Either way works and neither is ideal! Jan 15, 2013 at 16:20