Geovis Project Assignment @RyersonGeo, SA8905, Fall 2021
Introduction/ background
Every city has zoning bylaws that dictate land use. Most cities, including the City of Toronto, have zoning bylaws that set building height limits for different zoning areas. Sometimes, buildings are built above the height limit, either due to development agreements or grandfathering of buildings (when a new zoning by-law doesn’t apply to existing buildings). The aim of this project is to provide a visualization tool for assessing which buildings in Toronto are within the zoning height limits and which are not.
Data and Processing
3D Buildings
The 3D building data was retrieved from Toronto Open Data and derived using the following methods:
LiDAR (2015)
Site Plans – building permit site plan drawings
Oblique Aerials – oblique aerial photos and “street view” photos accessible in Pictometry, Google Earth, and Google Maps.
3DMode – digital 3D model provided by the developer
Zoning Bylaws
Two zoning Bylaw shapefiles were used (retrieved from Toronto Open Data as well):
Building Heights Limits – spatially joined (buildings within zoning area) to the 3D buildings to create the symbology shown on the map. Categories were calculated using the max average building height (3D data) and zoning height limit (zoning bylaws).
Zoning Categories – used to gain additional information and investigate how or why buildings went over the zoning height limit.
Geovisualization
ArcGIS experience builder was used to visualize the data. A local scene with the relevant data was uploaded as a web scene and chosen as the data source for the interactive map in the “Experience”. The map includes the following aspects: Legend showing the zoning and height categories, a layer list allowing users to toggle the zoning category layer on to for further exploration of the data, and a “Filter by Height Category” tool that allows users to view buildings within a selected height category. Pop-ups are enabled for individual buildings and zones for additional information. Some zones include bylaw expectations which may explain why some of the buildings within them are allowed to be above the zoning height limit (only an exception code is provided, a google search is required to gain a better understanding). instructions and details about the map are provided to the user as well.
Limitations
The main limitation of this project is insufficient data – a lack of either building height or zoning height results in a category of “No data” which are displayed as grey buildings. Another limitation is possibly the accuracy of the data, as LiDAR data can sometimes be off and provide wrong estimates of building height. Inaccuracies within 1m were solved by adding an additional category, but there may be some inaccuracies beyond
Geovisualization Project Assignment, SA8905, Fall 2021
INTRO
With the development of automation and machine learning, a new approach in raw data acquisition has been opened for people to try. QGIS is a popular open-source GIS software that allows the creation of custom plugins for all sorts of geoprocessing. One such plugin is called Mapflow, developed by Russian-based company GEOAlert. Mapflow is an easy-to-use plugin to retrieve ground data from satellite imagery such as buildings, roads, construction zones, and forest canopies. This blog will introduce how to use Mapflow through a browser environment. To learn how to use the plugin, please refer to the Esri Story Maps tutorial through this link: https://storymaps.arcgis.com/stories/dfd88d7170c74f33a4dd5f7583cdc414
The difference between the use of Mapflow in the browser and through the plugin is that browser only allows detection from web-based satellite services such as Mapbox, or custom imagery through URL, while in the plugin, custom satellite imagery can be processed straight from the user’s device. The major advantage of the browser approach is that the process is using remote servers which is faster than the plugin process.
Mapflow website project page
USER INTERFACE
Mapflow online service uses free to try system by giving 500 free credits when opening an account. Each process requires credits based on the size of the data area that the user wishes to process. If the user runs out of credits, it is possible to top up the balance in the top right corner for the price of 100 CAD per 1000 points.
Let’s explore the project page. The project is organized in steps where the user can choose the data source, the type of AI Model that the user wishes to run, and post-processing operation for additional data gathering. AI Models that are available in the browser copy the models which are available in the QGIS plugin. AI can provide digitization for buildings, high-density housing, forests, roads, construction, and agricultural fields.
User Interface of the Data source tab in Mapflow. Mapbox API is used to display geographic data.
In the data source tab, a user can either use the embedded draw tool to choose the area for processing or upload polygon data in GEOJSON format. The draw rectangle tool is very intuitive in its use and as soon as it’s drawn, the website provides the area’s size in squared kilometers. This number is used by the website to determine how many credits are required to process the area. The larger the area, the more credits it costs to process.
DATA
The area of interest for this example would be focused on the same area as was used in the plugin tutorial in Esri Story Maps: the city of Ciego De Avilo in Cuba. The drawn rectangle over the city and closest suburbs estimated the area to be 45.31 squared kilometers. Originally the area was raised to my attention when I was doing some research project for the company I work for to explore the possibility of constructing fiber service in the Caribbean region. While searching for building and road data through open sources such as OpenStreetMap, I realized that some Caribbean countries and especially Cuba is missing geographic data that is required to create a fiber map model. After exploring several options, the plugin Mapflow proved to be most useful to generate geodata from available free commercial satellite imageries.
Selected Area of the City of Ciego De Avila chosen through draw rectangle tool in the data source page of Mapflow
PROCESS
The Chosen area is now inputted in our project. The next steps would be to choose the model and post-processing data. We will choose a buildings model to test the speed of the browser process and compare it with the plugin process. The big perk of the browser tool is the post-processing options. One such option is automatic polygon simplification, which would simplify the results of the model. In the plugin version, the results of the model outputted some building polygons in broken shapes or fuzzy polygons. That would create additional work post-processing polygons manually. The browser tool offers that option for free.
Project window of Mapflow right before the beginning of the process.
The area of interest costs 227 credits to be processed, which means that every 100 squared kilometers processed costs 500 points.
As soon as the Run processing button is pressed, the final step is to wait for the process to finish and download the processed data. The process finished in 32 minutes. That is 15 minutes faster than in the plugin process, which was 47 minutes.
After the process is finished, the user can view the results in the browser and download the file in the GEOJSON format.
Data results in the browser window
The process assigns id numbers to each shape as well as shape types, such as rectangle, grid snap, or l-shape. This information can help with further post-processing and solve any automation mistakes.
LIMITATIONS AND FUTURE WORK
The most important limitation of this tool is its cost, however, if the user decides to process an area larger than 100 square kilometers, one can create multiple accounts and use free credits each time. Secondly, the processed results sometimes output shapes that are very questionable in their nature. Some polygons merged multiple buildings into ones, others detected buildings partially, in other cases the orientations of polygons are off. This can be fixed in the manual post-processing by GIS professionals.
In the future, this tool can be potentially be used to populate the OpenStreetMap dataset with the building polygons and roads data. Open Source data is very important for many gis users, and AI automation is the perfect companion that makes the work of GIS enthusiasts much easier by streamlining the most tedious processes in geographic analysis.
Submission for GeoVis Project Assignment @RyersonGeo, SA8905, Fall 2016
Interactive City Models
One of the most useful visualization and planning tools used in urban planning and design is the 3D model: a to-scale representation of the built form of a city, its existing (and as-built) conditions and its proposed (or possible) conditions. A 3D model effectively communicates information about the proportion, size, and distribution of structures and other urban elements, that when well made and presented is intuitively grasped by the people that are viewing it.
A principal drawback to most 3D models is that they are physical models, and they take a lot of time to create, to modify, and can only be shared with an audience who is physically present. One way to solve the this problem is to replace the physical with a 3D digital model (using 3D modelling software such as Rhino, ArchiCAD, Blender, Solidworks, etc.) and to share the models with other users. Yet, there are drawbacks to this approach, too. For one, these models can only be shared with users that have the same (or similar) software of the kind that was used to create the model. For users who do not have the correct software, static or animated representations of the model are made which, while they can still convey information, do not allow the user make choices on what aspects of the model they want to view or explore.
Beyond this technical problem, the models are not geographic and they are not data-driven. Though they are spatial, they are not referenced to a location on the earth and they don’t contain attributes. There is no way to know what building or open space you are looking at without asking someone who is familiar with the model. Informal exploration is just too limited. One way to solve these problems is to store and view 3D model information in CloudCities.
CloudCities and the Ryerson Campus
CloudCities is a geographically-enriched 3D model viewing and storage platform. The graphical rendering is done through ThreeJS, a javascript library used to build and render 3D objects in a browser. It is one of several platforms that blend geographic information within a 3D environment (see here and here for further examples).
CloudCities allows users to upload 3D model information, such as a building, tree, vehicle, or terrain, as well as their attributes. Not all 3D information can be uploaded (for instance, stylized 3D lines or other non-geographic 3D visualizations are not generally possible). In addition to upload, CloudCities has several customization features that allow the model scene to be modified: sun/shadow settings; pre-set camera views and 3D slides; a search function; location comparison to OpenStreetMap; and dynamic attribute and 3D editing, which allows the user to dynamically modify/add to object attributes and to use basic 3D editing functions.
CloudCities is built to store and view 3D models (as opposed to general 3D visualizations), and specifically 3D models of cities (multiple buildings, blocks, terrain, etc.) so for this project I have built a model of the bulk of Ryerson University’s Campus in downtown Toronto.
Area used for the CloudCities model
A view of the entire model
Data
The input data for the model’s 3D buildings is from two sources: myself, who modelled several buildings on the Ryerson campus, including Kerr Hall, in Rhinoceros (Rhino), a 3D modelling program, and the City of Toronto’s Open Data portal, which maintains a 3D massing and building model dataset that is frequently updated and that is available in several formats.
The 3D information from the City of Toronto is of high quality, but it is released in several formats, and not all of these formats contain equivalent data. Out of all of the data available, the 3D CAD information is the most detailed and accurate but it is harder to work with.
Ultimately, all of the 3D information that fits within the sample area were converted, by individual building, into multipatch features using the ArcGIS 3D Analyst extension. These multipatches were loaded into ArcScene, exported to an ESRI 3D webscene format, and then uploaded into a CloudCities scene. While there are other ways to create a functional CloudCities scene, uploading from ArcScene is the most straightforward, though it is certainly not an option for everyone (see the Asset import tutorial), especially when they do not have ArcScene or 3D Analyst available to use!
Rhinoceros model of Kerr Hall (above) and a multipatch of the Ryerson Student Center (below)
I manually modelled Kerr Hall because I wanted it to be more detailed than that stored within the City of Toronto dataset. The modelling was done in Rhino. The model was then exported from Rhino into .3DS format, then to multipatch to be included into the webscene uploaded into CloudCities. Deletion of original building massing data from the City of Toronto dataset was required where another model instance – in this case, custom-models like that of Kerr Hall – takes its place.
Zoning information is also provided by the City’s Open Data portal and this was used to code each building instance with its associated zone category (e.g. R or ‘Residential’).
I have customized and manually refined City blocks (which define the road surfaces) and green open space areas because these are not accurately captured within the City’s data.
Complex Data
Terrain surfaces and trees (which can be very complex objects) were not added to this model because of the eventual data size requirements, but in order for these elements to look good and not awkward, they must be of sufficient detail. Terrain published by the City of Toronto, even when simplified, is a complex geometry that would weigh on the model’s performance. In addition, terrain requires that buildings sit on top of the surface, but the buildings modelled by the City do not account for an uneven grade around the base (what is known as Finished Floor Elevation). While this detail can be made within the models, the eventual time required would have been onerous. The more detail in a building and the more the model approximates reality, the longer the model will take to create.
User Experience (UX) highlights
In the CloudCities model, buildings contain a name, whether they are Ryerson University buildings, the planning zone they fall within (e.g. commercial or residential), and the size of the building footprint area in sq.m. Some of this information is added within the pre-upload ArcGIS environment, but much of it is added from within CloudCities’ editing environment.
These attributes serve as the basis for dashboards and a search bar. The dashboard displays these vital statistics whenever a building object is clicked.
Dashboard reveals attributes when a building is clicked.
Additionally, a search bar and search constraints can be set, and the user can search through the scene’s attributes to highlight objects that are returned. For instance, every building that has the zone ‘Commercial Residential’ is highlighted whenever that term is entered into the search. The search functions are limited, however – there are no advanced queries supported by CloudCities. Instead, various constraints on searches must be set on the back end to make sure that a particular search does not return any object that fulfills any small dimension of the attribute data.
Search results when “Commercial Residential” is entered
Specific locations can be saved as bookmarks, and these aid in presentation purposes. These locations can be combined into a slideshow “tour” of the model. This is a particularly relevant feature when sending the model to others, as the locations are stored with the scene, and literally move the user point of view around the model in order to tell a story.
Camera bookmarks can help guide a user through the model
A sun/shade rendering tool can be implemented, which allows the user to set the time of year and time of day to create a realistic view of how shadows would be cast by model elements based on the model’s location on the earth, although this is not a sun shadow calculator and is meant simply to enhance the experience of the model.
Sun and shadow controls
Limitations of CloudCities
One of the main limitations of CloudCities is that it is not customizable from a development point of view. A user is limited to pre-set dashboard, search, and styling options. In addition, the platform costs money and is billed at a hefty $60 USD+/per month in order to create a city model to the detail that was made for this post.
The range of 3D visualizations possible is limited. It would be nice to have a platform that incorporates more options for presenting thematic data that goes beyond dashboards and search bars. There is a lot of 3D data that does not manifest itself in a 3D structure. ThreeJS’s gallery of 3D visualizations provides interesting examples of how 3D city modelling could be developed in the future.
Despite these limitations, CloudCities provides an easy-to-use platform for making and viewing 3D city models. I do not believe that CloudCities will always be the only platform that offers the same functionality, but it is currently a really good example of how urban planners and designers can take advantage of geo-technology to create a more interactive and data-rich experience of their 3D information.
The final model can be viewed on CloudCities here. After mid-December 2016, the model’s geographic extents will be greatly reduced so that the model can be stored on a free account.
