Saving geo data the WordPress way

[carstingaxion]

Hello!

I'm excited to use your plugin from the very first beginning. I really, really like your approach of staying close to WordPress core and your leverage of what's already there, instead of reinventing the wheel.

Now for a new use-case I have to work with a rigid data-architecture, which incorporates the WordPress Geodata Standard. I would love to allow the users of the system, to enter the relevant geo data using your block, but - you know already - your saving the geo data within the block itself.

The codex says:

WordPress does not include any geographic functionality or functions to deal with Geodata itself [...]. But there is a standard for how to store geodata, so that plugins can interoperate.

Maybe because this is a very old standard within the WordPress world, there are some nice plugins following it, using geodata in a standardized way and helping devs like me combining such tools in new, creative ways.

Can you think of a way to store the relevant bits of the Geodata Standard into post_meta instead?

This would be amazing and will increase the interoperability of your plugin btw. You even found a very nice way to query multiple posts on a map, but this would unfortunately not for work for me out of the block.

[gsarig]

Hi @carstingaxion and thanks for your feedback. I am trying to understand the use case here. If I understand correctly what you suggest, instead of storing the location coordinates on the block level, you would like to store it on a post meta.

In the block's case, though, it doesn't seem right to me, because a post can potentially have multiple map blocks, and the block itself isn't necessarily tied to the post's core content. I mean, you could have a blog post with a few maps in it (for whatever reason) in a similar way that you could have, for example, multiple YouTube embeds. In that case, the post isn't a location itself, to make sense having geolocation metadata on the post level. Besides, having to update the post's post_meta based on the blocks that it contain, can be tricky if you have multiple blocks which can be rearranged, removed, converted to reusable blocks etc. Instead, I could see it making sense in post types which are considered locations, where only one instance of the block would be allowed.

Am I right in my assumptions? It would help if you could give me a specific example of how exactly you would like to use it.

[carstingaxion]

If I understand correctly what you suggest, instead of storing the location coordinates on the block level, you would like to store it on a post meta.

That is almost correct, I‘d like to suggest 4 different post_meta fields, as the WordPress Geodata standard suggests.

In the block's case, though, it doesn't seem right to me, because a post can potentially have multiple map blocks, and the block itself isn't necessarily tied to the post's core content. I mean, you could have a blog post with a few maps in it (for whatever reason) in a similar way that you could have, for example, multiple YouTube embeds. In that case, the post isn't a location itself, to make sense having geolocation metadata on the post level.

Yes I agree. And yes I thought about the case too. There might -for sure- be a necessity to have multiple map blocks with one or multiple locations marked. And I don’t want to change that.

Besides, having to update the post's post_meta based on the blocks that it contain, can be tricky if you have multiple blocks which can be rearranged, removed, converted to reusable blocks etc. Instead, I could see it making sense in post types which are considered locations, where only one instance of the block would be allowed.

post types which are considered locations is very close to what I‘m looking for, but not on the point. It is more or likely news, post_types which hold location-related data. Something happens here, xyz is doing this is and that over there.

Am I right in my assumptions?

You are 97,8% right, yes.

It would help if you could give me a specific example of how exactly you would like to use it.

My use-case contains two types of websites, one for theatre artists, and one for NGOs representing those artists. Both websites are connected and share some content.

On the one hand side the artists create news about their work showcasing next events, insights from their workshop or rehearsals.

On the other hand side we have the NGOs consuming the artists’ news and showing them on their websites. Something like Have a look what our artists are doing (and where).

In terms of geo-data, this means the following:

An artist is doing her or his work in a kind of a workshop. In Germany this location data needs to be public in an imprint. So I have the first set of geo-data. This is saved as option and will be the default set of geo-data for all newly created posts. So until now, we have every post on the artists website being semantically geo-located.

Should also be possible for the artist to write some news and manually set the location-data, by utilising your block.

Also when uploading images with gps coordinates, if used as featured-image of a post, the image would dictate the geo-location of that post and overwrite the given default.

Now when the artist publishes her or his upcoming events, those will come with location data by definition. Leaving the existence of online events for now. In this case it’s the event-management system that has and saves the data, but it could also be your block doing the job. In terms of UI.

Now with all this in place the artist herself AND the NGO can now embed maps to accompany e.g. archive pages, like post_type archives or taxonomy term archives. This prevents the need to query by the location-meta, which I’d like to prevent.

To come back to your concerns about the block(s) itself. You were also right in this point: Such a block needs to be disallowed for reusing and multiple usage, which I think we can do with ´block.json´. I think there is also some core way to get to know, when the last instance of a block gets deleted, but I can’t remember the syntax.

Indeed I as a developer have to take care, that all these implementations follow the same rules, but thanks to the open web and its standards, I can rely on the WordPress Geodata Standard. Hopefully you can come along and join the party!

[carstingaxion]

And as a last addition: I can think of a kind of a block-variation here. The variation could be tied to post_meta and should not be able to handle multiple markers.

[gsarig]

So, I guess that this functionality would make sense in posts which would need to be identified, one way or another, as entities with a physical location, whether it would be a venue, a city, a building or whatever. The Block Editor (Gutenberg) isn't always the ideal way to register information that way, because of the issues that we already discussed (multiple blocks in a single page etc).

Besides, if used that way, it isn't necessary that a map should even be displayed on the frontend. You might need to set the location, but only to use the data somewhere else (e.g. on an archive, on the homepage or somewhere else).

Also, the whole idea of adding multiple locations on the same map, which is a key feature of the block, doesn't apply here. A post can only have a single set of coordinates, not multiple ones.

I do get your point, though, and out of the top of my head I could think of a few different ways to extend the plugin:

1. Add an option to the block level, like "Store this block's data to the post's post_meta". On that case, this option should only appear once on every block of a page, so if we had more than one, only the first instance would display the option. With that option enabled, many of the plugin's features should be deactivated: You shouldn't be able to draw shapes or add multiple markers, and you would only be able to drop a single marker to the map. An additional option to not render the block on the frontend might be useful as well.
2. Add an option to the plugin's global settings, to limit the times that you can insert the block to a post. That way, you could only add the block once per post, no matter what, and the same restrictions mentioned before should apply.
3. Investigate the possibility of having the block's functionality implemented as a Side Panel, which would function on the post level, independently of the block editor. That would probably be ideal, but I'm not sure how easy it is to implement, or if it's even possible.

I haven't given much thought on the above, so there might be things that I miss and side-effects that I can't predict yet, but it sounds like something worth investigating.

[gsarig]

This has been implemented on the latest release. To see exactly how it works, you can read the version 2.8.0 release notes.