Add offline Flinn Engdahl support

[fabienengels]

I opened a temporary repository ( https://github.com/fabienengels/python-flinnengdahl ) the time to translate this Perl script ( ftp://hazards.cr.usgs.gov/feregion/fe_1995/feregion.pl ).

It allows to convert coordinates to Flinn-Engdahl region (so do my code). I know this is already a client to query Iris webservice. But I think it can be interesting to have a local solution :

• Doesn't need an Internet access anymore
• First point involved better performance, http can be slow with a bunch of coordinates to convert
• Data doesn't evolved for a while, using webservice doesn't make sense (IMHO)
• Disk space required to store the data is ridiculous (less than 1MB)

The code is working and documented and have unit tests (one unit test who checks the result of 7200 coordinates with a coverage of 100% of FlinnEngdahl class)

But I still have two issues :

• I don't know the licence of data files I used (*.asc files on this ftp ftp://hazards.cr.usgs.gov/feregion/fe_1995)
• I don't know where to move my code in ObsPy modules heirachy (first contribution ... not yet familiar with the project structure)

[barsch]

will increase the filesize a bit - but thats totally fine with me :+1:

concerning your questions:

1. the Perl script states the following:

   #!/usr/local/bin/perl -w
   
   # feregion.pl - returns Flinn-Engdahl Region name from decimal lon,lat values given on command line.
   
   # Version 0.2 - Bob Simpson January, 2003  <simpson@usgs.gov>
   #               With fix supplied by George Randall <ger@geophysics.lanl.gov>  2003-02-03PROGRAMMER: G. J. 

   Did you try to contact them directly?

2. my suggestions would be obspy / core / util - eventually a new folder in there, but import the function in the obspy.core.util.__init__.py

Also please do a pull request once your done so we have a chance to review + comment on things ;)

[megies]

:+1: we can also store the data as .npz (numpy.save(), i'm doing that for noise models in signal.psd.PPSD for example) or .gz similar to keep repo size down. you would need to figure that out before the initial commit of the data file though.

[megies]

and.. you can open the pull request right after your first commit to the new branch you work on. that way we have a nice common place for comments right from the start.

[fabienengels]

@barsch : I'm waiting an answer from them and don't worry for the pull request, it's what I planned (this is THE feature of GitHub :) )

@megies : I'm not sure it'll be useful to compress the data file to reduce the size of the repository, Git already stores its object files using zip compression (as .npz). Data files are in ascii format so I think it's better to commit text files than binary files and that'll only save space for the final users (and could make update of data files a little more difficult). What do you think ?

Just to check if I understood, you advice me :

• create a branch in the main repository and do a pull request from here

than

• fork the project, do my commits in the master branche of the forked repository then do a pull request ?

[megies]

Interesting, I didn't know that. Yeah, it might not be worth the effort than to compress manually (although a gzip isnt too hampering, and not much overhead).

If I was unsure how the thing goes, I would probably go for a new branch in my own fork and do a pull request to obspy's master from there. This way if anything unwanted gets committed (e.g. inadvertently blowing up the repo size) I could just start over without the main repo's history getting cluttered. If it's clear what is going in there I guess you could also start a new branch directly in the main repo. Doesn't matter too much which way, I'd say.

If you do it in your fork, it might be good to add other people as collaborators of your fork so that they can directly work on the pull request by pushing to the branch.