I try to find a way to get the projection type of the following coords.
I need to convert these coords in WGS84 latitude longitude format. I have only 1 hint: these coords are located in Florida-USA (Broward County)
<XCoordinate>9082520</XCoordinate>
<YCoordinate>6563620</YCoordinate>
Thanks
I suspect your data are in "SPC" (State Plane Coordinate) system. This is often used for "local" coordinates - it makes calculations for such things as distances and routes much easier. If that is the case, and the county in question is Broward (which is zone 0901), then there is still some guessing to do... because one can use "US feet", "International feet", or meters in this system.
If you go to http://www.earthpoint.us/Convert.aspx you can enter your coordinates in the "Position" box. Depending on what you choose you will get different answers. I suggest you try to see which makes sense (if you suspect the coordinates are for a post office and you land in a lake you probably are using the wrong number):
0901 908252.0ftE 656362.0ftN gives 26°08'14.5036", -080°13'53.8483"
That puts you pretty much on top of a bus stop - which I guess is what the Hastus system might be giving you...
Related
I am participating in a starter Kaggle competition(Crimes in San Francisco) in which I want to predict the category of a crime using a bunch of predictor variables including X and Y coordinates of a crime. As I doubt of the predictive power of the coordinates, I want to transform these variables to something more relevant to the crime category.
So I am thinking that if I had the neighbourhood of San Francisco in which the crime took place, it would be more informative than the actual coordinates of the crime. I can find the neighbourhoods online but of course I cant use the borders of each neighbour to classify the corresponding crime because their shapes are not rectangular or anything like that.
Does anyone have any idea about how I could solve this one?
Thanks guys
Well that's interesting AntoniosK and it's getting close to what I want to accomplish. The problem is that the information " south-east and 2km from city center" can lead to more than one neighborhoods.
I am still thinking that the partition of the city in neighborhoods is valuable because the socio-economic and structural differences between them ( there is a reason why the neighborhoods of each city are separated as such, right?) can lead to a higher probability for a certain category crime and a lower one for another.
That said, your idea made me thinking of using the south-east etc mapping and then use the angle of the segment(point to city center) with x axis to map the point to appropriate neighborhood. I am on it right now. Thanks
After some time on the problem I found that the procedure I want to perform is titled " reverse geocoding". It also turns out that there are some api's to solve this. The best according to my opinion is revgeocode() function contained in ggmap package(google's edition). This one though has a query limit per day(2500 queries) unless you pay for extra.
The one that I turned to though is geonames package and GNneighbourhood function that turns coordinates to neighbours. It is free, though I have experienced some errors(keep in mind that this one is only for US and Canada cities)
revgeocode function-ggmap package
Gnneighbourhood-geonames package
I'm trying to create a map using the qmap (part of ggmap).
Here's an example piece of code to illustrate by question. It's kind of silly, but it's cleaner than using my own data.
install.packages("ggmap")
library(ggmap)
qmap("Capitol Building, Washington DC", zoom = 15)
So here's my question:
I'd like to zoom in a good bit (zoom=15) on the area around the Capitol Building, to get lots of street detail.
But I also want to include the Washington Monument in my map.
To do this, I'd like to extend the western part of the map and make it rectangular.
Does anybody know how to do that? Any insight would be much appreciated. Thanks for your patience with a beginner.
Like this?
library(ggmap)
cap <- geocode("Capitol Building, Washington DC")
wash <- geocode("Washington Monument, Washington DC")
loc <- unlist((cap+wash)/2)
ggmap(get_map(location=loc,zoom=15))+coord_fixed(ylim=loc[2]+.005*c(-1,+1))
So this pulls in a map based on coords midway between the Capitol Building and the Washington Monument, then trims it by setting the ylim.
The reason for unlist(...) is that geocode(...) returns a data frame and get_map(...) wants a numeric vector.
EDIT Response to OP's comment.
coord_fixed(...) forces an aspect ratio of 1:1, meaning that 1° of latitude is the same length as 1° of longitude. To get back the original aspect ratio from the map, use coord_map(...).
ggmap(get_map(location=loc,zoom=15))+coord_map(ylim=loc[2]+.005*c(-1,+1))
I have a large collection of pictures with GPS locations, encoded as lat/lon coordinates, mostly in Los Angeles. I would like to convert these to (1) zipcodes, and (2) neighborhood names. Are there any free web services or databases to do so?
The best I can come up with so far is scrape the neighborhood polygons from the LA times page and try to find out in which polygon every coordinate is. However this might be quite a lot of work, and not all of my coordinates are in LA. As for the zipcodes, this 2004 database is the best I can find, however zipcodes are encoded as a single coordinates instead of a polygon. So the best I can do is find the minimum distance from a given coordinate to the given zipcode-coordinates, which is not optimal.
I was under the impression that google-maps or open-street-maps should be able to do this (as they seem to 'know' exactly where every neighboorhood and zipcode is), however I cannot find any API's to do the lookups / queries.
You can now do this directly within R itself thanks to the rather awesome ggmap package.
Like others mention, you'll be reverse geocoding using the google maps API (and therefore limited to 2,500 queries daily), but it's as simple as:
library("ggmap")
# generate a single example address
lonlat_sample <- as.numeric(geocode("the hollyood bowl"))
lonlat_sample # note the order is longitude, latitiude
res <- revgeocode(lonlat_sample, output="more")
# can then access zip and neighborhood where populated
res$postal_code
res$neighborhood
Use Reverse Geocoding to convert your lat/lon to addresses. It has some limit on the number of queries per day though.
Here is a nice blog post with examples how to geocode and reverse geocode using google-maps.
Try this one:
http://www.usnaviguide.com/zip.htm
There is some limit as to how many queries per day you can do on the site, but they also sell the complete database, which changes every few months.
Sorry that I don't know of any free resources.
As others suggested, geocode them into street address should work fine for zip code. i am not too sure about neighborhood, because you may have to look if street number is odd/even to see if it is located which side of a road that determines neighborhood.
An alternative way is to prepare GIS polygon feature (ESRI shape file for example), test each point against this set of polygons see which one it intersects.
zip code is very straighforward, you can download shape file from the census.
http://www.census.gov/cgi-bin/geo/shapefiles2010/main
neighborhood is harder, i'd guess. In another part of US i had to create my shape file on my own by combining definitions from municipal government, real-estate website, newspaper etc so that it looks like what people thinks neighborhood in the city are without having any overlap or gap. It can take some time to compose such set of polygons. you may crab census "block group", or even census "block" from the above page and merge them
Once you prepared polygon features, there are couple of GIS tools on different environment (stand-alone executable, GUI program, c/python/sql etc API, probably R as well, to do intersection of polygons and points.
I am in charge of a program that is used to create a set of nodes and paths for consumption by an autonomous ground vehicle. The program keeps track of the locations of all items in its map by indicating the item's position as being x meters north and y meters east of an origin point of 0,0. In the real world, the vehicle knows the location of the origin's lat and long, as it is determined by a dgps system and is accurate down to a couple centimeters. My program is ignorant of any lat long coordinates.
It is one of my goals to modify the program to keep track of lat long coords of items in addition to an origin point and items' x,y position in relation to that origin. At first blush, it seems that I am going to modify the program to allow the lat long coords of the origin to be passed in, and after that I desire that the program will automatically calculate the lat long of every item currently in a map. From what I've researched so far, I believe that I will need to figure out the math behind converting to lat long coords from a UTM like projection where I specify the origin points and meridians etc as opposed to whatever is defined already for UTM.
I've come to ask of you GIS programmers, am I on the right track? It seems to me like there is so much to wrap ones head around, and I'm not sure if the answer isn't something as simple as, "oh yea theres a conversion from meters to lat long, here"
Currently, due to the nature of DGPS, the system really doesn't need to care about locations more than oh, what... 40 km? radius away from the origin. Given this, and the fact that I need to make sure that the error on my coordinates is not greater than .5 meters, do I need anything more complex than a simple lat/long to meters conversion constant?
I'm knee deep in materials here. I could use some pointers about what concepts to research.
Thanks much!
Given a start point in lat/long and a distance and bearing, finding the end point is a geodesic calculation. There's a great summary of geodesic calculations and errors on the proj.4 website. They come to the conclusion that using a spherical model can get results for distance between points with at most 0.51% error. That, combined with a formula to translate between WGS-84 and ECEF (see the "LLA to ECEF" and "ECEF to LLA" sections, seems like it gets you what you need.
If you want to really get the errors nailed down by inverse projecting your flat map to WGS-84, proj.4 is a projection software package. It has source code, and comes with three command line utilities - proj, which converts to/from cartographic projection and cartesian data; cs2cs, which converts between different cartographic projections; and geod, which calculates geodesic relationships.
The USGS publishes a very comprehensive treatment of map projections.
I'd do a full-up calculation if you can. That way you'll always be as accurate as you can be.
If you happen to be using C++ the GDAL is a very good library.
For a range of 40km, you may find that approximating the world to a 2D flat surface may work, although a UTM transform would be the ideal way to go - in any case, I'd advocate using the actual WGS84 co-ordinates & ellipsoid for calculations such as great circle distance, or calculating bearings.
If you get bored, you could go down a similar line to something I've been working on, that can be used as a base class for differing datums such as OSGB36 or WGS84...
I'm writing a mapping application that I am writing in python and I need to get the lat/lon centroid of N points.
Say I have two locations
a.lat = 101
a.lon = 230
b.lat = 146
b.lon = 200
Getting the center of two points is fairly easy using a euclidean formula. I would like
to be able to do it for more then two points.
Fundamentally I'm looking to do something like http://a.placebetween.us/ where one can enter multiple addresses and find a the spot that is equidistant for everyone.
Have a look at the pdf document linked below. It explains how to apply the plane figure algorithm that Bill the Lizard mentions, but on the surface of a sphere.
poster thumbnail and some details http://img51.imageshack.us/img51/4093/centroidspostersummary.jpg
Source: http://www.jennessent.com/arcgis/shapes_poster.htm
There is also a 25 MB full-size PDF available for download.
Credit goes to mixdev for finding the link to the original source, and of course to Jenness Enterprises for making the information available. Note: I am in no way affiliated with the author of this material.
Adding to Andrew Rollings' answer.
You will also need to make sure that if you have points on either side of the 0/360 longitude line that you are measuring in the "right direction"
Is the center of (0,359) and (0, 1) at (0,0) or (0,180)?
If you are averaging angles and have to deal with them crossing the 0/360 then it is safer to sum the sin and cos of each value and then Average = atan2(sum of sines,sum of cosines)
(be careful of the argument order in your atan2 function)
The math is pretty simple if the points form a plane figure. There's no guarantee, however, that a set of latitudes and longitudes are that simple, so it may first be necessary to find the convex hull of the points.
EDIT: As eJames points out, you have to make corrections for the surface of a sphere. My fault for assuming (without thinking) that this was understood. +1 to him.
The below PDF has a bit more detail than the poster from Jenness Enterprises. It also handles conversion in both directions and for a spheroid (such as the Earth) rather than a perfect sphere.
Converting between 3-D Cartesian and ellipsoidal latitude, longitude and height coordinates
Separately average the latitudes and longitudes.