Dr. Nadine Alameh is the CEO of the Open Geospatial Consortium. She lives and breathes open geospatial standards.
Nadine’s always been fascinated by innovation. Her background is in computer engineering and software development. She got into geospatial by chance — she was selected for a scholarship to study this “thing” called GIS at MIT.
She understood the MIT, but not the GIS part.
Who says no to MIT?
She’s spent her career trying to get out of geospatial only to get pulled back deeper, to where she’s now running the Open Geospatial Consortium, a global consortium of 500 plus members.
Geospatial is everywhere, and she’s lived it. She went from NASA and a startup in aviation to a large business like Northrop Grumman. As soon as people know she has geospatial as part of her portfolio, she becomes the connector for people or divisions or projects.
Geospatial standards, like any standard, are what we agree on as a community.
We need standards because we share and integrate data, and we solve complex problems.
Admittedly, standards aren’t exciting for everyone. What’s exciting people are smart cities and connecting billions of IoT devices, and for those, you need standards.
Location is the connector in the concepts that were sci-fi-ish 30 years ago, but now a reality for the younger generation.
Sometimes, you move to a new country and learn a new language, which is a grind.
But what if learning that language is the ultimate form of interoperability and that common way of communicating opens doors to everything?
No, we haven’t.
I’ll give you an example.
In 2018, SpaceX was launched. The FAA cleared 1,300 sq miles of airspace for three hours. Flights were delayed or left circling, burning extra fuel.
The rocket was out of the airspace in just 90 seconds, as reported in the news. The booster came back eight minutes later.
Unhappy passengers, amongst many others, must have wondered why thousands of flights needed to be disrupted, costing money and extra carbon.
Three hours for… eight minutes?
This was only a couple of years ago. The SpaceX systems environment supporting the launch didn’t communicate with air traffic management in the US.
Two separate systems that couldn’t connect and understand the location of a rocket, where it was going, what would happen to the debris if it exploded, and where the potential impact zone was.
The good news is that this kind of disconnection has been solved using standards to exchange location information across systems.
We haven’t made all the standards already because we haven’t solved all the problems yet, and we don’t even know what they might be.
Give you another example. In 2021, we still don’t have a common underground model in the US. If there’s construction down the road on your street and someone digs into a water pipe, you’ll be left without water supply for a couple of days.
Dashboard providers spend most of their time connecting to different data sources in various data formats, different APIs, and random namings. Frequencies of updating are all over the place.
We need standards.
But let’s not talk about age-old problems we haven’t solved yet exclusively.
We also need standards to make way for new stuff.
2021 stuff, like indoor mapping for virtual/augmented reality, geoJSON for drones, and AI for analysis-ready data.
We’ve elevated the layer upon which we need standards. Previously it was mainly about location and the spatial extent and how to query things.
Now it’s about APIs to ensure anybody can use the data for drones or mobile devices. The role of geospatial is abstracting up, and that’s part of the evolution.
We don’t just change the standards and evolve them.
We’re changing and evolvinghow we produce the standards.
Three things have changed to get there.
One is that people finally understand what geospatial people do at scale to the pace of innovation. Things happen fast these days, and we have to keep up.
Two is location. We have stepped up on location.
Three is pace. It’s this urgency because people cannot wait. There’s urgency for action.
We’re slowly moving away from traditional standards development and transitioning to an integrated approach to standards and innovation.
This is upfront saying, “We’re not nestled in a quiet corner with committees writing long documents.”
It’s way more agile. It’s from the ground up — the implementers are with you in the room, so whatever comes to exist is community-engaged already.
Apple recently announced its indoor mapping format (which is an OGC community standard). This is precisely how standards are evolving from the bottom up from the communities in an agile way. They get way more engagement, and they are implementer-friendly.
Even for Apple, Google, Microsoft, or Stack, the pace of development is too fast to keep up with and innovate out of their own little corner.
They’re trying to increase the size of the whole pie to increase their share, and for that, they need partnerships of communities.
These companies aren’t interested in the format itself. Their interests are in the market and what their users will use — iPhones to navigate the malls, airports, or warehouses.
Nobody can do it alone, and that’s part of the dynamics of innovation.
The real value is in increasing the size of the network and the value it can generate.
How many maps are Google maps looking at in the background…? Even Google needs other people’s data — so many data sources to integrate several times a day on a massive scale.
Both, and it depends on the community.
With Apple’s new release, they’ve done it as an OGC community standard. The community will decide if this new thing can be used and if they want to take it wider:
Can people integrate it with other geospatial standards? Can they take and run with it, so it becomes a portfolio within a suite of standards?
“I’ve developed a new, ground-breaking idea for data storage that’s unheard of. I want to make it a standard. How do I do that?”
Congratulations. We love hearing from people like you.
Hopefully, you didn’t just lock yourself in a room and come up with something so new that no one’s ever heard of it. That would be a shame because it would be hard to test it, get feedback, or get the community excited about it.
Your idea should not only be great, but relevant and easy to adapt, so you don’t spend your time and come up with something nobody’s interested in.
The next step is the operational adaptation. Suppose your great idea has already been tested, and you want to make it a standard because you want to grow the pie for everyone.
International ratification of your work is a big deal. ISO, a partner of OGC, has been blessing standards for decades because governments and organizations rely on them.
By standardizing something, you bring it to the community to ratify it. You include it in a larger suite of the ecosystem of standards.
So the path is experimentation, acknowledgment by the expert community, ratification, and adoption.
The timelines are significantly shorter today than what they used to be.
OGC is launching brand new OGC APIs. For a brand new standard, in the past, based on my aviation experience, it would take five to 10 years to come to existence.
And that was really fast.
In our OGC APIs case, we’re likely to finish the entire suite in two years — including testing, prototyping, projects completed around them, multiple implementations, a compliance test, and the documentation.
Ready in two years for a suite of standards — definitely unheard of for a brand new standard.
As my second example, with a community standard, it would depend on the maturity of that community standard.
Sometimes you come in, and your idea makes perfect sense to people — the gap the community has been hungry for is crystal clear.
You don’t have to convince anybody, and within six to nine months, it could be out there, provided you’ve done two or three implementations and proved it works, and nobody objects to it.
If you pick some “obscure” thing you want to standardize, and I’m calling it that with the utmost respect because obscure doesn’t mean irrelevant at all. You’ll have to do the heavy lifting on that.
Maybe you’re working on something that’ll replace an old standard, an existing piece of the standard puzzle, or it’s simply a difficult concept to convince the community of. Besides the technical development, you face an additional step, which is a human part, and showing results may take longer.
Machines are the only way we can handle the influx of data coming at us. We’ve got to automate things. Most standards spring from this automation and the need for analytics-ready data.
Take Earth Observation data — you need to abstract, and you can’t do it without automation.
Data? Storing data? Description of geometries? Any of these, or all of these?
It’s all of those and more.
Let's look at APIs, which are a good example because they’re fresh on everybody’s minds. They’re the building blocks for location, and they’re non-geospatial.
Sharing maps and the tiles and streaming 3D data are geospatial standards. Annotating your AI data sets or your training data sets so that other scientists can use them is also a geospatial standard.
Sensor things and how you get the information you need when you need it is another example of these standards for the Internet of Things.
New space is a new dynamic area with so many launches and getting data down. Figuring out what data to use and integrating it with others also require geospatial quality metadata standards.
It’s overwhelming because the problems we need standards for also have abstracted and are going up and wide.
There’s a lot of work going on — but then I’m not an expert on proprietary standards.
I live in the open world. We’ve got thede facto standards, like the technologies or the methodologies, plus some open-source code is bundled and reused, becomingde facto.
But in reality, nobody cares about the standards.
Nobody cares about how to bundle 3D information.
People care about getting a contract with a gaming company. People care about business opportunities and climbing up on the value chain. That’s where the return is.
From this want comes a greater willingness to collaborate around common concepts to build businesses and make innovations a reality.
A single concept can cater to hundreds or thousands of use cases. That’s exciting. Imagine how many domains you can expose yourself to.
In fact, geospatial is a great career for anybody who doesn’t want to commit to any domain because you will be in everything.
It’s not like you build it, and they’ll come… it doesn’t work like that.
A standard is as useful and impactful as the number of people and organizations involved in creating it.
It cannot be created in a vacuum.
The best way to ensure its adoption is to have the right people at the table.
A standard won’t be adopted or useful to anybody if it’s a theoretical thing.
At OGC, for example, we have a program called The Innovation Program.
We test ideas for use cases and try them on different people and connect them to other systems. You test something before it becomes a standard.
This is part of the evolution of standards.
Defense and intelligence are good examples. They’re communities based on geospatial.
They have their basic standards, then they come together and figure out the suite of geospatial standards:
Do they need to profile them? Extend them? How do they constrain them to work together, so it works for their community?
This goes for other communities, such as agriculture. They have sensors, and they have Earth Observation, but their community requirements are different. They come together and work out what is the community’s best practices around geospatial standards.
Partnerships are essential because you cannot have one organization that’s an expert in all domains. The community takes what it needs, shapes it the way it needs it, and gets what it needs out of it.
People and policies, like data sharing, lack of data sharing, and collaboration.
We talk about the outcome of a standard, but maybe the standard is not it.
It’s the process to get to a standard that’s just as important because you get the right people to talk to each other, and that’s a lasting impact that you have.
You can wave a magic wand and have the perfect technology or the best product in the world.
But somebody has to decide and invest in integrating it into their system or their solution. That someone has to change the way they do things to collaborate with different people. Sometimes they’ll need to change the people they work with.
That’s precisely why what we do is no longer just traditional standards development — it’s an integrated approach with the community.
In this case, the journey is really more important than the destination.
I was on a panel amid COVID in NYC when things weren’t going well.
There was representation from the state and the counties, where every county has a GIS department, and they wrongly assumed they didn’t have the correct data.
The problem was not sharing the information, despite having the technology.
This is a cultural issue.
It’s a matter of those departments being set up and weighed down by their organizational structure's legacy. The changes we’re living force all of us to adapt.
Today, there is no reason for all these GIS departments not to connect their COVID data to give the Governors what they need and work from the same sheet.
As a podcast host, you get to spend a significant amount of time with some fantastic people. Nadine is both charming and brilliant. I hope I get to meet her in person one day.
During this conversation, one thing that stuck out for me was the importance of having a common language and a language that we agree on.
This is the way we describe data. This is the way we talk about location.
These standards are not that exciting, but what they enable is exciting because if we can agree on that, then the network effect is real. If we can agree that collaboration is a good thing, and all of us together are better than any of us individually, then we need to have some way of enabling communication between us for that to happen.
This is where geospatial standards come into play.
It’s also equally important to highlight that just because we have standards and tools that understand and can speak those standards, that’s not the end of the road.
Nadine spoke of her experience in New York, in the middle of this pandemic, where she found people needed to communicate efficiently more than ever.
It wasn’t the standards that let us down. It wasn’t the tools that got in the way.
It was the people and the policies.
What good is building an organization based on open standards, sharing, and collaboration if the people aren’t willing to take part?
Be sure to subscribe to our podcast for weekly episodes that connect the geospatial community.
For more exclusive content, join our email. No spam! Just insightful content about the geospatial industry.
Google Earth Engine is acloud computing platform for scientificanalysis andvisualization of geospatial data sets. It isfree to use for research, education, and nonprofit. Google Earth Engine is essentially streaming data. You don’t need to go online to download the data — you just need a browser, and you can access the entire Google Earth Engine data catalog and a bunch of tools to do the analysis and visualization.
Coaches ask questions framed to help you clarify your own mind and come up with your own solutions and ideas. It’s powerful because, as the studies show, if you help anyone generate their own ideas and solutions, they’re more likely to implement them and succeed at them.