Context

This is a supplementary dataset to the Data Science for Good: Kiva Crowdfunding challenge. In the Kiva challenge, the kiva_loans.csv file contains a large record of loans with the borrower's locations. This dataset provides the latitude and longitude of these locations.

The original dataset also includes another file loan_themes_by_region.csv, which provides some additional information on geographical locations of the loan themes offered. However, there are significantly more borrower locations than loan theme locations, and these two locations are not always the same. This dataset tries to solve this problem by directly obtaining the geocode of all borrower locations via Google Maps Geocoding API.

Content

There are four columns in the CSV. "Region" and "country" match the corresponding fields in kiva_loans.csv. "Latitude" and "longitude" are self-explanatory. Queries without valid results from the Google Maps API are indicated by latitude=-999, longitude=-999.

The geocodes are not manually validated and should be used with caution. Bad query results may happen due to mistakes in the original dataset or Google Maps' autocorrection.

Acknowledgements

The building of this dataset uses the following API: https://developers.google.com/maps/documentation/geocoding/intro

Inspiration

This dataset can help participants in the Kiva challenge by allowing them to compare location proximity and visualise data on a world/regional map when analysing Kiva's loans. The original purpose of the dataset is for me to visualise loan type clustering results on a world map and find similarities in borrower needs between remote, disjoint regions, however I hope the community will find better, more creative uses for this tiny dataset.

Geoscape G-NAF is the geocoded address database for Australian businesses and governments. It’s the trusted source of geocoded address data for Australia with over 50 million contributed addresses distilled into 15.4 million G-NAF addresses. It is built and maintained by Geoscape Australia using independently examined and validated government data.

From 22 August 2022, Geoscape Australia is making G-NAF available in an additional simplified table format. G-NAF Core makes accessing geocoded addresses easier by utilising less technical effort.

G-NAF Core will be updated on a quarterly basis along with G-NAF.

Further information about contributors to G-NAF is available here.

With more than 15 million Australian physical address record, G-NAF is one of the most ubiquitous and powerful spatial datasets. The records include geocodes, which are latitude and longitude map coordinates. G-NAF does not contain personal information or details relating to individuals.

Updated versions of G-NAF are published on a quarterly basis. Previous versions are available here

Users have the option to download datasets with feature coordinates referencing either GDA94 or GDA2020 datums.

Changes in the November 2025 release

• Nationally, the November 2025 update of G-NAF shows an increase of 32,773 addresses overall (0.21%). The total number of addresses in G-NAF now stands at 15,827,416 of which 14,983,358 or 94.67% are principal.

• There is one new locality for the November 2025 Release of G-NAF, the locality of Southwark in South Australia.

• Geoscape has moved product descriptions, guides and reports online to https://docs.geoscape.com.au.

Further information on G-NAF, including FAQs on the data, is available here or through Geoscape Australia’s network of partners. They provide a range of commercial products based on G-NAF, including software solutions, consultancy and support.

Additional information: On 1 October 2020, PSMA Australia Limited began trading as Geoscape Australia.

License Information

Use of the G-NAF downloaded from data.gov.au is subject to the End User Licence Agreement (EULA)

The EULA terms are based on the Creative Commons Attribution 4.0 International license (CC BY 4.0). However, an important restriction relating to the use of the open G-NAF for the sending of mail has been added.

The open G-NAF data must not be used for the generation of an address or the compilation of an address for the sending of mail unless the user has verified that each address to be used for the sending of mail is capable of receiving mail by reference to a secondary source of information. Further information on this use restriction is available here.

End users must only use the data in ways that are consistent with the Australian Privacy Principles issued under the Privacy Act 1988 (Cth).

Users must also note the following attribution requirements:

Preferred attribution for the Licensed Material:

_G-NAF © Geoscape Australia licensed by the Commonwealth of Australia under the _Open Geo-coded National Address File (G-NAF) End User Licence Agreement.

Preferred attribution for Adapted Material:

