Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration

Beyond The Core Knowledge of Cartography

October 26th, 2016

 

It’s difficult to teach cartography as an expert because there are fundamental concepts that one can easily forget to impart on the students, though this can be ameliorated somewhat by following a comprehensive guide to core knowledge areas such as The GIS&T Body of Knowledge*. Even so, there are certainly some concepts that nobody anticipates struggling with, teacher or student, that are unique to each project undertaken. To tackle these project-specific struggles the cartographer must possess a certain amount of patience, research prowess, and a passion for discovering new solutions through a willingness to test and revise.

It’s these project-specific issues that I haven’t written much about on this blog, instead focusing on fundamentals like typefaces, colors, and layout. Thinking about this hole in my writing, I decided to take notes while creating my most recent print map. Hopefully these notes can be instructive in not just detailing specific solutions to specific problems, but also in providing a more general picture of the types of things that come up in a typical cartography project.

These notes include ideas on skills employed, issues encountered, and paths not taken. Here is the map, in reduced resolution, because it is not considered a fully finished product just yet. The final version will be somewhere around 8-10″ on a side. The notes follow.

 

LewClark

 

PROJECTION USA contiguous Albers equal area conic, an easy choice for the display of the contiguous U.S. and distances should be fairly accurate for the middle latitudes, which are inclusive of this data. This is important since I’m running some distance calculations and reporting on them in the layout, though of course I can always conduct the calculations separately from the display projection by simply starting a new GIS project with a different projection. In this case both needs are met with the one projection. So here I’m thinking, “does the projection look right? Does it calculate right (i.e., not distort the things I want to measure)?”

 

TRAIL DATA The trail line is a subset of linework from a university teaching database and I have not thoroughly explored its validity though comparisons by-eye to other maps of the journey show at least a superficial agreement. My need to trust this line is a problem. What if it’s wrong? How many times to cartographers blindly use data without complete knowledge of it’s correctness? In this case I’m helped by the fact that my partner in this project is a historian who can do some verification for me. In any case, verification of data should be a part of every cartographer’s workflow.

 

LINE RESOLUTION AND DISTANCE CALCULATIONS Another potential issue with the line trail data that crossed my mind was the issue where perhaps the line-digitizer made the line too “squiggly,” perhaps due to an unsteady hand (red line in the zoomed-in example below). If this were the case, then the distance calculations could show the Lewis & Clark crew going much greater distances than they really did. A worry, indeed, and next on my list of things to take a close look at. (Of course, conversely, distance calculations coming from a simplified line would under-report the true distance traveled.)

 

One section of the trail. The non-dashed black line is the real data, the dashed black line illustrates how distance would be too-low if calculated from a simplified line. The red line indicates distance would be too great if calculated from a line with inaccurate and artificially high numbers of vertices.

One section of the trail. The non-dashed black line is the real data, the dashed black line illustrates how distance would be too-low if calculated from a simplified line. The red line indicates distance would be too great if calculated from a line with inaccurate and artificially high numbers of vertices.

 

TERRAIN DISTANCE On a related note, the terrain distance can be much different from the straight-line distance for each segment. The straight-line distance over a ravine is shorter than the traveler’s distance, since they presumably hiked down and then back up the ravine on the other side. In the elevation profile, the true terrain distance is reported. This may account for the fact that my total mileage is greater than the total mileage reported elsewhere for this expedition.

 

LINE SPEED INSET: for this kind of visualization, sometimes we see the width of the line changing by speed but most often it’s depicted with a sequential color scheme instead. I’ve chosen to go with a pseduo-sequential color palette so that all the colors are clearly visible in the small space. The boldness of color needed for the size of the space is an interesting consideration that I haven’t written about before. In this inset, the expedition’s speed is calculated from a length field divided by a to/from date field converted to # of days per segment. This length field isn’t terrain-distance and thus could be a source of error. The inset still serves as a good at-a-glance comparison of the relative time it took the expedition to traverse each segment. The placement of the inset came from an inspiration map. Maintaining a rich library of inspiration maps is a must.

 

PAGE EFFECTS Who knew that you’d need to figure out how to create squiggly lines in Inkscape to evoke old parchment edges? Nobody, that’s one piece that can be learned on-the-fly. Also, get good at finding svg or raster textures to use as backgrounds, especially on these historic map styles. I’ve also seen lots of textures on contemporary map styles, usually in grided dot patterns. (Hint for the squiggly line page border: draw a rectangle and then use Filter>Filter Texture>Rough and Glossy and fine-tune the result with the Filter Editor as the Inkscape filters often default to startingly bold results.)

 

