Red is the original footprint, Blue is calculated
.but it depends on the inaccuracies of the original footprint….maybe your original footprint is underrpresenting the area.
@schwehr hmm, I don’t think I have the scene IDs anymore, just the gifs.
In hindsight that would have been useful to use to name the gif
In hindsight that would have been useful to use to name the gif
Any anyone attend prior years?
Hi all! Let me introduce myself. It is Javier Márquez. I work at Geomni, a business unit of Verisk Analytics Inc. as software engineering lead, mainly in the area of online GIS products. The company has been working in the area of spatial information and standards for many years. Our variety of data, both raster and vector, is really noticeable. Now we're analysing latest specs, mainly the new OGC API and, of course, the STAC recommendations for searching and discovery. We really think that this could help us a lot to improve the interoperability of all stakeholders involved in our market. As immediate action items, we're just knowing deeply all the work done by STAC, current challenges and considering ways to collaborate in the future. All help and guidance in all of this would be truly appreciated.
It should be aligned with stac 1.0.0-rc2
You can change the stac catalog url from homepage (it embeds the stacindex.org catalogs index)
Or programmatically from url e.g. https://rocket.snapplanet.io/home?u=https:%2F%2Fearth-search.aws.element84.com%2Fv0
Tips #1 - a long click on the map performs a reverse location and display the country/state/region
Tips #2 - you can drag&drop KML/geojson/shapefile or STAC url directly on the map to add new layers / change the STAC catalog endpoint
Tips #3 - to browse the current stac catalog on the map screen, click on the layer button (center left on the map) then click on the information "i" button on the corresponding catalog layer
Feedback appreciate !
Astrea EOD gives invalid catalog in Rocket. Do you know why that is? @jjrom
Ok found the issue for Astrea EOD - in https://stacindex.org/api/catalogs, look at the url for astrea catalog is prefixed with a space character. This broke my reader :) I just update the client so it handles that.
@m-mohr The format of bbox is unclear from the specification. The astrea implementation waits for a comma separated delimiter string (i.e. lon1,lat1,lon2,lat2) while the Element84 implementation waits for an array i.e. ([lon1,lat1,lon2,lat2])
From the specification it is unclear what is the right format...so i choose the one with brackets
We should clarify that in the API specification
In the OGC API Features examples, the bbox without brackets is the right way. I will modify rocket accordingly. Does it make sense ?
Hi all. I am creating a tool to upload some historic aerial imageries with the STAC format. There are a lot of fields that are specific to historic imagery like film, film_sequence_number, whether the imagery is black & white or RGB, physical_film_condition, etc. There are also some specific to aerial imageries like altitude, nominal_focal_length, photocentre_latitude, photocentre_longitude, etc. What is the best way to put these data in the Properties Object?
@Ben-Cheng - that's awesome! So the simplest thing you can do is just add those as custom fields, and ideally put them in a schema, with your own prefix. But given your description it'd be great if you wanted to put them into 2 extensions (aerial & historic imagery), that you could contribute as a STAC extension - https://github.com/radiantearth/stac-spec/tree/master/extensions
This would enable others to align on the same field names. We have talked a few times about aerial, and that would be a great one to have, but no one has gotten to write it up (and none of the core STAC team knows aerial well enough to do it ourselves). And historic images would be great too.
If you want to try to make pull requests and contribute directly to the spec that'd be awesome. But I'd love to see both of those, so if you just made a couple issues that wrote up all the fields and what they are used for I'd be happy to help draft the actual extensions.
@cholmes Thanks for the feedback!
Quick piece of background, we are in the process of creating a backup archive of about 110TB of historical aerial imagery and we are looking to store STAC metadata with it.
So I think for now we are looking to start using STAC internally until we can use it in anger for a bit to make sure it meets our needs then we could look at contributing it back as a STAC extension, Even if we have to go and remap all our fields we only have about 1M files so shouldn't take too long!
We will clean up some of our internal docs on what fields we have and where we are planning on storing them.
Another question: namespaces, Land Information New Zealand (LINZ) does a lot more than just historical imagery, we are thinking that our linz: namespace might get quite polluted do you have any thoughts about subname spaces
Some possibilities we are thinking of linz_aerial: linz:aerial or even sub sub namespaces linz:imagery:aerial
I had not thought about sub names. But I think linz_aerial: or linz_imagery_aerial: would make the most sense to me - keep the ':' to separate the prefix from the main thing. Though prefixes are just a convention.
You also could just use aerial: directly for the ones you think will have wider applicability. Then you wouldn't have to change them if it evolved to a STAC extension. You just have some risk if someone else contributes an extension with same prefix but different semantics (but can mitigate that risk by just paying attention to the community and reaching out to align when someone does).