Feature requests: item.title, breadcrumbs full nav hierarchy, asset actions

[jo-chemla]

Hi there, first of all, pretty impressed with stac-map and how fast things are moving! This is a pretty solid viewer, even for non-technical people, and a great addition in conjunction to STAC-browser. Here are some thoughts after loading our STAC catalog and playing with it for some time:

• In Items list, following a search, it would be useful when available to use item.title rather than item.id, especially when items ids are not meaningful, like uuids. Should happen here, easy PR in case it makes sense like it's done here

• Breadcrumbs navigation is nice to go back to root or parent once one get used to it. It might be more powerful to include the full path from root to currently viewed item. This is less easy to build since STAC item only knows its parent and root, so it could be built recursively, or by passing prop during navigation. Also, would involve some question about ui, visually integrating breadcrumbs possibly larger than sidepanel width.

• We implemented a batch of custom asset actions to stac-browser merged upstream - that we have to update, hopefully by next month - visible here stac-browser/src/actions/assets - so asset types that are not COGs can be viewed in a dedicated, external, web-viewer, for 3d-tiles 3DTilesRendererJS and Cesium), COPC (hobu viewer and potree), pmtiles (official viewer), potree, mesh (via f3d web or threepipe). Do you think it might be useful for stac-map to also support these? Note most can probably be added as link to each stac item, although this would include a repetition like https://threepipe.org/examples/tweakpane-editor?model=ITEM_URL.

• Possible bug although this might be on us: On this stac-map link of one of our stac collection (stac catalog, not stac-search api) (root > projects > project-id > scenes > scene-id > pointclouds), when performing a search for items on collection pointclouds with empty start/end datetimes, it is not the pointcloud item 257607d1 that gets returned but the scene/f67f686c

• Nice-to-have: it would be helpful to have the whole card of the collection being clickable rather than only its title. Also, when performing the Items search, auto-opening the Items panel could be nice.

EDIT:

• I just discovered stac-semantic-search which is integrated within stac-map, looking great to further filter-out items based on params other than bounds/datetime. This might be a substantial effort, but would it be possible in the Search or Filter panels to include an additional folded section, named advanced? This section would expose the properties which can be used to perform the search like on this item properties number properties like gsd, view:azimuth, tile:clouds_percent? Probably harder for free-form STAC properties like platform, but might be doable for standardized STAC extension properties.
• also, some items in our catalog have the same startDateTime and endDatetime, so it would be useful to have less restrictive datetime filtering, using <= & <= here in isItemInDatetimeBounds
• In case this makes sense, I can draft a micro PRs for the items that you deem a right fit.

Details

[gadomski]

@jo-chemla thanks so much for the extensive feedback, and apologies it took me a bit to get back to you. I'm glad you're finding stac-map useful, and I'd love to make changes (where it makes sense) to make it even more so!

