Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overpass API on relationships not working - #470

Open
HikeAndMap opened this issue Jul 7, 2023 · 2 comments
Open

Overpass API on relationships not working - #470

HikeAndMap opened this issue Jul 7, 2023 · 2 comments
Labels
bug An identified bug feedbacks The bug is unclear and feedbacks are needed

Comments

@HikeAndMap
Copy link

HikeAndMap commented Jul 7, 2023

What is the bug?

I'm not sure if it's a bug or maybe I don't understand the syntax - but - if I want to show relationships at overpass-turbo.eu and it works there flawlessly I get exactly what I expect and copy that to the QuickOSM query - then I don't get what I expect.

That's why I think it's a bug, but again, maybe I'm using the wrong syntax.

So I go to https://overpass-turbo.eu/ and there I enter the query:

[out:json][timeout:25];

{{geocodeArea:Baguio,Cordillera Administrative Region}}->.searchArea;

                                                
(
  rel[ref][!route](area.searchArea);
);


out body;
>;
out skel qt;

Shows me exactly what I expect to see (look especially for the area at "City Camp Proper") the relationships that have the "ref" key are shown.

Now I go to the QuickOSM and copy that exact piece of query-code

I get now in yellow "successful query but no result"

The weird thing is - the ways part of the relationship - I add there any tag.. literally anything.. even just something crap like blabla=abcd
et voila , now it shows that way as a result for my query of the relationships that have "ref" key.

This shouldn't be I think - if no tags are on the way/node but the way/node are part of a relationship I'm querying, the should return as a result.

Note I noiced this already months ago also on administrative boundaries.. relationships are NOT being shown if the way/node themselves which are part of the relationship have no tags at all.

And please keep in mind, the overpass-turbo.eu website does this very well, it shows relationships and their corresponding ways and nodes - even if those nodes and ways themselves are without tags.

Environment

Windows 11 - 64 bit
QGIS: 3.30.2 (but again, this is already for months even in older versions)
QuickOSM plugin version: 2.2.2

@HikeAndMap HikeAndMap added the bug An identified bug label Jul 7, 2023
@Gustry
Copy link
Member

Gustry commented Jul 10, 2023

Hi,

Shows me exactly what I expect to see (look especially for the area at "City Camp Proper") the relationships that have the "ref" key are shown.

Please share some HTTP links next time. It helps a lot to understand what you are looking for.

Are you talking about this relation for instance ? https://www.openstreetmap.org/relation/16059099
So you are referring to this tagging scheme : https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Multiple_ways_forming_a_ring ?

QuickOSM is relying on OGR for OSM data parsing : https://gdal.org/drivers/vector/osm.html

And please keep in mind, the overpass-turbo.eu website does this very well, it shows relationships and their corresponding ways and nodes - even if those nodes and ways themselves are without tags.

Yes, but there are a lot of differences between overpass turbo and GIS. There are a few warnings on some OQL queries when they are run within QGIS because of some incompatibilities. But not this particular query indeed.

@Gustry Gustry added the feedbacks The bug is unclear and feedbacks are needed label Jul 10, 2023
@HikeAndMap
Copy link
Author

Are you talking about this relation for instance ? https://www.openstreetmap.org/relation/16059099

yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An identified bug feedbacks The bug is unclear and feedbacks are needed
Projects
None yet
Development

No branches or pull requests

2 participants