Incorporates or developed using G-NAF © Geoscape Australia licensed by the Commonwealth of Australia under the Open Geo-coded National Address File (G-NAF) End User Licence Agreement.

What to Expect When You Download G-NAF

G-NAF is a complex and large dataset (approximately 5GB unpacked), consisting of multiple tables that will need to be joined prior to use. The dataset is primarily designed for application developers and large-scale spatial integration. Users are advised to read the technical documentation, including product change notices and the individual product descriptions before downloading and using the product. A quick reference guide on unpacking the G-NAF is also available.

Right of Way Scan. Right of Way Distribution Maps, created as part of the DC Geographic Information System (DC GIS) for the D.C. Office of the Chief Technology Officer (OCTO) and participating D.C. government agencies. Scans provided by DDOT identified rights of way locations which were best fit to road planimetrics.

Licensed Cannabis Store Locations in Canada (Geocoded)

This dataset provides a comprehensive list of all publicly licensed and operating retail cannabis store locations across Canada. It aims to offer a single, unified source for analyzing the evolving landscape of cannabis retail, supporting research in geographic analysis, market penetration, and regulatory studies. Each entry includes essential retail details like Store Name, City, Province, Full Address, Postal Code, and, critically, geocoded Latitude and Longitude coordinates for immediate mapping and spatial analysis.

Data Collection and Provenance

The data was systematically compiled from official public listings provided by provincial and territorial regulatory bodies, which are primarily accessible through the Health Canada portal:

Primary Source Portal: https://www.canada.ca/en/health-canada/services/drugs-medication/cannabis/laws-regulations/provinces-territories.html

The compilation methodology varied based on the structure of the provincial data releases:

-> Structured Sources (e.g., Alberta, Ontario, Saskatchewan): Data for these provinces were available in a structured, easily consumable format (e.g., downloadable files or APIs). They were merged directly into the master dataset.

-> Manual Sourcing: For provinces and territories where official data was only available as lists on government websites, the information was manually copied and structured to ensure completeness across the dataset.

Methodology and Data Enhancement

The raw source data often lacks precise geographic coordinates, limiting spatial analysis. Therefore, a critical step in creating this dataset was geocoding:

-> Coordinate Addition: Using the available Postal Code and Full Address fields, geographical coordinates (Latitude and Longitude) were obtained for each store location.

-> API Utilization: The geocoding process was conducted using the Google Geocoding API to ensure high accuracy and map-friendly visual presentation. Locations that lacked a complete postal code were prioritized using the full address for the best possible coordinate match.

This enhancement makes the dataset immediately usable for mapping projects, GIS analysis, and geospatial research.- -

SECTIC-24K is a digital file of the Public Land Survey (PLS) section corners of Minnesota as recorded on the U.S. Geological Survey's 1:24,000 7.5-minute quadrangle maps (map dates ranging from the late 1940s - 1970s). The database attempts to best fit the section corner locations shown on the published 1:24,000 maps, even though better real-world data for the location of the section corner might be available elsewhere. The SECTIC-24K data set also includes a program which has the following utilities:

Utility A: Section corner extraction from the SECTIC-24K database by county, 1:24,000-scale quad, or township.
Utility B: Conversion among PLS, UTM, or LAT/LONG coordinates, either interactively or by file conversion. It also allows NAD27 - NAD83 conversions.
Utility C: Creation of a dBASE output file from SECTIC-24K.

This program does not run on Windows 7 - 64 bit computers (it does run on Windows - 32 bit). There is also a web service that generates much the same info as the SECTIC program. The main differences are it may not do NAD27/NAD83 shifts and it does not have a batch mode. A batch mode could be created using the web service and the scripting code of your choice. Find the web service at: https://gisdata.mn.gov/dataset/loc-pls-api-service

