QGIS 2 Map Editing Basics
Never used a map‐editor? They’re… different.
This guide is presumptive
Guides/tutorials on map editing are generally bewildering or scattershot. Probably due to the mass of information involved. This guide will make a map that looks good and will give you some basic starts for editing. To do that, the guide makes sweeps across whole areas of information. For example, if you don’t want to edit a map of the United Kingdom, I’m not going to tell you how to find other maps—that would deviate too far from the through‐line. Feel free to turn your own ends if you want.
Essential background
Especially if you’ve never tried map‐editing,
Map editors are like photo and vector editors combined
If you understand the concepts of layers and and how points can make a path, which can be filled if enclosed, and the basics of text manipulation like fonts and sizing, that will help
Unlike most other media‐editors, map editors do not work with data in memory only
There is too much data to hold. So even individual layers in a map edit will usually be held in files
It helps to know about how data structures similar to XML/HTML are stored in memory
You don’t need to be an expert, but as long as you are not scared by seeing a file of XML code, and understand that an ‘object’ can have ‘attributes’, that will help
Map editors have special concerns
Map editors have huge chunks of interface to deal with issues that other editors barely touch on. For example, the underlying coordinate system of a land‐map—how it relates to the ground it is supposed to map, leads to a mass of configuration options. And they have unusual interfaces for styling results—land‐maps do not need free‐form drawing, but they need extensive systems for editing paths and managing symbols
Map‐editors can be crude and/or obscure for conventional configuration and editing
The other side of their unusual concerns. You can be left wondering how to do work that would be simple in other editors
Map editors are heavy‐duty
A single land‐map may contain twelve layers, which each define different features such as altitude marks, roads, tourist spots and so forth. Each layer may contain four thousand or more pieces of information. Frankly, map editors dislocate and crash all the time
Some upshots: when editing maps make yourself save areas. Think of an organisation strategy for data, choose filenames you can work with. Save work regularly.
Filetypes
One of the unusual concerns for map‐editors is the way map data is stored. There are many forms. But here are the types you need to know about.
Shapefiles
These have several files in their structure. The files are written together into directories, and are usually best kept together. The most important files are,
.shx
Have text, but not readable. Meta‐form of the data
.dbf
plain text space‐separated table data. This form is a dBase/xBase file. Stores attribute data of features
.shp
binary data. Stores locations/geometry of map features
The binaries are uneditable without a dedicated Shapefile editor. The DBF files can be opened in a spreadsheet application. This may be useful for viewing (I’ve tracked missing data like this), but no spreadsheet application I own can write these files in a form that matchers the Shapefile spec.
GML files
Data in the form of XML files. Usually comes as one file,
.gml
Usually one huge file, containing annotation elements etc.
GML data may come with a GMF file which defines data form. Also, the files may be broken up into many more files than Shapefile data. I’m not sure why—possibly because GML files have more overhead than Shapefiles? A GML file should be easy to edit by any XML editing method, but XML editing is never fun.
GeoPackage
Geopackages are slightly different. They store as one file, but inside are arranged as a database,
.gpkg
Usually one huge file, containing annotation elements etc.
May gain a extra files, but trivial indexes/annotation, not like GML schema files. If direct viewing or editing needed, would be edited using a SQLLite client interface and SQL. There are well‐established and good tools for doing this, but it’s far too much for quick fixes.
Comments on filetypes
GML files,
would seem to be the modern solution
only need one or two files, so easier to manage
should be easier to edit directly
However, GML files,
introduce surplus data
are XML, so are loaded with schema definitions and similar complexity
(my limited experience) behave worse and crash more
I’ve not found a way to load them in bulk from a directory
QGIS tells me that GML files do not support deletion (can be a important factor)
GeoPackages,
contain everything in one file
full set of layers and style data, even projects, in one file
can be used in ArcGIS Pro (GeoPackage is an open standard)
considering what they are, are lightweight
are default in recent QGIS
given a simple data format and often only one file access, are often fast
However, GeoPackages,
are new
have little QGIS documentation
often need to use expressions for actions like ‘create layer’ and clipping (expressions also poorly documented)
if something goes wrong, need SQL to fix
GeoPackages are clearly the future. The only downside is complex direct view and editing. However, support is uneven and will take years to filter through. Shapefiles are lean and many tools are available. This guide mostly uses Shapefiles.
End of basics
Or maybe not. Before they irritate or trip you, let’s cover coordinate and projection systems.
Refs
Gnumeric notes on dBase information,
https://help.gnome.org/users/gnumeric/stable/sect-file-formats.html.en#file-format-xbase
GML format, by Wikipedia,