-
Notifications
You must be signed in to change notification settings - Fork 17
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
fix: STAC files should comply to 1.0.0-beta.2 of the specification #1176
Conversation
metadata.bounds.map((a) => Bounds.fromJson(a)).reduce((sum, a) => sum.union(a)), | ||
); | ||
const bbox = [ | ||
sourceProj.boundsToWgs84BoundingBox( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this break with the antimeridian?
is the reason their are multiple bbox's for the antimeridian?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. only one bbox is needed even when AM is crossed; it just means the first longitude will be greater than the second longitude
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Guys, it's best practise to split across the anti-meridian for interoperability reasons with clients. See https://tools.ietf.org/html/rfc7946#section-3.1.9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacott with Jeremy's comment maybe we should split it on the antimeridian? Does the stac spec tell us not to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blacha , @palmerj The GeoJSON RFC does not split bbox
https://tools.ietf.org/html/rfc7946#section-5.2. STAC uses the GeoJSON for items but I defer to others and will split if you think I should.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What Jeremy's link above is for is polygons which we do split.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok thanks. You are correct. As long as we split the footprint geometry then we are ok. Clients querying on the bbox via the STAC API will of course need to normalise their input bboxes
packages/landing/static/json-schema/basemaps-extension/1.0/schema.json
Outdated
Show resolved
Hide resolved
556f2a2
to
c6751d3
Compare
c7df266
to
1d9ce32
Compare
1d9ce32
to
c54161d
Compare
packages/landing/static/json-schema/stac-basemaps-extension/1.0/schema.json
Outdated
Show resolved
Hide resolved
cf432d8
to
ac3c3da
Compare
ac3c3da
to
6c99132
Compare
/** | ||
* Upload all files from the dist directory, including any sub directories, to S3 bucket . | ||
*/ | ||
const uploadDirectory = async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: Why make a function and call it directly after? could you not just execute the function
extent/spatial/bbox
tonumber[][]
description
is always requiredstac_version
to1.0.0-beta.2
projection
extension forcollection.json