PROFILE GRAPH Exporting a profile graph is possible using a QGIS plugin called the Profile Tool. You can also create profile graphs with ArcMap’s Elevation Profile Add In. The tables of profile data that are produced for each segment of a given line can be exported to spreadsheet software to produce a nice looking graph (the graphs that are automatically output from these aren’t really suitable for a well designed map layout.) Using spreadsheet software (in my case, Excel) I made a graph, switched the progression to East–>West since that’s the direction they were headed, and further styled the graph in Inkscape. This was a process that probably took half a day or more from researching tools to implementation to styling. I even used a pen tool set to smoothing 25% to trace over the excel-derived profile line in order to create a more pleasing line (since my original profile had a point for every mile along the 4,000 mile route and created quite a jagged looking profile line.) Switching a profile graph’s direction to suit the data was a mental hurdle, overcome only by thinking, thinking, and more thinking about the data and the story I was trying to tell. This is something we’re always talking about: know your data, think about your story.

 

TYPEFACES The typefaces are chosen to complement the historic look of the map. Gabriola is used since there’s limited text and its decorative nature seems to suit the overall style. There are Myriad other fonts I probably could have used, and likely a better one will crop up as I revise. (The Myriad reference, ahem ahem, is a little type joke for the type nerds.)

 

X AXIS LABELS The x axis labels are problematic and will need to be redone. They depict distances at the segment end points, which is useful, but too jarring in the context of an x axis, which traditionally shows a smooth progression of numbers. An experiment gone awry. Sometimes, oftentimes, our experiments don’t work out. Note the axis lines and labels are in a medium-dark gray. I want them to remain firmly in the background as supporting information.

 

PROFILE LINE COLOR I considered changing the color of the profile line depending on the altitude. Green at low altitudes, progressing to brown, and finally white at the highest altitudes. A hypsometric tint for a profile chart! This seemed a bit much though, given the complexity of the rest of the page.

 

COLORS AND PRINTING The saturation of the hillshade will likely need to be adjusted once I see this printed on the final medium. It looks good on my screen but vast experience with this shows me that it can likely look too dark or too light depending on the press and the paper. Web designers have it easier in this respect. They’ll go on about how every monitor is different and that phones produce glare outside. But that’s nothing to needing a perfect print out on one media type and getting it wrong. There’s no excuses when it comes to printing a map in a known format (in this case, the map will be in a book so I will need to do a lot of exacting color proofing when the proofs come in.)

 

COASTLINE The overly stylistic coastline with drop-shadow was chosen specifically to comport with the historic style, though you’ll notice I didn’t interpret “historic” so literally so as to include such unfounded ornamentation as author cartouches or sea dragons. One must have boundaries. (Joke: boundaries, coastline, ahem.)

 

LET GO OF YOUR STYLING DARLINGS I am so hung-up on water=bright blue that when I began the map I of course made the water a very bold solid blue. It took several days of mulling over before I realized that was all wrong for this map. Pouring over the file of inspiration maps that I’ve been keeping for this project, it took only a few minutes to come up with an alternative to the blue, but only once I knew what I was looking for. This seems to be a frequent problem for cartographers who have a wide repertoire of map styles. They can intermingle to the great detriment of the final map unless time is taken to think things over. Knee-jerk styling such as my dark blue ocean (a modern map color for oceans) is only helpful if you keep to the same style-genre (e.g., historic, modern) all the time.

 

This wraps up my notes on the making of this map. Hopefully there will be a few bits you can use in your next project.

 

*The GIS&T Body of Knowledge is a great reference document when interviewing for a new GIS position. Use it as a check-list, checking off areas you have a firm understanding of and noting what subjects you need to study more.

 


 

City Maps: recent debate and details on its making!

May 23rd, 2016

——————————————————————————–
Note 8/3/2016: Not long after writing this post I came to my senses and revised the coloring book. “Ha ha,” you say. “After all the defensiveness in this post you actually revised the book!” And you are right to laugh, but let me explain.

