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.
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. monday.com 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.
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.
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. 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.
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.
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, Monday.com, 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. Monday.com 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.
I am using Fibery as a GIS and Geo-ICT Consultant. First, to organize my own work, which also involves many non-geospatial workflows. For this, Fibery is a great tool.
Secondly, I am using it for clients. I invite people to on my Fibery workspace to collaborate on specific projects, or as partners for multiple projects. And the non-geospatial features are all very useful.
But for all of this, having the ability to add geodata (especially vector data: (multi-) points, lines, polygons) would be helpful. I wish to describe a few usecases:
For a Sales CRM it would be very helpful to add the location of the client’s office and plot this on a map. As a starting entrepreneur, I plan to network a lot and having an overview of where my (potential) clients are could help me make decisions.
Event planning: having a map of an event could be useful. For example, I have ideas to make tools to organize sporting events. Fibery could fulfil this use case if you can make a map of where everything around the event is (volunteers, first aid, start, finish, etc).
Asset management: knowing where things are that you manage is useful, it’s hard to manage things that you lose
Those are my main use cases, in that order.
Some ideas on how to do this:
Using GeoJSON for a geospatial field and Leaflet/OpenLayers/MapLibre would work for my use cases. A puzzle is on how to do the visualization. And it would be nice if you can add layers from other sources to the map (WMS/WFS/WMTS/etc). I could elaborate on this if anyone is interested.
That is all for now. Curious what you all think (and I will read the previous posts and will respond to that as well)
While geo functions are interesting, I continue to feel they’re pretty niche as far as Fibery’s market is concerned. Which is a little ironic since I work in real estate so I’m one of the people that might benefit a little from it. But I think that may be also partly what informs my opinion that it should be low/no priority for the Fibery team. None of the use-cases you describe seem that compelling to me given the convenience of other options we already have. I’ll go case-by-case with your examples to explore a bit and then get to my proposed alternative(s) as far as Fibery functionality is concerned.
Sales CRM: Does the map truly serve a functional purpose here that helps you “network a lot” with your clients? For seeing their (individual) locations on a map you can just right-click on a selected address and do a Google search and have a map extremely quickly. Of course if you really do want to see all their locations on a map together, it would help to have a map that could pull location info from Fibery. But for this specific situation it feels like there are probably workarounds via Integromat/Zapier or another integration that would do pretty well and not require a whole new type of data, new types of views (maps), etc. in Fibery.
Event planning: I feel like this one is simple. Obviously you could do it outside Fibery, but I get that there may be value in having the Entity specifically associated with a position/location on a map of the event. However… I am a bit skeptical that actual geodata is at all necessary (or would even be useful) for this, depending on the size of the event. What I would do is just get a static image of a map of the area (could even be hand-drawn and scanned!), however large/small, and use that as a background of a Whiteboard and then you can easily add your Entity links, position them (or arrows to them) to show location, etc. What is much less obvious to me is any particular value from having the specific geocoordinates of these positions, and what you would do with that info in Fibery.
Asset management: again, why is the map - the specific geo coords - useful in itself beyond just having an address or location name or whatever that tells you where the asset is? You could, for example, have 15 business locations, each one a Fibery Entity, and each Asset has a relationship with the Business Entity Type, so then you get a list of what Assets are at each Location. I don’t really see a major value in having a map associated with this, nor even specific geodata (e.g. lat/long, etc.), but I’m interested to hear if there are use-cases or situations I’m not thinking of.
The common theme in my above approach is to take the simplest route, to focus on the end result capabilities (finding something on a map of an event, knowing which assets are in which location, etc.), rather than to be looking at it as “all of these things have position information associated and therefore could be used in a geodata-aware system”. Perhaps there are other examples where a more clear and critical business case can be made to have it integrated in Fibery, or maybe I’ve missed or misunderstood some of the aspects in the examples, so feel free to clarify.
That said, the one major piece of functionality that does suggest itself for most of these (and other) scenarios is the ability to embed arbitrary remote web pages into Fibery, like some other systems can do. This would solve at least some of the need here, I think, especially in combination with e.g. Integromat-driven integration to a mapping system from Fibery data. You could then have data in Fibery, push it out to a remote mapping service, and display the results within Fibery still. And the upcoming Block system would seem to be an ideal way to implement an iFrame, too, rather than having to paste arbitrary code into a page, or from the / menu, potentially making it difficult to edit, maintain, resize, etc. The Blocks seem to harmonize very well with the idea of an iFrame and the tools you’d want to manipulate it…
Bottom line, I’d like to see some of this discussion revolve around consideration of what kinds of more broadly useful/applicable functionality might help serve some of the core needs of this feature request (or at least an 80/20 view of what very few features would have the highest benefit/impact, like e.g. KML support as I mentioned above). It seems unlikely that dedicated geo fields will be added, or at least if they are, then unlikely that any full mapping functionality will be included (due to complexity, the “weight” of libraries to do it, API access and request limit complications, etc.). So if you take that assumption, then what creative workarounds can you imagine, that might suggest new features that the broader core use-cases of Fibery would also benefit from? (iFrame being my particular example)
I would certainly want Fibery to focus on the core aspects that are useful for most clients, not on niche applications. I can find some workarounds (when I do I will share them), interesting to find out what is possible now.
A quick response to the use cases: of course I am a geo-specialist and like all other people from my field, we tend to have a strong inclination to use maps whenever we can
The idea to embed remote web pages would certainly be helpful. Will think of what more broadly useful/applicable functionality might do the trick. I already have some ideas for this, in line with what you share.
I will respond to the rest of your post, I wanted to respond quickly from now on. Will look for some time to ponder your questions and response and experiment with Fibery
The way I have been trying to get around this issue is by building a small mapping tool where you can create a map (including adding some popups and controlling basic styling) and the URL-encode it so that you can save it in a URL field in fibery. It is based on leaflet and the leaflet-geoman library with a few additional tools.
I’ve got some information and details on how to use the tool below in case it is of interest:
I’ve tried to hack together various ways of making the URL as compact as possible, but there is still a limit to how much data can be transmitted this way. The URL is still very long and ugly to store in a URL field in fibery, so I go through an additional step of running it through url shortner.
You can try it if you want at QuickMap and can fork the repo (GitHub - cannibalflea/quickmap) if you would like to play around and improve it (e.g. move the centre/zoom to your area of primary interest). I have to say this was a couple of hours of work here and there and it is probably one of the most poorly-written pieces of code on the internet. I am hoping to clean it up in the future and add some other tools. I also need to add some of the images above to the readme to make using it easier.
I was initially going to save the GeoJSON in fibery in a rich-text field and maybe just pass an ID to the tool and have it query fibery for GeoJSON data. But the text fields can’t properly format the JSON and there is no validation, etc. not to mention how ugly it looks. The rich-text fields also are more particular in terms of access through the API, so I thought it makes more sense to do it this way for now.
This approach only allows you to visualize content on a map but doesn’t really help with any type of spatial analysis. It is also possible to build a small app with its own backend database so that you can save content and link it to fibery entities so that you are not storing any spatial data in fibery. This also allows you to do some spatial analysis (e.g. using turf.js) as well as consume other layers, etc. However, this again takes you away from a single tool to manage your data. It also means hosting some things and managing the various pieces. I don’t know if the fibery team or community have other suggestions to make this easier.
As @Oshyan said, I am looking forward to possibility of being able to build custom blocks and extensions for fibery. However, one of the things we may need to have natively in fibery is a JSON data/field type so that other extensions can be used on top of it.
Wow, bad code or not, this is fairly impressive and cool for a few hours of work. I realize Leaflet, etc. provides a lot of functionality, but still.
Thinking along here, let’s say you do the work of creating a little app with its own DB, as you say, and make it reusable for any project with similar baseline data (i.e. using common data definitions, types, etc. for geo type work). If you could link this data to Fibery via the API, and then embed the editor/app in Fibery interactively, would it really be a problem then that it was not “integrated” per se? That it is not, as you put it, “a single tool to manage your data”. If so, what are the primary issues/challenges of it that would ideally be solved?
I’m actually unclear on the plans for making custom blocks and other extensions possible (would love to hear clarification from @mdubakov ), but I think a JSON field type is an interesting and possibly very good feature request. Consider breaking it out into its own feature request topic.
@cannibalflea - Wow that is really impressive!! Lovely!! And will use it and let you know when I have found a nice application for it!
Having a JSON field would be useful, I agree with your suggestion as I see many applications (as @Oshyan mentioned it’s good to have more broadly useful/appicable functionality and I think this would work. I think in combination with other functionalities (like embeddable maps as Oshyan mentions) this could be pretty powerful… will think more about this! I think we really are getting somewhere… thanks guys for your smartness I love it!
@Chr1sG - Ooooeh I will try pressing this Alt key, wonder what will happen… secret functions? Easter eggs?
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.
But I think that may be also partly what informs my opinion that it should be low/no priority for the Fibery team. None of the use-cases you describe seem that compelling to me given the convenience of other options we already have. I’ll go case-by-case with your examples to explore a bit and then get to my proposed alternative(s) as far as Fibery functionality is concerned.
Well now… that’s very interesting indeed.
Lovely!! And will use it and let you know when I have found a nice application for it!
I think we really are getting somewhere… thanks guys for your smartness I love it!