In progress
https://the.fibery.io/@public/Public_Roadmap/Roadmap_Item/Field-Location-154
1 Like
This is exciting 
I wonāt repeat why I think this is an important feature! And I know it is ungrateful to say anything critical when this was totally a no-go previously, but I feel very strongly that the proposed implementation plan is short-sighted.
If I read the feature description correctly, the intent is (1) to limit this to point features and (2) the point features are actually just going to be generated using address reverse lookup through one of the existing geocoding APIs. I feel like this is really a missed opportunity. While this approach will get you to an address and a map view pretty quickly it will really limit what you can accomplish. I think it would be much better to actually spend the effort to develop a geometry data type/field type that can be used for a variety of features, including multiple points in a single field.
If I understood fineryās stack properly, it is built on top of Postgres which offers one of the most solid implementation of geometry types natively and spatial functions through PostGIS. There are also very mature geospatial libraries that provide all the necessary spatial functions that most users will need. So all the ingredients are there to really develop something amazing. And as I said before, fibery doesnāt need to offer spatial analysis or complicated cartography options. The real feature here is having geometry be a fundamental data type.
I know this is a bigger ask and based on what had been said before I know the community doesnāt think there is value here. However, I can tell you that there is currently no geospatial tool that offers the data management capabilities that fibery has and that even the most advanced tools that ESRI offers through AGO, either limit you in how you can structure your non-spatial data or require an amazing amount of coding to get a fraction of the functionality that fibery offers. By the same token none of the data management tools seem to take spatial/geometry data seriously.
One final point: if you are going to go down the root of just supporting one point per field, I would strongly encourage you to at least allow direct lat/long entry without geocoding them again. Most geocoding APIs seem to take coordinates and apply the same nearest POI search and then return a coordinate along with metadata associated with the location. This is not a big issue in urban areas due to the density of addresses/POIs. However, you can end up with huge errors in less developed areas as the nearest POI/address point might be quite a ways away from your original coordinate. So you may input exact coordinates into the system (say in a csv) but when you export the same data your coordinates would be totally different. This is how Monday.comās implementation works and it is really frustrating!
Apologies for the long message. I totally support whatever direction you take but felt I should again make a pitch just in case 
2 Likes
This feedback is really helpful, thanks!
-
We consider Geometry as a separate Field Type. We did discuss it, but so far we donāt see useful cases for our domain. We might consider it in future, but we need to understand the use cases and demand.
-
Point field flaw you mentioned is indeed a problem, we will think how to solve it. Technically it is just UI issue, since Location Field can store just coordinates or augment it with geolocation meta data. We will think how to support both cases it should not be hard.
4 Likes
Iām in the same boat as @cannibalflea. Iām happy to see ANY geospatial abilities coming to Fibery, and I also hope to have simple āmanualā point and geometry abilities at some point in the future as it will fill the huge gap between platforms like ESRI (hardcore cartographic analysis stuff) and all the other platforms of your competitors (like Monday and Clickup with their overly simplistic yet strangely complicated and poor UI/UX mapping systems that allow only the most basic address stuff).
My use case is admittedly not for software product management, but if I was in that space I could DEFINITELY see a use case for tracking sales, customer interaction metrics (such as number of tickets per category) per region with existing defined boundaries (like a country) and even manual geometric boundaries one could draw out themselves/provide lat long bounding points, and entities with a lat long within that boundary can be related as such if desired.
For my actually use personally, Iād use it to visually track my companies facility locations, property boundaries as they change due to add ons, customer job site locations and certain metrics for each, blah blah more non-primary Fibery use case purposes blah blah.
Note that this will be possible, since Location field in Fibery will be complex and with metadata, so you will be able to define at least lookups like Location.Country or Location.City and this have some filter to rely on in reports and views.
1 Like
That is seriously so awesome, there is so much potential with that ability, let alone all the other possibilities. Sky is the limit so it seems, very nice!
The most important thing is that when the user supplies a lat/long coordinate (in the location field textbox or via the map view), a lot of care must be taken if it is going to be parsed through a geocoding endpoint (e.g. google, bing, etc.) since when a coordinate is geocoded like a street address, that is usually when the a nearest point-of-interest returns and the location error is introduced.
You can see this in Googleās reverse geocoding example where the REST call was made with a lat/long pair (40.714224, -73.961452) but the āresultsā have different coordinates (geometry object). So if you were to take the (first) result returned, you have already introduced an error into the underlying data. The level of error is not significant in a dense areas with lots of results, but can become quite significant in less āinterestingā areas.
Note: using the location_type=GEOMETRIC_CENTER parameter seems to reduce the error but I havenāt done that much testing to confirm this.
Apologies if Iām again repeating myself, but this can really make life hard for users who import point coordinates in, but when they export it out to use it with a geospatial tool (like QGIS or ArcPro), they will have completely different geometries.
We are working on Location field. It will be possible to store plain coordinates as well like this:
3 Likes
Location Field usage preview
7 Likes
Amazing! Very excited for map view as well 
1 Like
Released today
NOTE: Map View is in development so far. Will be released next week.
5 Likes
looks like location fields cannot be used in automations as of yet. is this in the pipeline?
