I do think people are going way overboard with markdown though, and that'll be the new documentation debt. Needs to be relatively high level and pointers, not duplicate details; agents can parse code at scale much faster than humans.

DBH I'm doing for the "size" right now, though I'd love to figure out how to get canopy shape/size as well, and height where possible. (and then maybe proxy height a species level from DBH, since that's more common).

(apologies for belated response)

I think an application that exposes a curated dataset through a SQL-like interface - so the dashboard/analytic query case described here - is where I think this approach has value. You actually don't want to expose raw tables, INFORMATION_SCHEMA, etc - you're offering a dedicated query language on top of a higher level data product offering, and you might as well take the best of SQL and leave the bits you don't need. (You're not offering a database as a service; you're offering data as a service).

Agreed with the ecosystem cons getting much heavier as you move outside the product surface area.

I was thinking of a google maps kind of "here you are, here's your walking path of interesting trees" potentially, or something else that could tie the overview to the street experience - on the backlog!

https://greenmtnboy.github.io/sf_tree_reporting/#/

For all the places it's bad at, AI has been fantastic for making targeted data experiences a lot more accessible to build (see MotherDuck and dives, etc), as long as you can keep the actual data access grounded. Years of tableau/looker have atrophied my creativity a bit, trying to get back to having more fun.