As is typical in cartography and perhaps all subjective media, the criticisms thrown at the book were highlighting a deficiency but not quite hitting on the exact problems. In this case, after an immense amount of thought and hang-wringing, I realized that the real problem was with the linework. And so I fixed that linework to the best of my ability and released a revised book interior in July 2016. The details on that revision are here.
———————————————————————————

 

A few constructive criticisms have surfaced regarding the coloring book City Maps: A coloring book for adults that I released less than two months ago. I’m going to address those criticisms in this post.

In the less than two months of its existence, it has done phenomenally well as far as I’m concerned, with more than 2,000 copies sold and write-ups in The Atlantic’s City Lab, GIS Lounge, GIS User, Curbed and more to come in the months ahead. Furthermore, it went a bit viral over on Facebook following the City Lab article for at least a week to the tune of 14,000 shares (say what?!).

For this book to have sold 2,000 copies around the world in less than 2 months is amazing and is what I’m focusing on in terms of whether I consider it a success or not (I unequivocally do). Check this awesomeness out:

No1InMeditation

And at one point it was near Harry Potter in sales! Ok, for just a few days, but heck yeah for coloring books!

 

However despite very strong sales, the book just recently got some very intriguing criticism from a few people that I’d like to address.

We’ll disregard a couple of the critical reviews that were just outright scammy and focus on the few that had specific issues with the book.

As far as the honest comments were concerned, one said the maps appeared to be copied and pasted in the span of 30 minutes, one indicated that they thought the maps weren’t accurate, and another discussed some feature size, labeling, and dangles issues.

Map Making Procedure

Starting with the comment on procedure, which purported to be from an urban planner. I’m not really sure how a person would copy and paste map data as this person thinks, but I can assure you if that were possible then a book like this would have been created long ago. I’d like to take a moment to describe the exact procedure for creating the map pages, since I think it is instructive for those who read this blog for tips on map-making as well as addresses this criticism specifically.

The book was created in a highly focused manner over an extremely intense span of about 80 hours plus revision time after that. During those 80 hours, OpenStreetMap extracts for all the major metropolitan areas of the world were downloaded. My familiarity with OpenStreetMap data helped in this regard because I knew how to obtain it, in what format (I used osm2pgsql data for this) I wanted it, and what the fields and tags mean as well as how to query for the right mix of data such as primary roads over residential or querying out urban area polygons so that they didn’t appear, and so on.

All this data was imported into separate QGIS projects where suitable locations were chosen with the following criteria: (1) good density of information (OSM data is not always complete in some locations) (2) a place that made sense to color either from a famous-landmark perspective OR from an interesting-shapes perspective. These locations were researched to determine a place name (the beginning of the book caveats that place names are subjective nevertheless as locals may have different names, but these names are adequate for the layperson to look up the location on online mapping platforms if they are interested in what a particular shape represents, for example). They were also researched to ensure that they were adequately representing the area and depicting something interesting and, hopefully, non controversial.

A local projection for each location was researched and applied to each project. The data were massaged so that a good mixture of spaces to color and lines representing real-world locations came though. This was not always easy to get exactly right and I think that in some places it may not be what people would expect and could be better. Each image was exported at 600 dpi for inclusion in the final book.

The final portion of the procedure was book layout. I was aided in the fact that I’ve published before and know the ins and outs of layout. So, because this book was very simple layout-wise, I was able to do this in the easiest manner possible, using a pre-formatted template in Word that was designed specifically for my two destributors: Ingram (everyone but Amazon’s supplier) and CreateSpace (Amazon’s supplier). Cover files, which include front, spine, and back, I created in Inkscape to the exact specifications for each printer (they are different for each) and created for the width appropriate for the paper thickness and the number of pages so that the spine fits almost exactly. Due to printer error-margins the spine has a bit of error-space as well.

I already have accounts with my two major suppliers – Ingram requires quite a few signed documents that I was thankful to have already taken care of years ago – so the process for handing over the interior and cover files was straightforward for me. A new person to this process has a much harder time so this definitely saved me a lot of time. After that it is a matter of waiting for proofs and revising those proofs until I was happy. For example, initially the width  of some of the line features was not adequate on the presses. I increased the weights for some, decreased the weights for others, and just in general evened things out if there were large discrepancies between feature width on the same page for many of the pages. Though it must be noted that I did leave some variations in line-widths to comport with what you see in existing adult coloring books where there are some thick and some thin lines to create a visual variety.

