If people know of OpenStreetMap (OSM), they usually think of it as just a free alternative to Google Maps. While this is not actually wrong - OSM is a collaborative project to create a free editable map of the world - it is the geodata underlying the map that is considered the primary output of the project.
Being able to access this data - and not just a rendered representation in the form of a map - makes it handy for quite a number of applications. If you know the tools at your disposal, that is.
One interesting feature is that you can use OSM data to provide your own maps. One example can be found on my Raspberry Pi 4; it has map data for Bonn and the surrounding area that is used over on https://mapintosh.de/ to provide a a map of that region. While the map looks exactly the same as the one at https://openstreetmap.de that by no means is a must - I just happen to use the same style - use the layer selector in the upper right corner select what you want to displayed. All shown on that page is hosted on my Pi. If you find that interesting please take a look at my Installing a tile server on a Raspberry Pi 4.
Please note that the Raspberry has a narrow-bandwidth connection to the Internet and uses DynDNS so frequent it gently and do not expect it to be accessible 24/7.
If you want to put a map online, one question is: What region should I show at start. Most tools allow you to specify an extent (something along the lines of minimal/maximal longitude/latitude). Say you want to display a map of places to go in Porto, the second-largest city in Portugal. You might then want have your map start with an overview of the entire city. How to find out the extent of that city (which is called a *Bounding Box* for quite obious resons)?
That turns out to be insanely simple:
There you have it: The coordinates of the bouding box of Porto are -8.691294,41.138351,-8.552009,41.185935.
The meaning of these four values are
| || ||Westernmost longitude|
| || ||Easternmost longitude|
| || ||Southernmost latitude|
| || ||Northernmost latitude|
Let us again assume, you want to display a map of places to go in Porto. You may then like to display Porto's city limits. How to do that? Now that is a bit more involved than finding the bounding box.
Curious what the above data yield? https://mapintosh.de/Porto/
What does the Porto example lack so far? Obviously the actual places to go. Let us extract a couple of datasets:
First head to https://overpass-turbo.eu. On the right you see a map, on the left you may enter database request.
node [amenity=bar] (41.138351, -8.691294, 41.185935, -8.552009); out;
For the other kinds of amenity simply replace
pub. Note that the OSM wiki describes what else you can search for.
By now, the numbers should look familiar. They are again the bounding box, in this case it limits the database request to that region. You could also limit the request to Porto itself but that requires a slightly more involved query.
At the top of the page you find Export that (among other formats) allows you to export the query result as GeoJSON.
Besides simplicity there is another reason for using different JSON files for different kinds of points of interest (POIs for short)? There actually is: It makes it easy to use different markers for different kinds of POIs. See https://mapintosh.de/Porto/. If you are interested in the page's source head to https://penpendede.hopto.org/git/OSM/Maps/src/branch/master/maps/Porto.
Please note that the git repository is also hosted on my Raspberry Pi so it may not be available 24/7. Also don't expect great bandwidth.
As pointed out earlier, the core of OpenStreetMap is a geographical database. Like any other database it provides means to query it: The Overpass API that allows you to query the database using Overpass QL, the Overpass Query Language. Under the latter link you find some quite extensive documentation of Overpass QL, to try out queries you can use overpass turbo.
Say you want to obtain the city limits of Bonn as a geometry.
rel[name=Bonn] [admin_level=6] [type=boundary] [boundary=administrative]; out geom;
For comparison go to osm.org, search for Bonn and select County Boundary Bonn, North Rhine-Westphalia, Germany (may display in your local language).
For what follows we need other data on Bonn, the result of an area query
This result cannot be shown on a map, overpass turbo should automagically switch to Data to display it.
Query stolpersteine within a rough bounding box for Bonn:
[bbox:50.6,7.0,50.8,7.2]; node["memorial:type"="stolperstein"]; out meta;
You may notice that the query returns stolpersteine outside of Bonn, so let's limit the results to the area of Bonn:
[bbox:50.6,7.0,50.8,7.2]; area[name=Bonn][admin_level=6]->.bonnarea; node(area.bonnarea)["memorial:type"="stolperstein"]; out meta;
You could do without the bounding box but it makes the query faster and reduces the strain on the overpass turbo server.
Here is how the result will look like (shrunk screenshot):
The following was a query I made for finding out which stolpersteins around Bonn had mismatching pairs of memorial:text and inscription - something that seemingly is beyond the capabilities of JOSM (for easier finding them in JOSM I enriched the result with all the attributes):
[out:json][timeout:300][bbox:50.5,6.9,50.88,7.4]; ( node["memorial"~"stolperstein"]["memorial:text"]["inscription"](if:(t["memorial:text"] != t["inscription"])); way["memorial"~"stolperstein"]["memorial:text"]["inscription"](if:t["memorial:text"] != t["inscription"]); rel["memorial"~"stolperstein"]["memorial:text"]["inscription"](if:t["memorial:text"] != t["inscription"]); ); out body; >; out skel qt;