subclassData._products[p]['latency'] cannot be inf

[ircwaves]

https://github.com/Applied-GeoSolutions/gips/blob/60927408cf0ef41abc9147d9c0e2a68dbba909f8/gips/data/landsat/landsat.py#L648-L652

That makes for a blowout (below) on the dhscratch branch (which is datahandler with dev merged in). At the moment, I think the simplest fix is to remove this line completely. A better fix involving supporting floating point latencies (which is reasonable) and using inf as a guard for things that cannot be fetched may make sense.

{'asset': "['SR']",
 'band': 'landmask',
 'band_number': 0,
 'description': 'Land mask from LC8SR',
 'driver': 'landsat',
 'latency': inf,
 'product': 'landmask',
 'start_date': datetime.datetime(2013, 4, 1, 0, 0),
 'units': 'unitless'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/gips/scripts/config.py", line 66, in create_data_variables
    name=name, defaults=dv
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 488, in update_or_create
    obj, created = self._create_object_from_params(lookup, params)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 503, in _create_object_from_params
    obj = self.create(**params)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 399, in create
    obj.save(force_insert=True, using=self.db)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py", line 796, in save
    force_update=force_update, update_fields=update_fields)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py", line 824, in save_base
    updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py", line 908, in _save_table
    result = self._do_insert(cls._base_manager, using, fields, update_pk, raw)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py", line 947, in _do_insert
    using=using, raw=raw)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 1043, in _insert
    return query.get_compiler(using=using).execute_sql(return_id)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py", line 1053, in execute_sql
    for sql, params in self.as_sql():
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py", line 1006, in as_sql
    for obj in self.query.objs
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py", line 945, in prepare_value
    value = field.get_db_prep_save(value, connection=self.connection)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/fields/__init__.py", line 755, in get_db_prep_save
    prepared=False)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/fields/__init__.py", line 747, in get_db_prep_value
    value = self.get_prep_value(value)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/fields/__init__.py", line 1832, in get_prep_value
    return int(value)
OverflowError: cannot convert float infinity to integer

[bhbraswell]

What's the actual purpose of the inf? Just to allow any amount of latency? If so you could base it on the start date of the asset.

[ircwaves]

@naterubin -- I think inf was to make it so that it would never attempt to fetch, due to "not being available yet". Is that right?

[naterubin]

That is correct, small discussion about it here: https://github.com/Applied-GeoSolutions/gips/pull/327

[ircwaves]

Right. I'm inclined to say that non-fetchables should be guarded against by their fetch methods (which landsat does). The 'latency' may imply something about fetching, but actually it doesn't. 'SR' assets have about the same latency as 'C1' assets, they're just not fetchable at the moment. 'DN' is no longer available, so that's a whole other ball of rats. So, I still vote for dropping the block in question.

Other thoughts?