With that I think I’ve adequately addressed procedure and perhaps shown that it would have been absolutely impossible to “copy and paste” a book like this together. Next up is the accuracy issue.

Accuracy

A critic said that the maps lack accuracy. Let me speak to that as best I can as I don’t have any more information regarding what exactly they found lacking in this regard.

The copyright page lays out, perhaps too succinctly, the necessary disclaimers regarding the mapped data. The copyright page, in retrospect, may not have been the best place for this information as it may easily be overlooked. I squeezed all the text information onto that page in order to reduce page count so that I could maximize the coloring pages while keeping the cost quite low – at $9.99 US.

The copyright page points out the following:

Information printed in the front matter.

Information printed in the front matter.

That information states very clearly that the map data is from OpenStreetMap, indeed that what we are talking about is “data” and is as accurate as the chosen dataset. In my professional opinion, the OpenStreetMap data is reasonably accurate in the locations that were chosen for a coloring book. The aim for the book was to include at least one map from all of the top 10 largest metropolitan areas of the world, though in the end I did have to leave out Osaka due to a lack of a proper density of data for coloring. All the other metropolitan areas of the world are included, plus a smattering of other interesting locations such as Boston, Vancouver, and Venice. Ensuring that all the most populous metro areas were included was a way of making sure that I covered the globe, so to speak. There are other “great cities” books which focus on only those cities that Western  cultures are familiar with traveling to and from and I wanted to be more representative of the real world.

That’s why, if you are from the U.S., you might be surprised to see that a coloring page for a portion of Manila is included, for example, as this might be a place that isn’t high on your “to visit” or “have visited” or “have studied” list of cities. But it is one of the largest metro areas in the world. Also, I had at least one book buyer who was from Manila and who was happy with this inclusion.

In terms of accuracy, I first wondered if perhaps the critic might be too used to seeing Google Maps, which uses the Mercator projection. The maps included in the City Maps coloring book are each projected to a local coordinate system that is appropriate for the location, not Mercator, which is notorious for its inaccuracies with regard to shape and area and is used in webmapping systems primarily because it became the default projection for them after the first webmapping platforms employed it as an easier mathematical solution to their map tiling needs.

Let’s take a look at this in detail. The very first map in the book,The Palace Museum in Beijing, China (also known as The Forbidden City), is shown here in thumbnail form:

Thumbnail version of the first coloring page.

Thumbnail version of the first coloring page. Beijing – The Palace Museum

A close-up of the southeast corner of this map is shown below:

Southwest corner of the coloring page

 

 

This map is in the projection Beijing 1954 / Gauss-Kruger zone 20, also known as EPSG: 21420. The Mercator equivalent of the same location on Google Maps appears like this:

Mercator Aerial

Mercator Aerial

In this particular location and scale I don’t see too much difference between the projections and I see that the mapped data from OSM appears to be fairly accurate, though of course not every single feature is mapped.

In the coloring page close-up we see a few issues with overlapping lines at the southern portion of the page. This is definitely an issue that may be cleaned up in a future edition. It’s an artifact of OSM data wherein many people may map different cultural tags for the same location. One person may have mapped just the general location of The Palace Museum with an outline, for example, while another OSM contributor may have mapped the individual stalls. Many many of these artifacts were cleaned during the production of the book via teasing out the individual “tags” (in OSM parlance a tag is how you describe what the mapped location is) such that things like urban areas or shipping lanes, for example, weren’t included. They tend to confuse the map reader, who doesn’t expect to see lines in the water even though they do signify real things. I do think that further cleaning of this sort is warranted and I hope to ameliorate this in the future. Does it preclude your use of the book for coloring? That’s for you to decide.

Now let’s take a look at Manila since I’ve mentioned it already. That particular location was difficult because the OSM data for it wasn’t as detailed as in other locales. So this map is at a smaller scale and includes line features only where “water” = ‘river’ (not road lines) and all polygon features. The interstices of the polygons reveal the road network at this scale. A thumbnail version of the page is shown here:

Manila - Port Area

Manila – Port Area

The southeast corner of this map looks like this:

Manila Port Area southeast corner

Manila Port Area southeast corner

 

This map is in the PRS92 / Philippines zone 3 projection, also known as EPSG: 3123.

And here’s the aerial of the area (Mercator projection, from Google Maps):

Manila-aerial Port Area

Manila Port Area, Aerial

 

Here’s the Google Map of the same location:

