How to download json file from openstreet map

However, for non-standardized data like amenities, traffic signals, etc. This could end up taking up a lot of resources. Opening this file you'll have the following:. The configuration for that will have the following:. In the section keys to report as OGR fields with attributes , this is where we can add fields that will appear in the feature properties as keys. Since we'll be looking for amenities in North Los Angeles, we'll need the amenity keys and values.

Additionally, we'll need the cuisine keys and values because if we look for restaurants, we'll want to know the cuisine. A word of caution, however, is needed: you shouldn't modify the original OSM driver configuration file unless you really need to. Instead, we can set up our own custom, configuration file and tell ogr2ogr to use that. You also can copy the contents of the file linked from the OSM driver's webpage and save that, too. We'll save the contents of the file into one called customOSMconfig.

In that file, the only part we'll change is under [points] in the part that says attributes. We'll modify it to look like:. These are the only attributes that we'll need for our purposes. If we needed more, or wanted to keep the original attributes, we could just append what we need and run that.

Now that the new customized configuration file has been saved, we can transform the points layer again and see what our GeoJSON will look like. Now, if we look at the file, we'd get a 5 MB file with only the feature properties we added in our configuration file:.

Running ogrinfo on our GeoJSON file will provide us with a much clearer overview of the keys it contains. There's a lot we could find out just by running SQL queries with ogrinfo. But, let's see if we can make our GeoJSON file smaller by only including names, amenities, and cuisines. We can optimize our data further using SQL by selecting only documents were amenity or cuisine have at least one value. The reason why we're doing that is that sometimes amenities that are restaurants have not had the cuisine tag added, and vice versa.

Instead of only selecting amenities and cuisines that have values, we'll just select those that have at least one value. There is a problem with this as well in that some places, take a name like Starbucks as an example, doesn't always have amenities or cuisine tags. This may cause an issue if we wanted very accurate results because we'd have to locate it by name rather than by these tags. Importing our data is now much easier to manage since we filtered it down significantly.

By making the file smaller, we won't have as much overhead when trying to index or query over data that we're not interested in. To import the data, you can either use mongoimport or you could use Studio 3T, which we recently reviewed. As it stands, in order to import the GeoJSON feature collection into MongoDB, you'd have to modify the file and keep only the features array portion with the documents.

But, why would you want to manually fiddle with your data if you don't have to? To help us out, we can use the command line JSON processor jq which will select the documents in the features array them import them to Compose for MongoDB using mongoimport.

You can download and install jq for your platform , but if you're on macOS and using Homebrew, just use brew install jq. You can edit the data to re-upload it later. You can also save the data to. But because it employs the main API, it is not intended for downloading large quantities of data. Heavy use or large numbers of requests from many users should use one of the above mentioned services instead.

The region is specified by a bounding box , which consists of a minimum and maximum latitude and longitude. Choose as small a region as will be useful to you, since larger regions will result in larger data files, longer download times, and heavier load on the server.

When you're first starting out, choose a very small region so that you can figure things out quickly with small data sets. There are several ways of finding latitude and longitude values. Since we are interested in a bounding box, perhaps the clearest way is to use the bounding box selection features of the 'export data' link.

On the homepage map pan and zoom to roughly the right area, and then click the 'export data' link on the left. This sidebar display includes the four values you need for a bounding box matching the extents of the viewport. Click 'Manually select a different area' and then drag a box to select exactly the region you want. In the URL, a bounding box is expressed as four comma-separated numbers, in this order: left, bottom, right, top min long, min lat, max long, max lat.

Latitude and longitude are expressed in decimal degrees. North latitude is positive, south latitude is negative. West longitude is negative, east longitude is positive. The method described in the previous section will give you suitable values. The API is limited to bounding boxes of about 0.

For larger areas you might try to use XAPI , for example:. Refer to the XAPI page for details of other servers available. You can just type this URL into a browser if you want, but that may not work as well as you'd hope, especially if the data is large. If you know how to use them, command-line tools like wget and curl will do a better job. If you've specified a region with a lot of data, you may have to wait a while before the HTTP response begins the server is crunching your request.

If your client times out, try setting options for a longer timeout, or choose a smaller region. Here's an example command line for wget :. From OpenStreetMap Wiki. Purge Help. Downloading data - Other languages. Other languages Translate.