Technologies: Python, Ruby, C, C++, C#, JavaScript, TypeScript, PowerShell, Flask, SQL, PostGIS, Shapely, Unity, Unreal Engine, multiple assembly/machine languages, Windows user code and kernel drivers, Google Maps and other map APIs, geographic and airspace data
Hi, I'm Michael Geary. I've programmed in many languages and environments over the years. Some of my current interests are:
• Developer experience. I love helping my fellow developers solve problems, and building tools to make their jobs easier and more enjoyable.
• Aviation and geographic data. For example, airspace and obstacle data importers for Wing; election results and voter information maps for Google; many interactive maps for other companies.
• Hardware interfacing. In a way, I am a "full stack" developer, but my stack may involve a front end to a piece of hardware rather than the cloud. I first got into programming via ham radio, so RF hardware remains an interest.
• Designing and building APIs. Too often an API is designed by exposing the internals of whatever system provides the API. My philosophy is the opposite: start with the apps. I like to build a series of sample apps before starting on the API. This way I can imagine what API will make those apps and others like them easy to build.
• Talk with users! I don't like to sit in a back room cranking out code. I want to make sure it's the right code for what my users need, and that it's easy to maintain and improve as we learn more about what they want.
Technologies: Python, Ruby, C, C++, C#, JavaScript, TypeScript, PowerShell, Flask, SQL, PostGIS, Shapely, Unity, Unreal Engine, multiple assembly/machine languages, Windows user code and kernel drivers, Google Maps and other map APIs, geographic and airspace data
Hi, I'm Michael Geary. I've programmed in many languages and environments over the years. Some of my current interests are:
• Developer experience. I love helping my fellow developers solve problems, and building tools to make their jobs easier and more enjoyable.
• Aviation and geographic data. For example, airspace and obstacle data importers for Wing; election results and voter information maps for Google; many interactive maps for other companies.
• Hardware interfacing. In a way, I am a "full stack" developer, but my stack may involve a front end to a piece of hardware rather than the cloud. I first got into programming via ham radio, so RF hardware remains an interest.
• Designing and building APIs. Too often an API is designed by exposing the internals of whatever system provides the API. My philosophy is the opposite: start with the apps. I like to build a series of sample apps before starting on the API. This way I can imagine what API will make those apps and others like them easy to build.
• Talk with users! I don't like to sit in a back room cranking out code. I want to make sure it's the right code for what my users need, and that it's easy to maintain and improve as we learn more about what they want.
Which would violate FAA regulations if it was powered on (as it obviously was):
"When portable electronic devices powered by lithium batteries are in checked baggage, they must be completely powered off and protected to prevent unintentional activation or damage."
Of course there were smoking and non-smoking sections on airplanes. The same air recirculated through the entire airplane, and the non-smoking section began the very next row after the smoking section.
Yes, you could write code to do that. Or use the utilities provided in the TopoJSON GitHub and let them do it for you: convert to TopoJSON, simplify, convert back to GeoJSON. They have already written all the code for you.
It depends on what purpose you are using the polygons. In an online map you need to simplify way down. Consider these Colorado maps at two different zoom levels:
Even the one zoomed in on the state appears to use maybe 15-20 vertices max.
In the second one, if I squint real hard I can just barely make out one slight dogleg on the western border and one on the south. And that is partly because I knew to look for them in the zoomed-in map.
If we use, say, the Census TIGER/Line boundary definitions for the states, we are probably talking about hundreds of thousands of vertices, perhaps millions. You won't be using those in an online map without simplifying.
Similarly, typical map APIs like the Google Maps API accept GeoJSON and not TopoJSON. I was not suggesting TopoJSON as a replacement for GeoJSON, but as a complement to it. With the tools on the TopoJSON GitHub, you can have GeoJSON input and output, but convert to TopoJSON for the simplification step to avoid the "slivers" problem.
Yes, the same "slivers" problem occurs when you try to simplify features in any format that uses individual polygons, such as shapefiles or whatnot. That's the only case I was referring to.
I don't think I would trust a zebra or a giraffe for this task either.
To be clear, I'm not suggesting TopoJSON as an alternative to GeoJSON. I like GeoJSON and was loosely involved with the working group that created and updated its spec.
I'm just saying that for the specific task I mentioned GeoJSON or any format such as shapefiles that store polygons individually naturally leads to the "sliver" problem.
A nice processing pipeline is:
1. Convert GeoJSON to TopoJSON.
2. Run the simplification on the TopoJSON.
3. Convert the resulting TopoJSON back to GeoJSON.
The TopoJSON GitHub has tools for each of these steps.
One task where GeoJSON falls down is simplification of a group of polygons with common boundaries, e.g. the 48 conterminous US states. If you start with a highly detailed set of polygons, you need to simplify them for practical display in an online map.
GeoJSON doesn't encode the fact that the boundary points are common between adjacent polygons. When you simplify those polygons, each one is handled separately, and you end up with "slivers" where the boundaries are misaligned:
TopoJSON solves this by encoding each such boundary only once. So when you simplify the polygons, they are all done together, and the same simplification applies to adjacent polygons. No more slivers!
LinkedIn: https://www.linkedin.com/in/michaelgeary/
Stack Overflow: https://stackoverflow.com/users/1202830/michael-geary
Photos: https://geary.smugmug.com/ https://www.flickr.com/photos/geary/
One of these days I will figure out which of these sites I like so I can stop paying for two of them!