I have lots of places data(tourist attractions) stored in database. Every place has coordination info, such as latitude and longitude. When I randomly choose a route (for example: from somewhere in New York to somewhere in Boston), how can I find the 10 closest places along the route? I guess it's relative to geography algorithms. I'm trying to find a way to minimize the total calculation time and save cell phone battery. Thank you for any suggestions!
One way would be:
Consider the map to be a grid eg of 1km x1km boxes
plot the route and see which of these grid boxes it enters.
for each box, find the places/landmarks in the box which is not computationally expensive if you search your database my min/max longitude/latidtude position where the grid box starts/ends
To show the top N from these, you can calculate the shortest distance for these subset of places rather than the whole dataset.
Related
I have a dataset in which I have a column of geographical points, and I want to calculate the total distance of the path that these geographical points cover, so that I can add it to the details of the 'route'.
What's the cleanest and simplest way to do this?
My first thought was to create another column, which is the same as this one, except shifted by a single index value, and then to use DISTANCE, and then to SUM over this, however I'm new to Tableau and I'm not even sure if something like this is possible? I'm sure there's a more elegant way to do this.
Cheers.
I am working with the Uber H3 library. Using the poly fill function, I have populated an area with H3 indexes for a specific resolution. But I don’t need all the indexes. I want to identify and remove those indexes which are getting plotted on isolated areas like jungles, lakes, ponds, etc.
Any thoughts on how that can be achieved?
I thought that if I can map all the buildings in a city in their respective indexes, I can easily identify those indexes in which no buildings are mapped.
I’d maintain a Hashmap of h3 index as the key and a list of coordinates which lie in that index as the value.
In order to address this, you'll need some other dataset(s). Where to find this data depends largely on the city you're looking at, but a simple Google search for footprint data should provide some options.
Once you have footprint data, there are several options depending on the resolution of the grid that you're using and your performance requirements.
You could polyfill each footprint and keep the resulting hexagons
For coarser data, just using geoToH3 to get the hexagon for each vertex in each building polygon would be faster
If the footprints are significantly smaller than your hex size, you could probably just take a single coordinate from each building.
Once you have the hexagons for each building, you can simply do a set intersection with your polygon hexes and your building hexes to get the "good" set. But it may be easier in many cases to remove bad hexagons rather than including good ones - in this case you'd need a dataset of non-building features, e.g. water and park features, and do the reverse: polyfill the undesired features, and subtract these hexagons from your set.
I would like to know if from an image like the example it is possible to calculate the area between two consecutive cars:
Detect the two objects, calculate the distances between my camera and the two objects so deduce the area between the two objects
Any advice or references would be welcome thanks
https://i.stack.imgur.com/4IM6y.jpg
This is not a super scalable solution as it would vary by country. But license plates (at least in the US) are always of a similar dimension. This could be used to give you almost perfect distance reference and they are easy to detect. The difficulty remaining would be in estimating the space taken up by the partial view of the near car... but this would significantly reduce the complexity of the problem. To get that remaining bit, I would likely try to identify a tire/ hubcap and apply an offset to that... as I imagine that will get you pretty close (within 1-2 feet)
I have a large data set of regions , each of which is defined by a longitude, latitude and a given radius. I have a location point with a a latitude and longitude and I need to determine which of the regions contains my point.
Currently I am using brute force : I compute the distance between the target point and each region's center longitude and latitude ; if the distance is less than the radius of the region, I include the region in in my result.
Obviously this solution is not tenable.
Can GeoHash be used to formulate a solution ?
Edit : The business problem is given a set of cell phone with known ranges and a fixed set of available locations owned by a real estate holding, where is the place for a signal repeater. There are other considerations of course besides location and distance. Otherwise someone will have drive around the country with a signal detection kit -- not optimal . Not a homework question. I have Comp Sci background but GIS is new to me and I am willing to learn.
Edit : I will continue using brute force across several ec2 instances. Not the most optimum solution but it works. Thank you all for proposed solutions but unfortunately given the time and knowledge constraints and vagueness of the methodology, I am not going to be able to try them out.
The usual approach is to use a spatial index like quad tree or kd tree.
To this index you add the rectangular bounds of all circles to build up the index.
Uisng the quad tree:
Query the index which objects overlap a quad node at given position. The result will be some circles , these you check as you described.
quad trees don't like the deletion of elements.
We are purchasing a database of zip codes and their corresponding Lat/Long. I want to store cities in a separate table with a lat/long point representing the center of the city. Can I calculate that based on taking all of the zips that belong to that city, getting the min/max points for each direction, and taking the center point of the resulting rectangle?
Is there a more accurate method? I want to avoid purchasing another DB. We haven't purchased the full DB yet so I can't just try it and compare the results to Google Maps.
Well actually ZIP codes do not always encompass cities. Zip codes are arbitrary regions used to defined postal addresses.
Edit: Not always your assumption that the sum of all ZIP Codes will correspond to the city boundary or will retrieve you the correct centroid.
Your best bet is to get a countys table with spatial data in it.
In PostGIS a simple ST_Centroid(GeometryField) would suffice to get you the centroid of a polygon. That works out for any type of polygons.
If you are in the US, probably exists a public county/cities/states dataset availuable on the internet. Consider GIS tools for doing this work.
Would that be very helpful? That might give you something that approximates the geographic center, but normally when you talk about the center of the city, you are talking about the town square, or the commercial center, or the historical center.
Go to google maps for example. If you search for New York, it will take you directly to Times Square. Isn't that really what you expect if you search for the center of that City.
Well, the center of a city is impossible to calculate exactly, as there are probably as many views on what the center is as there are people...
Instead of using just the min/max points of the zip code areas, you could get the average of all positions, that would give you a more weighted position.
If you have an approximate number of people for each zip code you could use that as weight for the points, that would give you a "gravital center" of the population.
City Hall is always used to define the city center, used by the National Transportation and Highways division, all globes and maps.
I would use the average value of the four coordinates of the four borders of the town as the geographical center, using the Google map.