I'm attempting to stream Tweets from the UK as a whole, using Twitters stream API, however I'm having trouble with my bounding box.
The LAT/LON pairs I'm using to define a bounding box of the whoe UK(Ire included) is as follows.
-9.05, 48.77, 2.19, 58.88
However when I try to use this with the Twitter stream API, it states the following error message.
Location track must be less than 1 degrees on a side: LocationTrack(48.77,-9.05,58.88,2.19)
I can't imagine that Twitter do not allow you a specify a bounding box that covers an area that crosses between the negative/positive LAT. Am I missing something here, or would this mean that Twitter only allow you to stream if you are in the Wester hemishphere, effectively?
If anyone has a suggest as to how I might be able to over-come this, I'd be very interested in hearing you out.
The reason for this is ambiguity around the meaning of the word 'degree' in this error.
Due to the lat/lon coordinates being used, I assumed it meant the actual VALUE of the degree in the second lat/lon pair, where as in actual fact it means the SIZE of the bounding box.
My bad.
Related
I am working on an iOS app, that scans the room and, convert it to a FML3.0 format.
(FML3.0 is particular format for storing houses/design info in JSON).
I am able to get coordinates of walls using Scenkit/Arkit, but not sure how to get coordinates of area/room.
So, my question is:
Is there any way to form poly under "Areas" section in FML 3.0 using the walls array.
If not, how can I get the coordinates via scanning the room. Any documentation related to this will be helpful.
Thanks!
I receive coordinate of a vehicle and I need to find out the speed limit of that road at which this vehicle is at?. I know you can find maxspeed for a certain bounded box like this
www.overpass-api.de/api/xapi?[maxspeed=][bbox=5.6283473,50.5348043,5.6285261,50.534884]
but that is if this bounded box area has ONLY one speed limit. So say suppose there was an area which had two speed limit within the bounded box?
My second concern is how should i make the bounded box since I am just getting one co-ordinate at a time?
Please don't ask more than a single question at once.
Your first question is not clear to me. The query will return all speed limits in the given bounding box, not just the first one.
Regarding your second question: You should use the around query instead of a bounding box. With around you can retrieve all elements within a certain radius around a given coordinate. Example query:
<query type="way">
<around lat="5.6283473" lon="50.5348043" radius="25"/>
<has-kv k="highway" v=""/>
<has-kv k="maxspeed" v=""/>
</query>
<print/>
Also see the language guide as well as overpass turbo for testing your queries.
I am developing a location-based application in which I need to get nearby location name of any geopoint selected by user. I'm using Google Places API which is working fine for me.
Only problem is the service returns null for geopoints in water. Is there any way that I can retrieve nearby locations for a geopoint in water or ocean?
AFAIK the API has no way to do that.
So, you've got two options, in order of the effort it takes:
When user taps water just throw a dialog saying "Please select a
point on land". Next to no effort and will slightly annoy the user.
Try to find the closest land geopoint yourself and use it to run the API request on
(instead of the original point). Below are some ideas on that.
A good approach can be based on this answer: basically you can get a KML file with land polygons. For performance reasons, you can simplify the polygons to the extent that makes sense for your zoom levels. Now if your point is in one of those polygons -- it's sea. And you can simply iterate over all polygon edges and pick the one that's closest to your point, then pick a point on it - again closest to your point - and do one little epsilon-sized step towards the outside of the polygon to get a land point you can do a geocode request on. Also, the original author suggests you can use Haversine formula to determine neares land point -- I'm not really familiar with the appliance of that one.
The downside is, you have to deal with KML, iterate over a lot of polygons and optimize them (and lose precision doing that, in addition to possible differences between marineregions.org data and Google Places data)
Another cool trick you could try is using Sobel Filter [edge detection] on the visible map fragment to determine where coastline is (although you will get some false positives there), then trace it (as in raster->vector) to get some points and edges to calculate the closest land position with, in a manner similar to the former approach. Here's a clumsy drawing of the idea
For Sobel edge detection, consider GPUImage lib -- they have the filter implemented and it's probably going to work crazy fast since the lib does all the calculations on GPU.
UPD Turns out there's also a service called Koordinates that has coastline data available, check the answer here
I am a little curious about the cute little kaleidoscopic images associated with each user on this site.
How are those generated? Possibilities are:
A list of images is already there in some folder and it is chosen randomly.
The image is generated whenever a user registers.
In any case, I am more interested in what kind of algorithm is used to generate such images.
It's called an Identicon. If you entered and e-mail, it's a based on a hash of your e-mail address. If you didn't enter an e-mail, it's based on your IP address.
Jeff posted some .NET code to generate IP based Identicons.
Its usually generated from a hash of either a user name, email address or ip address.
Stackoverflow uses Gravatar to do the image generation.
As far as I know the idea came from Don Parks, who writes about the technique he uses.
IIRC, it's generated from an IP address.
"IP Hashing" I believe it's called.
I remember reading about it on a blog; he made the code available for download. I have no idea where it was from, however. :(
The images are produced by Gravatar and details of them are outlined here, however, they do not reveal how they are doing it.
I bet each tiny tile image is given a set of other tile images it looks good with. Think of a graph with the tiles as nodes. You pick a random node for the corner and fill it's adjacent spots with partners, then rotate it and apply the same pattern four times. Then pick a color.
Instead of a graph, it could also be a square matrix in which each row represents an image, each column represents an image, and cell values are weights.
I believe the images are a 4×4 grid with the upper 2×2 grid repeated 4 times clockwise, just each time rotated 90 degrees, again clockwise. Seems the two colours are chosen randomly, and each 1×1 block is chosen from a predefined set.
EDIT: obviously my answer was ad hoc. Nice to know about identicons.
Try this: http://www.docuverse.com/blog/9block?code=(32-bit integer)8&size=(16|32|64)
substituting appropriate numbers for the parenthesized items.
I am developing a game for the web. The map of this game will be a minimum of 2000km by 2000km. I want to be able to encode elevation and terrain type at some level of granularity - 100m X 100m for example.
For a 2000km by 2000km map storing this information in 100m2 buckets would mean 20000 by 20000 elements or a total of 400,000,000 records in a database.
Is there some other way of storing this type of information?
MORE INFORMATION
The map itself will not ever be displayed in its entirety. Units will be moved on the map in a turn based fashion and the players will get feedback on where they are located and what the local area looks like. Terrain will dictate speed and prohibition of movement.
I guess I am trying to say that the map will be used for the game and not necessarily for a graphical or display purposes.
It depends on how you want to generate your terrain.
For example, you could procedurally generate it all (using interpolation of a low resolution terrain/height map - stored as two "bitmaps" - with random interpolation seeded from the xy coords to ensure that terrain didn't morph), and use minimal storage.
If you wanted areas of terrain that were completely defined, you could store these separately and use them where appropriate, randomly generating the rest.)
If you want completely defined terrain, then you're going to need to look into some kind of compression/streaming technique to only pull terrain you are currently interested in.
I would treat it differently, by separating terrain type and elevation.
Terrain type, I assume, does not change as rapidly as elevation - there are probably sectors of the same type of terrain that stretch over much longer than the lowest level of granularity. I would map those sectors into database records or some kind of hash table, depending on performance, memory and other requirements.
Elevation I would assume is semi-contiuous, as it changes gradually for the most part. I would try to map the values into set of continuous functions (different sets between parts that are not continues, as in sudden change in elevation). For any set of coordinates for which the terrain is the same elevation or can be described by a simple function, you just need to define the range this function covers. This should reduce much the amount of information you need to record to describe the elevation at each point in the terrain.
So basically I would break down the map into different sectors which compose of (x,y) ranges, once for terrain type and once for terrain elevation, and build a hash table for each which can return the appropriate value as needed.
If you want the kind of granularity that you are looking for, then there is no obvious way of doing it.
You could try a 2-dimensional wavelet transform, but that's pretty complex. Something like a Fourier transform would do quite nicely. Plus, you probably wouldn't go about storing the terrain with a one-record-per-piece-of-land way; it makes more sense to have some sort of database field which can store an encoded matrix.
I think the usual solution is to break your domain up into "tiles" of manageable sizes. You'll have to add a little bit of logic to load the appropriate tiles at any given time, but not too bad.
You shouldn't need to access all that info at once--even if each 100m2 bucket occupied a single pixel on the screen, no screen I know of could show 20k x 20k pixels at once.
Also, I wouldn't use a database--look into height mapping--effectively using a black & white image whose pixel values represent heights.
Good luck!
That will be awfully lot of information no matter which way you look at it. 400,000,000 grid cells will take their toll.
I see two ways of going around this. Firstly, since it is a web-based game, you might be able to get a server with a decently sized HDD and store the 400M records in it just as you would normally. Or more likely create some sort of your own storage mechanism for efficiency. Then you would only have to devise a way to access the data efficiently, which could be done by taking into account the fact that you doubtfully will need to use it all at once. ;)
The other way would be some kind of compression. You have to be careful with this though. Most out-of-the-box compression algorithms won't allow you to decompress an arbitrary location in the stream. Perhaps your terrain data has some patterns in it you can use? I doubt it will be completely random. More likely I predict large areas with the same data. Perhaps those can be encoded as such?