The Address Points dataset shows Utah address points for all twenty-nine Utah counties. An address point represents a geographic location that has been assigned a US Postal Service (USPS) address by the local address authority (i.e., county or municipality) but does not necessarily receive mail. Address points may include several pieces of information about the structure or location that’s being mapped, such as:the full address (i.e., the USPS mailing address, if the address is for a physical location [rather than a PO box]);the landmark name; whether the location is a building;the type of unit;the city and ZIP code; unique code identifiers of the specific geographic location, including the Federal Information Processing Standard Publication (FIPS) county code and the US National Grid (USNG) spatial address;the address source; andthe date that the address point was loaded into the map layer.This dataset is mapping grade; it is a framework layer that receives regular updates. As with all our datasets, the Utah Geospatial Resource Center (UGRC) works to ensure the quality and accuracy of our data to the best of our abilities. Maintaining the dataset is now an ongoing effort between UGRC, counties, and municipalities. Specifically, UGRC works with each county or municipality’s Master Address List (MAL) authority to continually improve the address point data. Counties have been placed on an update schedule depending on the rate of new development and change within them. Populous counties, such as Weber, Davis, Salt Lake, Utah, and Washington, are more complete and are updated monthly, while rural or less populous counties may be updated quarterly or every six months.The information in the Address Points dataset was originally compiled by Utah counties and municipalities and was aggregated by UGRC for the MAL grant initiative in 2012. The purpose of this initiative was to make sure that all state entities were using the same verified, accurate county and municipal address information. Since 2012, more data has been added to the Address Points GIS data and is used for geocoding, 911 response, and analysis and planning purposes. The Address Point data is also used as reference data for the api.mapserv.utah.gov geocoding endpoint, and you can find the address points in many web mapping applications. This dataset is updated monthly and can also be found at: https://gis.utah.gov/data/location/address-data/.

This dataset, produced by Impact Observatory, Microsoft, and Esri, displays a global map of land use and land cover (LULC) derived from ESA Sentinel-2 imagery at 10 meter resolution for the years 2017 - 2023. Each map is a composite of LULC predictions for 9 classes throughout the year in order to generate a representative snapshot of each year. This dataset was generated by Impact Observatory, which used billions of human-labeled pixels (curated by the National Geographic Society) to train a deep learning model for land classification. Each global map was produced by applying this model to the Sentinel-2 annual scene collections from the Mircosoft Planetary Computer. Each of the maps has an assessed average accuracy of over 75%. These maps have been improved from Impact Observatory’s previous release and provide a relative reduction in the amount of anomalous change between classes, particularly between “Bare” and any of the vegetative classes “Trees,” “Crops,” “Flooded Vegetation,” and “Rangeland”. This updated time series of annual global maps is also re-aligned to match the ESA UTM tiling grid for Sentinel-2 imagery. Data can be accessed directly from the Registry of Open Data on AWS, from the STAC 1.0.0 endpoint, or from the IO Store for a specific Area of Interest (AOI).

Context

Realising which routes a taxi takes while going from one location to another gives us deep insights into why some trips take longer than others. Also, most taxis rely on navigation from Google Maps, which reinforces the use case of this dataset. On a deeper look, we can begin to analyse patches of slow traffic and number of steps during the trip (explained below).

http://www.thethinkingstick.com/images/2015/03/vpq.gif" alt="enter image description here">

Content

The data, as we see it contains the following columns :

• trip_id, pickup_latitude, pickup_longitude (and equivalents with dropoff) are picked up from the original dataset.
• distance : Estimates the distance between the start and the end latitude, in miles.
• start_address and end_address are directly picked up from the Google Maps API
• params : Details set of parameters, flattened out into a single line. (Explained below)

Parameters

The parameters field is a long string of a flattened out JSON object. At its very basic, the field has space separated steps. The syntax is as follows :

