I have some point data that has kilometers from the specific point of the road. I want to extract the lat and long. How could it be done?
You will not be able to get a precise set of Lat/Long, unless there is more detail in the data recorded at the police station.
One solution might be to buffer the police station to 1 km then select all the road sections within the 1 km buffer. If the police data holds the road name or ID you could then link your accident to the road section identified in the buffer. Theoretically you could then take the center point along the road, however this would be misleading as if you create a map of this it will create a false impression of where accidents occur.
Related
I'm aware this kind of questions is frequently asked. But due to the age of the most ones and the enhancements on databases that I rode, I think it could be a good idea to create a new one.
I try to efficiency store coordinates (100K) in a database and do some operations on it. In others words, I try to store coordinates and get a rapid access to them. A typical operation should return all the records within a circle with a radius of 20km and center with given coordinates.
I rode MongoDB has a 2D spatial index that can store lat and long like in this example: https://stackoverflow.com/a/6026634/6271092
I also rode that it's possible to store and get coordinates within the circle by using MySQL, a kd-tree and the Haversine formula.
So my question is, in January 2018, which database and how should I use to store, access and do some operations with coordinates efficiency? Thx.
I have thousands of trips and each trip has a starting point and destination. My goal is to actually store miles traveled in each state in each trip. (If I travel from Denver to SLC, to I will end up with some miles in CO and some miles in UT.
I already have a table that has start and finish points and I need to think about good architecture to storing Miles in each trip per state.
Idea #1:
- Create 1 table with trip_id and 48 columns -> 1 for each lower continental state.
Idea #2:
- Create a table with trip_id, state_id (+ additional table with locations), total_miles
Solution 1 seems to be more efficient when it comes to storing data (less rows), and I am not sure how one table would handle 2 millions trips + multiple entries per state in the new table.
Any suggestions?
Idea#2 sounds like a much better idea. Let me explain some reasons.
First, your definition of "state" might change and adding/removing columns is quite cumbersome. For instance, "DC" might be a state. Or you might expand to Canada. Or even bring in Alaska. Adding new rows to a table is trivial.
Second, for simple tasks such as adding up the total miles for the trip, an simple aggregation query is much simpler than adding up 48+ columns.
Third, what about trips that might re-enter a state more than one time. Imagine someone driving from Kalamazoo (MI) to Houghton (MI) on the upper peninsula. They could very reasonably take the route through Chicago, passing through MI --> IN --> IL --> WI and then back to MI.
I'm trying to find KML or polygon data for every city and then combine population data with it to create a heatmap in Google Fusion Tables. I'm not sure where to get the polygon data for the cities though?
I'm using this to compare population sizes against distance to map out territories that are worth while to campaign in while having reasonable driving distances.
Any suggestions are welcome. Thanks!
Natural Earth has a large data set that might be useful.
From their Features page, under Cultural:
Urban polygons – derived from 2002-2003 MODIS satellite data.
They're available at 10 m & 50 m resolutions.
http://www.naturalearthdata.com/downloads/ (Note: The urban polygons are in the Cultural data set!)
It depends on the city, but most large ones (i.e. Seattle, San Fran, LA, New York, Chicago, etc.) have county or state GIS data warehouses that can be accessed for free for public data such as transportation networks, zipcode or census tract (block group) polygons.
It'll take a bit of sifting, but google search engine with keywords: "city name" + words like kml, shapefile, zipcodes, GIS data should give you a place to start.
One example would be to type in "LA GIS data" into Google search.
If you're struggling and want specific links, let me know which cities you're interested in.
Folks,
How can I take a state and divide it into areas that are 50 miles in radius?
Perhaps there's a better way to solve my problem: I have a list of 700 locations with unique city names. Some cities are less than 50 miles apart. I need to reduce that list to the minimal number of locations that are no more than 50 miles away and that basically cover the nearby cities in the list. This way I can find the center radius ZIP code of each of the location on the reduced list and then search for "stores within 50 miles", which should return all 700 locations.
Update: I have 5000 products and 700 stores in different cities. I need to check inventory for ALL products. The site where I check it only shows inventory in stores that are within 50 miles of a given city. That mean that I need to make 3,500,000 requests. Hence, I am looking for a way to reduce 700 stores to a smaller number.
A simple algorithm which would work but is far from optimal. This starts with a list of candidate towns
Pick a town at random, draw a circle around that point
Remove all towns inside the circle
Repeat until there are no towns left
You could run it a few times to see if some runs produce significantly fewer resulting circles.
You can concatenate the binary value from the x- and y co-oordinates. Instead of a straight line it orders the points along a z-curve. Then you can compute the upper bounds with the mostsignificant bits. The z-curve is often use in mapping applications:http://msdn.microsoft.com/en-us/library/bb259689.aspx.
There's a collection of buildings each having multiple floors that are interconnected by stairs and lifts. Currently, I'm attempting to design a system that will find the shortest-path between two points across the any of the buildings, being the same building or in another building.
At the moment each floor is modeled in a graph as follows:
the door of each room is a vertex. the junctions of edges connecting the rooms to the main edge(corridor) is also a vertex.
The stairs between the floors are edges.
The question that remains is how should I represent the lifts(elevators) (which are right next to the stairs)?
To have it as an edge makes me wonder what weight it should have, given that I'll have to run a graph traversal algorithm after for finding the shortest path.
Lift(elevator) as edge or as vertex? That is the question.
thanks!
Edges
Using an edge is the most immediate answer, as you do that for stairs. However, while stairs can only go from floor X to floor X+1, a lift can go from any floor to any floor, with slightly different times - I usually find the stairs quicker for two floors, but slower for more than 2. To mirror this you'll need an edge from every floor to every other floor, complete with weightings for each.
Vertices
You could instead have some additional vertices as well as edges. If you had a vertex at each floor of the liftshaft, then you'd only need a single path of edges connecting all the floors together, rather than a combinatorial number of edges.
If you also added an additional vertex outside the doors at each level, then you could add the average delay for getting into a lift and so reflect the fact that a lift can pass multiple floors quickly. However, lifts are going to need average timings at best. At busy times, they can end up stopping at almost every floor anyway, so for a busy campus you wouldn't really gain from these extra vertices.
My vote is for a vertex for each floor of the lift and a single edge to link adjacent floors. It should simplify the graph and reduce the effort of any path-optimisation algorithm as there are fewer paths. Plus it is a more accurate reflection of reality and minimises your workload to set up the edge weights.
If the lifts are a possible shortest path from one floor to the next, then they must be edges with weights. The entrances to each level are vertices. If close enough to the stairs then they are possible shared with the stair vertices.
I vote for edge.
Say you choose to use an elevator. You walk to it, press button and wait a bit. You then get in, wait some more, get out and continue your walk. Now, although you are physically not moving much, in time you are moving. Taking a lift between floors is like walking, say, 50 meters.
What I mean is that the time spent standing around the elevator is equivalent to a distance that you travel if walking. So treat the elevator as an edge that you are walking along during the duration that you are using it. Use that distance to compare, say, walking down the stairs.