I just got an announcement in my inbox of a major update to HIFLD Open. A number of new data sets have been added, along with updates to many others. The announcement also addressed HIFLD Secure, but I won’t touch upon that here. From the flyer attached to the email, here are the updates. If you are so inclined, it’s time to get scraping.
The 10-year anniversary of this blog is rapidly approaching and it is not lost on me that it has been laying rather fallow of late. I know others with long-running geospatial blogs have experienced similar situations at around the decade mark, and that only seems natural. If you are living your life well, the motivations and interests that prompt you to start an online presence such as this evolve over the course of a decade.
When I started this blog, it was simply to create the kind of resource that I had been looking for: code-heavy posts that showed how to accomplish tasks I was working. I did that in the hope that others would find it useful, but also to serve as my own personal archive. Now, such resources are abundant as companies and projects recognize the need to engage via blogs and social media.
Of course, all such outlets now seem to be some sort of “official” arm of a company or organization or project. It seems to be increasingly difficult to find a “sole-proprietorship” blog that’s being kept current. It’s not for me to say whether that is positive or negative. I speak from experience when I say it is difficult to maintain such a venture over time, and I certainly see where being part of a content team has advantages.
It’s something of a running joke that, you hand existing code to a developer, that developer will stay up all night completely re-writing it. I wish I could say it was completely a joke but, not only have I seen it happen numerous times, I’ve done it.
Counter-intuitively, some developers find it easier to use an existing application as a storyboard for a re-write rather than simply digging into the existing code. This is because programming is not only an extremely mental activity, it is quite psychological as well. When you are asked to take over existing code, as has happened to me a few time recently, you are not only learning the code, you are are also become familiar with how the previous developer(s) approached problem solving. You must train yourself to think like the previous developer in order to understand their approach.
It’s hard to believe, but I last touched upon this topic over two years ago, when my family and I were living in our between-houses rental. One of the goals I had when building our current house was to create a space where I could more effectively work from home. To that end, I have a dedicated office that I’ve been working toward optimizing for my technical work.
One advantage of a dedicated space, which I did not anticipate ate the time, is compartmentalization. One of the dangers with working at home is the blurring of the boundary between work time and personal/family time. In our old house, I definitely felt that as I was working from the dining room table. Now, I can more effectively shut the door and step away. I’m not perfect at doing that, yet, but I am getting better.
As a consultant doing federal work, I don’t get to work off-site all the time. I’ve been fortunate, however, to have worked a few projects over the past couple of years that have allowed it, so I’ve taken advantage of it as much as possible.
Recently, I had the occasion to attempt to generate an OGC GeoPackage from QGIS and publish it using GeoServer. The use case was fairly straightforward. I had been given data in GML format and needed to publish it. For many valid reasons (such as lack of spatial indexing), GeoServer does not natively support publishing GML data. As a result, I need to convert it to something that GeoServer did support.
QGIS opened and displayed the data easily and, from there, I could export it into any number of formats. (Or I could have used OGR.) The feature attributes had very long names and I didn’t want to lose that richness by exporting to shapefile. I was trying to keep my server-side life simple, so I was hoping to avoid setting up an RDBMS data store for this purpose. It was then that I noticed QGIS supports exporting to GeoPackge, so I decided to give it a go.
For purposes of this post, I am using a shapefile of building footprints of Leonardtown, Maryland. The process is the same for a GML file, however.
As shown below, you initiate the process like any other by right-clicking and choosing “Save As…” in the context menu.
Aside from a day at the Esri Federal GIS Conference, I’ve been laying fairly low from geo industry events for about the past year. There’s no single reason for that; it’s been more that a combination of things like work deadlines or family happenings have taken priority over conflicting conferences and events. I’ve generally been watching from afar, finding tweet streams and their attendant embedded links to be particularly effective.
I had been considering heading out to San Diego for the Esri user conference this year. It’s the largest gathering of geospatial people in one place every year. Even if you are not an Esri user and can’t attend the event itself, it’s worth going and being in the vicinity as 15,000 geographers descend on San Diego. Even Mapbox is getting into the game on this.