Your company Galdos has been associated with data, data integration and more specifically with spatial data infrastructure. Now, it aims to be a global leader in location-enabled enterprise information management solutions. So is there a shift?
It is the same thing but more focused on the private sector than government. We found that government is not always the easiest customer. I suppose the shift that we are making is from saying, we are a geographic information company particularly focused on open standards to saying we are an enterprise information solutions company where geography counts. I think it is enterprise information solutions where location is important but we don’t identify ourselves as just a geography company. If you have a large organization and have information about physical assets that might be distributed across several departments and you wish to perform analytical operations, then you need to integrate that information readily. In this context, knowing where that information is as important to discriminate one asset from another or for some analysis.
In addition to location data, how do you process contextual data which is not structured?
We can help structure that information. For example, through our registry product classification of things, creating relationships of things, creating logical collections is intrinsic part of the technology, and each of the things can have geometric properties. However, in other cases we also deal with things that have no specific geographic context. So anything related to our solutions can have geographic or geometric properties, whether it is a relationship between objects, objects themselves or the taxonomy. Viewed from the GIS perspective you might say all this information is contextual but viewing from the problem perspective this is the information and geography is just one of the types.
Our focus is enterprise information integration where location is important and we provide strong support for that. However, the information assets may be more important to clients than the geographic aspects of them. Even in SDI much of the information has a spatial aspect to it, but it isn’t just about geography. SDI is about automated synchronization of data on a wide area network and the idea of subscribing to data changes from somebody else’s database doesn’t depend upon spatial.
How well the INdicio suite of products integrates to the business process of an organization be it that the ERP or CRM systems?
INdicio has an open interface but I would say it is a work in progress in terms of integrating with any specific CRM.
Does INdicio enable query visualization and analysis of data?
Yes, it does. You can make query requests based on geography and classification. Basically one of the interesting things about it is that it exposes an information model wherein you can see classifications, objects that have properties and taxonomies. This model is unlike say working in a relational database where you would do a graphical model and then compile it into tables and you have to know those tables in order to query the system. In the case of INdicio, if you create a taxonomy using a graphical tool, then you can query just directly in terms of taxonomy. The visualization is on the client side. If your data has geographic properties, then we have a client that draws maps or draws objects on top of maps, typically based on queries. Queries can also be stored, which is also a feature of the data model.
In one of your recent blogs you said Galdos is embracing the third platform. What is the kind of analogy you are trying to bring in?
The third platform resembles cloud-based services supporting mobile devices. What we have done to make that possible is to provide client libraries for Web service INdicio on standard platforms like iOS and Android. As INdicio is a Web service, it is naturally deployable in a cloud and we have been doing lots of cloud testing. In Canada, we have government-financed cloud called DARE where small companies can get time to get tested. We have done quite a bit of testing INdicio in this cloud. I would say in four to five years wearables will capture the market replacing phones and a rapidly deployable backend service will be needed for such devices to be able to accomplish various tasks. We hope that INdicio can also support those kind of things. And in the context of enterprise applications, we will soon see emergence of wearable devices linked to backend applications. Actually, there is a company in Vancouver that is trying to promote that in the mining sector. So any area where you need information with your hands free, there is going to be a lot of demand for wearable applications.
How do you see this integrating and evolving in the larger concept of Internet of Things?
I’m not sure they are different. Right now we give different names to these things. If you go back to the beginnings of the Internet, it was the Internet of Things. One of the first things to go on the Internet was a Coke machine. Somebody had the idea of ordering a Coke. It was guessed how it would get inside the machine and you can type in your office and type in Coke and Coke was ready. Similarly, in the early days of Internet, there were a whole bunch of devices on the Internet like there was a train set in Germany, that you could control by a switch and watch the train go round. There was a robot garden somewhere in California, where a robot would plant seeds and you could water the garden and come back and watch the seeds grow into plants. And that was a whole community of people that grew up around that. So the Internet of Things is not new. I was in China, 5-6 years ago. Then Wen Jiabao, the Premier of China at that time gave a speech on the Internet of Things and I wrote a blog on it. But to see a Premier of a country talking about Internet of Things was quite surprising to me. I couldn’t imagine the Premier here even now talking about it. He had announced that Internet of Things was going to be the focus of Chinese efforts and they had set up a research centre for Internet of Things. So I think wearables in the sense they are connected, are actually part of Internet of Things. So, I see wearables as a subset of Internet of Things.
You have been a very strong proponent of spatial data infrastructures. What, according to you, is the current state of majority of SDIs and their progress across the globe?
I would say their progress is slow. The reasons are mostly political and organizational. Part of the slowness was because they started in the wrong place. They started essentially with the national mapping agencies. While the national mapping agencies were engaged in doing it, the data that they held wasn’t that important. That is how it began in Canada. The value of Federal Government’s data is not that high as compared to data about the buildings around here and the idea of sharing data in an automatic way in a city as it changes— something that is still relatively non-existent in most parts of the world.
I think getting to a point where we have pan-enterprise sharing of that kind of information seems to me more important than government’s sharing data. We don’t do a good job globally sharing data also longitudinally and in time. So we build a building and the drawings of the building. But those drawings are examined by people who said that is what we built. But that information does not get fed automatically into emergency response systems like fire, police etc so that these departments could use it. You see cities actually remeasuring many things several years after the fact, simply not because they changed but simply because they don’t have that information. So I think infrastructure is to share that kind of information as automatically as possible not only across organizations in time but over time too. The city model idea is not just to produce pretty pictures but to produce usable information on which you make decisions. You get the permission to build a building because you submitted drawings. If you look at the specifications in drawings, they are about human inspection within the drawing. There are not so that a machine could read those drawings and automatically compile it into city models, which could automatically be used by fire departments etc. I think we are still not there in terms of any SDIs that I am aware of. The Delhi SDI goes in that direction but I think unfortunately we are still some distance away.
Even in Delhi SDI, the data has been successfully brought together and integrated but the departments that are involved in bringing in this data, they do not actually know how to utilize that data. So what kind of applications can they develop with data integrating rest of data and create a necessary application?
Obviously the data should begin from the applications and not the other way around. And I think that is also part of our re-orientation that we want to work from the applications people want. Hence, if there is a spatial component, we will support that and if they are not interested in that, that’s fine too. I think that will be true for an SDI too. I used to do a talk about SDI and then strike out the S and kept the D, and use to say that what we are talking about is the information about the physical world. And some of that might be spatial information but some may not. I think it is just matter of time for people to understand that. Now I think everybody is attuned to the idea that the real value of information and the real value in sharing information is either within the enterprise or within cities.
How is the progress with respect to the Canadian CGDI?
I think Canadian CGDI continues to be a national programme and it has been relatively successful in getting the adoption of standards to support that SDI at the provincial level but much less so at the city level. There is definitely less money from the government to do these things. I think when the standards like the GML were relatively new, there was a lot of experimentation by the government. And part of the problem was that people knew that they can share data but were not aware of the applications to use for sharing that data.
During the last five-year plan in Canada, the government gave it a kind of carrot-stick approach. The federal government gave money to a province and if the province would fund a project that was related to certain open standards endorsed by the government. And that was very successful. The stick approach was that this is a national standard and do not develop any other standards—something that was relatively successful. During those five years, I think they gave money to a city once and most of the money exchanged between the provinces and the government. Further, the federal government is supposed to give money to a city is only through a province and not directly. So that is a kind of a problem with CGDI.
In many of the SDIs, we see the challenges are not at the technology level but more at the policy and coordination level. So how was the CGDI placed in that context?
One aspect I already mentioned is the relationship between the province and the government.
Further, we also have in Canada the BNA Act, the British North America Act which is not really a constitution. The British North America Act, when Canada was created, specified what are the responsibilities of the federal government, responsibilities of the provinces. Not all of those divisions of powers are sensible in 20th century but they divide things up and after the problems you face you need to pull things together. That is a good rationale for SDIs in government in general, that the problems that people are dealing with, like a hurricane, doesn’t care that we divide information into twenty different pieces like emergency management, map collection etc. So the need to integrate information to respond to problems is pretty essential, whether it’s a short-term disaster like a hurricane or a long- term disaster like climate change, the problems are there. In the context of Canada, we divided things up between federal and provincial governments and from a problem perspective that doesn’t necessarily makes sense.
For example, the management of fish, if the fish are in the sea then they are managed by the federal government, if the fish are in lakes they are managed by provincial government but we have plagic fish like Salmon which start in lakes and then go into the sea and then come back. If your habitat is destroyed by the provincial regulations, then the fish dies. And here, you hear expressions like Fed fish which is Federal Government fish and there are many things like that. Similarly, roads if they are inside a municipality, then they are the responsibility of municipality. If they are inside a province, then they are the responsibility of the province and if they are national highways they are the responsibility of the federal government and all that has to make sense together. So there have been a couple of projects to produce a uniform road model across the whole country but that still doesn’t exist. But we are close. Environmental issues in general are the responsibility of a province to do anything but regulation is the responsibility of federal government. You can clearly imagine there are conflicts of money, policy and so on between them. The whole thing should be both bottom-up and top-down but that is not always an easy thing to do.
What is the most practicable approach to having SDIs in general and in Canada?
Our perspective on that is we need to support automated distribution of data based on publication subscription. So I can advertise as I got certain data. Whoever you are, you can find out that I advertised it. You can subscribe to it and can add restrictions to make your subscriptions and the data is automatically sent to you whenever it matches your subscriptions. Now there might be charging issues on that. That is our notion of SDI that you can look for these advertisements and find out what kind of data is available and construct the subscription and then data is automatically sent to you. It’s not a question of whether your query is part of the subscription but either all the data is piped into some warehouse or you can search across different databases and have the data when you ask for it. I don’t think this is workable mostly because you don’t want to be doing that all the time. There is a big discussion about open data and the city of Vancouver is one of the proponents along with the province of open data. But open data without some kind of automated subscription mechanism is not that useful because every time data changes in a city, you can’t be querying every 5 seconds to see if that’s the case. You want that information to be kept updated in your database. I guess that’s always going to be a battle.