Manila Google Maps-Port Area

Manila Port Area Google Maps

 

I think that the projection differences at these scales may not be enough to cause someone to say that the maps are “inaccurate” so perhaps my thesis on this being the issue is incorrect.

At any rate there are certainly some differences between OSM data and other mapped data, and that may be where we come into conflict with what people might deem to be “accurate” vs. “non.” When we do compare the maps shown above, though, we see a close-enough association, in my mind, for the colorer.

A NOTE ABOUT AUDIENCE I’m bolding the word colorer because this is where I want to talk a little bit about the audience for the book: the colorer. I’m forever talking about “know your audience” when it comes to creating a cartographic product. We must ask ourselves what our audience is expecting, how they need it to be presented for maximum informational absorption, and what we can bring to the map that adds to the audience’s experience and knowledge-base in a positive and efficient manner.

After hounding this in to countless people–most recently up in Manitoba where I gave several talks/workshops to the municipal government and planning association–I’m ashamed to say I may have misjudged the audience for this book given some of the feedback I have received! I believe that the primary audience is the mindfulness adult colorer and I still believe that. What I failed to grasp was just how many people would become a secondary audience for this book: those who are map nerds/cartographic enthusiasts who will  be sticklers for accuracy at the expense of coloring quality. For this secondary audience I should have made very clear, in a special section at the beginning of the book, exactly how the book was made, what the potential pitfalls are, and my reasoning behind not including labels, choosing the locations, constraints, and so on.

Small spaces, labels, and dangles

One criticism was actually with regard to the primary audience: those who want clear spaces to color. This critique focused on the fact that in some of the maps there are some spaces that are too small to color. In particular I point to an example from the Bidhannagar map:

Small locations on the Bidhannagar page, actual size.

Small locations on the Bidhannagar page, actual size, Asia South Lambert Conformal Conic, EPSG: 102030.

 

Bidhannagar Google Maps

Bidhannagar Google Maps, Mercator projection

When you compare the two maps, you can see in the coloring book page that there are fewer roads. This is because I only included polygons on this map. In this case I felt the polygons adequately represented major roads in their interstices, just as with the Manila coloring page, and also that including roads in this location would have caused a huge density issue (way too many small spaces to color). A few of the smallest polygons shown in that snippet at the above-right, are indeed too small to color. A closer look at the data reveals that these particular polygons are all tagged as water. A filter to get rid of polygons smaller than a particular size would have been in order here.

This was a compromise on my part having to do with the amount of time I had available to me and it may have been a poor decision. I do know that at least one person has shown me her colored version of this page and she simply colored right over these smaller boxes. The lines show through the color and seem to still look okay to me. I know from reading hundreds of coloring book criticisms that there are colorers who don’t mind small spaces, some who abhor them, and some who criticize if the spaces are too large (i.e., more like a child’s coloring book). It seems very difficult to get it just right on this score and I hoped that the compromises I made here were good enough. That said, it may be something to take a closer look at in a second edition if I do one.

Labeling of the maps is something that has come up a few times from a few cartographers I know. The maps in this coloring book are not labeled and this was a purposeful decision, again, with respect to the audience primarily being concerned with coloring. I didn’t include labels since those really get in the way of the coloring experience. I’m inclined to disregard this particular notion because for this primary audience of the adult colorer, I think that labeling would not be good.

Line dangles are definitely an issue in some of the maps. They were very difficult to get around considering the scale of the maps, the data, and the fact that many of the maps feature extra-wide road casing in order to make the roads colorable. These road casings do stick out into water locations on some pages. In another edition these definitely need to be cleaned up manually in Inkscape. I’ve wavered over whether to pull the book from the market to fix this particular issue, but I am convinced that the ROI on this is not enough to make this worthwhile. If there comes a time when I want to completely update, add new maps, and so on, then I will address this. In the meantime, I think that for the price, quantity of maps to color, and the interesting places to explore (I know many who have looked up the maps to discover more about a place), this book is more than worth the price. I’ve thoroughly enjoyed coloring most of the pages myself despite a few line dangles on some of the pages. I could fix them but considering my already too-booked schedule of consulting and speaking I just didn’t find that it would be worth it for the small increase in satisfaction that it would give to the sticklers. I’m thinking I may slightly edit the book’s description on the Amazon page to ensure that nobody incorrectly buys it thinking that it is a detailed road atlas or anything remotely similar.

