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

gips.inventory.DataInventory.inventory with tile list only #32

Open
ircwaves opened this issue Apr 28, 2015 · 1 comment
Open

gips.inventory.DataInventory.inventory with tile list only #32

ircwaves opened this issue Apr 28, 2015 · 1 comment
Assignees

Comments

@ircwaves
Copy link
Member

Based on this block (from here):

    spatial = SpatialExtent.factory(cls, site=site, key=key, where=where, tiles=tiles, pcov=pcov, ptile=ptile)
    temporal = TemporalExtent(dates, days)
    return DataInventory(cls, spatial[0], temporal, **kwargs)

Previously we were able to (I believe) inventory via tiles and dates (i.e. without a shapefile). The above results in only inventorying the data for the first tile. This seems like a bug.

I see that gips.core.SpatialExtent.factory returns a list of SpatialExtent objects, always. Seems like DataInventory.__init__ should handle (or always expect) the spatial extent being a list of SpatialExtent objects; OR SpatialExtent should internally keep track of the list of extents, and thus factory would return one SpatialExtent. I'm aesthetically drawn to the latter, but architectural constraints might necessitate the former.

What do you think, Matt?

@ircwaves ircwaves changed the title gips.inventory.DataInventory.inventory with tile list only gips.inventory.DataInventory.inventory with tile list only Apr 28, 2015
@matthewhanson
Copy link
Member

Ah yes, that was a work around to maintain the old behavior.

Think of it this way, if SpatialExtent were itself a collection of extents, then those individual extents should also be their own object. That would make SpatialExtent a container object, which really should contain other objects, otherwise your object is doing a lot of extra stuff.

Now, if a collection of spatial extents might have their own unique properties all together, then one might consider a new SpatialExtents object, that might have it's own functions in addition to normal list functions but I'm not sure what those would be.

Really the issue here is that any particular dataset .inventory function should actually return a list of DataInventories, because the input can now be 1+ geometries rather than 1.

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

No branches or pull requests

2 participants