Automated Document Creation and Typesetting with LaTeX

Creating a new document class file and then using this class is usually considered the “correct” way to typeset a form or other document generated with data in $\LaTeX$. However, there’s also the quick-and-dirty method of creating a regular $\LaTeX$ document every time in a script using some sort of string concatenation and then typesetting this, which also has its merits. When a class file is used, the class describes the document look and structure; a new $\LaTeX$ document still needs to be created each time to define the data. Not writing a class file and placing the document look and structure typesetting code directly in the generation script isn’t as clean as the class method as it mixes styling with data, but it does make some things easier. The quick-and-dirty approach doesn’t require knowing the additional $\LaTeX$ language features needed for creating a class, using only what would use in a normal document. In particular, it is useful for automatically generating documents that change in structure based on the input data or other more complicated logic. This can obviously all be implemented as a $\LaTeX$ class since $\TeX$ is a Turing-complete language, but general purpose scripting languages such as Python are easier to use for this, particularly since most programmers use them much more often than they create complicated $\LaTeX$ classes. The quick-and-dirty approach trades the class method’s cleaner design for ease of script creation. However, if the form will ever be created by hand, the class method is definitely superior.

OpenStreetMap Baltimore City Buildings and Addresses Import

Two years ago, I started trying to import building footprints and addresses provided by the City of Baltimore into OpenStreetMap but was held up by red tape and eventually gave up.1 The City provides building footprints and parcel data on their open data portal; the download pages for these two datasets list the data as public domain, but the site’s terms of service is the same as the rest of City’s websites, saying the data is copyrighted. I had worked through the technical aspects of preparing and simplifying the building footprints for import and had started working on how to associate addresses from the parcel data but eventually gave up after I was unable to secure the needed licensing clarifications from the Mayor’s Office of Information Technology (MOIT).

This past fall, Elliot Plack, who then worked for Baltimore County GIS and was appointed to the Maryland Open Data Council by Governor O’Malley, got in touch with me about restarting the import, after finishing an import of similar data for the County. After meeting with Jim Garcia from MOIT, he was able to secure the permissions that we needed to proceed with the import. Additionally, he was able to get address point data, which is much superior to and easier to use than the parcel data I was originally going to extract addresses from.

Bootstrap Navbar without jQuery

While I’m fond of Bootstrap in general, I dislike how much it relies on JavaScript and particularly dislike its dependency on jQuery. I have nothing against using JavaScript for creating interactive content, e.g. web applications, or progressive enhancement, e.g. lightboxes or copying text to the clipboard, but I do take issue with requiring JavaScript for basic site functionality as is the case with Bootstrap’s navbar and dropdowns. What I particularly dislike is that not only does this require JavaScript, but it requires a 32kB JavaScript library, jQuery, to do what would otherwise take less than 1kB of JavaScript. To avoid this when redesigning campworkcoeman.org, I made some modifications to open the navbar’s dropdowns on hover on larger devices and used a small piece of plain JavaScript to operate the menu on small, mobile devices. Unfortunately, this didn’t work properly under iOS, but I recently fixed this. I’m detailing the changes I made in case someone finds them useful.

Posted in | Tagged , , , | 2 Comments

Print Maps

Web maps, e.g. Google Maps, normally don’t print well, as their resolution is much lower than normal print resolution, not to mention the various other unwanted text and elements that print along with the map. While the unwanted elements can be cropped out, the only fix for the low resolution is to render a higher resolution image (or use vectors). Formerly, this required installing GIS software, which also requires a suitable data source. Print Maps changes that by leveraging Mapbox GL JS and OpenStreetMap data to render print resolution maps in the browser. After the user selects the map size, zoom, location, style, resolution, and output format, PNG or PDF, Mapbox GL JS is configured as if it was being used on a very high pixel density display and used to render the map output. To use Print Maps, visit printmaps.org.

The site’s source code is available on GitHub. Also, slides from my HopHacks presentation on the project.