Feature Request - Expose raw location details & places API

[cdloh]

Love the plugin. I was hoping to use it to gather further location data and details programatically for when I add notes via QuickAdd

Something along these lines

await app.plugins.plugins["obsidian-map-view"].suggestor.searcher.search("search query")

To get raw query data I was thinking of updating the search function to allow setting getting the data back raw. Or it might be better to instead create a different function/API that just exposes the responses from the search APIs?

await app.plugins.plugins["obsidian-map-view"].suggestor.searcher.search("search query", null, true)

I also wanted to expose another function to get Google Places details API data.

I've created a POC branch (largely untested) just to explain a bit of what I'm aiming for. Can see it here - https://github.com/cdloh/obsidian-map-view/pull/1/files

Is this something you'd be willing to accept as an MR to the plugin?

[esm7]

That's a great direction. I'd love to get a MR for this functionality, with one request. In order for it to not break easily upon regular code changes in the plugin, I think it would be beneficial to explicitly define an API interface, e.g. a MappingApi class that is part of the plugin and exposes various functions like geosearch and pretty much anything else users may want. If we don't do that, I have no way to know that someone uses the suggestor field outside the Map View code base and any plugin update that changes how this mechanism works may break your code.

[cdloh]

Great! That sounds sane.

Given the API I imagine will be attempted to be rather stable is it worth only exposing fairly low level stuff whos structure won't change.

ie searchResults and transform functions? Rather then the geosearch functions directly?

[esm7]

Exactly, I imagine such an API would have a search method that receives a query (and whatever other parameters you may want to pass), and internally it would call the internal Map View structures, rather than expose an existing object directly. This way it can be kept stable even when internal structures change. If someone changes searcher.search into something else, and doesn't fix the API, it will be a build error.