So my last post was very positive. I figured out how to relate the teams that share a stadium with the stadium itself. This was important because I wanted to eliminate the redundant points that were on top of each other. For those who don’t recall, I have an example in this gist:
Now I mentioned that there were issues displaying this in GIS applications and was promptly told I was doing this incorrectly:
If you click on that tweet you’ll see basically that you can’t do it the way I want and I have to go back to the way I was doing it before:
I had a conversation with Bill Dollins about it and he sums it up susinctly:
I get it, but “Do it this way because that’s what the software can handle” is an unsatisfying answer.
So I’m stuck, I honestly don’t care if QGIS can read the data, because it can. It just isn’t optimal. What I do care about is an organized dataset in GeoJSON. So my question that I can’t get a definitive answer, “is the array I have above valid GeoJSON code?”. From what I’ve seen, yes. But nobody wants to go on record as saying absolutely. I could say, hell with it I’m moving forward but I don’t want to go down a dead end road.
In a way it is good that Sean Gillies doesn’t follow me anymore. Because I can hear his voice in my head as I was trying to do something really stupid with the project. But Sheldon helps frame what I should be doing with what I was doing:
Exactly! What the hell? Why was I trying to do something so stupid when the while point of this project is baseball ballparks in GeoJSON. Here is the problem in a nutshell and how I solved it. First off, let us simply the problem down to just one ballpark. Salt River Fields at Talking Stick is the Spring Training facility for both the Arizona Diamondbacks and the Colorado Rockies. Not only that, but there are Fall League and Rookie League teams playing there. Probably even more that I still haven’t researched. Anyway, GeoJSON Ballparks looks like this today when you just want to see that one stadium.
It’s a mess right? Overlapping points, so many opportunities to screw up names. So my old school thought was just create a one-to-many relationship between the GeoJSON points and some external table. Madness! Seriously, what was I thinking? Sheldon is right, I should be doing a JSON array for the teams. Look how much nicer it all looks when I do this!
The problem now is so many teams, especially in spring training, minor leagues and fall ball, share stadiums, that in GeoJSON-Ballparks, you end up with multiple dots on top of each other. No one-to-many relationship that should happen.”
The project had pivoted in a way I hadn’t anticipated back in 2014 and it was a sure a mess to maintain. So now I can focus on fixing the project with the Minor League Baseball realignment that went on this year and get an updated dataset in Github very soon.
One outcome of doing this nested array is that many GIS tools don’t understand how to display the data. Take a look at geojson.io:
geojson.io compresses the array into one big JSON-formatted string. QGIS and Github do this also. It’s an issue that I’m willing to live with. Bill Dollins shared the GeoJSON spec with me to prove the way I’m doing is correct:
3.2. Feature Object
A Feature object represents a spatially bounded thing. Every Feature
object is a GeoJSON object no matter where it occurs in a GeoJSON
o A Feature object has a "type" member with the value
o A Feature object has a member with the name
"geometry". The value of the geometry member SHALL
be either a Geometry object as defined above or, in
the case that the Feature is unlocated, a JSON
o A Feature object has a member with the name
"properties". The value of the properties member is
an object (any JSON object or a JSON null value).
ANY JSON OBJECT! So formatting the files this way is correct and the way it should be done. I’m going to push forward on cleaning up GeoJSON Ballparks and let the GIS tools try and catch up.
Quite the journey, from basically a viewer application to now a full fledged GIS application. I looked back and the first time I mentioned QGIS was for the release of QGIS 0.7 back in 2005. I mention back then that I was impressed how far QGIS had come but almost 15 years later clearly it has come so much farther. I probably wished back in 2005 that QGIS could eventually become my preferred GIS application but today I know I can use it without any problems to accomplish any task I need to with GIS. In fact, I’m downloading 3.6 right now.
SpatialTau is my weekly newsletter that goes out every Wednesday. The archive shows up in my blog a month after the newsletter is published. If you’d like to subscribe, please do so here.
If there is one thing that you can take away from GIS software is it’s love of the toolbar. Every function has a little button on the toolbar. One can turn on all the toolbars in ArcGIS Desktop and you get this nightmare.
But it isn’t just Esri, QGIS almost as bad (possibly uglier).
I get some things are best done by having a toolbar, editing vectors for one seems so logical. But most are just some tool library that some programmer links up to some obscure bitmap graphic that represents what we’re trying to do. I’ve been struggling to think of a better way though.
ModelBuilder/FME Workbench: The logical method to performing GIS analysis is a flow diagram. The data flows through analysis like water through pipes. At the bottom is the outcome (hopefully clean and pure). Rather than highlighting a feature/layer, you perform the selection with SQL-type statements and apply logic rather than luck.
Scripting: Goes somewhat hand-in-hand with above. The visualization of the scripting is handled by ModelBuilder/FME Workbench allowing the GIS analyst to show others what they are doing. As much as I do love scripting and GIS, the visualization methods used by ModelBuilder/FME Workbench allow sharing of the model with other who might not see the workflow.
Wizards: Yea I hate wizards but in a way they work better than a toolbar. They are very limited in what they do but it limits the user to the “rails” of the wizard workflow ensuring that they complete the analysis correctly. Most of the time the toolbars call wizards to complete a function. This is the method preferred by button pushers.
Intellisense: This was the great hope I’ve had with GIS software. All the power of the command line but all the modern features of an IDE. Esri has prototyped this for Python and ArcPy but it is sort of a hack rather than the preferred method. I always felt I was at my best spatial analysis with ARC/INFO back in the day and I’m sure when Esri/QGIS release such a tool integrated into the application I’ll go back to using it.
I love the clean look of a blank canvas for creativity and unfortunately GIS software just clutters up that zen with crazy Windows XP logic. ArcGIS Professional brings the ribbon interface which hides much of these toolbars but it’s still confusing and illogical (seriously, those tabs are a crap shoot for finding a tool). There has been much innovation with mobile and web mapping. Hopefully we’ll see ArcGIS Professional and QGIS start to push the envelope with their interfaces. Just because we’ve been doing this way since ArcView 2.x does mean it is right.
I just noticed that Quantum GIS (QGIS) is now up to version 0.7. For those who don’t know much about QGIS, it is an Open Source GIS (licensed under the GNU Public License) that runs on Linux, Unix, Mac OSX, and Windows. QGIS supports vector, raster, and many database formats. I am quite impressed at how far this project has come and it continues to grow. If you have a Macintosh or prefer Linux, this is definitely your best way to go. I’ve used it at home for quite some time now on personal projects.