Imagine I have a PostGIS database with following pieces of information
OSM (OpenStreetMap) of a city,
the roads/streets inside the city and
the routes of public transport in that city.
I want
to calculate distance from building A to building B in that city via streets/roads (for people with cars) and
to estimate the amount of time it takes to get from building A to building B using available public transport (for people without a car).
Is there any ready-made (open source or commercial) software for performing such calculations in PostGIS?
For public transport planning you should check OpenTripPlanner, too. After the link, you will see various examples, not all works, but Athens does.
It seems that PgRouting does exactly that. Here's an intro.
Related
I am working on creating a map sales report to show the sales by product for various territories. The territories are based upon zip codes and are custom territories that overflow into multiple states or are partially in a state. I have gotten everything set up and it looks good for the most part...EXCEPT 2 areas.
1.) one of the sales numbers shows up in Alaska which is not viewable if a user is zoomed in on the USA (we are US-based so it's only relevant to show anyways). Is there a way to force a sales number to show up on a user-defined location? For instance, can I show this on the State of Washington instead of Alaska or can it only default to the largest (area) part of a user-created territory map?
2.) being that we are US-based is there a way to move the states Alaska and Hawaii closer to the US? I know that utilizing the dashboard is a workaround, but it does not look good.
I'm not sure this could be a complete answer, but I think this question has more than one take.
That being said, if your worksheet is based on zip codes in order to create a map, I don't think you can force Tableau to visualize data out of their original position based on the specific geographic role.
The only thing that come to my mind is switching your approach from geographical role (country, state, city, zip, etc) to a more generic lat/long coordinates.
Doing so, you can manually match your Alaska zip codes to lat/long more "continental" areas.
Anyway this would require a lot of data manipulation prior to Tableau.
An alternative way of accomplish something similar to what you say in your second point could lead you to use 3 seperate worksheets in a single dashboard: continental, Alaska, Hawaii.
I did something on US data and I was facing the same problem for Hawaii, so I decided to use a floating worksheet putting it on the bottom left corner of the continental map.
I have a GIS model where a truck leaves a main distributor, visits several customers along a route to make deliveries, and then return to the distributor once it is empty. The route is chosen based on proximity of agents to the main distributor and to each other. I'm trying to figure out how to log the route the truck took in order to make the deliveries, though I have not been able to do so yet. Any help is greatly appreciated. Thank you!
If you want to log street names (as you do):
You can't.
Not with the free GIS map service that pulls data from OSM. I believe that you could do it from Google Maps services but it is very expensive... Your only chance is to download OpenStreeMap shapefiles of the area of interest, convert them into a network of paths and pull the street names from there.
The OSM shapefiles should have street names in their dbf files and you can specify in the AnyLogic GIS map object in which column of your dbf file the street names are located. Then, upon converting to path objects, AnyLogic will name the path object according to the street name.
But to be honest, this is not trivial and might be overkill for you. Maybe think about logging something else?
In order to log coordinates i would use a collection of type GISRoute. This is the type you are getting anyway when calculating route for your truck. And GISRoute contains an array of segments (GISMarkupSegment). And every segment has a start and end (type Point) with its lat and lon (methods getLatitude, getLongitude).
I'm looking for some good tool to import map.osm to postgres and next create some routes which will be displayed by geoserver. I need route, with some text information about vertexes (e.g. city, address, address number, and so on...)
I found this:
osm2pgrouting - Import OSM data into pgRouting Database
osm2postgis -Import OSM data to PostGIS
osm2po - tool to convert OSM data into a routable format
osm4routing - OpenStreetMap data parser to turn them into a nodes-edges adapted for routing applications
I do not have many experiences with GIS, so how tool is the best for me? I try osm2pgrouting, but in result I have tables, which do not contains data about vertexes(only lat. and alt.) Thanks for answers.
UPDATE App Info:
I will be have web and android client where user enter text value of start and end node, and next over geoserver get wms with vertexes of entered route for example
My result from could be be some edges and nodes like this like this:
sequence_num, edge_distance, and informations about edge vertexes like osm_id, some text value, lat alt, etc...
I think you have a lot of work to do before you get to a complete solution, but here are some pointers. I suggest you break down your project into smaller chunks and ask specific questions on any bits you might get stuck on.
First, you need to import your data. Then you'll need some pre-processing / cleaning. Then you need your routing queries and, finally, a way to use the outputs (with this last part determining to some extent the previous steps).
Import OSM data
As I described in an answer to your previous question here, you can use OGR2OGR to import OSM data to Postgis. You can use other programs, as you mention above, but I guess you'll get much the same results. I think the difference between the OGR2OGR tables and the osm2postgis ones is that some of the columns in the latter appear in the other_tags column. However, the data is still there, you just need slightly different queries.
Preparing data
I'm assuming you'll use pgrouting for the routing, but whatever you use, you'll need a network suitable for routing (in short, the edges have a start and end node, and the end nodes must connect with other start nodes). Pgrouting has tools to create what you need and validate it. E.g. you create integer columns source and target and the function pgr_createtopology will populate the columns for you.
OGR2OGR gives you tables "lines", "points", "multipolygons", "multilinestrings". I suggest you read up on OSM to understand exactly what is in these tables, but, roughly speaking, the lines contain your roads and the multipolygons contain, amongst other things, buildings with e.g. addresses. The addresses are in a hstore column called "other_tags".
The lines do not contain addresses! (although they do contain street names). So, if you want to do address-to-address routing you need to do some preparation. You can skip this if you can live with the street names.
Create your network (e.g. if you're routing for cars, you'll want to
throw out pedestrian routes and so on)
Extract the desired addresses (including coordinates)
Either snap the addresses to the nearest node, or otherwise
relate the address to the nearest node
Pgrouting will return the edges in your route, so you need the above to relate back to your addresses.
Routing
Your app is going to send to your server (in an as-yet unspecified way) a pair of addresses or coordinates and you need postgis to return the route. With pgrouting, that's quite easy and there are plenty of examples out there, for example here. You will need to write queries that join the output to your address table to give you the desired output.
pgrouting creates a vertices table. You can get the nearest vertex with the following query:
select id from vertices_pgr
order by the_geom <-> st_setsrid(st_point(lon,lat),4326)
limit 1
Using the output
Using WMS from geoserver is unlikely to be a good choice - you won't have the information on individual edges without a lot of messing about. You might consider geoJSON, which can be read by e.g. OpenLayers, Leaflet, or you can manipulate in Javascript. Postgres has lots of useful functions for working with json and geojson.
Conclusion
That's quite a lot of work and probably new stuff if you have little GIS knowledge, and it, er, basically recreates what you'd get from Graphhopper! Are you sure that's not a better way to go?
If you do decide to go this (or similar) route break things down into manageable chunks! First, figure out exactly what you're trying to achieve, then work backwards from there. If you do decide to use OSM / pgrouting, then play with the data and pgrouting first so you understand how it works before trying address matching etc.
The tools you listed are only for producing data, but I think you actually need a routing engine.
Try Graphhopper: https://graphhopper.com
Using the WEB Api (more likely what you need), you don't need the import the data in your database. This is the easiest solution. You will have not control over the input openstreetmap data but this is fine if you don't have special requirements.
Import data and implement/integrate a routing engine directly in your application would be much more complicated.
I'm using the Reverse Geocoding provided by Apple (Linked to the dev documentation at the bottom of this post).
I have set this up to work with my current project. When I touch the map, the touchPoint is converted to coordinates which I use with my reverse geocoding. The problem is though, that I only get information regarding address (street, housenumber, country and so on) when I geocode a location from Europe, North America and parts of South America. I do NOT get this information when doing a reverse geocoding on coordinates from Africa and Asia.
I used Forward Geocoding (some random addresses in Africa and Asia) to check if these could be found with all the information. And they could - the forward geocoding works brilliant.
So how can it be, that I don't get address information when I reverse the geocoding with coordinates from especially Africa and Asia? Anyone experienced the same thing?
http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/LocationAwarenessPG/UsingGeocoders/UsingGeocoders.html#//apple_ref/doc/uid/TP40009497-CH4-SW1)
Reverse GeoCoding (See error message returned kCLErrorGeocodeFoundPartialResult and kCLErrorGeocodeFoundNoResult). Many times only the US, Europe and densely populated cities of the world return full reverse address information.
When kCLErrorGeocodeFoundPartialResult occurs, that mean only a portion of the reverse geocode information is available. This may be the street name (individual addresses, meaning house/bdlg or lot#) is not available. This could be less and less information down to just the country name.
This is because for use with Google, the satellites only return lat & lon. It is up to Google or other mapping companies to provide data points and data point region information (meaning lat/lon and span around that point that a bldg would occupy for an address). Because this information has to be acquired from each and every single municipality around the world, then verified and data entered - it is a HUGE undertaking for which Google has been actively doing for over 10 years. In this time, there is less than 7% of the earth's land masses that is majority geocoded. Adding to this difficulty is that the US and the Majority of Europe are relatively well organized at the municipality level with up to date maps and parcel/lot locations. That same is not true for many other areas of the world.
So it is up to you, the developer, to sift through the available information and structure the annotation callout information that makes the most sense from the limited information returned. Again, this may just be the Country Name.
Also, don't forget about Ocean and InlandWater fields for if you user drops a pin in the great Lakes or the Hudson River.
the Name field is also helpful for Landmarks.
Yes, in the end, there is a lot of juggling to figure out how best to display place mark data returned from a reverse geocode lookup, but your users will thank you for trying out every possibility you can think of.
The above information as well as lists for full geocode and partial geocode countries is in the Apple Documentation. You would be surprised to see just how few countries there are on those lists!
There are probably about 600 councils in Australia. I need to work out how to create boundaries for them all within my iPhone application so that when a user is in a certain area the application will know which council the user is in.
I probably can get a lot of this information from councils, however what information would I need to ask for? Is boundary information enough? And then how should my developer use that?
Thanks,
It sounds like what you're asking about is how to define the boundary of a council. Generally the boundary of a council (or country, or any other geographic region) can be defined by an ordered series of latitude, longitude pairs which represent points on the surface of the Earth; the border is the line that connects them.
Such a series might look a bit like the following:
Region 1:
64.222, 41.135
64.161, 41.143
64.114, 41.080
...
Region 2:
64.114, 41.080
64.008, 41.090
64.008, 40.902
...
Given such a series of border points there are established algorithms for determining whether a given point is within the region (if you're curious you can read about them here). I'm not sure whether there are more efficient algorithms for determining which of several regions a point is in, but that's for your developer to figure out.
I'll answer your two questions separately:
1. Where do I get council map boundaries for Australia?
The Australian Bureau of Statistics publish this data in ESRI Shapefile and MapInfo format. The areas are known as "Local Government Areas". The 2010 data set is available at http://www.abs.gov.au/AUSSTATS/abs#.nsf/DetailsPage/1259.0.30.001July%202010?OpenDocument
2. How do I use geospatial data?
The ESRI Shapefile format can be read by pretty much every spatial data package under the sun. I have some favourites however:
On client side my favourite library is GDAL, a translator library with an X/MIT style Open Source license. It comes with C, C++, Python and C# bindings. Or if this is too heavyweight, you might prefer to directly use Shapelib, an MIT licensed C library used by GDAL.
On the server side you can't go past PostGIS. If you are sending your latitude/longitude pair to a web server, consider installing these spatial extensions for the postgresql server. You can load a shapefile into the database using the bundled shp2pgsql utilty. Then, to find the LGA your lat/lon pair fall into query the database like this:
SELECT * FROM lga2010
WHERE ST_Intersects(lga2010.the_geom,
ST_SetSRID(ST_MakePoint(your_longitude, your_latitude),4326))