I think it would be very useful if a geospatial data type was provided that supported points as well as lines and polygons. As @thiago_nascimentodf said, it needs to be a fundamental data type which can then be used built other object types. None of the tools currently available capture geospatial data and require users to use other services to store this information.
Hi, @Oshyan! I don’t believe this specific request should be in the plugins category. Of course it would enable a lot of plugin functionalities, but the request is for a built-in relation type that would allow storage of basic spatial information, just like date, for example.
I have moved it because it’s unlikely to be implemented in core in the near future and may be best handled as a plugin. If the team decides to implement it themselves we can move it back. But we’re in the process of rethinking how this kind of situation should be handled, so stand by.
Update/resolution: API and Plugin discussion will now occur within the Feature Request category. Likely plugin ideas will be tagged as #Plugin-and-Extension-Ideas .
Would it perhaps make sense to have some kind of type safety? That is, right now, if one has a relation to an object, it can be an object of any type, which would be strange for coordinates. If instead, we require locations to be of, say, “Geo Location” type, and then require objects of “Geo Location” type to have lat/long (number) properties, this would perhaps solve this issue. It would be even better if we have custom views for objects that would display “Geo Location” objects simply as pairs of numbers (or, alternatively, a picture of a map for a large view).
I’ve always wanted to raise this as a feature request but it requires a large amount of work. As you said, a Geo Location can be given a custom view but that still can’t be added to any relations as no relation takes a custom object as its value. Which is why, I requested it as an improvement to the already existing Card UI in the following request so that we can have custom cards displaying only the required relations
In order to enable further functionalities for plugins, I guess the important thing is to have a standardized, error-proof (validation on insertion) type. It could be a built-in Relation or a Type.
I think of it in the same way that we actually could create a custom Date type that would have 3 relations (day, month, year) instead of having a built-in Date type. But this would add a complexity burden to the user side and limit the scope of functionalities.
Anyway am surely biased towards it because I work with geolocation information and I tend to think that space is as important as time.
This is the one thing I always found lacking in notion. There are so many practical real-world use case scenarios: photographers tracking the location of photos, estate agents managing their property portfolio, people buying a house, people who journal, planning a trip, making a bucket list, etc. etc. The list goes on!
I can see plenty of use-cases for this. Data can often relate to a specific location, so having location as a Relation-type makes perfect sense.
I can see how it gets complicated quickly: while GPS coordinates are the most accurate, they’re only practical for the mobile version. Having a search query to position an address is probably better, but that would mean relying on the API of an external database, which is probably also the only practical solution for a “Map view” of objects. OpenStreetMap comes to mind.
Then again, if all of this gets complicated, GPS coordinates that open as a link with a mapping service of choice would already be enough to get going.