For New Jerseyans this is no trivial matter. Where does “North Jersey” end and “South Jersey” begin? Is there such a thing as “Central Jersey”? Numerous tractates have been dedicated to this topic, not to mention blog posts (yours truly has contributed to the discussion) and at least one documentary film.

All heretofore existing North-South delineations have followed county boundaries, with a few “swing counties” always in contention. Is Mercer county North or South? How about Middlesex? Monmouth? The issue resembles a Gordian Knot, getting tighter with every argument.

Enter my friend Randall Solomon, who happens to be the Co-Director of Sustainable Jersey and the Sustainability Institute at The College of New Jersey. Randy submits that the county-by-county approach lacks the granularity needed to properly address the issue. Much like Alexander the Great, Randy slices Middlesex county in half, and voila! Everything falls into place, everything now makes sense.

Not content to merely identify the North-South Jersey checkpoint, Randy also names it – “Hamburger Hill”. Also known as “The South Brunswick water tower”, this is the elevated point on Route 1 and Sand Hills Road in South Brunswick with a McDonald’s and a Burger King on either side.

Click here for a Google Maps map of Hamburger Hill. Below is my own North-South Jersey map, based on Randy’s Hamburger Hill postulate.

As Google unloaded SketchUp today, a discussion ensued amongst the georati about the meaning of the event and the usefulness of SketchUp as a tool. As is often the case, I was at odds with many.

While I was mistaken about the interoperability between SketchUp and AutoCAD (it exists on a technical level; I thought it did not), I stand by my assessment of SketchUp as a toy, and by my statement that if SketchUp were a useful tool for architects, Autodesk would have snapped it up, instead of letting it go to Trimble. Trimble?

The gist of my argument is this: SketchUp is an easy-to-use tool to create quick 3D visualizations. Nothing wrong with that. But these visualizations cannot be used in AutoCAD to create construction drawings because of the different accuracy specifications for a SketchUp sketch and a construction drawing.

There is a parallel in the world of digital mapping: Digital tax maps must adhere to a higher accuracy standard than a quick-and-dirty parcel digitization over aerial photos. If we need both a digital tax map and a GIS parcel layer, we are better off creating the tax map (higher accuracy product) first, and generating the GIS parcel layer from it. We cannot go the other way – we cannot generate a tax map from the less accurate GIS parcel layer. The less accurate GIS parcel layer linework is not reusable for the tax map project.

Likewise, even if we can import a SketchUp sketch into AutoCAD and generate a DWG file, the file will almost certainly be unusable for the construction phase of the project.

"BlackBerry? What is this, 2005???"

This is the typical reaction of my geogeek friends when they realize that I still use a BlackBerry. And they do have a point. Who uses a BlackBerry in 2012?

But that's beside the point. And my point is: How can Foursquare be unable -- consistently and repeatedly -- to locate me on my BlackBerry, while Google Maps and Facebook can? Some have suggested that this is not Foursquare's fault, but rather that my inferior device is to blame. I disagree with this very weak argument. If location is THE ONLY THING YOU DO, you better make sure it works on as many devices as possible.

Salespeople sell "easy to use". They have magical (often rigged) demos that blow the socks off the decision-makers. They promise increased productivity by orders of magnitude. They are well groomed and always on time.

But the salespeople don't tell their prospect who finds the product easy to use. Is it Jane who just got her computer science Ph.D. from Harvard, or is it Joe who has been in the same job for 35 years, started as a manual draftsman, and counts down the days to retirement? The salesperson doesn't go there. They move product, then they move on.

Then comes the tech. He must deal with the unrealistic expectations set by the salesperson. He must deal with the sobering reality that there are a lot more Joes than Janes in the real world. He must deal with the user's disappointment and often intimidation. He must deal with the user's boss's frustration with their employee. And he has to make it all work.

I say make the salespeople support the product they sell.

...

I write this as I am preparing for an upcoming training. I did not sell this one, so I don't know what the users' expectations are. I hope they don't expect "easy to use". 'Cause it ain't.

If I had a nickel for every time I have had to explain this to somebody…

There is an ongoing discussion among mapping professionals about the parcel data in Google Maps -- what this data layer represents, what the data source is, etc. At this point there are many unknowns, but one thing is certain -- these are not "property lines." Property lines, or boundaries, represent where a piece of property ends and the next one begins. A certain degree of accuracy is required for property boundary delineations. The accuracy of the Google Maps parcels in undeclared. As such, they cannot be construed to represent anything, really, much less "property lines."

[UPDATE 10:53 AM 03/14/2012] Several exchanges on the twitters helped me crystallize and fine-tune my point further. Which is: Mapping professionals know that the Google Maps parcel layer does not represent property boundaries. It is lay people who get confused. Due to its dominant position in search Google (unintentionally, I’m sure) conveys the expectation that the mapping (parcel) data they serve is authoritative, whereas in fact it is not.

Thanks to Don Meltz (@DonMeltz) and Bryan McBride (@brymcbride) for helping me tease this out.

While my poor cell phone pictures do not do this treasure justice, I here present to you a few photos.

I was prompted to write this post as the GIS blogosphere celebrated Mercator’s 500^th birthday two days ago. So I asked David for permission to post it. Not only did he give me permission, he offered yet another high-quality image from his map collection. Said David:

“Here is a scan of one of my prizes – the frontispiece portrait of Mercator from his first world atlas. I found it at a print shop in Boston about 30 years ago. Notice the tired eyes of the cartographer!”

Yes, I do notice. Thank you, David!

“The 200-foot notification application harnesses the power of GIS to improve municipal government efficiency. This technology allows us to accomplish in minutes what used to take hours. We can now do more with less, and we can serve our citizens more efficiently.”

As it should.

If you are a geek, or a geek-wannabe, you quickly learn to deride Windows and to avoid Microsoft products whenever possible. You run Ubuntu, or – if you are less adventurous than affluent – the Mac OS. If your applications only run on Windows, you are quick to point this out as the reason for your operating system of choice, lest you get ridiculed. If you are a die-hard Mac fan, you run Parallels Desktop.

The first geek commandment says: “Thou shalt despise Windows.” Yet the Windows caravan moves on, largely ignored by the open source community, as if ignoring Windows could make it go away.

But things have changed.

In her widely retweeted blog post, Sophia Parafina describes her experience with a set of open source mapping tools for Windows – QGIS, Postgres/PostGIS and TileMill. The confluence of a bunch of open source mapping tools for Windows is hailed as a game changer, and this is not an exaggeration. Open source web mapping, just until very recently the province of the hard-core geogeek, has suddenly come within reach of someone who doesn’t want to run multiple operating systems.

Sophia promises more articles. I can’t wait.