On the one hand I agree with the "It doesn't matter here" crowd, but on the other hand, Python (only language mentioned in the article) has a json library in the stdlib, and it's certainly easier than doing it with regexes.
So, it doesn't matter much, but it was an odd choice.
Even if it's in the standard library, it still might be more work to find where it is in the standard library than just do it the way you already know how.
Agreed... It's a devil you know vs. the "oh I'll just use this other library to do $simple_thing, how hard can it really be?" Hours later you realize that you didn't think it completely through and it's a bit tougher than you thought.
It's actually pretty easy and quick to write when the data is highly regular (no pun intended!). You can write this kind of expression by taking one of the lines of input:
I've been a Perl programmer and regular expression user for over a decade. It didn't take long and if you use them regularly, it's second nature. I agree, I could have used a JSON parser, but the source was well-structured and sed seemed easier. PostgreSQL can import JSON, but I haven't had a good experience with it so far.
You put together a really awesome project! Kudos on that and for sharing it first and foremost!! I speak regex pretty fluently, and I may very well have reached for sed/perl -ne there as well, depending on mood. I guess it just struck me as odd to use a parser for XML but not JSON. Anyhow, off on a tangent, I recently learned about a program called xgrep that lets you pull elements out of XML using xpath or pcre (althought pcre support was kind of spotty for me)--it's neat for one-offs like this and pipeline building while playing with rest apis and such!
Maybe, if you're doing it all at once. I often use my text editor as a regex platform, using the Find/Replace menu to dice off chunks of text in a series of quick and easy operations, using UNDO if I get one wrong. It's really very quick if you don't force yourself to do it in one step.
Yup, I've done a bit with 9.2, and it accepts JSON just fine (although not with automatic string conversion) but it's a short road to wishing the data were in standard tables and columns.
Cool, thanks. Last time around I used a pg-driver-specific datatype to hold the parameter on its way through sql2o, and felt rather guilty about doing so.
It was a bit odd to me, but I was willing to accept that it might be faster than figuring out the API for spitting out csv, but when he did exactly that for the XML extraction...
I feel the same way. Heaven forbid that I do something that I know how to do that gets the job done and it's not the perfect way or is even, perhaps, completely silly. Let's focus on that thing and not the overall project.
In the closed source GIS world JSON hasn't exactly taken the world by storm. In open source (and I'm assuming the author is pretty familiar, seeing as he's using Postgres) GeoJSON is the format of choice. Wrangling that data INTO GeoJSON would net little advantage all for the purpose of importing it into Postgres. For displaying the results in a wonderful tool like QGIS, I could see going the extra mile.
"Between February and June of 1969 ... no more full-service properties were planned ... difficult to control quality with in-house restaurants ... All inns built after La Quinta #505 were built ... at locations with area available to build a restaurant ... which would be leased to a major restaurant chain for management."
"June, 1969 ... La Quinta #507 ... Restaurant on the premises was leased to Denny's."
Actually, they are talking about combination pizza hut and taco bells, which are in the same building (and owned by the same parent company). So it is slightly different. They are literally the exact same location, not just close by.
I always thought it was funny that for a while Starbucks operated two shops on opposite corners of the same intersection at Robson & Thurlow in Vancouver.
One of them has been closed since this Street View image was taken in 2012, but they were both there for some time (I had worked in the area in 2008 and they both were definitely there then).
I would think that's somewhat similar to two gas stations on opposite corners. You can get in and out of one of them fairly easily from any direction and going back out in your desired direction.
You're not invested (usually) in going to a particular Starbucks when you're getting your coffee on the go. This lets them increase the throughput for the area, while also capturing traffic (foot traffic in the case of this setup it seems) from more directions. You want coffee, but it's on the opposite corner then you have to cross two roads two times each? That's inconvenient. You have to cross, in the worst case, one road twice to get coffee in this setup. (Note: I don't think people analyze their behavior to that depth, but ease of access is at least an unconcious factor in determining whether to visit a place.)
"So, only 3.4% of the La Quintas out there live up to Mitch Hedberg’s expectations...Update:...This yields 49 pairs (or 5.8% of all La Quintas)"
Brings to mind:
"Humor can be dissected, as a frog can, but the thing dies in the process and the innards are discouraging to any but the pure scientific mind" - E.B. White
Almost no comments about the amazing comedy of Mitch?
I hadn't known about him until today ...
The kinds of observation he makes are hilarious. Any fans?
One thing missed here is this sort of thing is a lot easier (to read and code) using the built-in earthdistance module.
The query doesn't need the added "shape" column unless you want it for indexes, and becomes simply:
SELECT d.city, d.state, earth_distance(
ll_to_earth(d.latitude, d.longitude),
ll_to_earth(l.latitude, l.longitude)) as distance
FROM dennys d, laquinta l
WHERE distance <= 150
ORDER BY 3
No more magic numbers or confusing function names.
Note I don't mean this as a slight on the article - I purely mean it to educate postgres users that they can do this sort of thing easily without downloading/installing PostGIS.
59 comments
[ 2.3 ms ] story [ 114 ms ] threadwat.
Using the wrong tool for a really easy job can sometimes be faster than the minimal effort of getting the right tool ready.
So, it doesn't matter much, but it was an odd choice.
... for you.
s/^."n":"(.+)","i":"(.+)","p":\[([\d\.\-]+),([\d\.\-]+)],"s":"(\w+)","c":"(.+)".$/\1,\2,\3,\4,\5/;
insert into my_table values ($$ json_goes_here $$);
Works for all stringy things.
1. http://en.wikipedia.org/wiki/Comma-separated_values#Basic_ru...
At the risk of providing something useful to the discussion though, I'd like to point out the excellent tool jq: http://stedolan.github.io/jq/
Here's how to use it for the conversion in the article:
(after editing hotelMarkers.js into a proper json file)"Between February and June of 1969 ... no more full-service properties were planned ... difficult to control quality with in-house restaurants ... All inns built after La Quinta #505 were built ... at locations with area available to build a restaurant ... which would be leased to a major restaurant chain for management."
"June, 1969 ... La Quinta #507 ... Restaurant on the premises was leased to Denny's."
http://www.business.txstate.edu/users/jb15/MGT4350/how_la_qu...
http://edition.cnn.com/2010/LIVING/wayoflife/01/06/i.spy.ste...
https://www.google.com/maps/@49.284602,-123.12482,3a,75y,229...
One of them has been closed since this Street View image was taken in 2012, but they were both there for some time (I had worked in the area in 2008 and they both were definitely there then).
You're not invested (usually) in going to a particular Starbucks when you're getting your coffee on the go. This lets them increase the throughput for the area, while also capturing traffic (foot traffic in the case of this setup it seems) from more directions. You want coffee, but it's on the opposite corner then you have to cross two roads two times each? That's inconvenient. You have to cross, in the worst case, one road twice to get coffee in this setup. (Note: I don't think people analyze their behavior to that depth, but ease of access is at least an unconcious factor in determining whether to visit a place.)
http://www.theonion.com/articles/new-starbucks-opens-in-rest...
Brings to mind:
"Humor can be dissected, as a frog can, but the thing dies in the process and the innards are discouraging to any but the pure scientific mind" - E.B. White
"Dogs are forever in the pushup position" ~ Mitch
The query doesn't need the added "shape" column unless you want it for indexes, and becomes simply:
No more magic numbers or confusing function names.Note I don't mean this as a slight on the article - I purely mean it to educate postgres users that they can do this sort of thing easily without downloading/installing PostGIS.