Hello! I’m fairly new to OpenStreetMap and Overpass queries in general, so I hope I haven’t missed something obvious in other forum posts.
I am trying to grab a list of every node with a tag of surveillance:type=ALPR within California’s 3rd congressional district (QID of Q1002522). I’ve attempted grabbing vertices manually and defining a polygon from here to no avail. I’ve been doing most of this in Overpass Turbo, which I understand may have limitations, especially in cases like these. I would appreciate help in making a working query for this.
There’s a link in the README in the working branch to the modified Overpass Turbo pages. If you can get the congressional district into a GeoJSON polygon, you should be able to import it and use it in a (poly:"{{import}}") filter in your Overpass query.
This file contains GeoJSON, which would be suitable for the modified Overpass turbo. Note that the file represents the 3rd district approved by the Citizens Redistricting Commission. Depending on your goal, you may want a different geometry, reflecting the changes from Proposition 50 that will take effect next year.
I don’t know where in California the other tags are located.
This is a map of all the objects that have a surveillance:type=ALPR tag: Tags | OpenStreetMap Taginfo California Taginfo generates this systematically. However, the geographical choices are California, Northern California, Southern California.
You can then run a search for surveillance:type=ALPR and type:node in “Nevada County” in Overpass Turbo and continue county by county and then add all the counties together. Note however that some county names are re-used in different states and countries, so those ones may pose a problem.
Just to make sure it would work, I downloaded the Shapefile, put the pieces together to get a single closed way for CD3, and exported to GeoJSON.
In spite of what the Overpass documentation suggests, performance is just fine with an 11,000 point polygon in a (poly:...) filter. I haven’t looked at that part of the Overpass source code, but I suspect it’s converting the polygon to quadtile indexes and using the quadtile indexes for the query lookups (which would be fast), then post processing to exclude results that happen to fall outside the polygon (also fast because the result set is small).
That’s great to hear. Back in the day when I did a coverage assessment based on the 408 area code, I had to simplify the area code’s geometry down to just 72 points so the query would run on a public Overpass instance. But that area is a lot denser than either the current or future CA-3.
As it happens, I’m working on an import of area code boundaries in OHM that would make it simple to filter OSM data by area code in QLever. Your findings give me hope that something analogous would be possible in Overpass by brute-forcing a poly: filter. OHM would also be open to electoral boundaries, such as these congressional districts, but boundary conflation would not be for the faint of heart.
This worked phenomenally. Thank you for this hack, it’s exactly what I needed. Also, thank you @Minh_Nguyen, in combination with your GeoJSON advice, it worked!