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

expose array+profile API #89

Closed
j08lue opened this issue Sep 4, 2019 · 4 comments
Closed

expose array+profile API #89

j08lue opened this issue Sep 4, 2019 · 4 comments

Comments

@j08lue
Copy link
Contributor

j08lue commented Sep 4, 2019

I often want to write data from numpy arrays as a cloud-optimized GeoTIFF, together with the usual rasterio profile dictionary (transform, crs, width, height, dtype, etc.). It would be super nice to have a Python API for this.

This would require splitting the large cogeo.cog_translate function into two at least, roughly here:

matrix = vrt_dst.read(window=w, indexes=indexes)

or, if that becomes too complicated, create a separate function for this, like

def cog_write(
    src_data,
    src_profile,
    dst_path,
    nodata=None,
    add_mask=None,
    overview_level=None,
    overview_resampling="nearest",
    web_optimized=False,
    latitude_adjustment=True,
    resampling="nearest",
    in_memory=None,
    config=None,
    quiet=False,
):

What do you think? Would this make sense to add to this package? Or will this package anyways be superseded by the new COG driver in GDAL?

@vincentsarago
Copy link
Member

Hey @j08lue thanks for this issue.

What do you think? Would this make sense to add to this package?

In short term I think this could make thing a bit complex and definitely be a breacking change.

Or will this package anyways be superseded by the new COG driver in GDAL?

This is still to be defined, To be honest I guess most of the feature of rio-cogeo will be replaced by the new GDAL COG driver, but I think there is still one-two feature that won't, but I need to better study the subject.

Back to array to cog, we could maybe to a simple change to allow memory file as input (instead of path). in

with rasterio.open(src_path) as src_dst:

we could maybe to a simple check to see if we have an already open file (memory file) or if we need to open it (like in https://github.com/cogeotiff/rio-tiler/blob/master/rio_tiler/utils.py#L403-L407), thus you could do something like

with MemoryFile() as memfile:
    with memfile.open(** src_profile) as mem:
         mem.write(data)
         cog_translate(mem, *args, **kwargs)

@j08lue
Copy link
Contributor Author

j08lue commented Sep 4, 2019

we could maybe to a simple check to see if we have an already open file (memory file) or if we need to open it

That solution would serve me very well! Should I submit a PR or can you implement this quickly?

Btw, I actually have a working implementation of this API already, but the COGs are not fully valid and I would like to merge into using rio-cogeo instead.

@vincentsarago
Copy link
Member

That solution would serve me very well! Should I submit a PR or can you implement this quickly?

Yes, I will be happy to review it.

Btw, I actually have a working implementation of this API already, but the COGs are not fully valid and I would like to merge into using rio-cogeo instead.

Not sure to understand here

@j08lue
Copy link
Contributor Author

j08lue commented Sep 4, 2019

Not sure to understand here

😄 haha, nevermind. I'll submit a PR shortly.

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