I am storing a number of point features inside a SQLite database for display inside of MKMapView and I would like to precompute and store coordinates in the the projection of the map instead of in lat/lon (for index/performance reasons). However, I am creating this database externally (in Python), so I cannot simply use the MKMapPointForCoordinate() function. What is the projection used by MKMapView? The documentation states that it is a mercator projection but it does not appear to be the web mercator projection that I expected. How can I compute an X/Y coordinate from a Lat/Lon ?
Personally I feel you're approaching the problem from the wrong angle - you say don't want to store latitude/longitude co-ordinates for 'index/performance reasons'. What are these reasons?
Storage, indexing, and querying of geographic coordinates inside of a database is not an unusual problem. They are simply two decimal numbers, making indexing and querying very straightforward.
Apple also tell you only to save co-ordinates rather than MKMapPoints in their own documentation:
When saving map-related data to a file, you should always save coordinate values (latitude and longitude) and not map points.
Perhaps you could share some of the issues you're having saving co-ordinates to a database?
I'm pretty sure it is webmercator because the overlay tiles I have produced are in that projection and they fit. But like other conmenters said, you're advised to store them in lat/long. If you want to query results in a grid lat/long provide a pretty good starting point. The grid isn't square as you leave the equator but it is rectangular.
Related
I´ve got a job offer to work with postgres and I have not much idea of it. The guy told me to build a simple data base which automatically calculates the distance to my house from a list of some other places (bars, pharmacies, museums, whatever...) everything given in geocoordinates.
I have already installed postgres, also postgis and create a data base. May you give me some hints about how I should do this task? Is there any tutorial or resource I could use to make this tasks easier? Should I use postgis?
Thank you.
PostGIS will do this easily. Boundless Geo have an excellent PostGIS tutorial. I also recommend you are familiar with Ch3 & 4 of the PostGIS manual.
I strongly advise you to learn & understand the difference between projected and unprojected coordinates if you're going to be working with spatial data. Projected means the coordinates have been taken from a 'round earth' and adjusted or projected onto to a flat map page (with coordinates normally given in feet or metres depending on the properties of the projection used). This enables computationally efficient normal cartesian calculations to be done for distance, area, direction, intersection, contains etc. There are trade offs for using projections- You can't preserve all of area, distance, shape, direction when you project a curved line or surface onto a flat map. Different projections are optimised for different trade-offs. Calculations on projected data are only accurate over a relatively small portion of the earth's surface. There are many map projections available to suit various needs and localities. If you are going to be working with projected data, you need to pick a projection that suits your purposes and location. If you don't understand projections, your queries can easily produce garbage without realising it.
Unprojected data (ie, raw Lat/Lon coordinates which is what you have) involve much more complicated calculations as they are done on the curved surface of the spheroid representing the earth. There are a number of reference coordinate systems that are used to express Lat/Lon, however the most common is "WGS84" (which is what "GPS" coordinates are expressed in).
PostGIS objects (in the form of "simple features" as defined by the OGC) can be stored as either "geometry" types (projected coordinates) or "geography" types (unprojected Lon/Lat in WGS84: note the order, a common source of confusion!). As a bit of a wrinkle, Lon/Lat (order again!) can also be stored as a "pseudo projected" geometry type (typically with a projection SRID of '4326' for WGS84 Lon/Lat).
The method you use to calculate distance will depend on how you choose to store your points ('geometry' or 'geography').
See ST_Distance from the PostGIS docs for excellent examples of measuring distance using both geometry and geography points. Note, if you wish to calculate projected map distances you will need to pick an appropriate map projection and use ST_Transform to project your points to the appropriate spatial reference system (currently in SRID 4326- "GPS" coordinates). For only a few points the difference won't be at all noticeable, but once you start doing lots of more complex spatial queries, the difference can be significant. PostGIS has a lot more functions for geometry types than for geography types which may influence your decision. Also see ST_DistanceSpheroid for another possibility for calculating distance from Lon/Lat coordinates.
To start with, I'd store your points as 'geography' to simplify your experiments. Your distances will then be 'great circle' calcs in metres and you won't have to worry about projections initially.
I'm a complete illiterate when it comes to working with geographical data, so bear with me.
For our application we will be tracking a fairly large amount of rapidly changing points on a map. It would be nice to be able to cache the location of these points in some kind of map-tile structure so it would be easy to find all points currently in the same tile or neighbouring tiles, making it easier to quickly determine the nearest neigbours and have special logic for specific tiles, etc.
Although we're working for one specific (but already large) location, it would be nice if a solution would scale to other locations as well. Since we would only cache tiles that concern the system, would just tiling the enitre planet be the best option? The dimensions of a tile would then be measured in arc seconds/minutes, or is that a bad idea?
We already work with Postgres and this seems like something that could be done with PostGIS (is this what rasters are?), but jumping in to the documentation/tutorials without knowing what exactly I'm looking for is proving difficult. Any ideas?
PostGIS is all that you need. It can store your points in any coordinate reference system, but you'll probably be using longitude/latitude. Are your points coming from a GPS device?
PostGIS uses GIST indexing, making the search for points close to a given point quite efficient. One option you might want to look at, seeing that you are interested in tiling, is to "geohash" your points. Basically, this turns an (X,Y) coordinate pair into a single "string" with a length depending on the level of partitioning. Nearby points will have the same geohash value (= 1 tile) and are then easily identified with standard database search tools. See this answer and related question for some more considerations and an example in PostgreSQL.
You do not want to look at rasters. These are gridded data, think aerial photography or satellite images, weather maps, etc.
But if you want a more specific answer you should give some more details:
How many points? How are they collected?
Do you have large clusters?
Local? Regional? Global?
What other data does this relate to?
Pseudo table structure? Data layout?
etc
More info = better answer
Cheers, hope you get your face back
I have a table that contains a bunch of Earth coordinates (latitude/longitude) and associated radii. I also have a table containing a bunch of points that I want to match with those circles, and vice versa. Both are dynamic; that is, a new circle or a new point can be added or deleted at any time. When either is added, I want to be able to match the new circle or point with all applicable points or circles, respectively.
I currently have a PostgreSQL module containing a C function to find the distance between two points on earth given their coordinates, and it seems to work. The problem is scalability. In order for it to do its thing, the function currently has to scan the whole table and do some trigonometric calculations against each row. Both tables are indexed by latitude and longitude, but the function can't use them. It has to do its thing before we know whether the two things match. New information may be posted as often as several times a second, and checking every point every time is starting to become quite unwieldy.
I've looked at PostgreSQL's geometric types, but they seem more suited to rectangular coordinates than to points on a sphere.
How can I arrange/optimize/filter/precalculate this data to make the matching faster and lighten the load?
You haven't mentioned PostGIS - why have you ruled that out as a possibility?
http://postgis.refractions.net/documentation/manual-2.0/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions
Thinking out loud a bit here... you have a point (lat/long) and a radius, and you want to find all extisting point-radii combinations that may overlap? (or some thing like that...)
Seems you might be able to store a few more bits of information Along with those numbers that could help you rule out others that are nowhere close during your query... This might avoid a lot of trig operations.
Example, with point x,y and radius r, you could easily calculate a range a feasible lat/long (squarish area) that could be used to help rule it out if needless calculations against another point.
You could then store the max and min lat and long along with that point in the database. Then, before running your trig on every row, you could Filter your results to eliminate points obviously out of bounds.
If I undestand you correctly then my first idea would be to cache some data and eliminate most of the checking.
Like imagine your circle is actually a box and it has 4 sides
you could store the base coordinates of those lines much like you have lines (a mesh) on a real map. So you store east, west, north, south edge of each circle
If you get your coordinate and its outside of that box you can be sure it won't be inside the circle either since the box is bigger than the circle.
If it isn't then you have to check like you do now. But I guess you can eliminate most of the steps already.
I would like to add placemarks to parts of collada geometry in google earth. To do this I need to translate the geometry coordinates in the xml to match the transformation to the model in google earth. Given longitude latitude and orientation how do I translate geometry coordinate to match the google earth transformation?
I believe models are located on the earth using only 1 coordinate which is used to position the 'center' of the model. How that is determined I am not sure, and might even depend on the kind/shape of the model.
The coordinate is easily found in the kml structure for the model which is referenced here
http://code.google.com/apis/kml/documentation/models.html
Determining how far a certain part of your geometry is from the middle might be very complex but here is an example of some code that will provide you the distance between two points.
http://earth-api-utility-library.googlecode.com/svn/trunk/extensions/examples/ruler.html
It is based upon the google earth extensions (gex) library
http://code.google.com/p/earth-api-utility-library/
Perhaps you could use SketchUp to help determine the location of your points of interest within the geometry?
http://sketchup.google.com/
I have a series of nature reserves that need to be plotted, as polygon overlays, on a map using the coordinates contained within KML data. I’ve found a tutorial on the Apple website for displaying KML overlays on map instances.
The problem is that the reserves vary in size greatly - from a small pond right up to several hundred kilometers in size. As a result I can’t use the coordinates of the center point to find the nearest reserves. Instead I need to calculate the nearest point of the reserves polygon to find the nearest one. With the data in KML - how would I go about trying to achieve this?
I've only managed to find one other person ask this and no one had replied :(
Well, there are a couple different solutions depending on your needs. The higher the accuracy required, the more work required. I like Phil's meanRadius parameter idea. That would give you a rough idea of which polygon is closest and would be pretty easy to calculate. This idea works best if the polygons are "circlish". If the polygon are very irregular in shape, this idea loses it's accuracy.
From a math standpoint, here is what you want to do. Loop through all points of all polygons. Calculate the distance from those points to your current coordinate. Then just keep track of which one is closest. There is one final wrinkle. Imagine a two points making a line segment that is very long. You are located one meter away from the midpoint of the line. Well, the distance to these two points is very large, while, in fact you are very close to the polygon. You will need to calculate the distance from your coordinate to every possible line segment which you can do in a variety of manners which are outlined here:
http://www.worsleyschool.net/science/files/linepoint/distance.html
Finally, you need to ask yourself, am I in any polygons? If you're 10 meters away from a point on a polygon, but are, in fact, inside the polygon, obviously, you need to consider that. The best way to do that is to use a ray casting algorithm:
http://en.wikipedia.org/wiki/Point_in_polygon#Ray_casting_algorithm