Geospatial fields

Hi everyone,

One of the features that almost all work/project management systems miss is the ability to assign geospatial information to tasks or outline location of a project or mark different phases of a project on a map. I think this is because most of these systems are geared towards developers and makers whose work doesn’t really have a direct spatial dimension. However, for anyone who delivers projects or services across a region, this is a must. What is needed is a way to store geometry(geojson perhaps), a widget to draw and manipulate the data and a widget to display it (leaflet perhaps).

I’m not sure how complicated this would be to add, but it would be quite amazing to have.

Many thanks,


Oh and I obviously forgot that it would be great to have a map view as well to compliment all other views.

@anayericov It would be great if you can describe 1-2 cases how you will use it.

1 Like

Sorry for the delay. I was trying to find some good examples.

I think the simplest case would be to have a map view of all the entities represented by points (either geocoded or just encoded as lat/long pairs). Examples I could think of are:

  • Service call locations for a particular day or the last month
  • Project locations
  • Contacts in a CRM application
  • Physical asset management (where assets have a location)

It would be great if you could filter the points and bring up the details of the points. has implemented this as a view which is quite unique among task/project management software.

It would be great if more complicated geospatial data could be attached (points, lines and polygons) to entities. You could use these to represent linear assets (like roads and pipes), paths/routes, boundary objects (like properties, project sites, etc.).

I can provide mock-ups of how this would work in the app I’m working on if that would help.

1 Like

Maybe this will be possible simply using custom fields / formulae, but, it would be neat to be able to also filter by location fields in terms of distance between. For instance, you can use the haversine formula to find nearby points on a globe. If I’m a roving field engineer, then being able to see / pick locations nearest to me, which also have some open problem or task, could be useful.

Yes, being able to do some basic geospatial analysis/filtering (perhaps through turf.js) would really push fibery ahead of other platforms. I think lat/long points as a field type would be relatively painless to add. However, I would strongly advocate for including lines and polygons which then allow for some automation like setting regions for sales or technicians and automatically assigning new customers or service calls to the right users based on if they fall within a polygon.


As a Geo-ICT developer I’d LOVE to see this implemented! :grinning:

I see so many potential applications of geospatial fields and functions!

1 Like

This is interesting. On the one hand lines/polys really seems quite far outside the main goals of Fibery to me. On the other hand they have already implemented some similar-seeming capabilities (and probably have more to add) in Whiteboards. So as far as baseline spatial data manipulation, the foundation may be there. But extending that to actual data interaction, especially with geospatial data, seems complex and probably outside their area of expertise.

I definitely think having a Lat/Long field and a Map view would be nice though! My particular Fibery workspace is for a real estate company, so the use here is obvious. :smile: But I see it useful often enough for other purposes that it could be good to add, at least if it is not too challenging to do.

I should also point out, though, that this may be the kind of thing that would be much better handled in a plugin at some point. At least for the more extended geospatial data manipulation ideas touched on above.

1 Like

I agree with @Oshyan that this seems outside the area of focus for fibery at the moment. However, I am wondering if adding geospatial data type is going to that big of a leap from other data types. I don’t think right now it is necessary to provide any geospatial analysis/query capabilities. But if we at least allow people to collect the information, they would be able to either do the analysis elsewhere or if there is a plugin environment in the future, someone could build those capabilities.

If it possible to add the geometry data types as well as an interface to add/draw these and display them (leaflet seems the most natural fit), then I think that would be plenty for most users.

I am also hoping that along with the data types and display in fibery, a map view is also added to vizydrop as well to make their dash boarding capability more complete.

I’m glad I’m not the only one. @mdubakov if I can help brainstorm ideas or contribute on this, let me know. This is something nobody else is paying attention to, but I think if it is done right can be another differentiator for fibery.


Before I respond more specifically, I’ll just reiterate I am generally in favor of both a geospatial data type/field (lat/long at a minimum) as well as a Map view type for Vizydrop.

