Yes it's valuable as a commodity. That always confounds these discussions. Copper has value as a commodity too and has a long history of use in currencies as well, but people don't obsess over it they way they do over gold. The point I was making is just that there's nothing special about gold that requires that currency be backed by stacks of it sitting in a vault somewhere. If currency has to be backed by a commodity, then it can be backed by any precious metal, or by non-metallic elements, or by land, or by any mineral rights, or by any other resource a nation may possess.
Gold at the moment, and throughout history, is a valuable commodity. At the moment people would probably accept gold bullion because the value is going up. It's gone up ridiculously in the last few years, even compared to other precious metals. At the moment, I believe it's higher than rhodium. Anyone who has paid any attention to the price history of gold can see that there's currently a gold bubble. When the price of gold breaks, the only people who will want to be paid in gold will be people operating in black markets and they'll expect to be paid well above the market value.
After a failure of the US, gold will have value, just like steel, copper, silver, lithium and partially hydrogenated soybean oil will hold value. Metals, when used as a currency have always had the advantage of being worth something just about everywhere, but that doesn't mean that you could ever just spend your gold coins everywhere. For one thing, it's almost always been illegal just about everywhere to spend foreign minted money locally. You had to take your money to a money changer and pay what amounted to a service fee and/or a tax. Black market transactions were all over the place, but counterfeiting was rife in such transactions and very few people actually have the expertise to identify counterfeit gold coins. As for the value of just a given amount of gold, it was all over the place. The massively wealthy Mali empire prospered as a gateway for gold from more southern parts of Africa to Europe where it was worth many times as much. Laws were necessary all over the place to stabilize precious metal values. For example all the laws setting the value of silver at 1/16 the value of gold.
Given all this, it's hard to see gold as anything special. I find it almost funny that a lot of people investing in gold right now because they think the country is going to completely break down aren't actually directly buying gold. Instead they're buying shares in a market. A market that, if the reasons they think they need gold pan out, will just collapse and vanish.
Right. Can't tell the difference. You can't say in exactly what way it can't tell the difference, but you're sure that those climatologist guys must be getting it wrong. Meanwhile, whether they're right or wrong, you prefer to err on the side of recklessness rather than on the side of caution. That's the problem with this whole debate, global climate change is only one of the things wrong with current resource usage, waste and irresponsible gaseous, liquid and solid waste disposal. It's doing a hundred other bad things to the entire world, but people want to quibble over how accurate climate change predictions are. The fact is, whether or not the ocean levels are higher in 100 years, it's looking like the actual life in the oceans will be devastated and maybe not safe to eat when you can find some to catch. That doesn't require any complex models, it's pretty much that way now and it's looking like it will just get worse.
You're half right. Money hasn't been worth anything since before the gold standard was dropped. Even gold is fiat currency. Money, including precious metal coinage, is just tokens meant to simplify complex barter arrangements. It only has value based on people's faith in its value.
You don't have to be an advanced civilization to have discovered slood. It's easier to discover than fire, and only marginally harder to discover than water.
Umm yeah. Even if your oversimplified notion of how things will turn out for Canada comes true, you haven't considered the fact that Canada has a highly aggressive and heavily armed neighbour to the south which will suffer from global warming effects and may want to expand into other territory. Oh, and they have an irrational hatred of anything French.
The last ice age ended about 10,000 years ago and was going on for about 100,000 years before that. I think you're a bit confused about the age of those ice sheets that are melting. So, what data precisely is it that you believe "not a single person who supports Global warming" will even look at? You haven't actually asserted any particular set of data, just speculated that the current trends are part of a normal warming trend and that the people studying climate haven't considered that possibility. You'll have to do a little better than that. It is possible that the climatologists are wrong, but at least they seem to be putting the work in.
Also "So water levels increase? It will be disastrous, but the majority will survive.". Considering how heavily leveraged the human race is in all sorts of ways right now (and how many live on the coasts), I don't have that much confidence that it will be the majority that will survive. In any case, the callous attitude you display that, sure a huge chunk of the human race will suffer and die, but it probably won't be you, so you don't really care is just really swell. Really great, you know. It seems to be the one a lot of denialist types fall back on in the end. They don't care if they're actually right or wrong, or what the consequences are. They've chosen their position, and that's it. I just don't understand why you bother.
Because someone is making a killing on the recurrent costs and is related to or friends with the people in the local government who make the decisions? Or, because the government couldn't justify the extra cost and continues to not be able to justify it even though they clearly would save money in the long run: "Yes, ok, but we just don't have the money for that right now, maybe next year.". Or because that's just the way it's done. Road breaks, you repair it.
You can't actually release something you made to the public domain. That's not the way it works. Anything you create that is copyrightable is, under the terms of the Berne convention and associated laws, copyrighted to you to the extent that the law recognizes you as the creator and is such for the entire duration of copyright (and any future extensions sadly). You can transfer your ownership to another entity (I'm a little fuzzy whether that's really just a license assignment), but there is no Public Domain entity for you to transfer it to. Now, you may have seen people grant their work to the public domain in their licenses and such licenses can be binding based on intent, but they're still technically licenses on a copyrighted work. In other words, it's not in the public domain, but it has a license that lets the world treat it as if it is and any (just) court will find that way.
The critical thing missing for people to decide is numbers. Depending on the numbers, there may be particular windows where it's cheaper to use the cloud than it is to use your own hardware. Or, it may be the case that it's always cheaper (although that's incredibly unlikely). It also may be the case that it's never cheaper to use the cloud (also not very likely because of the special cases where you need a truly massive amount of computation done in a very short time (like rendering a two hour video to meet your 4 hour deadline). Without decent numbers, all of this is just speculation.
That's right, they could create something stealing valuable Disney intellectual property like Cinderalla, or Snow White, or the _Hunchback of Notre Dame_, or something resembling the Buster Keaton short film _Steamboat Bill Jr._.
They use a meerkat (and possibly other animals), which is in the mongoose family. The theory is, I think, supposed to be that the meerkats will find and eat the best beans, therefore you get the best beans out of the other end. In practice... well I don't drink coffee anyway, what do I care?
Despite what the commercials say, your body knows the difference between sugar and corn syrup.
There's a reason why we have a sex drive. It fills an important reproductive function. Humans and other animals are full of all kinds of bits and pieces driving us to perform our reproductive functions. Orgasm is a neat little reward feedback mechanism, but it's far from the only part of the human sex drive. It's made up of all kinds of bits, some of them pure genetic programming, some shaped by environment. Sometimes they come together a bit differently and you get homosexuals which is pretty unsurprising considering that males and females are built on the exact same template with only minor differences. And sometimes you get your misanthropes who are disgusted by the thought of any human contact. You don't appear to actually be one though. So, if there's no difference between a woman and your hand, why do you ever bother with a woman at all? Surely it takes more effort for the same end result? If it's more sexually arousing, then there's that "connection" the GP was talking about. No need to read anything mystical into it.
The first two problems you mention aren't really problems, at least not problems with my approach. The second is a problem mainly because you're proposing something intrinsicly hard then demanding to know how my solution will do it simply.
First, although the earth is not a perfect sphere, and is technically referred to as an oblate spheroid, it is actually very, very close to a perfect sphere. It deviates from perfectly spherical by only a third of a percent. Using this approach, and for the article submitters purposes, that deviation can be completely ignored. This software isn't for people to compute ballistic trajectories from point A to point B, it's to give people an idea how far they are from various things. Clearly it only gives people a very rough idea since we don't have flying cars, so they'll have to take roads to get there.
Second. Now you're just descending to personal insults. I don't know how to calculate distances? Clearly I do, to within acceptable tolerances. That's the point of the Haversine formula I linked to. Oh, right, the earth isn't a "perfect" sphere. Neither is any real sphere in existence or that can exist. Sorry Plato. If you're happy with non-perfect results, then the distances I can compute with my methods are fine for all practical purposes. If you can provide perfect results then you must be the magical man, from Happy Land, who lives in a gumdrop house on Lolly Pop Lane! The reason for that is that you clearly don't live in the real world. So, since we've established that I can, in fact, compute distances that are good enough, the answer to the question of how you efficiently search for for rows that are within 1000 km of any particular point was actually in my original post which, if you read, you clearly didn't try to understand. I'll try to explain it simply and generally, then I'll address your specific 1000 km example. The way it works is that you select an area (a circular area in this case, but you can use others) on a latitude/longitude grid and you determine which degree-sized, minute-sized, and second sized grid blocks there are in that area. If an entire degree sized block fits inside the area, then you just need that degree sized block and you can ignore the minute and second sized blocks inside it, and for the minute-sized blocks you can ignore the second sized blocks within it and so forth. Then you form a database query and you pull in all rows that match whatever other criteria you have and whose latitude and longitude numbers match up with the list of blocks you've created. I should note at this point that if you're going to claim that the data set will be too large, that it will be too large no matter what method you're using. Anyway, all selected blocks that don't intersect the circumference of your circle are automatically accepted as being inside your search area and you don't need to do any computations on them (unless you're doing it three dimensionally, in which case you just have to have a second circle inside your first circle representing the tolerance. Then you go around the edge of the circle, and look at only those second (or larger/smaller depending on your requirements) size blocks that actually intersect the circumference of your circle. Inside those blocks, you check the coordinates of each row (or, if you decide that you're going to allow a +/- 31 meter tolerance, you just don't bother) against the center point and see if it's within the search area or not. If it is, you keep it, and if it isn't, you drop it. This is real world data so, barring errors or shenanigans in the data set, there's going to be an upper limit on how many rows you'll have inside each second sized block ( Now, on to the specific example of 1000 km. A degree is a little under 111 km long. A circle with a radius of 1000 km is going to have a circumference of about 6284 km, and an area of pi million km^2. Since a square degree is about 12233 km^2, the circle will contain about 256 square degrees. Most of those will be solidly within the circle, so you can select th
I hope it helps. If you need to do a lot more than a basic "find x within y units of z" some more general support from the tools being used might be needed. Finding things based on geometry in a database may seem like it requires support within the database itself, but latitude and longitude are coordinates on a two-dimensional grid system, so you don't actually need the database system to do the geometry, you just do it on a grid outside the database, then select those grid squares from inside the database. Probably you don't need to get fancier than that and can just ignore altitude differences. As for drawing a circle based on the Haversine formula, I kind of treated that as trivial in my post and skipped over it. There should be lots of stuff about doing it found in a google search though. You can just create a polygon by going around the center point by degrees. There are lots of resources out there on how to fill a polygon and you need to find all the intersecting rectangles and accumulate smaller rectangles (if you have all the seconds of a particular minute, collapse them into that minute, if you have all the minutes of a particular degree, collapse them into that degree, etc.). It's not dead simple, but this is stuff that's been done and done and done over and over again.
Sorry, but my solution works, is simple to implement, and works without major modifications to their existing database. I never claimed that it was the perfect solution, just that it works and that anyone calling themselves a programmer should be able to implement it. Creating a full implementation of an R-tree might be the kind of task that the programmer could get away with calling too complicated. Now, maybe they need more flexibility than just "find x within radius y of point z" but that's the only concrete example they gave in the summary.
In any case, if you're not concerned about altitude differences, this is a very simple problem. Even with the altitude problem thrown in, you just need the right fudge factors. Over small distances, the sites aren't going to be dense enough that brute force searching within map grids will be a problem and over large distances, you can have a really good idea of what the maximum slope of the earth could possibly be because it's constrained by physical reality, so all you need is a fudge factor.
When it comes down to it, the solution I listed is functionally similar to a simple r-tree. You have a grid broken up into rectangles of a degree latitude and longitude on a side. Each of those has 3600 rectangles a minute on a side in it, and each of those has 3600 rectangles a second on a side in it. That's a tree. If you draw your circle on the map, and it completely contains any particular degree sized rectangle, you know you don't have to search inside that rectangle and so on for rectangles of size minute and size second. If you need to, you can split your map into different sized rectangles. Overall, for the type of things that seem to be required, my solution seems to be perfectly workable
Now, maybe an r-tree would be better optimized, but optimizing an r-tree is not actually an easy problem. The fact that you have no suggestions on that tells me that you probably just found the wikipedia article on r-trees through a google search, then didn't even bother to read the whole thing.
Has the article submitter actually identified the software they need? It's trivial to implement something that will draw a circle on a grid, identify all the grid squares that might have points in that circle, submit an sql query for all sites inside those grid squares, then pick off all the points that don't fit in just the edge squares. The fact that they don't recognize that and think that they they need some vendors special solution to do it all in the database engine suggests that they either don't have the expertise to make such a determination, or they haven't thought about the problem too hard.
As for the people doing the job telling you what tools they prefer... It probably depends a bit on what their job description was when they were hired, but if they say they can't do what I wrote above, then they're either lying, or they haven't thought about the problem too hard either. Or, possibly they're incapable of implementing such a thing and think that all programming involves calling from libraries written by professionals.
I was just trying to cover the what ifs for anyone who says I'm oversimplifying and that the geographical functions in mssql provide this or that feature that I haven't covered. This is overall a pretty easy problem to solve. Optimizing it would, of course, be more of a problem, but optimizing it probably isn't necessary without a really massive data set. The approach I outlined has the up side that the circumference of a circle grows linearly in relation to its radius and the Earth itself is close enough to a perfectly smooth sphere (from the point of view of a wide search area) that the actual area within which you have to check distances can only grow so big. Also, presumably, the sites are not going to be at least tens of meters apart (barring errors in the dataset, or overloaded site labelling), so there's a density limit. So this really can be brute-forced without much thought and a bit of testing afterwards.
So, I absolutely agree, any programmers uncomfortable about whipping up something to do this must be scared of math. Or they're making excuses to get the tool they're comfortable with in place. Or, possibly, they're playing a longer strategic game and it's some other feature of mssql they really think they'll need along the line so they're pushing for it by pretending not to be able to do this.
Am I the only one who finds it a bit sad that this is considered a hard problem to solve in house? It depends on how you have your database set up, but, you could store your latitude and longitude in different fields as degrees, minutes, and seconds (do you need resolution finer than about 30 meters?, then add more fields, need coarser resolution, do the same). Then, you start at your center point and draw an appropriately sized circle (more on that after) around that point using an algorithm that gives you all the second^2, minute^2, and degree^2 (and larger and or smaller blocks as precision requires) sized blocks that fall inside or touch the circle. Then you craft a select statement for all sites that match that set of blocks. Then, after you have that set, if you don't care too, too much about precision, you're done. If you do, you take the data set that's been returned and you look at all of the sites whose block intercepts the circumference and calculate their distance to the center and throw out the ones that are too far away. If you're using a flat earth (not flat as in pancake, flat as in a perfect ellipsoid) model, then you're done at this point. If you want to consider three dimensional distances on an earth with mountains and valleys, etc. (the "appropriately sized circle" mentioned above should already be taking care of the perfect ellipsoid model), so that a site 100 meters away horizontally but at the bottom of a 1.5 km cliff isn't considered to be 100 meters away, then you need to do more work and you need the altitude of each site in your database as well. Since you can pretty much rely on a fairly low maximum amount of overhang from cliffs and so forth, all you need to do is have an inner circle and an outer "appropriately sized circle" based on some precalculated constants regarding maximum changes in altitude over the whole earth calculated by coordinate block of some given size (computing or obtaining those constants is the trickiest part, put it's not hard, it just requires the appropriate GIS data and some number crunching) and stored in a table. When you compute your inner and outer circles, you just take the local terrain into account and draw the outer circle as far out as any sites in those blocks could possibly be from the center, and the inner circle as far in as they could possibly be. Then you work the blocks from the outside of the max circle to the inside of the min circle (not bothering to search blocks bounded on the outside by other blocks where you've already determined all the sites are inside your max area).
For calculating the "appropriately sized circle" in the first place, you make use of the Haversine Formula or an appropriately modified (for altitudes) version thereof and some safe margin around the edge. Voila. Now, I know I've fudged past some of the math here, especially for the more complicated cases, but this is still pretty simple stuff, especially for the simpler cases. This is CS Major Sophmore or Junior year stuff.
Sounds reasonable until you consider that both approaches are going to require custom work. Even though the whole point of languages like SQL is that you're supposed to be able to swap out the back end easily, in the real world, you have to do all kinds of work. So the choice isn't between some kinds of simple switchover or doing a lot of custom work, it's between doing a bunch of custom work or doing a different bunch of custom work. Oh, and the third option of finding a prepackaged solution that does what you want without swapping out such a major part of your application stack.
That chart prompts a really interesting question. To those taking it to heart as some sort of proof of the inferiority or superiority of some particular group, I have to ask, are you male or female? Because if you're male and looking at that chart and sneering down at blacks and hispanics as inferior, are you also acknowledging vast superiority of women on those same criteria? Or are you being a hypocrite?
Slashdot Mirror
Yes it's valuable as a commodity. That always confounds these discussions. Copper has value as a commodity too and has a long history of use in currencies as well, but people don't obsess over it they way they do over gold. The point I was making is just that there's nothing special about gold that requires that currency be backed by stacks of it sitting in a vault somewhere. If currency has to be backed by a commodity, then it can be backed by any precious metal, or by non-metallic elements, or by land, or by any mineral rights, or by any other resource a nation may possess.
Gold at the moment, and throughout history, is a valuable commodity. At the moment people would probably accept gold bullion because the value is going up. It's gone up ridiculously in the last few years, even compared to other precious metals. At the moment, I believe it's higher than rhodium. Anyone who has paid any attention to the price history of gold can see that there's currently a gold bubble. When the price of gold breaks, the only people who will want to be paid in gold will be people operating in black markets and they'll expect to be paid well above the market value.
After a failure of the US, gold will have value, just like steel, copper, silver, lithium and partially hydrogenated soybean oil will hold value. Metals, when used as a currency have always had the advantage of being worth something just about everywhere, but that doesn't mean that you could ever just spend your gold coins everywhere. For one thing, it's almost always been illegal just about everywhere to spend foreign minted money locally. You had to take your money to a money changer and pay what amounted to a service fee and/or a tax. Black market transactions were all over the place, but counterfeiting was rife in such transactions and very few people actually have the expertise to identify counterfeit gold coins. As for the value of just a given amount of gold, it was all over the place. The massively wealthy Mali empire prospered as a gateway for gold from more southern parts of Africa to Europe where it was worth many times as much. Laws were necessary all over the place to stabilize precious metal values. For example all the laws setting the value of silver at 1/16 the value of gold.
Given all this, it's hard to see gold as anything special. I find it almost funny that a lot of people investing in gold right now because they think the country is going to completely break down aren't actually directly buying gold. Instead they're buying shares in a market. A market that, if the reasons they think they need gold pan out, will just collapse and vanish.
Right. Can't tell the difference. You can't say in exactly what way it can't tell the difference, but you're sure that those climatologist guys must be getting it wrong. Meanwhile, whether they're right or wrong, you prefer to err on the side of recklessness rather than on the side of caution. That's the problem with this whole debate, global climate change is only one of the things wrong with current resource usage, waste and irresponsible gaseous, liquid and solid waste disposal. It's doing a hundred other bad things to the entire world, but people want to quibble over how accurate climate change predictions are. The fact is, whether or not the ocean levels are higher in 100 years, it's looking like the actual life in the oceans will be devastated and maybe not safe to eat when you can find some to catch. That doesn't require any complex models, it's pretty much that way now and it's looking like it will just get worse.
That's a pretty good way of putting it.
Yeah, maybe just a little.
You're half right. Money hasn't been worth anything since before the gold standard was dropped. Even gold is fiat currency. Money, including precious metal coinage, is just tokens meant to simplify complex barter arrangements. It only has value based on people's faith in its value.
You don't have to be an advanced civilization to have discovered slood. It's easier to discover than fire, and only marginally harder to discover than water.
This won't mean more sunlight, however. In fact, all indications are that, while temperatures are going up, insolation is going down.
Umm yeah. Even if your oversimplified notion of how things will turn out for Canada comes true, you haven't considered the fact that Canada has a highly aggressive and heavily armed neighbour to the south which will suffer from global warming effects and may want to expand into other territory. Oh, and they have an irrational hatred of anything French.
The last ice age ended about 10,000 years ago and was going on for about 100,000 years before that. I think you're a bit confused about the age of those ice sheets that are melting. So, what data precisely is it that you believe "not a single person who supports Global warming" will even look at? You haven't actually asserted any particular set of data, just speculated that the current trends are part of a normal warming trend and that the people studying climate haven't considered that possibility. You'll have to do a little better than that. It is possible that the climatologists are wrong, but at least they seem to be putting the work in.
Also "So water levels increase? It will be disastrous, but the majority will survive.". Considering how heavily leveraged the human race is in all sorts of ways right now (and how many live on the coasts), I don't have that much confidence that it will be the majority that will survive. In any case, the callous attitude you display that, sure a huge chunk of the human race will suffer and die, but it probably won't be you, so you don't really care is just really swell. Really great, you know. It seems to be the one a lot of denialist types fall back on in the end. They don't care if they're actually right or wrong, or what the consequences are. They've chosen their position, and that's it. I just don't understand why you bother.
Because someone is making a killing on the recurrent costs and is related to or friends with the people in the local government who make the decisions? Or, because the government couldn't justify the extra cost and continues to not be able to justify it even though they clearly would save money in the long run: "Yes, ok, but we just don't have the money for that right now, maybe next year.". Or because that's just the way it's done. Road breaks, you repair it.
You can't actually release something you made to the public domain. That's not the way it works. Anything you create that is copyrightable is, under the terms of the Berne convention and associated laws, copyrighted to you to the extent that the law recognizes you as the creator and is such for the entire duration of copyright (and any future extensions sadly). You can transfer your ownership to another entity (I'm a little fuzzy whether that's really just a license assignment), but there is no Public Domain entity for you to transfer it to. Now, you may have seen people grant their work to the public domain in their licenses and such licenses can be binding based on intent, but they're still technically licenses on a copyrighted work. In other words, it's not in the public domain, but it has a license that lets the world treat it as if it is and any (just) court will find that way.
The critical thing missing for people to decide is numbers. Depending on the numbers, there may be particular windows where it's cheaper to use the cloud than it is to use your own hardware. Or, it may be the case that it's always cheaper (although that's incredibly unlikely). It also may be the case that it's never cheaper to use the cloud (also not very likely because of the special cases where you need a truly massive amount of computation done in a very short time (like rendering a two hour video to meet your 4 hour deadline). Without decent numbers, all of this is just speculation.
That's right, they could create something stealing valuable Disney intellectual property like Cinderalla, or Snow White, or the _Hunchback of Notre Dame_, or something resembling the Buster Keaton short film _Steamboat Bill Jr._.
They use a meerkat (and possibly other animals), which is in the mongoose family. The theory is, I think, supposed to be that the meerkats will find and eat the best beans, therefore you get the best beans out of the other end. In practice... well I don't drink coffee anyway, what do I care?
Despite what the commercials say, your body knows the difference between sugar and corn syrup.
There's a reason why we have a sex drive. It fills an important reproductive function. Humans and other animals are full of all kinds of bits and pieces driving us to perform our reproductive functions. Orgasm is a neat little reward feedback mechanism, but it's far from the only part of the human sex drive. It's made up of all kinds of bits, some of them pure genetic programming, some shaped by environment. Sometimes they come together a bit differently and you get homosexuals which is pretty unsurprising considering that males and females are built on the exact same template with only minor differences. And sometimes you get your misanthropes who are disgusted by the thought of any human contact. You don't appear to actually be one though. So, if there's no difference between a woman and your hand, why do you ever bother with a woman at all? Surely it takes more effort for the same end result? If it's more sexually arousing, then there's that "connection" the GP was talking about. No need to read anything mystical into it.
The first two problems you mention aren't really problems, at least not problems with my approach. The second is a problem mainly because you're proposing something intrinsicly hard then demanding to know how my solution will do it simply.
First, although the earth is not a perfect sphere, and is technically referred to as an oblate spheroid, it is actually very, very close to a perfect sphere. It deviates from perfectly spherical by only a third of a percent. Using this approach, and for the article submitters purposes, that deviation can be completely ignored. This software isn't for people to compute ballistic trajectories from point A to point B, it's to give people an idea how far they are from various things. Clearly it only gives people a very rough idea since we don't have flying cars, so they'll have to take roads to get there.
Second. Now you're just descending to personal insults. I don't know how to calculate distances? Clearly I do, to within acceptable tolerances. That's the point of the Haversine formula I linked to. Oh, right, the earth isn't a "perfect" sphere. Neither is any real sphere in existence or that can exist. Sorry Plato. If you're happy with non-perfect results, then the distances I can compute with my methods are fine for all practical purposes. If you can provide perfect results then you must be the magical man, from Happy Land, who lives in a gumdrop house on Lolly Pop Lane! The reason for that is that you clearly don't live in the real world. So, since we've established that I can, in fact, compute distances that are good enough, the answer to the question of how you efficiently search for for rows that are within 1000 km of any particular point was actually in my original post which, if you read, you clearly didn't try to understand. I'll try to explain it simply and generally, then I'll address your specific 1000 km example. The way it works is that you select an area (a circular area in this case, but you can use others) on a latitude/longitude grid and you determine which degree-sized, minute-sized, and second sized grid blocks there are in that area. If an entire degree sized block fits inside the area, then you just need that degree sized block and you can ignore the minute and second sized blocks inside it, and for the minute-sized blocks you can ignore the second sized blocks within it and so forth. Then you form a database query and you pull in all rows that match whatever other criteria you have and whose latitude and longitude numbers match up with the list of blocks you've created. I should note at this point that if you're going to claim that the data set will be too large, that it will be too large no matter what method you're using. Anyway, all selected blocks that don't intersect the circumference of your circle are automatically accepted as being inside your search area and you don't need to do any computations on them (unless you're doing it three dimensionally, in which case you just have to have a second circle inside your first circle representing the tolerance. Then you go around the edge of the circle, and look at only those second (or larger/smaller depending on your requirements) size blocks that actually intersect the circumference of your circle. Inside those blocks, you check the coordinates of each row (or, if you decide that you're going to allow a +/- 31 meter tolerance, you just don't bother) against the center point and see if it's within the search area or not. If it is, you keep it, and if it isn't, you drop it. This is real world data so, barring errors or shenanigans in the data set, there's going to be an upper limit on how many rows you'll have inside each second sized block (
Now, on to the specific example of 1000 km. A degree is a little under 111 km long. A circle with a radius of 1000 km is going to have a circumference of about 6284 km, and an area of pi million km^2. Since a square degree is about 12233 km^2, the circle will contain about 256 square degrees. Most of those will be solidly within the circle, so you can select th
I hope it helps. If you need to do a lot more than a basic "find x within y units of z" some more general support from the tools being used might be needed. Finding things based on geometry in a database may seem like it requires support within the database itself, but latitude and longitude are coordinates on a two-dimensional grid system, so you don't actually need the database system to do the geometry, you just do it on a grid outside the database, then select those grid squares from inside the database. Probably you don't need to get fancier than that and can just ignore altitude differences. As for drawing a circle based on the Haversine formula, I kind of treated that as trivial in my post and skipped over it. There should be lots of stuff about doing it found in a google search though. You can just create a polygon by going around the center point by degrees. There are lots of resources out there on how to fill a polygon and you need to find all the intersecting rectangles and accumulate smaller rectangles (if you have all the seconds of a particular minute, collapse them into that minute, if you have all the minutes of a particular degree, collapse them into that degree, etc.). It's not dead simple, but this is stuff that's been done and done and done over and over again.
Sorry, but my solution works, is simple to implement, and works without major modifications to their existing database. I never claimed that it was the perfect solution, just that it works and that anyone calling themselves a programmer should be able to implement it. Creating a full implementation of an R-tree might be the kind of task that the programmer could get away with calling too complicated. Now, maybe they need more flexibility than just "find x within radius y of point z" but that's the only concrete example they gave in the summary.
In any case, if you're not concerned about altitude differences, this is a very simple problem. Even with the altitude problem thrown in, you just need the right fudge factors. Over small distances, the sites aren't going to be dense enough that brute force searching within map grids will be a problem and over large distances, you can have a really good idea of what the maximum slope of the earth could possibly be because it's constrained by physical reality, so all you need is a fudge factor.
When it comes down to it, the solution I listed is functionally similar to a simple r-tree. You have a grid broken up into rectangles of a degree latitude and longitude on a side. Each of those has 3600 rectangles a minute on a side in it, and each of those has 3600 rectangles a second on a side in it. That's a tree. If you draw your circle on the map, and it completely contains any particular degree sized rectangle, you know you don't have to search inside that rectangle and so on for rectangles of size minute and size second. If you need to, you can split your map into different sized rectangles. Overall, for the type of things that seem to be required, my solution seems to be perfectly workable
Now, maybe an r-tree would be better optimized, but optimizing an r-tree is not actually an easy problem. The fact that you have no suggestions on that tells me that you probably just found the wikipedia article on r-trees through a google search, then didn't even bother to read the whole thing.
Has the article submitter actually identified the software they need? It's trivial to implement something that will draw a circle on a grid, identify all the grid squares that might have points in that circle, submit an sql query for all sites inside those grid squares, then pick off all the points that don't fit in just the edge squares. The fact that they don't recognize that and think that they they need some vendors special solution to do it all in the database engine suggests that they either don't have the expertise to make such a determination, or they haven't thought about the problem too hard.
As for the people doing the job telling you what tools they prefer... It probably depends a bit on what their job description was when they were hired, but if they say they can't do what I wrote above, then they're either lying, or they haven't thought about the problem too hard either. Or, possibly they're incapable of implementing such a thing and think that all programming involves calling from libraries written by professionals.
I was just trying to cover the what ifs for anyone who says I'm oversimplifying and that the geographical functions in mssql provide this or that feature that I haven't covered. This is overall a pretty easy problem to solve. Optimizing it would, of course, be more of a problem, but optimizing it probably isn't necessary without a really massive data set. The approach I outlined has the up side that the circumference of a circle grows linearly in relation to its radius and the Earth itself is close enough to a perfectly smooth sphere (from the point of view of a wide search area) that the actual area within which you have to check distances can only grow so big. Also, presumably, the sites are not going to be at least tens of meters apart (barring errors in the dataset, or overloaded site labelling), so there's a density limit. So this really can be brute-forced without much thought and a bit of testing afterwards.
So, I absolutely agree, any programmers uncomfortable about whipping up something to do this must be scared of math. Or they're making excuses to get the tool they're comfortable with in place. Or, possibly, they're playing a longer strategic game and it's some other feature of mssql they really think they'll need along the line so they're pushing for it by pretending not to be able to do this.
Am I the only one who finds it a bit sad that this is considered a hard problem to solve in house? It depends on how you have your database set up, but, you could store your latitude and longitude in different fields as degrees, minutes, and seconds (do you need resolution finer than about 30 meters?, then add more fields, need coarser resolution, do the same). Then, you start at your center point and draw an appropriately sized circle (more on that after) around that point using an algorithm that gives you all the second^2, minute^2, and degree^2 (and larger and or smaller blocks as precision requires) sized blocks that fall inside or touch the circle. Then you craft a select statement for all sites that match that set of blocks. Then, after you have that set, if you don't care too, too much about precision, you're done. If you do, you take the data set that's been returned and you look at all of the sites whose block intercepts the circumference and calculate their distance to the center and throw out the ones that are too far away. If you're using a flat earth (not flat as in pancake, flat as in a perfect ellipsoid) model, then you're done at this point. If you want to consider three dimensional distances on an earth with mountains and valleys, etc. (the "appropriately sized circle" mentioned above should already be taking care of the perfect ellipsoid model), so that a site 100 meters away horizontally but at the bottom of a 1.5 km cliff isn't considered to be 100 meters away, then you need to do more work and you need the altitude of each site in your database as well. Since you can pretty much rely on a fairly low maximum amount of overhang from cliffs and so forth, all you need to do is have an inner circle and an outer "appropriately sized circle" based on some precalculated constants regarding maximum changes in altitude over the whole earth calculated by coordinate block of some given size (computing or obtaining those constants is the trickiest part, put it's not hard, it just requires the appropriate GIS data and some number crunching) and stored in a table. When you compute your inner and outer circles, you just take the local terrain into account and draw the outer circle as far out as any sites in those blocks could possibly be from the center, and the inner circle as far in as they could possibly be. Then you work the blocks from the outside of the max circle to the inside of the min circle (not bothering to search blocks bounded on the outside by other blocks where you've already determined all the sites are inside your max area).
For calculating the "appropriately sized circle" in the first place, you make use of the Haversine Formula or an appropriately modified (for altitudes) version thereof and some safe margin around the edge. Voila. Now, I know I've fudged past some of the math here, especially for the more complicated cases, but this is still pretty simple stuff, especially for the simpler cases. This is CS Major Sophmore or Junior year stuff.
Sounds reasonable until you consider that both approaches are going to require custom work. Even though the whole point of languages like SQL is that you're supposed to be able to swap out the back end easily, in the real world, you have to do all kinds of work. So the choice isn't between some kinds of simple switchover or doing a lot of custom work, it's between doing a bunch of custom work or doing a different bunch of custom work. Oh, and the third option of finding a prepackaged solution that does what you want without swapping out such a major part of your application stack.
That chart prompts a really interesting question. To those taking it to heart as some sort of proof of the inferiority or superiority of some particular group, I have to ask, are you male or female? Because if you're male and looking at that chart and sneering down at blacks and hispanics as inferior, are you also acknowledging vast superiority of women on those same criteria? Or are you being a hypocrite?
"Fascism should rightly be called Corporatism, as it is the merger of corporate and government power."
-- Benito Mussolini