Several geospatial systems use Well Known Text (WKT) as their preferred/only format for geospatial objects. What if you wanted to use Elasticsearch for your geospatial data though? Until 6.2, Elasticsearch has only provided the option of providing shapes in GeoJSON format. To get your WKT data into Elasticsearch, you may have to go through a complicated export + conversion process. No longer! You can now index a shape in a WKT string directly to Elasticsearch.
I’ve been using WKT quite a bit because it supports curves and now I can load WKT natively into Elasticsearch without converting it beforehand. There is much here to think about for sure!
I know, I used the buzzword IoT in my title above. Stay with me though! We think about IoT as a link between a physical device (your Nest thermostat for example) and the digital world (your Nest app on your iPhone), but it is so much more. While we have been working with many IoT providers such as Current by GE we’ve also fundamentally changed how our backend APIs work to embrace this messaging and communication platform.
Using AWS IoT Services everything that happens in our backend API can alert our front end apps to their status. This ties very nicely into our Unity front-end Smart World Professional application because it can tell you exactly what is happening to your data. Uploading a detailed Revit model? The conversion to glTF occurs in the background, but you know exactly where the process is and exactly what is going on. Those throbber graphics web apps throw up while they wait for a response from the API are worthless. Is the conversion process two thirds the way through or just 10%? Makes a big difference don’t you think?
Where this really starts to matter is our analytics engine, Mapalyze. If I’m running a line of sight analysis for a project in downtown Chicago, there is a ton that is going on from the 3D models of all the buildings to trees, cars and the rest that can affect what you can see and can’t see. Or detailed climate analysis where there are so many variables from the sun, weather (wind, temperature, rain) and human impacts that these models can take a very long time to run. By building the AWS IoT platform into our backend, we can provide updates on the status of any app, not just ours. So if you want to call Smart World Professional Mapalyze from within Grasshopper or QGIS, you won’t get a black box.
In the end what this means is Smart World Professional is “just another IoT device” that you will be able to bring into your own workflows. Really how this is all supposed to work, isn’t it? For those who want to get deeper on how we’re doing this, read up on MQTT, there is a standard under here that everyone can work with even if you’re not on the AWS platform.
The GovTech 100 is an annual list compiled and published by Government Technology as a compendium of 100 companies focused on, making a difference in, and selling to state and local government agencies across the United States. We were excited to find this month that GovTech has put Cityzenith on this list.
There are a lot of spatial companies on that list which just shows how important this space is. We’re getting ready to release our Smart World Professional tools later this quarter which are built on Unity and the Mapbox Unity SDK. It’s been a crazy 6 months from being part of Dreamit to now being on the GovTech 100 and then on to Smart World Professional.
Why did Cityzenith choose Cesium?
The choice of Cesium predates me, so I was not involved with the decision. That said those who made the decision have explained why they went that way. Cesium was probably not the original choice but at the time in 2014/2015 it was the best solution of a “game engine” for our product. We did look at other engines such as Unreal but the 64-bit support and the ease of use in the browser, Cesium won out. In implementing Cesium what were we able to do?
We were able to implement a cross platform 3D world in a browser. That’s not an insignificant accomplishment. Our Cesium team really did an amazing job of making Smart World feel like a regular desktop application even if it was in a browser. No extensions to load, Java or Flash to configure. In a modern browser it basically just worked (more on this though later).
While normally a pain in the rear, the fast updates and quick support for new features on the Cesium project gave us access to new features regularly. We were able to continually update our support for better graphics, performance and features almost by just loading up a new version of Cesium. Of course, in reality it is not that easy but the feature improvements were regular and powerful.
Open source is very liberating on many levels. Not having to fight a licensing battle and focus on the product is a nice change from other development libraries and SDKs. Also having direct access to the developers. If you don’t follow Patrick Cozzi yet you should. Amazing work and they listen to feedback.
glTF support is second to none. I’ll be talking about glTF soon as well and why we absolutely love it.
OK, so what didn’t work with Cesium? Why leave it?
There are really only two reasons we have left. Most of everything else we get with Unity we would either have with Cesium very soon or it’s being implemented today. But the two reasons have been killer for Smart World. I don’t think everyone runs into the same problem we have with their apps so this is more of a specific issue with what we are doing rather than a problem with Cesium.
Cross browser support. Remember when I said that we had cross platform support? Well that really only works if you use Google Chrome. Other browser support is poor at best. Microsoft Edge? Yea not going to happen. Being an enterprise app, we don’t always have the latest and greatest browsers that our customers can use. It’s not an IE8 problem but Edge and Firefox support really killed it for us. It got so bad that we had to put up a modal dialog box that basically said you couldn’t use Smart World without Google Chrome. That’s just unacceptable to us and while we tried to work on solving this the reality of support in other browsers was not coming quick enough and I’m not sure it was a problem that Cityzenith could have solved throwing money at the problem.
Performance in the browser. Chrome is many things and one of them is that it is a memory hog. Loading up cities in Chrome really would put a strain on our user’s computers. The browser is great for simpler 3D mapping but streaming gigabytes of data into a browser really tasked computers. We worked on a ton of LOD workarounds but the compromises to make the application work on a typical enterprise desktop or laptop really left a bad taste in our mouths.
Roadmap for Cityzenith
We want to provide the best 3D analytical tools and we’ll continue to do so. Combined with AWS Lambda and AWS IoT services, we’re making a huge leap in how people perform spatial analysis. Not only are we working on our own planning tools such as rooftop solar analysis, LEED-ND analysis and traffic analysis, we’re integrating RhinoGrasshopper plugin support, so anyone can use their existing workflows. As I said above, we’re moving our 3D engine to Unity. In fact we’ll be having a closed beta very soon for our customers to try it out. One of the biggest reasons we went with Unity was Mapbox’s Unity SDK. We are already a big user of Mapbox and thus moving to the SDK made a ton of sense. I’ll go more into this in another article.
At Cityzenith we provide open data to all our customers for their decision making. Cities make it so easy to get this data and use it. But there is so much here than open city data. Our partners from General Electric to Mapbox all use open data one way or another to help us all get our jobs done.
Today though we don’t use TIGER data anymore, at least directly. We use OpenStreetMap data which is more complete and accurate than TIGER ever was. We use Mapbox for our basemaps (aerial, street, traffic, etc) and they’re all built with OSM data. But what is so very different than what GDT and others is companies like Mapbox help build OSM in return for using the data. That means when Cityzenith uses building heights in San Francisco for modeling that we can take advantage of the community and fill in the blanks where needed.
That’s the big difference between then and now. You can have literally the same look and feel as Mapbox without having to pay a dime if you want. That’s the big game changer, open access to open data means that we’re all working on the same basemap and making improvements to that map. We can get all emotional with words like democratization but it has changed how we work with data. Power is no longer controlled by large companies (the reason why GDT was purchased by TeleAtlas which was acquired by TomTom). But we never have to worry about that because the map is controlled by everyone.
As we move to AR and VR mapping, we’ve got the data in place to make all we need for these virtual environments. That’s why we see such innovation in our space, the freedom to create without fear of not having access to the same data as everyone else.
As I mentioned in my last post, Cityzenith launched last week in Chicago. Thanks to everyone who turned out to see us move out of beta and into a full blown data platform for BIM and GIS. We were lucky enough to have many special guests speaking including State of Illinois CIO Hardik Bhatt, City of Chicago Chief Data Officer Tom Schenk, John Kizior of AECOM, Tom Coleman of WSP-USA, and Gordon Feller of Meeting of the Minds. Michael Jansen, our CEO, lead the discussion and talked about the road to where we are today and how we’re going to change how things are done.
A warm thanks to attendees from Arup, HOK, HKS, CannonDesign, Foursquare, Perkins+Will, SOM, AECOM , Gensler, DeWalt, CallisonRTKL, WSP USA, BuiltWorlds, the University of Illinois at Chicago, the Illinois Institute of Technology, Argonne National Laboratory and many more who attended. The hard work has begun for us and we’re looking forward to helping companies connect with each other around the world.
If you’d like to give Cityzenith a spin free of change, sign up now. Let us know if you’d like to see a demo first. There is so much more to come, stay tuned!
Asq is simple, a query tool to search through our indexed data stores in Elastic. But is also much more, a way to manipulate what you see in your view. Using the GUI to add and work with files and layers is of course how must people will work with the product but being able to stack together commands to perform the same action is where the power is. Much like Automator on Mac OS X or similar scripting tools, the idea is to batch functions together in building blocks.
I don’t want users of Cityzenith to feel constrained by buttons, dialogs and options. Start typing and autocomplete takes care of your next decision. In showing our development team how you perform a Definition Query on ArcGIS Desktop, they were speachless at how many right clicks, OKs and other UI madness one must complete before getting something as simple as [PARK_NAME] = “Grant”. I want to type:
SHOW -> FILE -> PARK -> WHERE -> PARK_NAME -> IS -> “Grant”
That’s not even including all the spatial query functions we can do.
We just launched so this is the beginning of command line City Information Modeling (CIM). Cityzenith can help manage the built environment but taking control of all the aggregated data is critical. Hence Asq being the command line of Cityzenith.