We are Oscar Car Rental (driveoscar.com) a car-rental network with 38 branches, in Wisconsin, part of the Oscar Car Rental group (also DK, NL, DE, ES, BE). Before we edit anything, we want to announce our planned organised edit per the Organised Editing Guidelines and the Import Guidelines.
Today: 3 of our 38 branches are in OSM; ~34 are missing. We also know of 3 OSM listings for branches that have permanently closed.
What we plan to do:
Create the ~34 missing branches as amenity=car_rental nodes, with facts from our own operational database (address, opening hours, phone, website).
Retag the 3 closed-branch listings with the lifecycle prefix (disused:amenity=car_rental) and remove the stale contact facts. We never delete elements.
Going forward: keep our own POIs up to date when facts change.
Full tag set (we write only these keys and never modify or remove any other tag):
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 29 July 2026. 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.
Thanks for your interest in contributing your company’s locations to OSM.
Considering the size of your company, I recommend submitting your brand to the name suggestion index here:
Is the danish company the “parent” and the other countries subsidiaries?
I see that different countries have different websites, do they operate as separate companies? I created Wikidata objects for each country.
Denmark: Q127731404 (already existed)
Netherlands: Q130349057 (already existed)
Germany: Q140566458
Spain: Q140566470
Belgium: Q140566474
United States: Q140566150
An NSI object should be created for each country, so that they are documented.
The brand:wikidata should correspond to the matching Wikidata item to that country
Internationally, I would also use name:en
On the wiki, you write
Human review: every batch is prepared per country and an employee reviews the complete tag set of every element before upload. Nothing is uploaded unreviewed.
what tool/software is the employee using to review the data?
one thing I noticed while looking at a couple of your sites in Germany and the Netherlands via StreetView is that you apparently rent through local car shop or dealers, correct? Only at one in about 20 places I look at I could spot a (small) flag with your brand name. Therefore I think it would be very nice to go the extra mile and add the name of the local car shop or car dealer operating on your behalf in the operator tag - especially as you already have this data displayed on your website. This would help people using your service to know where to get their car from and not searching for a (non existing) entrance with “Oscar” branding.
Thanks all. Very useful feedback. The declaration page is updated accordingly.
@CjMalone The three existing listings: way/438196721 (Madison South), way/678060664 (Madison – Dane County Regional Airport) and way/415119534 (Menomonie).
On 41 vs 38: good catch, 38 is correct. Three recently closed branches were still in our count; the batch adds 34 new branches. I have corrected the opening post.
@SherbetS Thanks for creating the country items. I have adopted per-country brand:wikidata across all markets: DK Q127731404, NL Q130349057, DE Q140566458, ES Q140566470, BE Q140566474, US Q140566150. On the structure: the country companies are independent sister companies under the same ownership, so per-country items linked by ownership matches reality.
NSI: agreed. We’ll submit per-country entries once the Danish pilot has verified cleanly, and we’ll revisit name:en with that.
Reviewers use an internal review screen - our own software: every element’s full tag set is checked, and each batch requires explicit approval before upload.
@BjörnSc Really good point. Under our franchise model the operator is the local partner garage, and that’s how we’ll tag it. The US batch includes operator=tag from the start; other countries follow in reviewed update batches.
Quick update now that the batch has run: the final count came to 35 rather than 34. One location we had been double-checking (Eau Claire) turned out to have no existing entry after all; the nearby listing belongs to our former Altoona branch, which will be marked disused: separately. All new nodes carry operator=<the local dealer's trading name> as committed. Everything is tagged #oscarcarrental
Feedback is very welcome.
Since you requested feedback, I wanted to point out some pretty significant issues I spotted in a quick look-over:
The wiki page is very difficult to read due to the arbitrary hard line breaks constantly inserted throughout, and it also breaks the syntax (e.g. bulleted lists). Please fix that.
Your phone number format is not correct, at least for the US locations I checked (originally pointed out to me out GA_Kevin); the consensus standard for NANP phone numbers is +1-NNN-NNN-NNNN, while internationally its +1 N[N...] [N...], and in the US +1 NNN-NNN-NNNN remains somewhat common for historical reasons. Certainly not +1 (NNN) NNN-NNNN as you have it. (Although @confusedbuffalo 's bot might eventually come around and fix this, assuming it supports this case).
Not critical, but helpful: your changeset comments could use a descriptor actually describing that batch, i.e. by location (e.g. “…in Green Bay” for this one)
To confirm, the bot does support such cases, which are basically correct but not quite standard, and sure enough has fixed all of the elements in that changeset. But still best to use standard format in the first place
Thanks @CAM-Gerlach for the thorough review, and @confusedbuffalo for the bot assist. All four points are handled:
Wiki page: formatting repaired (the broken line breaks were a paste error on our side).
Phone format: our pipeline now emits +1-NNN-NNN-NNNN from the start, matching the bot’s correction, future edits won’t regress it.
Street abbreviations: the pipeline now expands them (“E Washington Ave” → “East Washington Avenue”); the 35 existing nodes get corrected in the next maintenance batch rather than one off churn.
Changeset comments: they now name the localities per changeset, visible from today’s changesets on.
Separately, the three leftover listings of our closed branches (including the former Altoona site) are now retagged disused: (changesets 186650118 / 186650124 / 186650130). Feedback continues to be welcome.
I did notice a couple followup issues in your latest changesets (e.g. changeset 186650130, your most recent from the same time as your last post as of this writing:
Make sure to add the disused:*=* prefix to the other appropriate tags that are no longer true after the disuse–in that case, brand=*, name=*, phone=* and website=*; see the wiki for more details.
@CAM-Gerlach Both points fixed - thanks for the careful review.
Lifecycle prefixes: you’re right, the retag was incomplete. All three ways now carry disused:name / disused:brand and the stale phone/website values are removed (changeset 186893127). Our pipeline now does this automatically for future closures: identity tags (name, branch, brand, brand:wikidata, operator, ref) move under disused: with the element’s existing values, and contact facts (opening_hours, phone, website) are removed. The declaration page is updated to say so.
Tracking parameters: agreed they don’t belong on OSM. For clarity: those URLs predate this project - our pipeline strips query/tracking parameters from every URL it writes, and the 35 nodes we created carry clean URLs. But the two old website values should not have survived our own retag pass, so that’s on us; they’re gone now.
