Im having some issues querying the openstreetmap DB using overpass.
What I want is to get all the nd nodes in a way, so my query is like so:
[out:json][timeout:30]; (way(id:397466166);._;>;); out body center qt 15;
This...sorta works. It gives me all the nodes in the way, but they are not in the right order. Ive tried countless queries to try and get the children nodes of the way, but I just can't get it. One query I tried was:
[out:json][timeout:30]; (way(id:397466166);<;); out geom;
But this just returns the ways latitude and longitude...
Any help?
Related
I'm fairly new at using overpass API, I finally managed to generate a query to retrieve all nodes within an area by using overpass-turbo wizard.
Using highway=* in "Paulino Navarro" in the wizard generates me the following query.
/*
This has been generated by the overpass-turbo wizard.
The original search was:
“highway=* in "Paulino Navarro"”
*/
[out:json][timeout:25];
// fetch area “Paulino Navarro” to search in
{{geocodeArea:Paulino Navarro}}->.searchArea;
// gather results
(
// query part for: “highway=*”
node["highway"](area.searchArea);
way["highway"](area.searchArea);
relation["highway"](area.searchArea);
);
// print results
out body;
>;
out skel qt;
However, how could I use a polygon as a search area? maybe something like highway=* in poly([lat,lon],[lat,lon],...,[lat,lon]) or how can I do that on the query itself.
I don't quite understand the documentation in overpass wiki nor overpass-turbo wizard.
The polygon filter is explained in the Overpass QL documentation.
Example:
[out:xml][timeout:30];
way[highway=primary](poly:"50.7 7.1 50.7 7.2 50.75 7.15");
(._;>;);
out;
If the polygon you want to query inside of is an OSM feature, you can also query using an area ID.
Area IDs are generated by the Overpass server to make querying data within existing polygons easier. You can determine the area ID for a way by adding 2400000000 to the way ID and the area ID for a relation by adding 3600000000 to the relation ID (assuming that the way or relation is a valid area feature).
Example:
[out:xml][timeout:30];
way[highway=primary](area:2400000001);
(._;>;);
out;
I'm working with OrientDB (2.2.10) and occasionaly I would like to visually inspect my dataset to make sure I'm doing things correctly. On this page of OrientDB http://orientdb.com/orientdb/ you see a nice visualization of a large graph with the following query:
select * from V limit -1;
So I tried the same query on my dataset but the result is so extremely sluggish that I can't work with it. My dataset is not extremely large (few hundred vertices, couple thousand edges) but still the result is unworkable. I tried all major browsers but with all I have the same result. Also my computer is not underpowered, I have a quad-core i7 with 16GB RAM.
As a very simple example I have the following graph:
BAR --WITHIN---> CITY --LOCATED_IN--> COUNTRY
Here: Find "friends of friends" with OrientDB SQL I was able to get at least an example of how to do this type of query on a graph. I managed to get a subset of my graph for example as follows:
select expand(
bothE('WITHIN').bothV()
) from Bar where barName='Foo' limit -1
This get's me the graph of 1 Bar vertex, the edge WITHIN and the City vertex. But if I now want to go one step further by also fetching the country which the city is located in I cannot get this style of query to work for me. I tried this:
select expand(
bothE('WITHIN').bothV()
.bothE('LOCATED_IN').bothV()
) from Bar where barName='Foo' limit -1
This results in the same subset being shown. However, if I first run the first query and then without clearing the canvas run the second query I do get the 3 vertices. So it seems I'm close but I would like to get all 3 vertices and it's edges in one query, not having to run first the one and then the other. Could someone point me in the right direction?
If you want to get all three vertices, it would be much easier start from the middle (city) and than get in and out to get bar and contry. I've tried with a similar little structure:
To get city, bar name and country you can try a query like this:
select name, in("WITHIN").name as barName,out("LOCATED_IN").name as barCountry from (select from City where name='Milan') unwind barName, barCountry
And the output will be:
Hope it helps.
If it is not suitable for your case, let me know.
You could use
traverse * from (select from bar where barName='Foo') while $depth <= 4
Example: I tried with this little graph
and I got
Hope it helps.
I'm trying to query the OSM Overpass API to find any amenities within a bounding box. The actual query in my program will be generic but in my testing I noticed I cannot retrieve the coordinates(latitude, longitude) of any of the ways. Here is my script:
(
node
["amenity"="police"]
(39.235,-76.715,39.373,-76.525);
way
["amenity"="police"]
(39.235,-76.715,39.373,-76.525);
);
(._;>;);
out meta;
I need to use ways because I'm missing a significant amount of data without them. Unfortunately they do not include any coordinate data despite me adding out meta instead of the normal out. This was answered here, overpass-api ways query include coordinates about a year ago but that solution no longer works. Is this a bug? Or am I doing something wrong? I've also tried out center, out geom, and out skel to no success. I'm outputting the data in xml.
ANSWERED, I left on the recursion line on the end by accident. Thanks Tyr.
I want to write a code that has the Countrycode and Postcode as an input and the ouput are the streets that are in the given postcode using some apis that use GSM.
My tactic is as follows:
I need to get the relation Id of the district. For Example 1991416 is the relation id for the third district in Vienna - Austria. It's provided by the nominatim api: http://nominatim.openstreetmap.org/details.php?place_id=158947085
Put the id in this api url: http://polygons.openstreetmap.fr/get_wkt.py?id=1991416¶ms=0
After downloading the polygon I can put the gathered polygon in this query on the overpass api
(
way
(poly: "polygone data")
["highway"~"^(primary|secondary|tertiary|residential)$"]
["name"];
);
out geom;
And this gives me the streets of the searched district. My two problems with this solution are
1. that it takes quite a time, because asking three different APIs per request isn't that easy on ressources and
2. I don't know how to gather the relation Id from step one automatically. When I enter a Nominatim query like http:// nominatim.openstreetmap.org/search?format=json&country=austria&postalcode=1030 I just get various point in the district, but not the relation id of the searched district in order to get the desired polygone.
So my questions are if someone can tell my how I can get the relation_Id in order to do the mentioned workflow or if there is another, maybe better way to work this issue out.
Thank you for your help!
Best Regards
Daniel
You can simplify your approach quite a bit, down to a single Overpass API call, assuming you define some relevant tags to match the relation in question. In particular, you don't have to resort to using poly at all, i.e. there's no need to convert a relation to a list of lat/lon pairs. Nowadays the concept of an area can be used instead to query for certain objects in a polygon defined by a way or relation. Please check out the documentation for more details on areas.
To get the matching area for relation 1991416, I have used postal_code=1030 and boundary=administrative as filter criteria. Using that area you can then search for ways in this specific polygon:
//uncomment the following line, if you need csv output
//[out:csv(::id, ::type, name)];
//adjust area to your needs, filter critera are the same as for relations
area[postal_code=1030][boundary=administrative]->.a;
// Alternative: {{geocodeArea:name}} -> see
// http://wiki.openstreetmap.org/wiki/Overpass_turbo/Extended_Overpass_Queries
way(area.a)["highway"~"^(primary|secondary|tertiary|residential)$"]["name"];
(._;>;);out meta;
// just for checking if we're looking at the right area
rel(pivot.a);out geom;
Try it on overpass turbo link: http://overpass-turbo.eu/s/6uN
Note: not all ways/relations have a corresponding area, i.e. some area generation rules apply (see wiki page above). For your particular use case you should be ok, however.
I am working on a project where we are going to be looking at finding the shortest/fastest route from point A to point B. I've been looking at the tables generated by the osm2pgsql. And I'm wondering how would I represent a road obstructed after the osm has been loaded into our database. Our project will rely on osm to map out all of the roads we will also have an operator looking at live video footage of roads. At which point if the operator see's a road is obstructed we want to update the database to reflect this road obstructed say by a downed tree.
I've been looking at all of the columns and the only one that stands out in my head is barrier. I have been unable to find any documentation on what each column represents and how pg_route takes each into consideration when creating a route. What I'm looking for is a column that when pg_route looks in the database and sees a road it says oh that roads blocked skip it?
This is good question for gis.se...
First thing is pg_routing can't route via data generated by osm2pgsql - this data is not a network. You need data generated by osm2po or osm2pgrouting and this data is quite different.
Second thing is - there is no such column. In every pg_routing function you're passing sql which will select data for route search so you're deciding which edge will be in this dataset and which not - it's not a problem to add extra column to table with edges.
Here is link to pgrouting workshop it will guide you through all process from import of data to first generated route. It's using osm2pgroutin to import data, but I suggest you use osm2po instead.
So as Jendrusk mentioned, when you generate a route you will pass the function a SQL query to select the edges for the graph you want to solve, 'select * from edges where the_geom && <bbox>' You can model blockages using point and radius, lines, or polygons that you want the route to avoid by adding to the query above avoidance zones like:
'select * from edges where the_geom && <bbox> and not st_dwithin(the_geom, point, radius) and not stdwithin(the_geom, line_or_polygon, 0.0)'
If you have lots of these avoidances then put them in a table and do a join to eliminate the edges that are used to build the graph. If the edges are not there the route is forces to find a way around the avoidance.