Oscar (car rental): import of ~95 missing branches + ongoing maintenance (organised editing)`

Hi all,

We are Oscar (oscar.be) - a car-rental network with 95 branches across Belgium, part of the Oscar Car Rental group (also DK, NL, DE, ES, US). Before we edit anything, we want to announce our planned organised edit here, per the Organised Editing Guidelines and the Import Guidelines.

**Today:** none of our 95 Belgian branches are in OSM.

**What we plan to do:**

1. **Create the ~95 missing branches** as `amenity=car_rental` nodes, with facts from our own operational database (address, opening hours, phone, website).

2. Going forward: **keep our own POIs up to date** when facts change (including positions when a branch relocates), and mark permanently closed branches with `disused:amenity=car_rental` while removing stale contact facts — **we never delete elements**.

3. **`operator` follow-up:** every branch is run by an independent local partner company. Once our Belgian partners’ real trading names are verified, we add `operator=<the partner’s trading name>` in a separate reviewed batch

**Full tag set** (we write only these keys and never modify or remove any other tag):

```
amenity=car_rental

name=Oscar

brand=Oscar

brand:wikidata=Q140566474

branch=Aartselaar

opening_hours=Mo-Fr 08:00-18:00

phone=+32 …

ref=1234 (our branch number — matches the branchCode in our website’s schema markup)

website=https://oscar.be/…

addr:street=… / addr:housenumber=… / addr:postcode=… / addr:city=…

```

**How:**

- One human-reviewed batch, uploaded via the API (osmChange) from the dedicated account `OscarCarRental_import` (per the Import Guidelines; our main account `Oscar Car Rental` stays for manual edits and communication).

- A named employee reviews the complete tag set of every element before upload.

- **Conflation:** before creating anything we check country-wide via Overpass, and again live via the API at upload time, for existing `amenity=car_rental` elements within 150 m. An existing element **of our brand** is adopted/updated, never duplicated; other rental brands nearby are left alone. A foreign rental sitting directly at our coordinates blocks the automation - a human decides.

- **Position verification:** before the batch we verify every branch’s coordinates against a geocode of its official address and fix mismatches in our source data first — a lesson from our Dutch batch, where the community caught three imprecisely placed nodes (fixed within hours).

- **Pace:** at most **one batch per country per day**; batches are 30–150 elements.

- Every changeset carries the hashtag **#oscarcarrental** (filterable in OSMCha), `bot=yes`, `import=yes`, and a link to our declaration page: wiki link

**Track record:**

Denmark 142/142 branches listed ([thread]( Oscar Biludlejning – organiseret redigering: ~131 nye filialer + vedligeholdes )),

The Netherlands with active community review ([thread]( Oscar Autoverhuur: ons filiaalonderhoud formeel als organised editing + de laatste ~7 toevoegen ))

the US incl. operator([thread]( Oscar Car Rental: adding ~34 missing Wisconsin-area branches + ongoing maintenance (organised editing) )).

**Data & licence:** all data comes from our own first-party database; as the data owner we explicitly grant its use in OSM under ODbL.

**Timeline:** we will start no earlier than Aug 17. Feedback before then shapes the batch; feedback after is taken just as seriously. Reply here, comment on a changeset, or message the account. If the community objects, we stop immediately and revert on request

Contact: Oscar K (fitting name, I know), Oscar.

1 Like

Hi Oscar,

Thanks for taking the time to do this properly!

Some questions:

  • How exact is the geocoding of the places?
  • Assuming your locations are in places used by some other shop or something before, will you also try to remove the places that were closed (if OSM is out of date?
  • Are all your offices already open or will you add planned places too?

Looks very good except for one element. Car-rental stations are not addressable. I don’t recommend adding addr:* tags to the objects. Better let reverse-geocoding work normally.

Linking every station to a dedicated page on your website is good, but can you give some thoughts to an internal process to make sure that those constructed URL will be stable over time, or that someone will update OSM data? This will avoid 404_NOT_FOUND errors if one day you redesign your website.