I'm currently undergoing a pretty significant rewrite in #249, and am using your feedback to help guide a few of the features. I'd be grateful if you could take a look at the preview (http://ds-preview-stac-map-249.s3-website-us-west-2.amazonaws.com/) and see if it makes sense.

Now for some per-item responses:

In Items list, following a search, it would be useful when available to use item.title rather than item.id, especially when items ids are not meaningful, like uuids.

Done: https://github.com/developmentseed/stac-map/pull/249/changes#diff-f916300f8a4a38d42fb7569b3046c4947b1718df6c7946acacefe771a4752d0cR13

Breadcrumbs navigation is nice to go back to root or parent once one get used to it. It might be more powerful to include the full path from root to currently viewed item.

Done, I think it should behave ok with lots of parents:

asset types that are not COGs can be viewed in a dedicated, external, web-viewer

I'd be open to adding external links to other viewers, yup!

it is not the pointcloud item 257607d1 that gets returned but the scene/f67f686c

stac-map will send this query: https://app.iconem.com/api/stac/search?collections=pointclouds&bbox=5.765773953865022,47.03119329311431,5.783454952010146,47.03554761438224

If that's not what you expect, then I think it's something on your side.

Nice-to-have: it would be helpful to have the whole card of the collection being clickable rather than only its title. Also, when performing the Items search, auto-opening the Items panel could be nice.

Done:

Screen.Recording.2026-01-23.at.2.04.33.PM.mov

This might be a substantial effort, but would it be possible in the Search or Filter panels to include an additional folded section, named advanced?

This would be a nice feature, but would take some work to build well. Can you open this as it's own issue (feature request)?

[jo-chemla]

Thanks for getting back! And no worries for the time it took, I actually find it quite impressive what you did in such a short timeframe!

I'll open a feature request for advanced search/filters. Do you want me to do the same to track progress for actions for external asset viewers/browsers?

I just had a look at the #249 preview, the UI/features redesign helps a lot! A few remarks on the items I mentioned:

• item.title and id, thanks for handling this. We serve both static catalogs/collections as well as the search API on the same endpoints, and it seems that the new stac-map uses the search api rather than the catalog. The fact that we do not expose labels for stac-search api responses yield ids in the ui, that's on us we'll fix this easily.
• Breadcrumbs navigation is great with the whole hierarchy visible, and whole card selectable helps also, thanks
• Is this where you now handle datetime filtering, which is indeed more permissive? Looks like you're now handing it over to duckdb to filter out items? Pretty neat!

  stac-map/src/utils/stac-geoparquet.ts

  Line 77 in 4d6b020

  query += ` WHERE ${startDatetimeColumnName} >= '${start.toISOString()}' AND ${endDatetimeColumnName} <= '${end.toISOString()}'`;

A few new items:

• Filter by viewport: when I zoom on France, it filters out all collections, like Projects, Scenes, when the map viewport is fully within the collection bbox, probably a wrong check of polygon intersection/overlap. I've attached a video screencast below.
• One cannot reset a search, which is useful when updating the viewport.
• The asset properties and item properties were visible, but no more.
• for some BW COG orthophoto, I get error Uncaught (in promise) Error: Unsupported PhotometricInterpretation 1
• I saw the PR also mentions feature request Visualize four-band GeoTIFFs #234 which does look pretty nice. I recently discovered awesome-spectral-indices and mentioned it over t High-level STAC API deck.gl-raster#147 (comment) in case this might be useful!

2026-01-26.-.17-07-35.mp4

[gadomski]

Do you want me to do the same to track progress for actions for external asset viewers/browsers?

Yes please

Filter by viewport: when I zoom on France, it filters out all collections, like Projects, Scenes, when the map viewport is fully within the collection bbox, probably a wrong check of polygon intersection/overlap. I've attached a video screencast below.

If the collection is global, I filter it out when we zoom in becuase otherwise it's never filtered. I've gone back and forth on whether this is correct or not ...

for some BW COG orthophoto, I get error Uncaught (in promise) Error: Unsupported PhotometricInterpretation 1

Yeah, it might be developmentseed/deck.gl-raster#196, deck.gl-raster still has issues with non-simple COGs. I'm working to surface those errors better so it's less mysterious when something doesn't appear.

One cannot reset a search, which is useful when updating the viewport.

Thanks, I'll fix this.

[jo-chemla]

Thanks, just did open the dedicated threads in #259 and #260.

My point-of-view is whatever collection, items, assets that overlaps to some extent my viewport should be visible in the search results when filtering with view bounds, so I can then dig down through. If a collection bbox is the whole world, it should always be displayed when filtering by viewport bounds.

Thanks for adding back item properties, the link to deckgl-raster for non-simple COGs, and really all the fixes you continuously bring.

Regarding a few usability improvements,

• It would be great for the link name to be clickable (probably opening the link in stac-map like the arrow button rather than the external link button)
• foldable section titles (Assets, Links, Properties) could also be clickable to expand their content, actually the whole chakra card title
• Properties could probably be open by default? Or it depends on anyone's use-case, and this could be a user-setting, like mentioned in Control colors and opacity of deck.gl layers #15 probably stored in localStorage.
• Another nice user-setting could be custom tilejson or TMS/XYZ url basemap style, to allow for satellite, OSM or user-provided backgrounds
• the JSON editor could have syntax highlighting, line numbering using chakra-ui CodeBlock rather than Code component with props language={file.language} meta={{ showLineNumbers: true }} probably over here

[jo-chemla]

Not sure it's the new paging system but we just face a new, weird behavior where stac-map for our collections (eg on these links for the scene or parent project, which shows no STAC items, neither the child collections.

It seems that the STAC-search API query /stac/search?collections=uuid prevails over the items (link with rel=items or rel=child), which results in showing all scenes of root rather than showing the children collection (or children collection items)

This might be because our STAC endpoint conforms to search and static collection, which might be an error from our side, as it declares. So either we should remove this conformance declaration block, remove the rel=search links from the response, or have a way in stac-map to choose between dynamic search-api vs static-stac items fetching/parsing.

"conformsTo": [
  "https://api.stacspec.org/v1.0.0-rc.1/item-search",
  "https://api.stacspec.org/v1.0.0-rc.1/core",
  ...
]

[gadomski]

This might be because our STAC endpoint conforms to search and static collection, which might be an error from our side, as it declares. So either we should remove this conformance declaration block, remove the rel=search links from the response, or have a way in stac-map to choose between dynamic search-api vs static-stac items fetching/parsing.

Good catch. I'm trying out "auto-searching", where a collection that has a root endpoint that includes search will automatically fetch the first page on load. You're correct that this doesn't work well with a "searchable" collection that also has "item" links.

There's nothing illegal about being searchable and having item links, from a spec perspective. I like your suggestion to provide a switcher between the two — if we enabled both at the same time, the map representation would get really confusing.

[gadomski]

@jo-chemla I'm going to close this as complete, but if I've missed anything please feel free to re-open or open new issues to track. Really appreciate your feedback and iterations! v1.0.0 is live at https://developmentseed.org/stac-map/, I'll be making wider announcements today/this week.