Is your feature request related to a problem? Please describe.
na
Describe the solution you’d like
To have a new type of relation which would require a pair of signed float numbers. This would represent a point’s latitude and longitude values.
Describe alternatives you’ve considered
It could be created as a type. But having a more fundamental, unambiguous and error-proof way of associating objects geographically would open a whole new range of possible use cases and applications.
Additional context
It should always assume that the stored coordinates are in WGS1984 (spatial reference system), which is broadly used and can reference any place on Earth without any further information.
So a location for the Eiffel Tower would look like:
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!
