obsidian-map-view icon indicating copy to clipboard operation
obsidian-map-view copied to clipboard

Request - More complex location formats

Open gentlegiantJGC opened this issue 3 years ago • 11 comments

It would be great to be able to specify polygons rather than individual points in some cases to specify an area rather than just a point.

gentlegiantJGC avatar Feb 05 '22 10:02 gentlegiantJGC

I have been working towards implementing this myself. My plan is to implement support for the geoJSON format embedded in the file (and perhaps in the front matter). This seems to make the most sense since it requires the least amount of work and does not introduce a new propitiatory format.

I have so far been working through all the code to understand what it does and where I would need to implement the logic. I have been commenting and adding docstings in order to make it easier to understand.

I think I am close to implementing geoJSON alongside your location system.

Just wondering if you have any thoughts on the embedded format.

my current plan is geoJSON:{} and geoJSON:[] where the array or object at the end is the geoJSON data.

I think tags would be put in like this geoJSON:tag1:tag2:{} and geoJSON:tag1:tag2:[]

gentlegiantJGC avatar Feb 13 '22 20:02 gentlegiantJGC

Hey,

Thanks for the cool suggestion and thanks even more for picking it up :sunglasses:

First, please note that last week I finished some massive refactoring of the plugin (to allow better state encapsulation together with the introduction of a "presets" functionality). I didn't push it because I didn't yet get to update the README, screenshots etc, but I think it's important that you merge with the updated version, so I'll do my best to push it today or tomorrow, even if to a side branch.

Second, regarding the syntax, I understand why your plan makes sense when the geoJSON is in the front matter. But when it's in the content of the note, it might be better to use a standard Markdown code block that starts with ```geojson . At least when it is inside the content of the note, it might be better to support tags within the geoJSON as a "tags": ... key. Note that in this case, I think it's also important to require the locations key in the front matter, so Map View won't need to parse all notes to search for embedded geoJSONs.

esm7 avatar Feb 14 '22 05:02 esm7

Okay. That might make it interesting to merge since I have also changed quite a bit.

Tags in the JSON data would only work if the root type is an object but geoJSON can also be an array. I thought the geoJSON spec said not to extend the format but it does allow arbitrary keys https://datatracker.ietf.org/doc/html/rfc7946#section-6.1

I was planning to require the key in the front matter to enable embedded data.

Can I request that we move front matter keys under a single key. Adding more keys to the root will get cluttered and may cause conflicts with other plugins. I think geoJSON can just be in the root since that is a standard and other plugins can share that. I think all other keys related to this plugin should be under a key like map_data (obviously keeping support for the location and locations keys in the root) The inline behaviour could be triggered either by the presence of the map_data key or perhaps an inline key under map_data

gentlegiantJGC avatar Feb 14 '22 10:02 gentlegiantJGC

In order to implement this there are a number of things that must be implemented first. I previously implemented these as one pull request but the changes became too large to merge. I will open a feature request for each required component and link back to here.

gentlegiantJGC avatar Jul 18 '22 09:07 gentlegiantJGC