A Cartographer’s Gifkit

Posted by G.P. in Crazy on September 18, 2015

  1. When the colors, typography, labels, and features harmonize perfectly on each page in the map atlas you just created.
    whoa
     
     
     
  2. When one small change in the cartography causes a cascade of unintended consequences.
    andersoncooper
     
     
     
  3. Your reaction when someone in a frog suit tells you to make that color a little more peachy.
    kermit
     
     
     
  4. When your first d3.js interactive map actually works.
    cookie
     
     
     
  5. When someone tries to reign in your cartographic profligacy but you badass onward.
    stop
     
     
     

 

1 Comment

Huge Increase in Sharability by Combining Git and QGIS

Posted by G.P. in Workflow on August 31, 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. You can order online cheap Viagra that will help you get a strong erection in bed. 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

 

 

 

 

 

 

No Comments

foundational education vs pinnacle education

Posted by G.P. in Cartography Profession on August 20, 2015

In education there’s a debate over whether a student should start with foundational knowledge and build from there or whether they should start at a place (i.e., framework) that’s further along so that they can reach even higher at an earlier age than those who have to, for example, spend time memorizing addition and subtraction problems when they could have just relied on a calculator. (Apparently this is something they do in Sweden?)

Recently we in GIS land have brought up the question of whether a 12 week course that promises to teach you to be a data scientist is snake oil or not. Given: an advanced statistics degree is a huge accomplishment and we need some people who know those fundamentals.

The question is, though, what if we taught the tools (but not the theory, thus saving people time) to people who are experts in other disciplines? I think there’s definitely a place for modularized education like this. And providing this 12 week option–if the quality of the teaching is good–could enable more and better advances.

It’s kind of like saying: “we shouldn’t enable people without expertise in cartography or GIS analysis to make maps by providing shortened educational opportunities.” Well guess what? We didn’t provide shortened educational opportunities and still our entire profession has been up-ended over the past 10 years by people who have had virtually no expertise in GIS analysis or cartography.

The gut tells us that too much territoriality never leads to new thinking. If the 12 week course turns out to be a disappointment due to poor teaching that’s certainly something to complain about. But to complain about the spirit of the course? Perhaps that’s sour grapes.

potter

No Comments

Disclaimer Idea

Posted by G.P. in Crazy on August 7, 2015

 
I’m thinking something like this for your next cartographic disclaimer? Adjusted for mappiness of course.

 

No Comments

Too Much New Software, Too Many New Libraries, Even for the Nerds

Posted by G.P. in Cartography Profession, Design on July 28, 2015

minioncompute

I’ve been learning d3 and it’s been a fantastic learning experience. It’s a low-level javascript library for making interactive visualizations–including maps–inside SVGs for nifty client-side rendering effects of datasets that can be updated easily with new data. Incidentally, Scott Murray’s book Interactive Data Visualization for the Web is a fantastic first resource full of the most important bits to know and written in an accessible style.

So that’s been great, yes. But even the nerdiest among us have their limits to how much of their day, their week, or even their year, they can jam with brand-new material. And that leads me to my thesis, which is that when you are designing a new product or a new library or a new software, keep in mind that it isn’t just your computer laypersons who have to leap a mental hurdle to even begin working with your product, it’s also people who have just simply saturated their number of “new things” that they can handle that week or that month, even if they are supremely computer-savvy individuals who would really have very little trouble with your product.

In product design teams, the engineers and managers all have a tendency to think about the lowest common denominator when designing, and that’s certainly not a bad thing. But the computer scientists among us hit their limits from time to time too. So you’re not just in the business of making things simple for the newbies, your making your product easy to adopt by everyone.

My forays into d3 came at a time when I was granted a few hours of paid time to work on it, and that helped. It also came at a time when I was ready to really dive into something new. Don’t count on that being the case for all your users.

As usual I’ve reached the end of my little thesis statement with a feeling that it could be argued in the opposite direction as well (the downside of being analytical). So if you’d like to argue the opposite please go for it. And keep in mind the goal here: giving the best advice for teams building brand-new products as well as individuals who are building brand-new tools and libraries.

 


 

1 Comment

More Mark Twain, on His Paris Map

Posted by G.P. in Uncategorized on July 17, 2015

I previously wrote about Mark Twain’s Paris Map but I don’t believe I had come across this particular account of it in his autobiography at the time. I’ve been re-reading the autobiography lately and when I read the bit shown below I figured I should pass it along. It sets up the reasons why he made the map–in a fit of creativity resulting from the somberness of having just taken care of two people who ultimately died–and also goes into what he (imagines?) the map’s effects were on those who saw it.

 

TwainParisMapText

 

It seems as though Twain forgot to mention in this part of his autobiography the fact that the map had been printed in reverse. Elsewhere he says:

By an unimportant oversight I have engraved the map so that it reads wrong end first, except to left-handed people.

TwainParisMap

TwainParisMapText2

 

No Comments