I’m sure most of us understand this, but still I did want to say that a collection of differentiators does not necessarily make a compelling and cohesive product for any given market segment in itself. Having a feature no other product in your market has is not necessarily an indicator of beneficial innovation. It is at least as likely to be due to “implementing something that the core market for your product doesn’t actually need” as it is to “getting there first with a key new feature”. So having something be identified as a differentiator is interesting, but it needs to harmonize with other features and overall goals of the application, the markets they are targeting, etc.

In this case I am not really seeing how geospatial-oriented features would help Fibery capture significant market and thus revenue given its current feature set and general orientation as a tool. That said, this is not an outright denial of that possibility. Rather, I am curious to perhaps hear more about what market(s) people think are A: only partially served by Fibery’s existing capabilities and B: would be significantly better served (and likely to adopt Fibery) if geospatial tools were added.

1 Like

I fully agree with the sentiment here and concede being different is probably not the best reason to do something. I don’t want to prolong the discussion, but thought I should put my request in context:

One of the problems that I’ve seen with almost all work management software and services (at least the ones I’ve tried like todoist,, wrike, coda, etc.) that are currently available is that they are primarily geared towards software development, marketing, communication, etc. which often do not have a basis in the real/physical world. That is what makes them very difficult to use for anyone working in fields whose work involves something physical (AEC, real estate, asset and facility management, heritage conservation, governments, etc.). At some point we will need to record information about locations and physical features and that is when you are forced to use a different tool. Examples of this are location of all ongoing projects, available listings, outstanding work orders, boundary of properties, location of all assets you need to manage (e.g. light poles, benches, streets).

I know ESRI’s complete dominance of the geospatial field discourages most companies from even considering entering this area and there are specialized software for all the fields I discussed above. But one of the selling points for fibery is that you can build your own tool and grow your process without having to spend huge amounts on software/system acquisition up front. However, without a way of attaching some of the records to the real world, the tools I am making would be incomplete. I think the investment to support storage and representation of geospatial data is no longer as daunting as it was before with standard libraries and universal database support. I do agree that most companies at this point will not be able to compete with the likes of ESRI on geospatial analysis, so we will have to live with using those tools when the need arises. But for basic level of data, it would be nice to have an all in one tool.

One final thought: if you are considering adding this as a feature, please consider going the full way and adding all geometry types. supports single points (for some reason, insist on geocoding rather than also allowing just inputting/importing coordinates) but that will quickly become a barrier if you need to associate multiple points or a boundary.

I really appreciate the interest in this topic from everyone. If anyone has ideas on other systems that would work well as a workaround for now, I would be very interested to hear about them.


Thanks for the additional detail! So what if we shift, then, to thinking of creative potential ways to address some or all of this need. Here are a couple.

1: This is all based on the idea that there is some need for integration between project/work management and location-correlated data and tools. As you pointed out, for generating and editing the location-specific data, a wide range of dominant tools exist. So it makes me wonder, would it be adequate for your needs and/or a good number of the needs of this kind that you’re aware of, for the data to be added into Fibery and viewable (or “visualizable”, e.g. a map) but not necessarily editable? For example if you could simply upload a .kml created in another tool and Fibery would have appropriate fields to hold that data, and basic map visualizations to display it.

I ask because I’ve worked on a tool that incorporated GIS functions before, and as you probably know well, in order to implement these features well it requires a lot of domain knowledge and attention to detail. From accuracy issues to varying map projections, etc. If one can use a library like GDAL for some of the heavy lifting that’s great, but that in itself is a very “heavy” library to implement even a small part of.

Anyway, in summary, generation and editing of geospatial info beyond simple lat/long is complex. So perhaps simply integrating in some ways with existing tools would be good enough? This could either be through data import/export (aforementioned .kml), or through actual API connections, assuming ESRI or one of the other dominant players has such a thing (I’d imagine they do). This approach would seem to connect more readily with how Fibery is orienting itself, with integrations coming fairly early on (coming soon, in fact), and the recent automations, etc. helping to serve those needs as well.

2: Another thought might be, if Fibery team can identify geospatial as a “premium” profit center, i.e. they can charge more for those features (ESRI’s business would indicate potentially yes), then they could charge an add-on fee or higher overall fee for the “geospatial edition” or whatever, and thus potentially justify the higher complexity of that development and fund it directly through those higher proportional revenues.

1 Like