How do we turn our idea into a location-based web application? If you've heard this question before or asked it yourself, you would know that this deceptively simple question can have answers posed in a limitless number of ways. In this book, we will consider the application of QGIS through specific use cases selected for their general applicability. There's a good chance that the blueprint given here will shed some light on this question and its solution for your application.
In this book, you will learn how to leverage this ecosystem, let the existing software do the heavy lifting, and build the web mapping application that serves your needs. When integrated software is seamlessly available in QGIS, it's great! When it isn't, we'll look at how to pull it in.
In this chapter, we will look at how data can be acquired from a variety of sources and formats and visualized through QGIS. We will focus on the creation of the part of our application that is relatively static: the basemap. We will use the data focused on a US city, Newark, Delaware. A collection of data, such as historical temperature by area, point data by address, and historical map images, could be used for a digital humanities project, for example, if one wanted to look at the historical evidence for lower temperatures observed in a certain part of a city.
In this chapter, we will cover the following topics:
The software
Extract, Transfer, and Load
Georeference
The table join
Geocoding
Orthorectification
The spatial reference manipulation
The spatial reference assignment
Projection
Transformation
The basemap creation and configuration
Layer scale dependency
Labeling
The tile creation
QGIS is not a black box—it is a part of a dynamic community of software users and developers. Although this book strives to apply generalizable blueprints to a range of actual web applications, there are times when a deeper understanding of the makeup of the QGIS platform is invaluable; sometimes even as soon as at installation. The latest version of QGIS is 2.10.
As QGIS is open source, no one entity owns the project; it's supported by a well-established community. The project is guided by the QGIS Project Steering Committee (PSC), which selects managers to oversee various areas of development, testing, packaging, and other infrastructure to keep the project going. The Open Source Geospatial Foundation (OSGeo) is a major contributor to software development, and QGIS is considered an official OSGeo project. Many of QGIS' dependencies and complimentary software are also OSGeo projects, and this collective status has served to bring some integration into what can be considered a platform. The Open GIS Consortium (OGC) deliberates and sets standards for the data and metadata formats. QGIS supports a range of OGC standards—from web services to data formats.
When QGIS is at its best, this rich platform provides a seamless functionality, with an ecosystem of open or simply available software ready to be tapped. At other times, the underlying dependencies and ecosystem software require more attention. Since it's an open source software, contributions are always being made, and you have the option of making customizations in code and even contributing to it!
The OSGeo ecosystem provides capabilities for data format read/write through the OGR Simple Features Library (OGR, originally for OpenGIS Simple Features Reference Implementation) and Geospatial Data Abstraction Library (GDAL) libraries, which support around 220 formats.
The models of the earth, which the coordinates refer to, are collectively known as Coordinate Reference Systems (CRSs). The spatial reference transformation between systems and projection—from a system in linear versus the one in angular coordinates—is supported by the PROJ.4 library with around 2,700 systems. These are expressed in a plain text format defined by PROJ.4 as Well Known Text (WKT). PROJ.4 WKT is actually very readable, containing the sort of information that would be familiar to the students of cartographic projection, such as meridians, spheroids, and so on.
Analysis, or application of algorithmic functions to data is rarely handled seamlessly by QGIS. More often, it is an extension of one of the dependencies already listed before or is provided by System for Automated Geoscientific Analyses (SAGA). Many other analytical operations are provided by numerous QGIS Python plugins.
In general, these libraries will seamlessly transform to or from the formats that we require. However, in some cases, additional dependencies will need to be acquired and either be built and configured themselves or have the code built around them.
OSGeo project binaries have sometimes been bundled to ease the installation process, given the multitude of interdependencies among projects. Tutorials in this book are written based on an installation using the QGIS standalone installer for Windows.
QGIS hosts repositories with the most current versions for Debian/Ubuntu and bundled packages for other major Linux distributions; however, these repositories are generally many versions behind. You will find that this is often the case even with the extra repositories for your distribution (for example, EPEL for RHEL flavors). Seeking out other repositories is worthwhile. Another option, of course, is to attempt to build it from scratch; however, this can be very difficult.
There is no bundled package installer for Mac OS, though you should be able to install QGIS with only one or two additional installations from the binaries readily available on the Web—the KyngChaos Wiki has long been the go-to source for this.
Installation with Windows is simpler than with other platforms at this time. The most recent version of QGIS, with basic dependencies such as GDAL, is installed with a typical executable installer: the "standalone" installer. In addition, the OSGeo4W (OSGeo for Windows) package installer is very useful for the extended dependencies. You will likely find that beyond simply installing QGIS, you will return to this installer to add additional software to extend QGIS into its ecosystem. You can launch the installer from the Setup shortcut under the QGIS submenu in the Windows Start menu.
The most extensive incarnation of the OSGeo software is embodied in OSGeo-Live, a Lubuntu Virtual Machine (VM) on which all of the OSGeo software is already installed. It is listed here separately since it will boot into its own OS, independent of the host platform.
Updates to OSGeo Live are typically released in tandem with FOSS4G, an annual global event hosted by OSGeo since 2006. Given that these events occur less regularly and are out of sync with OSGeo software development, bundled versions are usually a few releases behind. Still, OSGeo-Live is a quick way to get started.
Now that you've prepared your local machine, let's return to the idea of the generalizable web applications that will be the focus of this book. There are a few elements that we can identify in the process of developing web-mapping applications.
After any preliminary planning—a step that should include careful consideration of at least the use cases for our application—we must acquire data. Acquisition involves not only the physical transfer of the data, but also processing the data to a particular format and importing it into whatever data storage scheme we have developed. This is usually called Extract, Transform, and Load (ETL).
Though ETL is the first major step in developing a web application, it should not be taken lightly. As with any information-based project, data often comes to us in a form that's not immediately useable—whether because of nonuniform formatting, uncertain metadata, or unknown field mapping. Although any of these can affect a GIS project, as GISs are organized around cartographic coordinate systems, the principle concern is usually that data must be spatially described in a uniform way, namely by a single CRS, as referred to earlier. To that end, data often requires georeferencing and spatial reference manipulation.
For certain datasets, an ETL workflow is unnecessary because the data is already provided via web services. Using hosted data stored on the remote server and read directly from the Web by your application is a very attractive option, purely for ease of development if nothing else. However, you'll probably need to change the CRS, and possibly other formatting, of your local data to match that of the hosted data since hosted services are rarely provided in multiple CRSs. You must also consider whether the hosted data provides capabilities that support the interface of your application. You will find more information on this topic under the operational layer section of this chapter.
By georeferencing, or attaching our data to coordinates, we assert the geographic location of each object in our data. Once our data is georeferenced, we can call it geospatial. Georeferencing is done according to the fields in the data and those available in some geospatial reference source.
The simplest example is when a data field actually matches a field in some existing geospatial data. This data field is often an ID number or name. This kind of georeferencing is called a table join.
In this example, we will take a look at a table join with some temperature data from an unknown source and census tract boundaries from the US Census. Census' TIGER/Line files are generally the first places to look for U.S. national boundary files of all sorts, not just census tabulation areas.
The temperature data to be georeferenced through a table join would be as follows:
tract,date,mean_temp 014501,2010-06-01,73 014402,2010-06-01,75 014703,2010-06-01,75 014100,2010-06-01,76 014502,2010-06-01,75 014403,2010-06-01,75 014300,2010-06-01,71 014200,2010-06-01,72 013610,2010-06-01,68
Temperature data metadata would be as follows:
"String","Date","Integer"
Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
To perform a table join, perform the following steps:
Copy the code from the first information box calls into a text file and save this as
temperature.csv.Copy the code from the second information box into a text file and save this as
temperature.csvt. Otherwise, QGIS will not know what type of data is contained in each column.Tip
Data for all the chapters will be found under the data directory for each chapter. You can use the included data under
c1/data/originalwith the file names given earlier. Besides selecting the browse menu, you can also just drag the file into the Layers panel from an open operating system window. You can find examples of data output during exercises under the output directory of each chapter's data directory. This is also the directory given in the instructions as the destination directory for your output. You will probably want to create a new directory for your output and save your data there so as to not overwrite the included reference data.Navigate to Layer | Add Layer | Add Vector Layer | Browse to, and select
temperature.csv.Download the Tract boundary data:
Visit http://www.census.gov/geo/maps-data/data/tiger-line.html.
Click on the tab for the year you wish to find.
Download the web interface.
This will take us to http://www.census.gov/cgi-bin/geo/shapefiles2014/main.
Navigate to Layer Type | Census Tracts and click on the submit button. Now, select Delaware from the Census Tract (2010) dropdown. Click on Submit again. Now select All counties in one state-based file from the dropdown displayed on this page and finally click on Download.
Unzip the downloaded folder.
Navigate to Layer | Add Layer | Add Vector Layer | Browse to, and select the
tl_2010_10_tract10.shpfile in the unzipped directory.Right-click on
tl_2010_10_tract10in the Layer panel, and then navigate to Properties | Joins. Click on the button with the green plus sign (+) to add a join.Select temperature as the Join layer option, tract as the Join field option, TRACTCE10 as the Target field option, and click on OK on this and the properties dialog:
To verify that the join completed, open the attribute table of the target layer (such as the geospatial reference, in this case, tl_2010_10) and sort by the new temperature_mean_temp field. Notice that the fields and values from the join layer are now included in the target layer.
If our data is expressed as addresses, intersections, or other well-known places, we can geocode it (that is, match it with coordinates) with a local or remote geocoder configured for our particular set of fields, such as the standard fields in an address.
In this example, we will geocode it using the remote geocoder provided by Google. Perform the following steps:
Install the MMQGIS plugin.
If you don't already have some address data to work with, you can make up a delimited file that contains some standard address fields, such as street, city, state, and county (ZIP code is not used by this plugin). The data that I'm using comes from New Castle County, Delaware's GIS site (http://gis.nccde.org/gis_viewer/).
Whether you've downloaded your address data or made up your own, make sure to create a header row. Otherwise, MMQGIS fails to geocode.
The following is an example of
MMQGIS-friendly address data:id,address,city,state,zip,country 1801300170,44 W CLEVELAND AV,NEWARK,DE,19711,USA 1801400004,85 N COLLEGE AV,NEWARK,DE,19711,USA 1802600068,501 ACADEMY ST,NEWARK,DE,19716,USA
Open the MMQGIS geocode dialog by navigating to MMQGIS | Geocode | Geocode CSV with Google/OpenStreetMap.
Once you've matched your fields to the address input fields available, you have the option of choosing Google Maps or OpenStreetMap. Google Maps usually have a much higher rate of success, while OpenStreetMap has the value of not having a daily limit on the number of addresses you can geocode. At this time, the OSM geocoder produces such poor results as to not be useful.
You'll want to manually select or input a filesystem path for a
notfound.csvfile for the final input. The default file location can be problematic.Once your geocode is complete, you'll see how well the geocode address text matched with our geocoder reference. You may wish to alter addresses in the
notfound.csvfile and attempt to geocode these again.
Finally, if our data is an image or grid (raster), we can match up locations in the image with known locations in a reference map. The registration of these pairs and subsequent transformation of the grid is called orthorectification or sometimes by the more generic term, georeferencing (even though that applies to a wider range of operations).
Add a basemap, to be used for reference:
Add the OpenLayers plugin. Navigate to Plugins | Manage | Install Plugins; select OpenLayers Plugin and click on Install.
Navigate to Web | OpenLayers plugin, and select the basemap of your choice. MapQuest-OSM is a good option.
Obtain map image:
I have downloaded a high-resolution image (
c1/data/original/4622009.jpg) from David Rumsey Map Collection, MapRank Search (http://rumsey.mapranksearch.com/), which is an excellent source for historical map images of the United States.Search by a location, filtering by time, scale, and other attributes. You can find the image we use by searching for Newark, Delaware.
Once you find your map, navigate to it. Then, find Export in the upper right-hand corner, and export an extra high-resolution image.
Unzip the downloaded folder.
Orthorectify/georeference the image with the following steps:
Navigate to Raster | Georeferencer | Georeferencer.
Pan and zoom the reference basemap in the canvas on a location that you recognize in the map image.
Pan and zoom on the map image.
Select Add Control Point if it is not already selected.
Click on the location in the map image that you recognized in the third step.
Click the Pencil icon to choose control point from Map Canvas.
Click on the location in the reference basemap.
Click on OK.
Add three of these control points, as shown in the following screenshot:
Start georeferencing by clicking on the Play button.
Enter the transformation settings information, as shown in the following screenshot:
Now, start georeferencing by clicking on the Play button again.
Once your image has been georeferenced, you should see it align with the other data on your map. You can alter the layer transparency under Layer properties | Transparency:
QGIS will sometimes do an On-the-Fly (OTF) projection of all the data added to the canvas on the project CRS (defined under Project | Project Properties | CRS). You will want to disable OTF projection in the projects you intend to produce for web applications, as all layers should have their own spatial reference independently defined and transformed or projected in the same CRS, if needed.
When geospatial data is received with no metadata on what the spatial reference system describes its coordinates, it is necessary to assign a system. This can be by right-clicking on the layer in Layers Panel | Save as and selecting the new CRS.
At other times, data is received with a different CRS than in the case of the other data used in the project. When CRSs differ, care should be taken to see whether to alter the CRS of the new nonconforming data or of the existing data. Of course we want to choose a system that supports our needs for accuracy or extent; at other times when we already have a suitable basemap, we will want operational layers to conform to the basemap's system. When a suitable basemap is already available to be consumed by our web application, we can often use the system of the basemap for the project. All major third-party basemap providers use Web Mercator, which is now known as EPSG:3857.
You can project data from geographic to projected coordinates or from one projection to another. This can be done in the same way as you would define a projection: by right-clicking on a layer in Layers Panel | Save as and selecting the new CRS. An appropriate transformation will generally be applied by default.
There are some features in CRS Selector that you should be aware of. By selecting from Recently used coordinate reference systems, you can often easily match up a new CRS with those existing in the workspace. You also have the option to search through the available systems by entering the Filter input. You will see the PROJ.4 WKT representation of the selected CRS at the bottom of the dialog.
Although the data has been added to the GIS through the ETL process, it is of limited value without adding some visualization enhancements.
The layer style is configured through the Style tab in the Layer Properties dialog. The Single Symbol style is the default style type, and it simply shows all the geographic layer objects using the same basic symbol. This setting doesn't provide any visual differentiation between objects other than their apparent geospatial characteristics. The Categorized and Graduated style types provide different styles according to the attribute table field of your choosing. Graduated, which applies to quantitative data, is particularly powerful in the way the color and symbols size are mapped to a numerical scale. This is all accomplished through the Layer Properties | Style tab.
To configure a simple graduated layer style to the data, perform the following steps:
Under the Layer Properties | Style tab, select Graduated for the style type.
Select your quantitative field for Column (such as
temperature_mean_temp).Click on Classify to group your data into the number of classes specified (by default, 5) and to select the classification mode (Equal Interval, by default):
If you applied the preceding steps to the joined tract/temperature layer, you'd see something similar to the following image:
You can add some layer transparency here if you'd like to simultaneously view other layers. This would be appropriate if this layer were to be included in a basemap.
Now, click on OK.
You will now see the following output:
Perhaps the lower temperatures to the north of the city are related to the historical development in other parts of the city.
Labels can provide important information in a map without requiring a popup or legend. As labels are automatically placed by the software (they do not have an actual physical position in space), they are subject to particular placement issues. Also, a map with too much label text quickly becomes confusing. Sometimes, labels can be easily rendered into tiles by integrated QGIS operations. At other times, this will require an external rendering engine or a map server. These issues are discussed later on in this chapter.
To label the address points in our example, go to that layer's Layer Properties | Labels tab. Perform the following steps:
Select address for the Label this layer with field. Note that the checkbox next to this selection will be toggled. All other label style options will remain the same, as shown in the following screenshot:
Open the Buffer subtab and toggle Draw text buffer:
After you click on OK, you will see something similar to the following screenshot:
In web map applications, the meaning of basemap sometimes differs from that in use for print maps; basemaps are the unchanging, often cached, layers of the map visualization that tend to appear behind the layers that support interaction. In our example, the basemap could be the georeferenced historical image, alone or with other layers.
You should consider using a public basemap service if one is suitable for your project. You can browse a selection of these in QGIS using the OpenLayers plugin.
Tip
Use a basemap service if the following conditions are fulfilled:
The geographic features provide adequate context for your operational layer(s)
The extent is suitable for your map interface
Scale levels are suitable for your map interface, particularly smallest and largest
Basemap labels and symbols don't obscure your operational layer(s)
The map service provides terms of use consistent with your intended use
You do not need to be able to view the basemap when disconnected from the internet
If our basemap were not available via a web service as in our example, we must turn our attention to its production. It is important to consider what a basemap is and how it differs from the operational layer.
The geographic reference features included in a basemap are selected according to the map's intended use and audience. Often, this includes certain borders, roads, topography, hydrography, and so on.
Tip
Beyond these reference features, include the geographic object class in the basemap if you do not need:
To regularly update the geometric data
To provide capabilities for style changes
To permit visibility change in class objects independently of other data
To expose objects in the class to interface controls
Assuming that we will be using some kind of caching mechanism to store and deliver the basemap, we will optimize performance by maximizing the objects included therein.
Obtaining data for a basemap is not a trivial task. If a suitable map service is available via a web service, it would ease the task considerably. Otherwise, you must obtain supporting data from your local system and render this to a suitable cartographic format.
A challenge in creating basemaps and keeping them updated is interacting with different data providers. Different organizations tend be recognized as the provider of choice for the different classes of geographic objects. With different organizations in the mix, different data format conventions are bound to occur.
OpenStreetMap (OSM), an open data repository for geographic reference data, provides both map services and data. In addition to OSM's own map services, the data repository is a source for a number of other projects offering free basemap services.
OpenStreetMap uses a more abstract and scalable schema than most data providers. The OSM data includes a few system fields, such as osm_id, user_id, osm_version, and way. The osm_id field is unique to each geographic object, user_id is unique to the user who last modified the object, osm_version is unique to the versions for the object, and way is the geometry of the object.
By allowing a theoretically unlimited number of key value pairs along with the system fields mentioned before, the OSM data schema can potentially allow any kind of data and still maintain sanity. Keys are whatever the data editors add to the data that they upload to the repository. The well-established keys are documented on the OSM site and are compatible with the community produced rendering styles. If a community produced style does not include the key that you need or the one that you created, you can simply add it into your own rendering style. Columns are kept from overwhelming a local database during the import stage. Only keys added in a local configuration file are added to the database schema and populated.
High quality cartography with OSM data is an ongoing challenge. CloudMade has created its business on a cloud-based, albeit limited, rendering editor for OSM data, which is capable of also serving map services. CloudMade is, in fact, a fine source for cloud services for OSM data and has many visually appealing styles available. OpenMapSurfer, produced by a research group at the University of Heidelberg, shows off some best practices in high quality cartography with OSM data including sophisticated label placement, object-level scale dependency, careful color selection, and shaded topographic relief and bathymetry.
To obtain the OpenStreetMap data locally to produce your own basemap, perform the following steps:
Install the OpenLayers and OSMDownloader QGIS plugins if they are not already installed.
Create a new SpatiaLite database.
Turn on OSM:
Navigate to Web | OpenLayers | OpenStreetMap | OpenStreetMap.
Browse your area of interest.
Download your area of interest:
Navigate to Vector | OpenStreetMap | Download Data:
Import the downloaded XML data into a topological SQLite database. This does not contain SpatiaLite geographic objects; rather, it is expressed in terms of topological relationships between objects in a table. Topological relationships are explored in more depth in Chapter 4, Finding the Best Way to Get There, and Chapter 5, Demonstrating Change.
Navigate to Vector | OpenStreetMap | Import Topology from XML.
Convert topology to SpatiaLite spatial tables through the following steps:
Navigate to Vector | OpenStreetMap | Export Topology to Spatialite.
Select the points, polylines, or polygons to export.
Then, select the fields that you may want to use for styling purposes. You can populate a list of possible fields by clicking on Load from DB.
You can repeat this step to export the additional geometry types, as shown in the following screenshot:
You can now style this as you like and export it as the tiled basemap. Then, you can save it in the
mapnikorsldstyle for use in rendering in an external tile caching software.
Here's an example of the OSM data overlaid on our other layers with a basic, single symbol style:
Of course, heaping data in the basemap is not without its drawbacks. Other than the relative loss of functionality, which occurs by design, basemaps can quickly become cluttered and otherwise unclear. The layer and label scale dependency dynamically alter the display of information to avoid the obfuscation of basemap geographic classes.
When classes of geographic objects are unnecessary to visualize at certain scales, the whole layer scale dependency can be used to hide the layer from view. For example, in the preceding image, we can see all the layers, including the geocoded addresses, at a smaller scale even when they may not be distinctly visible. To simplify the information, we can apply the layer scale dependency so that this layer does not show these small scales.
At this scale, some objects are not distinctly visible. Using the layer scale dependency, we can make these objects invisible at this scale.
It is also possible to alter visibility with scale at the geographic object level within a layer. For example, you may wish to show only the major roads at a small scale. However, this will generally require more effort to produce. Object-level visibility can be driven by attributes already existing or created for the purpose of scale dependency. It can also be defined according to the geometric characteristics of an object, such as its area. In general, smaller features should not be viewable at lower scales.
A common way to achieve layer dependency at the object level using the whole-layer dependency is to select objects that match the given criteria and create new layers from these. Scale dependency can be applied to the subsets of the object class now contained in this separate layer.
You will want to set the layer scale dependency in accordance with scale ratios that conform to those that are commonly used. These are based on some assumptions, including those about the resolution of the tiled image (96 dpi) and the size of the tile (256px x 265px).
|
Zoom |
Object extent |
Scale at 96 dpi |
|---|---|---|
|
|
Entire planet |
|
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
Country |
|
|
|
| |
|
|
| |
|
|
State |
|
|
|
| |
|
|
Metropolitan |
|
|
|
| |
|
|
City |
|
|
|
| |
|
|
Town |
|
|
|
| |
|
|
Minor road |
|
|
|
| |
|
|
Sidewalks |
|
Labels are commonly separated from the basemap layer itself. One reason for this is that if labels are included in the basemap layer, they will be obscured by the operational layer displayed above it. Another reason is that tile caching sometimes does not properly handle labels, causing fragments of labels to be left missing. Labels should also be displayed with their own scale dependency, filtering out only the most important labels at smaller scales. If you have many layers and objects to be labeled, this may be a good use case for a map server or at least a rendering engine such as Mapnik.
To achieve conflict resolution between label layers on our map output, we will convert the geographic objects to be labeled to centroids—points in the middle of each object—which will then be displayed along with the label field as a label layer.
Convert objects to points through the following steps:
Navigate to Vector | Geometry Tools | Polygon Centroids.
If the polygons are in a database, create an SQL view where the polygons are stored, as shown in the following code:
CREATE VIEW AS SELECT polygon_class.label, st_centroid(polygon_class.geography) AS geography FROM polygon_class;
Create a layer corresponding to the labels in the map server or renderer.
Add any adjustments via the SLD or whichever style markup you will use. The GeoServer implementation is particularly good at resolving conflicts and improving placement.
Chapter 7, Mapping for Enterprises and Communities, includes a more detailed blueprint for creating a labeling layer with a cartographically enhanced placement and conflict resolution using SLD in GeoServer.
The characteristics of the basemap will affect the range of interaction, panning, and zooming in the map interface. You will want a basemap that covers the extent of the area to be seen on the map interface and probably restrict the interface to a region of interest. This way, someone viewing a collection of buildings in a corner of one state does not get lost panning to the opposite corner of another state! When you cache your basemap, you will want to indicate that you wish to cache to this extent. Similarly, viewable scales will be configured at the time your basemap is cached, and you'll want to indicate which these are. This affects the incremental steps, in which the zoom tool increases or decreases the map scale.
The best way to cache your basemap data so that it quickly loads is to save it as individual images. Rather than requiring a potentially complicated rendering by the browser of many geometric features, a few images corresponding to the scale and extent to which they are viewed can be quickly transferred from client to server and displayed. These prerendered images are referred to as tiles because these square images will be displayed seamlessly when the basemap is requested. This is now the standard method used to prepare data for web mapping. In this book, we will cover two tools to create tile caches: QTiles plugin (Chapter 1, Exploring Places – from Concept to Interface) and TileMill/MBTiles (Chapter 7, Mapping for Enterprises and Communities).
|
Configuration time |
Execution time |
Visual quality |
Stored in a single file |
Stored as image directories |
Suitable for labels | |
|---|---|---|---|---|---|---|
|
QTiles Plugin |
1 |
3 |
3 |
No |
Yes |
No |
|
GDAL2Tiles.py |
2 |
1 |
2 |
No |
Yes |
No |
|
TileMill/MBTiles |
3 |
2 |
1 |
Yes |
No |
Yes |
|
GeoServer/GWC |
3 |
2 |
1 |
No |
No |
Yes |
You will need to pay some attention to the scheme for tile storage that is used. The .mbtiles format that TileMill uses is a SQLite database that will need to be read with a map interface that supports it, such as Leaflet. The QTiles plugin and GDAL2Tiles.py use an XYZ tile scheme with hierarchical directories based on row (X), column (Y), and zoom (Z) respectively with the origin in the top-left corner of the map. This is the most popular tiling scheme. The TMS tiling scheme sometimes used by GeoServer open source map server (which supports multiple schemes/service specifications) and that accepted by OSGeo are almost identical; however, the origin is at the bottom-left of the map. This often leads to some confusing results. Note that zoom levels are standardized according to the tile scheme tile size and resolution (for example, 256 x 256 pixels)
We will now use the QTiles plugin to generate a directory-based ZYX tile scheme cache. Perform the following steps:
Install QTiles and the TileLayer plugin.
QTiles is listed under the experimental plugins. You must alter the plugin settings to show experimental plugins. Navigate to Plugins | Manage and Install Plugins | Settings | "Show also experimental plugins".
Run QTiles, creating a new
mytilestileset with a minimum zoom of14and maximum of16.You'll realize the value of this directory in the next example.
You can test and see whether the tiles were created by looking under the directory where you created them. They will be under the directory in the numbered subdirectories given by their Z, X, and Y grid positions in the tiling scheme. For example, here's a tile at 15/9489/12442.png. That's 15 zoom, 9489 longitude in the grid scheme, and 12442 latitude in the grid scheme.
You will now see the following output:
Create a layer description file with a tsv (tab delimited) extension in the UTF-8 encoding. This is a universal text encoding that is widely used on the Web and is sometimes needed for compatibility.
Note
Note that the last six parameters are optional and may prevent missing tiles. In the following example, I will use only the z parameters, zmin and zmax, related to map zoom level.
Add text in the following form, containing all tile parameters, to a new file:
title credit url yOriginTop [zmin zmax xmin ymin xmax ymax]
For example,
mytiles me file:///c:/packt/c1/data/output/tiles/ mytiles/{z}/{x}/{y}.png 1 14 16.In the preceding example, the description file refers to a local Windows file system path, where the tiled
.pngimages are stored.
Save
mytiles.tsvto the following path:[YOUR HOME DIRECTORY]/.qgis2///python/plugins/TileLayerPlugin/layers
For me, on Windows, this was
C:\Users\[user]\.qgis2\python\plugins\TileLayerPlugin\layers.The path for the location to save your TSV file can be found or set under Web | TileLayer Plugin | Add Tile Layer | Settings | External layer definition directory.
Preview it with the TileLayer plugin. You should be able to add the layer from the TilerLayerPlugin dialog. Now that the layer description file has been added to the correct location, let's go to Web TileLayerPlugin | Add Tile Layer:
After selecting the layer, click on Add. Your tiles will look something like the following image:
In this chapter, you learned the necessary background and took steps to get up and running with QGIS. We performed ETL on the location-based data to geospatially integrate it with our GIS project. You learned the fundamental GIS visualization techniques around layer style and labeling. Finally, after some consideration around the nature of basemaps, we produced a tile cache that we could preview in QGIS. In the next chapter, we will use raster analysis to produce an operational layer for interaction within a simple web map application.