City Maps constitutes a mash-up of two popular genres: adult coloring and cartography. This concept had never really been put forth in book format, in our recent past, before*. As such I believe these few critiques stem from the fact that it is a unique and interesting type of book and this kind of unique product will always bring with it a healthly amount of skepticism from those who may have expected something a little different. The hundreds of privately and publicly posted expressions of enthusiasm, support, and positive critiques has helped greatly to outweigh these issues addressed here but no good cartographer should create a product without a thorough look-back and lessons learned for the future as I’ve done here.**

 

*Apparently someone created a city maps coloring book 400 years ago?

**I propose that cartographers in production work incorporate some sort of “code review” and “retrospective” process (terms borrowed from software engineering).

 

***********

Huge Increase in Sharability by Combining Git and QGIS

August 31st, 2015

SourceTree2
After tweeting today about the Unmitigated Amazingness that is a QGIS + Git workflow, someone suggested that I write a blog about my experiences in this regard. Unfortunately today is a deadline day for a portion of what will become my next book* so I can’t put a lot of time into a full-blown explanation of how this workflow will CHANGE your life. But I can give you a taste.

To that end, in a nutshell, and realizing I might be leaving out some important bits of information and because I suspect there are a lot of people out there who’ve never used this workflow before in their life, I’m deliberately not using the technical Git terms pull, push, etc., just to keep it simple:

  • You begin by installing Git on your machine
  • Unless you want to use command-line Git the two choices that I’m familiar with are the following combinations: Bitbucket for your online stuff** and SourceTree to manage updating that stuff OR GitHub for your online stuff and GitHub Desktop to manage updating that stuff
  • You create a project (aka “repo”) on Bitbucket or GitHub
  • Copy it locally via SourceTree or GitHub Desktop
  • (alternatively you can create it locally and then create it in the cloud)
  • I suggest that all the geodata you’ll use goes in one folder within the repo while all the QGIS projects you create go in another, any images or other odd things that you need in your QGIS projects could go in a Misc folder
  • You do your work normally: create a QGIS project, add data, but do it all within that repo folder on your machine
  • Open SourceTree or GitHub Desktop on your machine and it’ll tell you that you made changes like that you added data and that you created a project, you can choose if you want all of that to be put in your Bitbucket or GitHub cloud. If you do want it up in the cloud, you use one of those programs to sync it up with your cloud repo
  • Your collaborators simply use their own SourceTree or GitHub programs to put that project and its data on their machine exactly as you uploaded it. If they make changes that they want you to see then they can also sync those up, then your SourceTree or GitHub alerts you about the changes

And guess what?! In this way your QGIS project and all the files it uses are easily synced with other people. You don’t have to zip anything up. You don’t have to locate all the places where you put your data because you’ve already put it all in that repo/geodata folder. There is NO repairing of data source paths on your collaborator’s end! Think of the possibilities! It is truly a wonderful thing.

Now, I really am sure that I’ve left a whole lot of info out while trying to create this simple bird’s-eye view of the process but hopefully this provides a taste of the possibilities so that you can go learn more. After using both the Bitbucket/SourceTree workflow and the GitHub/GitHub Desktop workflow I personally find the GitHub/GitHub Desktop workflow to be a bit easier. Its desktop program is a little more streamlined as it “exposes” less of the advanced capabilities.

————Edited 9/1/2015 to add: Soon after posting this a reader pointed out that James Fee and I had coincidentally written about similar topics on our blogs yesterday. His topic was spatial DATA versioning while mine was spatial PROJECT versioning. To be clear, the project-sharing that I’m talking about in this post doesn’t really involve changing data at all. In fact, what I’ve been doing is collaborating with someone else on cartography designs using QGIS, and we needed a way to see each other’s designs (i.e., QGIS projects) and tweak them and send them back and forth. So yes, while we do store spatial data in our git repos, we aren’t concerned about that data changing, just really the styling of the data within the QGIS projects themselves. Fee explains much better in his follow-up post GIS and Git. ————

*First public hint about my next book: it will be about cartography! 😉

**Highly technical here

 

 

 

 

 

 

How to Win Friends and Use QGIS

March 16th, 2015



I had the opportunity to speak at a great conference last week: the Free and Open Source Software for Geo North America (FOSS4G NA 2015) conference. With over 400 enthusiastic people getting together to talk about geo software in the opensource realm, it was a big success.

