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!
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.
Ideally, I’d like to be able to create a set that is filtered by a radius around a location. Like all the notes I took while at work, or at home, etc. Also, imported photos could have their exif data extracted to populate this relation.
New to all this today so pardon me if I use the wrong terms. But I think this would be a new type that contained lat and long. Obviously, I could do this already, I think, but I’d want them to default to where I am at the moment. I think the messy part would be the filtering. I know there are databases that do this so it’s obviously a solved problem I would hope you could just pull in a library to take care of it.
I suppose I could attach a relation to each object and choose the locations manually… But that isn’t going to be as accurate or easy as geolocation data.
Hopefully this makes sense. I think the benefit is self-explanatory.
Hi, @carl ! I posted a feature request to have a built-in point coordinate relation. It might be a step to achieve what you have proposed: Relation for point coordinates
To have “geolocation” as a new relation type, would allow to use Anytype to integrate data over maps.
HOW COULD IT BE DONE?
This new relation type would be linked to a new “Map View”. Then users would fill fields with latitude and longitude and see the corresponding pins over the map.
REAL WORLD USE CASES
House locations for real estate; see on a map the physical location of the contacts on a CRM database; collections of places for ordinary users (restaurants, hotels, touristic places); Shops lists; Etc.
What if I want to store a position, a geographic location?
I am suggesting to add the Geolocation/Position Property Type.
HOW COULD IT BE DONE?
Adding a Property Type that stores a position either using coordinates or using the geo URI scheme. To add/edit it, a geographic map could pop up when the Property is selected, allowing a person to select a point on it, or to search a location.
Ideally, it would be super cool to have a Graph view alternative that places Objects on a geographical map!
REAL WORLD USE CASES
E.g. I am creating an Object about a place I love. It would be extremely useful to place it on a map.
RECOMMENDED ALTERNATIVES
adding a GeoURL (following the geo URI scheme) as an URL field
Adding a link to the location in OpenStreetMap as an URL field
Having two numeric properties: latitude and longitude
I don’t understand, why create a new FR instead of vote for the existing one?
(newFR that’s likely to be lost at the bottom rather than the existing one with votes)
Full support - Anytype could become quite a bit more useful if it had the notion of a location. It’s something that really is missing.
A location type, that can be interpreted as such, would enable interesting new functionality - just like time has a certain interpretation - days, minutes, hours, tomorrow, yesterday, on that day in the calendar, etc.
see your objects on a map - for example, when planning a trip and related locations
collaborate with others on a map and avoid the Google stack, which fits well in Anytype’s “the user is in control of the data” philosophy. Very few tools do this well today!
