I'm trying to use overpass to find piers within "large" bodies of water. However, it seems like often piers are not inside water regions, but rather that the water curves around them. Is it possible to search by proximity to an area? Or maybe there is an alternative approach?
Here is a contrived example near Duluth, MN illustrating the issue.
We can look at piers (and bodies) of water within a bounding box:
[out:json][timeout:180];
(
nwr(
46.762191510926186,
-92.08509489611468,
46.76367911337914,
-92.08318778203628
)["man_made"="pier"];
wr["name"]["natural"="water"]["water"!="river"]["boat"!="no"](if: length() > 3000)(
46.762191510926186,
-92.08509489611468,
46.76367911337914,
-92.08318778203628
);
);
(._;>;);
out body;
>;
out skel qt;
Here we see that there is a body of water and several piers. However, if I alter the query so that the bodies of water in the bounding box are areas and then I search for piers within that area, I get an empty response:
[out:json][timeout:180];
area["name"]["natural"="water"]["water"!="river"]["boat"!="no"](if: length() > 3000)(
46.762191510926186,
-92.08509489611468,
46.76367911337914,
-92.08318778203628
)->.mywater;
(
nwr(area.mywater)["man_made"="pier"];
);
(._;>;);
out body;
>;
out skel qt;
As mentioned above, it seems like the piers are not contained within the body of water, but rather sit on the boundary.
Paul, this works for me:
[out:json][timeout:180];
area[name="Lake Superior"];
way(area)["man_made"="pier"];
(._;>;);
out;
This query in Overpass Turbo: https://overpass-turbo.eu/s/1osL
Notes:
Please have a look whether the list is complete. From your question it seems that you found a set of piers that "sit on the boundary" of the body of water. It might be useful if you published such examples.
As you see, this is simplified version of your query: I limited it to Lake Superior, and only to piers mapped as ways. However, I believe you can expand it to other areas (using the bounding box in your original query) and piers mapped as nodes or relations.
Alternatively, have a look at the around filter in Overpass Query Language reference. I have good experience with searching around nodes; not sure how it works with areas.
Related
I have a high volume dataset with keys like this:
lat:6.897585,
long:52.785805,
speed:12,
bearing:144
Basically it is a dataset of records of various trips on cars. The data was stored every few seconds during each trip. The main goal of this project is to be able to visualize only u-turns (turn arounds) on a map. But for now, I am trying to at least show the data on specifc roads. For that, I am using Overpass API
With the help of Overpass Turbo, I can get a dataset with all the roads I need.
However, in the dataset, the road's geometry is represented with LineString type.
My question is, How can I get a bounding box(es) of the roads from Overpass API, so later on, I can display events that happened only on the given roads? Or maybe you have a better solution on how to achieve this?
A bounding box wouldn't be very helpful here, as using it to filter your points would show everything that falls within the box (which could include other nearby roads)
It sounds like getting a buffer around a linestring might get you closer, but could still include points that are within the buffer but not on the road you are inspecting.
The smarter way to do this would be to assign each event to a road segment using some logic based on their attributes/properties, so you don't have to depend on a spatial filter.
I need to extract building geometry by coordinates
I have this, but as I use around it selects the nearest buildings too.
Is there a way to select only one? the building that includes the coordinates
[out:json][timeout:25];
// adjust the search radius (in meters) here
// gather results
(
// query part for: “building=*”
way["building"](around:5,37.780495290046375,-122.47132010628351);
);
// print results
out body;
>;
out skel qt;
I cannot find anything about selecting only one building (or more generally: the best match only) in the Overpass API documentation, although I do surmise it should be possible.
A workaround would be to compare the coordinates of your matches with the desired coordinates, and only retain the match with smallest distance in radial coordinates.
For a project on geospatial data analytics, we are currently extracting road type and speed limit data of certain roads along a track by using Overpass' polygon query (where we define the roads by a buffer zone around them). The problem is that in the case of separate tracks, we can end up with disconnected polygons which often lead to a significant increase in computation time. In this situation, we were wondering how Overpass' polygon query actually works. Does the algorithm actually query only the data inside this polygon/these polygons, or does it query inside a bounding box, after which it filters out the data inside the polygons?
The algorithm checks if nodes are inside the defined polygon, or if a way crosses the polygon. It's not based on bounding boxes as you mentioned.
From your description it's not quite clear why disconnected polygons pose an issue. You should get decent performance with a lz4-based backend and a reasonable number of lat/lon pairs in your (poly: ) filter (the more pairs you provide, the more expensive the computation gets).
BTW: The best approach to tackle this issue would be something I described in this blog post: https://www.openstreetmap.org/user/mmd/diary/42055 - unfortunately, this feature is not yet available in the official branch. If you see some use for it, please upvote here: https://github.com/drolbr/Overpass-API/issues/418
I'm pretty new to postgresql, so there might be a pretty simple answer to my question, at least I hope so.
I have imported a table with thousands of single linestrings that represent the main roads of a country.
I'd like to buffer every single one of them and intersect the results with another polygon (Basically just a circle, but the thing is, that the position of the circle is dynamic, depending on the preferences of the user).
However, I don't know how to buffer all linestrings at once. It works just fine when I buffer and intersect just one linestring, but it's kinda crucial that I buffer all of them.
And importing the roads as a multilinestring with SPIT doesn't work at all.
So ... how do I make that happen? Any hints?
I'd really appreciate any help.
The best approach would be to simply add another column that represents the buffers of the roads and add a spatial index, ie,
alter table roads add column road_buffer geometry(POLYGON, SRID);
update table roads set road_buffer = st_buffer(roads, distance);
create index ix_spatial_road_buffer on roads using gist(road_buffer);
where POLYGON and SRID indicate the type and spatial reference ID of the column. You can omit this, although it is good practice to use a specific type and SRID. YOU could also use AddGeometryColumn for the same end.
You can now run a query against the buffered roads, which will be fast, as it is indexed, but return the actual roads, eg,
Select road_id, road from roads where st_intersects(road_buffer, circle);
Now, if you wanted to do it the other way, without actually having a pre-buffered linestring, you could do somthing like,
select road_id, road, road_buffer from
(select st_buffer(road, dist) as road_buffer, road, road_id
from roads where
st_intersects(st_expand(st_envelope(road), dist), circle)
) road_buff
where st_intersects(road_buffer, circle);
The trick here is that you compute the buffer in a subquery, but only for those linestrings/roads whose envelope (ie, minimum bounding rectangle) intersects with your circle -- a much faster calculation than buffering all linestrings. Note, also, the use of st_expand, by the same amount as the buffer distance, which basically expands the mbr and ensures you don't miss any potential candidates. I did a quick test on half a million random lines, and this approach was much faster (10x) than simply checking for circle intersections against the buffer of all points.
Actually I came up with a solution that works just fine.
I just buffered my linestrings externally (used qgis) and reuploaded the entire thing as one big polygon.
However, I'd still like to know how it is done while maintaining the linestring structure.
Both approaches that John Barça suggested would work for me.
I am trying to call OpenStreetMap API:
http://api.openstreetmap.org/api/0.6/map?bbox=43.65,-79.38,43.66,-79.37
It returns no error, but map is empty:
Do you have any ideas why?
thanks
I think for the given request, the empty dataset delivered is actually the correct response.
The API documentation says api/0.6/map returns
All nodes that are inside a given bounding box and any relations that reference them.
All ways that reference at least one node that is inside a given bounding box, any relations that reference them [the ways], and any
nodes outside the bounding box that the ways may reference.
All relations that reference one of the nodes, ways or relations included due to the above rules. (Does not apply recursively, see
explanation below.)
As far as I can see, your bounding box selects a bit of Antarctica. What data did you expect?
I guess, in OSM, Antarctica is just a way, describing its outline (and maybe some research stations somewhere). If you now ask for an area in the middle of nowhere there, there are no data to get. This is because within your bbox there are no nodes. The way for the outline/area of Antarctica is only fetched if at least one of its nodes lies within your bounding box.
PS: If you want a piece of Toronto (with lots of data), swap longitude and latitude values :)
https://wiki.openstreetmap.org/wiki/Download#Construct_a_URL_for_the_HTTP_API
it says the bounding box can only be 0.5 by 0.5 degrees. it also says you might want to try XAPI for such a large area