Hi Lansing,
I have put ^ at the beginning of the regex but the same error is
reproduced. I have tested it with the time expression and without it.
<collection
> spec="/data/current/opendap/observational/mooring/weather_station/station_salines-ime_met002/L1/**/^.*_station-salines_ime-met002_L1_#yyyy-MM#.nc$"
> />
> <collection
> spec="/data/current/opendap/observational/mooring/weather_station/station_salines-ime_met002/L1/**/^.*_station-salines_ime-met002_L1_\d{4}-\d{2}.nc$"
> />
Cheers,
Kristian
On 23 May 2013 17:49, Lansing Madry <madry@xxxxxxxxxxxxxxxx> wrote:
> Hi Kristian,
>
> I'll pull down your zip and try to reproduce what you're seeing locally.
> In the meantime, could you try putting a ^ at the beginning of your regex?
> I'm not sure what effect (if any) a wildcard has if it's the first thing in
> the regex, but it's often worthwhile to anchor the beginning and ending of
> the pattern.
>
> Regards,
> Lansing Madry
> Unidata
> Boulder, Colorado
>
>
> On 5/23/2013 2:23 AM, Kristian Sebastián wrote:
>
> Hi,
>
> We are testing to define the collection spec file name with a regular
> expression and time expression #yyyy-MM# at the same time. The THREDDS
> catalog throws and HTTP 404 error but the thredds.inventory.
> MFileCollectionManage found 20 dataset:
>
>> [2013-05-23T09:13:17.318+0200] INFO
>> thredds.inventory.MFileCollectionManager: station_salines-ime_met002_agg :
>> was scanned
>> MCollection{name='/data/current/opendap/observational/mooring/weather_station/station_salines-ime_met002/L1',
>> dirName='/data/current/opendap/observational/mooring/weather_station/station_salines-ime_met002/L1',
>> wantSubdirs=true, ff=WildcardMatchOnPath{wildcard=null
>> regexp=.*_station-salines_ime-met002_L1_........nc$}}
>> [2013-05-23T09:13:17.318+0200] DEBUG
>> thredds.inventory.MFileCollectionManager: station_salines-ime_met002_agg :
>> initial scan found n datasets = 20
>
>
> The collection spec attribute is defined as:
>
>> <collection
>> spec="/data/current/opendap/observational/mooring/weather_station/station_salines-ime_met002/L1/**/.*_station-salines_ime-met002_L1_#yyyy-MM#.nc$"
>> />
>
>
> It works without the regular expression ".*":
>
>> <collection
>> spec="/data/current/opendap/observational/mooring/weather_station/station_salines-ime_met002/L1/**/dep0001_station-salines_ime-met002_L1_#yyyy-MM#.nc$"
>> />
>
>
> Also we have test it without the time expression:
>
>> <collection
>> spec="/data/current/opendap/observational/mooring/weather_station/station_salines-ime_met002/L1/**/.*_station-salines_ime-met002_L1_\d{4}-\d{2}.nc$"
>> />
>
>
> But in this case, the CDM remote subset doesn't identify the "Time
> Range", the Starting and Ending fields are empty, and the "TimeCoverage"
> at the dataset catalog page. We have test the "Time Subset" with a
> working range when the collection spec doesn't have the regular expression
> (2013-04-01T00:00:00Z 2013-05-02T00:00:00Z), but THREDDS throws a HTTP
> Status 500 error. The threddsServlet.log attached hold in the exception
> trace.
>
> Finally we know the regular expressions are not supported in the dirName
> ='/data/current/opendap
> /observational/mooring/weather_station/station_salines-ime_met002/L1'. We
> are very interested in this feature, Are there plans to implement it?
>
> Attached are the zipped file with the example files, the
> featureCollection xml configuration and the threddsServlet.log.
>
> Cheers,
> Kristian
>
> --
>
> Kristian Sebastian Blalid
> SOS Division: Data Center Technical
> Tel: 971439860 - Fax: 971439979
> E-mail: kristian.sebastian@xxxxxxxx
>
>
>
> _______________________________________________
> thredds mailing listthredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
>
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
--
Kristian Sebastian Blalid
SOS Division: Data Center Technical
Tel: 971439860 - Fax: 971439979
E-mail: kristian.sebastian@xxxxxxxx