-
Notifications
You must be signed in to change notification settings - Fork 51
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
Only support pystac? #223
Comments
Agreed, people are mostly using pystac / pystac-client these days.
I think we've tracked down most of the performance issues around pystac, relative to plain lists / dicts. There's still a bit of overhead though, so up to you on how much of a headache supporting those types is.
…________________________________
From: Gabe Joseph ***@***.***>
Sent: Tuesday, September 19, 2023 2:02 PM
To: gjoseph92/stackstac ***@***.***>
Cc: Mention ***@***.***>; Subscribed ***@***.***>
Subject: [gjoseph92/stackstac] Only support pystac? (Issue #223)
Currently, stackstac supports sat-stac<https://github.com/sat-utils/sat-stac>, pystac<https://github.com/stac-utils/pystac>, and plain lists/dicts in STAC format. My impression is that the community has consolidated around pystac and pystac-client, and sat-stac is not used much anymore. For maintenance, just supporting pystac might make things simpler.
Any thoughts on:
1. Dropping support for sat-stac
2. Dropping support for plain Python lists/dicts in STAC format
There's really no urgency to this. I just happened to notice we're still using get_all_tiems() with pystac, which is now deprecated, and thought some of this might be slightly easier to maintain if we weren't supporting as many possible input types.
https://github.com/gjoseph92/stackstac/blob/30e7c5bc6f4f8bb717decb616f3ad25b506e08fe/stackstac/stac_types.py#L187-L188
cc @TomAugspurger<https://github.com/TomAugspurger> @matthewhanson<https://github.com/matthewhanson>
—
Reply to this email directly, view it on GitHub<#223> or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKAOIUVU44VKEQLC5PVJZDX3HT53BFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJLJONZXKZNENZQW2ZNLORUHEZLBMRPXI6LQMWBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTLDTOVRGUZLDORPXI6LQMWSUS43TOVS2M5DPOBUWG44SQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKJTGQ2TAMBUG43DBAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDCOJQGM2TMOBZHA42O5DSNFTWOZLSUZRXEZLBORSQ>.
You are receiving this email because you were mentioned.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, stackstac supports sat-stac, pystac, and plain lists/dicts in STAC format. My impression is that the community has consolidated around pystac and pystac-client, and sat-stac is not used much anymore. For maintenance, just supporting pystac might make things simpler.
Any thoughts on:
There's really no urgency to this. I just happened to notice we're still using
get_all_tiems()
with pystac, which is now deprecated, and thought some of this might be slightly easier to maintain if we weren't supporting as many possible input types.stackstac/stackstac/stac_types.py
Lines 187 to 188 in 30e7c5b
cc @TomAugspurger @matthewhanson
The text was updated successfully, but these errors were encountered: