I would like to calculate the number of unique kilometers of roadways in my city. More generally, I wish to sum the distance of every road within a bound, for simplicity a rectangle will do.
Is this possible using the Google Maps suite of APIs? If so, how would you go about doing it? If anyone has any resources related to this type of problem, I would be interested in reading them regardless of language (or even solutions with other mapping tools).
Bonus points: A general solution to this problem that can be applied to the pre set "cities" (example) that appear in Google Maps with well defined city limits.
You can use OpenStreetMap to calculate the total road length of a specific country or geographic area. There are multiple solutions available, based on multiple similar questions already asked.
Approach 1 from Total road length in Kilometers for a country at help.openstreetmap.org:
Use the Perl script osm-length-2.pl. There is an example at a mailing list post.
Approach 2 from Actual road length of exported map at help.openstreetmap.org:
Import your data (the planet or an country or area extract) into a PostGIS database, then use the following queries proposed by Frederik Ramm:
SELECT way AS clip
INTO clipping_polygon
FROM planet_osm_polygon
WHERE boundary='administrative' AND admin_level='8' and name='My City';
SELECT name, highway, ST_INTERSECTION(way, clip)
INTO clipped_roads
FROM planet_osm_line, clipping_polygon
WHERE ST_INTERSECTS(way, clip) AND highway IS NOT NULL;
SELECT highway, SUM(ST_LENGTH(way::geography))
FROM clipped_roads
GROUP BY highway;
I have a list of latitude/longitude which point to some cities in England.
For each of these coordinates I want to get the region they belong to.
By region, I mean one of these: https://en.wikipedia.org/wiki/Regions_of_England
For instance: For coordinates (53.38112, -1.47008), ie. Sheffield, I need to find Yorkshire and the Humber.
To achieve this, I tried to use Google Reverse Geocoding API:
https://maps.googleapis.com/maps/api/geocode/json?latlng=53.38112,-1.47008&key=
Google then tells me that:
country is United Kingdom
administrative_area_level_1 is England, which is a State (or kind of)
administrative_area_level_2 is South Yorkshire, which is a County
administrative_area_level_3 is Sheffield District, which is a District
So Google returns me the correct State, County and District. However, Region is missing.
Is there any way to obtain it?
Looking at the documentation I don't think the Google API returns such information.
An alternative way to get round this would be to build a list of which counties belong in which of the 9 regions and then look up the region based on the county name. Obviously, this would be a bit of work on your part putting all the county names into a list.
While this doesn't directly answer your query, you could use a set of polygons which trace the regions and a point in polygon algorithm (this example is in PHP but the algorithm exists in many languages) which would allow you to check which of the regions any latitude and longitude is in
I want to find the distance between two cities say 'Mumbai' and 'Pune'.so which Google API (to be more specific, which function from which API) I can use which will accepts two parameters as input and returns the distance between them? Thanks in advance.
Update: if you're wanting Driving Directions, here's how to do it:
https://developers.google.com/maps/documentation/javascript/directions
You can just use the strings for Mumbai and Pune, you don't have to convert them to LatLng objects first (although that can still be done).
If you meant the distance as a straight line then you would need to convert 'Mumbai' and 'Pune' to latitude and longitudes. For that you need to use the Geocoding service.
Once you have those, you can use the Geometry library to calculate that distance.
I would like to find all points that are within N miles of a given area.
E.g. the area is California: Find all points that are within 50 miles of the border of California (not the middle of California).
When using Google Maps the distance is calculated using 'the middle' of the given location, but I need to calculate the distance using the borders of the given location. The location could be any zip code, city or country.
Could that be done by drawing a polygon using California's coordinates on a map and calculate the distance to location B using the points of the polygon?
Is there a more elegant solution to this? Any ideas?
Thanks!
I'm not sure if I understand your requirements completely, but I will give it a try with different interpretations:
1. You want to filter own map points:
This can be done with any GIS or a own service that offers a call like my_points_in_area(bbox). Bbox means here boundingbox and is the 2x lat/lon pair describing the rectangle around your given centerpoint. If you want to be accurate and really just deliver whats within 100km, you might need to test the distance to the POIs once more, as the rectangle will also include points that are a bit more far away.
2. You want to filter OSM data:
You might use a reverse-geocoding service as Nominatim to get informations about points of interests that are within this distance: http://wiki.openstreetmap.org/wiki/Nominatim
Otherwise import the OSM data using osmosis to a PostGIS DB. AFAIK there is (currently) no DB tool for Oracle: http://wiki.openstreetmap.org/wiki/Oracle
I'm sorry if I missed your question, but then please add more details :)
When dealing with GIS source code you often need to write latitude and longitude coordinate tuples.
E.g. in Google Maps links (123, 456):
http://maps.google.com/maps/ms?msid=214518704716144912556.00046d7689a99e95b721c&msa=0&ll=123,456&spn=0.007996,0.026865
Which is preferred order (and why?)
latitude, longitude
longitude, latitude
I have seen both being used in various systems and I hope to find some evidence to stick with other one.
Is there a standard practice, and if so, what is it / what are they?
EPSG:4326 specifically states that the coordinate order should be latitude, longitude. Many software packages still use longitude, latitude ordering. This situation has wreaked unimaginable havoc on project deadlines and programmer sanity.
The best guidance one can offer is to be fully aware of the expected axis order of each component in your software stack. PostGIS expects lng/lat. WFS 1.0 uses lng/lat, but WFS 1.3.0 defers to the standard and uses lat/lng. GeoTools defaults to lat/lng but can be overridden with a system property.
The GeoTools docs on the history and explanation of the problem are worth a read:
http://docs.geotools.org/latest/userguide/library/referencing/order.html
The prefered order is by convention latitude, longitude. This was presumably standardized by
the International Maritime Organization
as reported here. Google also uses this order in its Maps and Earth. I remember this order by thinking of alphabetic order of latitude, longitude.
The correct order is longitude, latitude, in virtually all professional GIS applications, as it is in conventional math (ie, f(x ,y, z)). The GeoJSON standard is fairly typical and succinct:
The order of elements must follow x, y, z order
(easting, northing, altitude for coordinates in a
projected coordinate reference system, or longitude,
latitude, altitude for coordinates in a geographic
coordinate reference system).
The same is true of the primary Open Geospatial Consortium standards (WKT and WKB, and extensions like EWKB). Likewise Google may output the order in Lat/Lon to make it more familiar to users who grew up with that custom (ie from navigation standards like IMO, rather than computational ones.) But the KML standard itself is like virtually all other GIS systems:
The KML encoding of every kml:Location and coordinate
tuple uses geodetic longitude, geodetic latitude, and
altitude (in that order).
Good rule of thumb: if you know what a tuple is and are programming, you should be using lon,lat. I would even say this applies if your end user (say a pilot or a ship captain) will prefer to view the output in lat,lon. You can switch the order in your UI if necessary, but the overwhelming majority of your data (shapefiles, geojson, etc.) will be in the normal Cartesian order.
By convention in 'real-life', when giving a position, the latitude (i.e. North/South) is always given 1st, e.g. 20°N 56°W (although, this doesn't follow normal convention if thinking about a standard Cartesian grid); similarly, all co-ordinates on Wikipedia follow this convention (e.g. see location for Southampton: http://en.wikipedia.org/wiki/Southampton). To save confusion, especially when units aren't being included, I'd always recommend that the latitude is given 1st in a tuple.
So the preferred order depends on personal preference!
Latitude came first; the equinox has been known for millenia, as the days the "sun crosses the equator"; in March crossing from S to N and Sept from N to S.The only question might have been whether the Equator should have been 0 or 90 degrees. By taking 0 deg, the angle between vertical and the midday solar zenith on the equinox is the latitude of a location, everywhere on the planet. The prime latitude, or prime parallel effectively defined itself.
Longitude could only be by agreement. Britain put up a Longitude prize. Britain needed its ships to know where they were and needed better maps. Harrison (http://www.youtube.com/watch?v=T-g27KS0yiY) produced an accurate marine chronometer; they sent mapmaking voyaging journeys eg James Cook 1770's. Britain therefore claimed the Prime Meridian by using Greenwich as 000deg for their maps. After 100 years of their use, the Prime Meridian was accepted internationally, in 1884.
In Christopher Columbus time Latitude was the only number they had. The strategy was to traverse a parallel before turning left or right for destination; watching for clouds or birds. Measuring speed in knots every hour was common but did not account for currents. Perhaps Columbus's greatest achievement was getting back home from the West Indies four times. Without that, land he discovered could not be added to the maps.
Read "Longitude" by Dava Sobel (ISBN: 9780007214228)
ISO 6709 standardizes listing the order as latitude, longitude for safety reasons. Graham's explanation above sounds correct to me as well. Someone suggested this answer isn't related to the question--it absolutely is, and explains why the order is often given as latitude, longitude.
This is how it has been listed for however long navigators have been using the system; changing that now would be confusing, and as ISO suggests, potentially dangerous. GIS softwares, like ArcMap, list them the other way around because that is the typical convention for x,y coordinate pairs. Latitude is y, longitude is x, so that's how Arc lists them.
Personally I've never seen anything but latitude followed by longitude.
And, when using + and - instead of N and S, it's always been + is N and - is S.
I have observed variation when using + and - for E and W. Generally + has been E and - has been W. However, on older applications where they were dealing overhwlemingly with W longitudes, I've seen + be W and - be E.
Hopefully you'll not have to be dealing with applications that old.
Apart from GeoJSON spec, which others have already mentioned, there are other practical cases where longitude,latitide order is recommended, even mandatory - e.g.: geospatial indexing in MongoDB. If you get the order wrong there, your queries will return wrong results, as if performed again a transposed dataset.
Longitude then Latitude (lon, lat).
When projected to Mercator longitude defines the x direction and latitude defines the y direction. Most geometry libraries strictly uses this format of (lon, lat) as it is the most intuitive way to think of geographic coordinates in a 2D plane.