Step1:{ ... }, Step2:{ ...

Each step denotes the presence of an intermediate point.

Inside the curly braces of each of the steps we have the distance for that step measured in ft, and the start and end location. The start and end location are surrounded by round braces and are in the following format :

Step1:{distance=X ft/mi start_location=(latitude, longitude) end_location ...}, ...

One can split the internal params over space to get all the required values.

Acknowledgements

All the credit for the data goes to the Google Maps API, though limited to 2000 queries per day. I believe that even that limited amount would help us gain great insights.

Future prospects

• More data : Since the number of rows processed are just 2000, with a good response we might be able to get more. If you feel like contributing, please have a look at the script here and try and run in for the next 2000 rows.

• Driver instructions : I did not include the driver instruction column in the data from the google API as it seemed to complex to use in any kind of models. If that is not the general opinion, I can add it here.

These are map products depicting modeled treeline dynamics. The left panel indicates modeled treeline dynamics from a single 2014 baseline year to the year 2100. The right panel indicates basal area accumulation on a 1km x 1km pixel basis during the year 2100, which gives an indication where possible further treeline advance may occur beyond 2100.

The source datasets used to create these maps can be found here: https://catalog.snap.uaf.edu/geonetwork/srv/eng/catalog.search#/metadata/53b35453-7b88-4ea7-8321-5447f8926c48

ALFRESCO is a landscape scale fire and vegetation dynamics model. These specific outputs are from the Integrated Ecosystem Model (IEM) project, and are from the linear coupled version using AR4/CMIP3 and AR5/CMIP5 climate inputs (IEM Generation 1a).

These outputs include data from model rep 171(AR4/CMIP3) and rep 26(AR5/CMIP5), referred to as the “best rep” out of 200 replicates. The best rep was chosen through comparing ALFRESCO’s historical fire outputs to observed historical fire patterns. Single rep analysis is not recommended as a best practice, but can be used to visualize possible changes.

The IEM Generation 1 is driven by outputs from 4 climate models, and two emission scenarios: AR4/CMIP3 SRES A1B CCCMA-CGCMS-3.1 MPI-ECHAM5

AR5/CMIP5 RCP 8.5 MRI-CGCM3 NCAR-CCSM4

Geoparsing with Large Language Models

The .zip file included in this repository contains all the code and data required to reproduce the results from our paper. Note, however, that in order to run the OpenAI models, users will required an OpenAI API key and sufficient API credits.

Data

The data used for the paper are in the datasetst and results folders.

**Datasets: **This contains the XML files (LGL and Geovirus) and Json files (News2024) used to benchmark the models. It also contains all the data used to fine-tune the gpt-3.5 model, the prompt templates sent to the LLMs, and other data used for mapping and data creation.

**Results: **This contains the results for the models on the three datastes. The folder is separated by dataset, with a single .csv file giving the results for each model on each dataset separately. The .csv file is structured so that each row contains either a predicted toponym and an associated true toponym (along with assigned spatial coordinates), if the model correctly identified a toponym; otherwise the true toponym columns are empty for false positives and the predicted columns are empty for false negatives.

Code

The code is split into two seperate folders gpt_geoparser and notebooks.

**GPT_Geoparser: **this contains the classes and methods used process the XML and JSON articles (data.py), interact with the Nominatim API for geocoding (gazetteer.py), interact with the OpenAI API (gpt_handler.py), process the outputs from the GPT models (geoparser.py) and analyse the results (analysis.py).

Notebooks: This series of notebooks can be used to reproduce the results given in the paper. The file names a reasonably descriptive of what they do within the context of the paper.

Code/software

Requirements

Numpy

Pandas

Geopy

Scitkit-learn

lxml

openai

matplotlib

Contextily

Shapely

Geopandas

tqdm

huggingface_hub

Gnews

Access information

Other publicly accessible locations of the data:

The LGL and GeoVirus datasets can also be obtained here (opens in new window).

Abstract

Geoparsing- the process of associating textual data with geographic locations - is a key challenge in natural language processing. The often ambiguous and complex nature of geospatial language make geoparsing a difficult task, requiring sophisticated language modelling techniques. Recent developments in Large Language Models (LLMs) have demonstrated their impressive capability in natural language modelling, suggesting suitability to a wide range of complex linguistic tasks. In this paper, we evaluate the performance of four LLMs - GPT-3.5, GPT-4o, Llama-3.1-8b and Gemma-2-9b - in geographic information extraction by testing them on three geoparsing benchmark datasets: GeoVirus, LGL, and a novel dataset, News2024, composed of geotagged news articles published outside the models' training window. We demonstrate that, through techniques such as fine-tuning and retrieval-augmented generation, LLMs significantly outperform existing geoparsing models. The best performing models achieve a toponym extraction F1 score of 0.985 and toponym resolution accuracy within 161 km of 0.921. Additionally, we show that the spatial information encoded within the embedding space of these models may explain their strong performance in geographic information extraction. Finally, we discuss the spatial biases inherent in the models' predictions and emphasize the need for caution when applying these techniques in certain contexts.

Methods

This contains the data and codes required to reproduce the results from our paper. The LGL and GeoVirus datasets are pre-existing datasets, with references given in the manuscript. The News2024 dataset was constructed specifically for the paper.

To construct the News2024 dataset, we first created a list of 50 cities from around the world which have population greater than 1000000. We then used the GNews python package https://pypi.org/project/gnews/ (opens in new window) to find a news article for each location, published between 2024-05-01 and 2024-06-30 (inclusive). Of these articles, 47 were found to contain toponyms, with the three rejected articles referring to businesses which share a name with a city, and which did not otherwise mention any place names.

We used a semi autonmous approach to geotagging the articles. The articles were first processed using a Distil-BERT model, fine tuned for named entity recognicion. This provided a first estimate of the toponyms within the text. A human reviewer then read the articles, and accepted or rejected the machine tags, and added any tags missing from the machine tagging process. We then used OpenStreetMap to obtain geographic coordinates for the location, and to identify the toponym type (e.g. city, town, village, river etc). We also flagged if the toponym was acting as a geo-political entity, as these were reomved from the analysis process. In total, 534 toponyms were identified in the 47 news articles.

SummaryThis data set shows building permits for the Baltimore metropolitan region. The data goes back to 2000 and is updated approximately once every two months. Expanded building permit data can be found at https://www.baltometro.org/community/data-maps/building-permit-data. Description The permits include any permit that is use code 40-48 (most new residential), 60-65 (mixed use), or is greater than or equal to $50,000. Historically, BMC receives the permits from participating jurisdictions and geocodes them. In recent years, some jurisdictions have started geocoding their own permits. When this is the case, BMC incorporates the geocoded points as given, and does not include them in its own geocoding process.Expanded building permit data can be found at https://www.baltometro.org/community/data-maps/building-permit-data.Layers:BPDS_Residential_New_ConstructionBPDS_Residential_AlterationsBPDS_Non_Residential_New_ConstructionBPDS_ Non_Residential _AlterationsBPDS_Mixed_Use_New_ConstructionThere is no layer for Mixed Use alterations; alterations to Mixed Use always get classified as Residential or Non-Residential. Field Names Field Name (alias)Descriptionpermit_no (County Permit ID)Original permit ID provided by the jurisdiction issue_dt (Date Permit Was Issued)Date the permit was issuedxcoord (X Coordinate)Longitude, in NAD 1983 decimal degreesycoord (Y Coordinate)Latitude, in NAD 1983 decimal degreessite_addr (Site Address)Address of the constructionzipcode (Site Zipcode)Zipcode of the constructionoffice (Office Number)This number corresponds to a jurisdiction and is used for BMC administrative recordspmt_use (Permit Use)Permit use code. A list of the values can be found at https://gis.baltometro.org/Application/BPDS/docs/BPDS_Permit_Use_Codes.pdfpmt_type (Permit Type)Permit type code. A list of the values can be found at https://gis.baltometro.org/Application/BPDS/docs/BPDS_Permit_Use_Codes.pdfdevelopment_name (Development Name / Subdivision)Subdivision name, if providedunit_count (Number of Units)Number of units, if provided. Only found in residential recordstenure (Tenure)If provided, indicates whether building is expected to be for rent or for sale after construction is complete. 1=For Rent, 2=For Saleamount (Amount)Estimated cost of constructionpmt_cat (Permit Category)Simplified classification of the pmt_use and pmt_type fieldsdescrip (Description)Description of construction, if providedJurisdiction (Jurisdiction)Jurisdiction (a county or city) Update CycleThe data is updated approximately once every three months. User Note Over the years, building permit points were geocoded using a variety of software and reference data. The Baltimore Metropolitan Council made every effort to ensure accurate geocoding however there may be inaccuracies or inconsistencies in how the points were placed. For best results, the Baltimore Metropolitan Council recommends aggregating the building permit points to a larger geography (ex. Census tract, zip code) when analyzing the data.Data Access Instructions To download the data or access it via API, visit https://gisdata.baltometro.org/. Technical ContactFor questions or comments, contact Erin Bolton, GIS Coordinator, at ebolton@baltometro.org or 410-732-0500.

Background and purpose: Two hubs are designated to provide endovascular clot retrieval (ECR) for the State of Victoria, Australia. In an earlier study, Google Maps application programming interface (API) was used to perform modeling on the combination of hospitals optimizing for catchment in terms of current traveling time and road conditions. It is not known if these findings would remain the same if the modeling was performed with a large-scale transport demand model such as Victorian Integrated Transport Model (VITM). This model is developed by the Victorian State Government Transport has the capability to forecast travel demand into the future including future road conditions which is not possible with a Google Maps based applications. The aim of this study is to compare the travel time to potential ECR hubs using both VITM and the Google Maps API and model stability in the next 5 and 10 years.Methods: The VITM was used to generate travel time from randomly generated addresses to four existing ECR capable hubs in Melbourne city, Australia (i.e., Royal Melbourne Hospital/RMH, Monash Medical Center/MMC, Alfred Hospital/ALF, and Austin Hospital/AUS) and the optimal service boundaries given a delivering time threshold are then determined.Results: The strategic transport model and Google map methods were similar with the R2 of 0.86 (peak and off peak) and the Nash-Sutcliffe model of efficiency being 0.83 (peak) and 0.76 (off-peak travel). Futures modeling using VITM found that this proportion decreases to 82% after 5 years and 80% after 10 years. The combination of RMH and ALF provides coverage for 74% of cases, 68% by 5 years, and 66% by 10 years. The combination of RMH and AUS provides coverage for 70% of cases in the base case, 65% at 5 years, and 63% by 10 years.Discussion: The results from strategic transport model are similar to those from Google Maps. In this paper we illustrate how this method can be applied in designing and forecast stroke service model in different cities in Australia and around the world.

This dataset comprises 2 collections of maps. The facsmile collection contains all the marginalia information from the original map as well as the map itself, while the georectified collection contains just the map with an associated index for locating them. Each collection comprises approximately 101 000 monochrome images at 6-inch (1:10560) scale. Each image is supplied in .tiff format with appropriate ArcView and MapInfo world files, and shows the topography for all areas of England, Wales and Scotland as either quarter or, in some cases, full sheets. The images will cover the approximate epochs 1880's, 1900's, 1910's, 1920's and 1930's, but note that coverage is not countrywide for each epoch. The data was purchased by BGS from Sitescope, who obtained it from three sources - Royal Geographical Society, Trinity College Dublin and the Ordnance Survey. The data is for internal use by BGS staff on projects, and is available via a customised application created for the network GDI enabling users to search for and load the maps of their choice. The dataset will have many uses across all the geoscientific disciplines across which BGS operates, and should be viewed as a valuable addition to the BGS archive. There has been a considerable amount of work done during 2005, 2006 and 2007 to improve the accuracy of the OS Historic Map Collection. All maps should now be located to +- 50m or better. This is the best that can be achieved cost effectively. There are a number of reasons why the maps are inaccurate. Firstly, the original maps are paper and many are over 100 years old. They have not been stored in perfect condition. The paper has become distorted to varying degrees over time. The maps were therefore not accurate before scanning. Secondly, different generations of maps will have used different surveying methods and different spatial referencing systems. The same geographical object will not necessarily be in the same spatial location on subsequent editions. Thirdly, we are discussing maps, not plans. There will be cartographic generalisations which will affect the spatial representation and location of geographic objects. Finally, the georectification was not done in BGS but by the company from whom we purchased the maps. The company no longer exists. We do not know the methodology used for georectification.

http://www.openstreetmap.org/images/osm_logo.png" alt=""/> OpenStreetMap (openstreetmap.org) is a global collaborative mapping project, which offers maps and map data released with an open license, encouraging free re-use and re-distribution. The data is created by a large community of volunteers who use a variety of simple on-the-ground surveying techniques, and wiki-syle editing tools to collaborate as they create the maps, in a process which is open to everyone. The project originated in London, and an active community of mappers and developers are based here. Mapping work in London is ongoing (and you can help!) but the coverage is already good enough for many uses.

Browse the map of London on OpenStreetMap.org

Downloads:

The whole of England updated daily:

• england.osm.bz2 ~185M - .osm formatted raw XML data (compressed)
• england.shp.zip ~156M - ESRI shapefiles

For more details of downloads available from OpenStreetMap, including downloading the whole planet, see 'planet.osm' on the wiki.

Data access APIs:

Download small areas of the map by bounding-box. For example this URL requests the data around Trafalgar Square:
http://api.openstreetmap.org/api/0.6/map?bbox=-0.13062,51.5065,-0.12557,51.50969

Data filtered by "tag". For example this URL returns all elements in London tagged shop=supermarket:
http://www.informationfreeway.org/api/0.6/*[shop=supermarket][bbox=-0.48,51.30,0.21,51.70]

The .osm format

The format of the data is a raw XML represention of all the elements making up the map. OpenStreetMap is composed of interconnected "nodes" and "ways" (and sometimes "relations") each with a set of name=value pairs called "tags". These classify and describe properties of the elements, and ultimately influence how they get drawn on the map. To understand more about tags, and different ways of working with this data format refer to the following pages on the OpenStreetMap wiki.

• .osm - About the raw XML data format of OpenStreetMap
• Downloading data - More details of the API and extract download options
• Xapi - The extended api for filtering by tag
• Map Features - A list of tags, and what map features they represent
• Converting map data between formats - catalogue of tools for converting from .osm to other formats

Simple embedded maps

Rather than working with raw map data, you may prefer to embed maps from OpenStreetMap on your website with a simple bit of javascript. You can also present overlays of other data, in a manner very similar to working with google maps. In fact you can even use the google maps API to do this. See OSM on your own website for details and links to various javascript map libraries.

Help build the map!

The OpenStreetMap project aims to attract large numbers of contributors who all chip in a little bit to help build the map. Although the map editing tools take a little while to learn, they are designed to be as simple as possible, so that everyone can get involved. This project offers an exciting means of allowing local London communities to take ownership of their part of the map.

Read about how to Get Involved and see the London page for details of OpenStreetMap community events.

Context

This data is webscraped from PDGA.com. Please do not abuse their webservers. The source code here caches the html responses so you only hit their site once (per course). If you prefer to use a sql lite file it is located here.

This data is only scoped to the United States. It could easily contain other country data if there is feedback.

I acquire location data (lat/long, addresses) from some course detail pages on PDGA.com if the Google Geocode API doesn't return anything.

Acknowledgements

PDGA.com

I am not an affiliate of the PDGA. All rights and copyrights reserved by PDGA.com

Image Source

Inspiration

Popular disc golf websites like PDGA.com, Udisc, and dgcoursereview offer great services, but don't give you a dataset of courses. If you wanted to create your own maps with the geo data or add custom meta data you cannot. This data puts you in control.