My talk was on using QGIS and had a somewhat unusual format in that I switched back and forth between quotes from Dale Carnegie (of How to Win Friends and Influence People fame) and a live demo of the making of a complete map using QGIS 2.8.

Check it out here and when you’re done head over to the FOSS4G NA 2015 YouTube channel to see all the other fantastic talks. The content taught in this talk will be expanded and made into a tutorial for the upcoming Maptime Boulder (sign up here) and also posted online sometime in April for everyone.



2015 GeoHipster Calendar

November 6th, 2014

At Boundless, we put together a nice and subtle world-wide basemap for our new product: Versio. It’s meant to be a basemap that shows you where your data is but doesn’t get in the way, thus the quiet color scheme coupled with ample data from OpenStreetMap.

A stitched together series of screenshots at about zoom level 14 in the San Francisco region provided a good entry for the 2015 GeoHipster Calendar and I’m pleased to announce that it has made the cover.

GeoHipster_2015_calendar_cover_layout

While I was the main designer for the map, we all know that cartography is only as good as its underlying data, and in the case of dynamic maps, as good as its underlying infrastructure. That’s why the map was really a

team effort by all of the Versio team at Boundless.

A short background on the map in case you’re interested: we used imposm3 to obtain a world-wide OpenStreetMap dataset with a customized mapping.json file that allowed us to get some generalized data for roads and things for the lower zoom levels while still getting the non-generalized data for the higher zooms. We also used quite a bit of NaturalEarth data for the lower zooms, including a raster hillshade for the ocean overlaid with a semi-transparent ocean layer to make it more subdued. Most of the labels are not cached, they are dynamic so that we don’t have any issues with double labels or labels cut off at tile edges. Because we aren’t using too many labels in the dynamic label layer, this doesn’t seem to affect performance. The map was made with most of the OpenGeoSuite components, including–yes, I’ll say it–SLDs that I basically edited by hand. GeoServer serves up the data + SLDs, PostGIS holds the OSM data, the NaturalEarth data are kept in shapefile format, geowebcache cuts the tiles, and OpenLayers shows them off on the webmap.

Making a basemap with OSM data, some notes

June 22nd, 2014

Creating a zoomable map with openstreetmap data that covers the entire world is doable even if you’re a single-person entity without your own server infrastructure. You’ll have to use a provider like AWS to scale up to the level of performance that you’ll need, of course. As with any cartography project, minding the data becomes about 50% of the work and multi-zoom basemaps of the world are certainly no exception to that rule.

blogpostosm

A tool like imposm or osm2pgsql is usually required to parse data from a source like geofabrik (pbf). At Boundless we’ve had some great success with imposm3, though it is still in the experimental phase, but so far proves to be much faster than imposm2. The benefit of imposm is that you don’t dump everything into 3 tables like osm2pgsql; instead you dump it into any number of tables based on data type, usually around 25 tables (you customize the download via a json file with whatever parameters you want to specify). This makes querying faster. You also get “diff support,” which means that you can easily incorporate updates from OSM diff files, thus enabling easy updates however often you want to update. (We haven’t tested that in imposm3 yet.)

Going along with the “data is 50% of the project” maxim, you need to become familiar with PostGIS in order to deal with this data. You need to be able to use a viewer like pgAdmin and/or get familiar with the command-line tools both for viewing the tables and their contents so that you can actually use and style the data but also to manipulate the data if needed.

For example, performance is often enhanced if you create attribute indexes on any attributes that you are using for styling. Let’s say I’m showing parks at a high zoom level. My GeoServer SLD that contains the styling rules for my map might specify that type=parks in table landusages needs to be green with a dark green outline. The table landusages may benefit from an attribute index being created on the type field.

blogpostosm3

Personally, I believe the very best way to get familiar with all the tools that I’ve mentioned above is to play with them yourself in a real-world environment. For this my favorite two options are 1) learn on your own (I love Boundless’s new online training courses) and 2) attending a maptime near you. And on a final note, don’t try to download and parse the entire world’s worth of OSM data your first time. 😉 Start with a city, county, or small state of interest and scale up from there.

Spending even a few nights beginning to fool around with OpenStreetMap, imposm2 or imposm3, PostGIS, and/or GeoServer will make you more marketable. Investing in this knowledge acquisition will certainly pay dividends.

Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration