Organised Editing/Activities/Digitaleo

Rationale

Digitaleo is a SaaS platform that enables businesses to manage their online presence across multiple directories (Google Business Profile, Apple Business Connect, Bing Places, OpenStreetMap, etc.). When a business owner updates their point-of-sale information on Digitaleo, the changes are automatically published to OpenStreetMap via the API. Each edit corresponds to a single user action this is not an autonomous bot.

The goal is to keep business information (name, address, opening hours, phone, payment methods...) accurate and up-to-date on OpenStreetMap, based on first-party data provided directly by the business owners themselves.

Contact

• 
   Digitaleo (on OSM) (on OSM · edits · contributions · heatmap · comments)

• Email: serviceclient@digitaleo.com
• Website: https://digitaleo.com

Community consultation

This wiki page serves as the primary documentation of the activity. Digitaleo's OSM user profile also describes the editing process and scope. Digitaleo responds to changeset comments and private messages on OSM, and is open to community feedback.

A dedicated topic on the French OSM community forum is available for discussion, feedback, and tracking changes: Digitaleo - suivi et retours.

Hashtag

Changesets are identified with the following tags:

• created_by: Digitaleo-OSM-API/1.0
• source: digitaleo
• Changeset comment: "Update business information", "Add new business location", or "Mark business location as vacant"

Edits can be tracked via OSMCha.

Timeframe

The activity started in January 2026 and is ongoing with no planned end date. Edits occur continuously as business owners update their information on the Digitaleo platform.

Data source

Who provides the data

All data published to OpenStreetMap by Digitaleo originates from first-party sources:

• Establishment owners who directly manage their own business information (e.g., a bakery owner updating their opening hours).
• Network managers (franchise or brand managers) who manage information for multiple establishments in their network (e.g., a regional manager updating addresses for 50 stores).

This data is not scraped, not imported from third-party databases, and not automatically generated. Each piece of information is entered or validated by a person who has authority over the business.

Multi-publishing context

Digitaleo is a multi-publishing platform. When a user updates their business information, the same data can be published to several platforms simultaneously:

• Google Business Profile
• Apple Business
• Bing Places
• Facebook
• OpenStreetMap
• And others

The user explicitly enables OpenStreetMap publishing for each establishment.

Fields managed

The following business fields are managed by Digitaleo users and may be published to OSM:

Category	Fields
Identity	Name, website, email, SIRET (French business registration number)
Phone	Phone number, fax number
Address	House number, street, postcode, city
Schedule	Opening hours (full weekly schedule with multiple time slots), opening date (for upcoming or temporarily closed businesses)
Primary category	Primary classification tag (amenity, shop, tourism, leisure, office, craft) — set on creation only
Food & Drink	Cuisine types, dietary options (vegetarian, vegan, halal, kosher, gluten-free), pastry, chocolate, ice cream, cake, bubble tea, juice, organic
Services	Delivery, takeaway, drive-through, indoor seating, outdoor seating, breakfast, wheelchair accessibility, Wi-Fi, reservation, booking URL
Payment	Cash, credit cards, debit cards, cheque, contactless, Visa, Mastercard, American Express, Discover, Diners Club, JCB
Social media	Facebook, Twitter/X, Instagram, LinkedIn, YouTube, TikTok, Pinterest

Tools and technical overview

Parameter	Value
Editing method	Automated publication via the OSM API, triggered by individual user actions on the platform
OSM API version	v0.6
User-Agent	Digitaleo-OSM-API/1.0
Authentication	OAuth2 Bearer token
Rate limiting	1 request per second
Changeset created_by	Digitaleo-OSM-API/1.0
Changeset source	digitaleo

Participants

• 
   Digitaleo (on OSM) — single account used for all API edits

Element lifecycle

Search and matching

Before creating a new element, Digitaleo always searches for an existing OSM element that may already represent the business. This avoids creating duplicates.

Search method:

1. A bounding box search is performed around the business coordinates (default radius ~22 meters, i.e. ~0.0002 degrees).
2. All elements with tags within the bounding box are retrieved.

Matching strategy (two stages):

Stage	Method	Details
Fuzzy name matching	Token-based comparison	The business name and OSM element names (name, official_name, brand, alt_name, short_name, old_name, operator) are tokenized. French stop words are removed (de, du, la, le, les, etc.). Accents are normalized. A minimum 60% token overlap ratio is required. Minimum token length: 3 characters.
Exact tag matching	Direct value comparison	Compares phone/contact:phone, email/contact:email, website, ref:FR:SIRET. Phone numbers are normalized (digits only, French +33 prefix replaced by 0). URLs are normalized (lowercase, protocol and www. stripped, trailing slash removed). SIRET numbers have whitespace removed.

Decision rules:

• If at least one exact tag match is found, all name-only matches are discarded (higher confidence).
• If multiple elements match ambiguously, no edit is made and the system flags the business for manual review.

Element creation

Element creation occurs only when:

1. No existing OSM element was found by the search algorithm, AND
2. The user has explicitly authorized the creation (automatic creation is blocked by default).

When creation is authorized:

• A new node is created at the business coordinates.
• A changeset is opened with comment: "Add new business location"

Example changeset and node creation:

<!-- 1. Open changeset -->
<osm>
  <changeset>
    <tag k="created_by" v="Digitaleo-OSM-API/1.0"/>
    <tag k="source" v="digitaleo"/>
    <tag k="comment" v="Add new business location"/>
  </changeset>
</osm>

<!-- 2. Create node in changeset -->
<osm>
  <node changeset="12345" lat="48.8566" lon="2.3522">
    <tag k="name" v="Boulangerie Martin"/>
    <tag k="shop" v="bakery"/>
    <tag k="phone" v="+33 1 42 36 12 34"/>
    <tag k="email" v="contact@boulangerie-martin.fr"/>
    <tag k="website" v="https://boulangerie-martin.fr"/>
    <tag k="ref:FR:SIRET" v="12345678901234"/>
    <tag k="contact:housenumber" v="12"/>
    <tag k="contact:street" v="Rue de Rivoli"/>
    <tag k="contact:postcode" v="75001"/>
    <tag k="contact:city" v="Paris"/>
    <tag k="opening_hours" v="Mo-Sa 07:00-20:00"/>
    <tag k="cuisine" v="sandwich"/>
    <tag k="pastry" v="yes"/>
    <tag k="payment:credit_cards" v="yes"/>
    <tag k="payment:contactless" v="yes"/>
    <tag k="delivery" v="yes"/>
    <tag k="contact:facebook" v="https://www.facebook.com/boulangeriemartin"/>
  </node>
</osm>

Element update

When an existing element is found (either by search or because the business was previously linked to an OSM element):

1. The current element is fetched from OSM (supports node, way, relation).
2. Tags are merged: Digitaleo's tags are applied on top of the existing tags. All tags that Digitaleo does not manage are preserved unchanged.
3. Before sending, the merged tags are compared with the current tags. If they are identical, no changeset is created (avoids unnecessary edits).
4. A changeset is opened with comment: "Update business information"
5. The element's version number is used for optimistic concurrency control. If another edit was made concurrently, the OSM API returns HTTP 409 (Conflict) and the operation is retried.
6. For way and relation elements: geometry is fully preserved. Only tags are replaced in the XML, all nodes/members/references remain untouched.

Example: updating a phone number

Before (current OSM element tags):

name=Boulangerie Martin
phone=+33 1 42 36 12 34
amenity=bakery
opening_hours=Mo-Sa 07:00-20:00
wheelchair=yes

Digitaleo sends these tags (phone changed, other fields same):

phone=+33 1 42 36 99 99
email=contact@boulangerie-martin.fr
contact:street=Rue de Rivoli
opening_hours=Mo-Sa 07:00-20:00

Result after merge (sent to OSM):

name=Boulangerie Martin           -- preserved (already existed on OSM)
phone=+33 1 42 36 99 99           -- updated by Digitaleo
email=contact@boulangerie-martin.fr   -- added by Digitaleo
amenity=bakery                     -- preserved (not managed by Digitaleo)
opening_hours=Mo-Sa 07:00-20:00    -- unchanged
wheelchair=yes                     -- preserved (not managed by Digitaleo)
contact:street=Rue de Rivoli       -- added by Digitaleo

Important: Tags like amenity, shop, building, wheelchair that were added by other contributors are never removed or modified by Digitaleo.

Name handling

The name tag receives special treatment:

• On creation: The name is set from the business data.
• On update of an existing element: If the element already has a name tag, Digitaleo does not overwrite it. The existing OSM name is preserved.
• Exception: If a name incoherence was previously detected (the OSM name does not match the expected business name) and the user explicitly republishes, the name will be overwritten.

The name is resolved with this priority:

1. Platform-specific name configured for OpenStreetMap (if the user set a different name for OSM)
2. Network brand name
3. Business name

Synchronization monitoring

A background process periodically checks whether the data on OSM still matches what Digitaleo expects:

• Frequency: Every 2 hours (checks businesses whose last refresh exceeds the threshold).
• Process: Builds the expected tag set from local data, compares it with the current OSM element using the same merge and sanitization logic as updates, and checks if the result differs.

Behavior on desynchronization:

• If tags differ: the business is flagged as "out of sync" internally. Digitaleo does NOT automatically overwrite external changes. The user must explicitly choose to republish.
• If tags match and the business was previously flagged: the flag is automatically cleared (self-healing).
• Name coherence is also checked: if the OSM name no longer matches the expected name, the business is flagged for review.

This means: If an OSM contributor corrects a tag on an element managed by Digitaleo, that correction will be detected but not automatically reverted. The business owner or network manager will be notified that their data is out of sync and must decide whether to accept the OSM change or republish their version.

Tag deletion

Specific tags can be removed from an element while preserving all other tags. The element is fetched, the specified tags are removed from the tag set, and the element is updated with the remaining tags. Geometry and unrelated tags are not affected.

Element vacating (marking as disused)

When a business takes over a location that was previously occupied by another business, the existing OSM element may still carry the previous owner's information. To clean the element before republishing the new business's data, Digitaleo can vacate the element — marking it as disused and removing all business-specific tags.

This is typically used when remapping a point of sale to an existing OSM element that still holds stale data from a previous occupant.

Vacating process:

1. The current element is fetched from OSM.
2. Primary classification tags (amenity, shop, tourism, leisure, office, craft) are moved to the disused: prefix (e.g., shop=bakery becomes disused:shop=bakery). This follows the OSM lifecycle prefix convention.
3. All business-managed tags are removed: identity (name, brand, operator), contact (phone, email, fax), web (website, URL), social media, opening hours, opening date, cuisine, diet tags, services (delivery, takeaway, wheelchair, Wi-Fi, etc.), payment methods, and other business-specific tags (SIRET, pastry, ice cream, organic, second hand, repair).
4. Address tags (addr:* and contact:* address tags like housenumber, street, postcode, city) are preserved — the physical location does not change when a business closes.
5. Unmanaged tags (building, source, note, level, etc.) are preserved.
6. If the resulting tags are identical to the current tags (element is already vacated), no changeset is created.
7. A changeset is opened with comment: "Mark business location as vacant"

Example:

Before (current OSM element):

shop=bakery
name=Boulangerie Martin
phone=+33 1 42 36 12 34
website=https://boulangerie-martin.fr
opening_hours=Mo-Sa 07:00-20:00
payment:cash=yes
payment:credit_cards=yes
cuisine=sandwich
pastry=yes
addr:street=Rue de Rivoli
addr:housenumber=12
addr:postcode=75001
addr:city=Paris
building=yes
source=cadastre

After vacating:

disused:shop=bakery
addr:street=Rue de Rivoli
addr:housenumber=12
addr:postcode=75001
addr:city=Paris
building=yes
source=cadastre

After vacating, the new business's data can be published to the same element via the standard update process, which will set the new primary tag and business information.

Automatic cleanup on republish:

When a new business is published to a previously vacated element, any disused:* tags for primary classification keys (disused:amenity, disused:shop, disused:tourism, disused:leisure, disused:office, disused:craft) are automatically removed during the update. This prevents stale lifecycle tags from coexisting with the new business's primary tag (e.g., disused:shop=bakery would be removed when the new business sets shop=florist). Non-primary disused:* tags (e.g., disused:railway) are not affected.

Complete tag mapping

Basic information

Digitaleo Field	OSM Tag	Format / Notes
Business name	name	See Name handling for conditions
Website	website	URL forced to https://, validated format, query string and fragment stripped. Social media URLs are reclassified (see Tag sanitization).
Contact email	email	As entered by the user
SIRET	ref:FR:SIRET	14-digit French business registration number (ref:FR:SIRET)

Phone numbers

Digitaleo Field	OSM Tag	Format
Phone	phone	International format via libphonenumber (e.g., +33 1 42 36 12 34)
Fax	fax	Same formatting as phone

Address

French addresses are parsed to extract the house number from the street name.

Digitaleo Field	OSM Tag	Notes
Address (number part)	contact:housenumber	Extracted from the address string. Supports French ordinals: bis, ter, quater, and letter suffixes (e.g., 12B).
Address (street part)	contact:street	Remainder after house number extraction. Normalized (see Street name normalization).
Postal code	contact:postcode	As entered
City	contact:city	Normalized: all-uppercase names are converted to Title Case (e.g., LYON becomes Lyon)

Note: Digitaleo publishes address tags using the contact:* form by default. See Address conflict resolution for how existing addr:* elements are handled.

Address parsing examples:

Input Address	contact:housenumber	contact:street
35 cours Fauriel	35	Cours Fauriel
12B rue de la Paix	12B	Rue de la Paix
12 bis avenue Victor Hugo	12 bis	Avenue Victor Hugo
rue de la Paix	(none)	Rue de la Paix

Special location handling

When a business is located inside a named place (shopping center, industrial zone, etc.), the address fields often contain the place name rather than a street address. The system detects these cases to avoid publishing incorrect contact:street values.

Detected place name prefixes:

Centre Commercial, CCial, C.Cial, CTRE Cial, CC, C/C, Zone Industrielle, Zone Artisanale, Zone Commerciale, Zone d'Activité, Galerie, Galerie Marchande, Parc d'Activité, Parc Commercial, Espace Commercial, Résidence

Addresses starting with a house number (e.g., 14 Zone Artisanale Pen Mané) are not flagged as place names — the number is extracted normally by the address parser.

Routing logic:

The system examines both the primary address field and the secondary address field (Address2) to determine which one contains the actual street address:

Address	Address2	contact:housenumber / contact:street	level
Place name only (e.g., CENTRE COMMERCIAL CARREFOUR)	(empty)	(not published)	Extracted if present
Place name (e.g., Centre Commercial Westfield (2ème étage))	Street (e.g., 17 rue du Docteur Bouchut)	Parsed from Address2: 17 / Rue du Docteur Bouchut	2
Street (e.g., 30 avenue Jean Médecin)	Place name (e.g., Centre Commercial Nice Étoile - niveau 1)	Parsed from Address: 30 / Avenue Jean Médecin	1
Normal address	(any)	Parsed from Address (default behavior)	Extracted if present

When no real street address can be identified (place name in Address, Address2 empty or also a place name), contact:housenumber and contact:street are omitted entirely rather than publishing the place name as a street.

Floor / level extraction

The system extracts floor information from either address field and publishes it as the level tag.

Recognized patterns:

Input Pattern	level Value
2ème étage, 1er étage, 3e étage	2, 1, 3
étage 2, niveau 1, Niv. 3	2, 1, 3
RDC, rez-de-chaussée	0

Opening hours

Business schedules are converted to the OSM opening_hours format.

Weekly rules:

• Days are mapped: Monday→Mo, Tuesday→Tu, Wednesday→We, Thursday→Th, Friday→Fr, Saturday→Sa, Sunday→Su
• Consecutive days with identical hours are grouped into ranges (e.g., Mo-Fr 09:00-18:00)
• Multiple time slots per day are comma-separated (e.g., Mo 09:00-12:00,14:00-18:00)
• Different day groups are semicolon-separated (e.g., Mo-Fr 09:00-18:00; Sa 10:00-13:00)
• End time 23:59 is converted to 24:00
• Overnight slots are merged: if a business is open until midnight and the next day starts at 00:00, the slots are combined (e.g., Fr 18:00-02:00 instead of Fr 18:00-24:00; Sa 00:00-02:00)

Dated rules (exceptional openings / closures):

Businesses can declare one-off openings or closures tied to a precise date range (public holidays, summer schedule, end-of-year closure). These are emitted as year-prefixed rules appended to the weekly rule, following the wiki spec:

• Single-day closure: YYYY MMM D off — e.g., 2026 Dec 25 off
• Same-month date range closure: YYYY MMM D-D off — e.g., 2026 Aug 1-15 off
• Multi-month / multi-year range closure: YYYY MMM D-MMM D off or YYYY MMM D-YYYY MMM D off — e.g., 2026 Dec 24-2027 Jan 2 off
• Special opening hours on a date: YYYY MMM D HH:MM-HH:MM[,HH:MM-HH:MM] — e.g., 2026 Dec 31 09:00-16:00

Months are always 3-letter English abbreviations (Jan, Feb, …, Dec), never localised. Rules are chained with ;; the spec specifies that later rules take precedence over earlier ones for overlapping time spans.

An exception is treated as a closure when its time-slot list is empty or a single zero-duration slot (00:00-00:00); otherwise it's a special-hours opening.

Dated rules whose end date is before today are not emitted — past exceptions carry no useful information in opening_hours.

Dated rules are sorted chronologically by start date in the emitted tag, so the tag reads as a natural timeline.

Grouping of single-day exceptions:

Single-day exceptions (startDate = endDate) that share the same year, month, and hours are grouped under a single rule using the comma-separated monthday_selector form, where each date is fully qualified (year + month + day) per the strict opening_hours specification:

• Two single-day closures in May 2026 with the same hours:

   * emitted as — 2026 May 1,2026 May 8 off
   * not as — 2026 May 1 off; 2026 May 8 off (longer, equivalent) or 2026 May 1,8 off (non-standard shorthand, parser-dependent)

• Mixed same-month and different-months:

   * Input: 2026-05-01 and 2026-05-08 (both 00:00-24:00), 2026-07-14 (00:00-24:00), 2026-11-01 and 2026-11-11 (both 00:00-24:00)
   * emitted as — 2026 May 1,2026 May 8 00:00-24:00; 2026 Jul 14 00:00-24:00; 2026 Nov 1,2026 Nov 11 00:00-24:00

Rules with different hours, different months, or multi-day ranges are not grouped and each produces its own rule.

255-character OSM tag limit:

OSM enforces a hard limit of 255 characters on the value of any tag (the v attribute). When the combination of weekly rules, dated exceptions, and preserved contributor rules (e.g., PH) would exceed this limit, Digitaleo drops dated rules from the furthest future backwards until the tag fits. Weekly rules and preserved contributor rules are never sacrificed; they describe the ongoing rhythm of the business and must remain intact.

This truncation is silent: there is no on-tag indication that exceptions were dropped. If you observe a business whose dated exceptions seem incomplete on OSM, it is likely hitting this ceiling — the source data on Digitaleo's side still carries them, but the opening_hours tag cannot physically store the full set.

Examples:

A restaurant open Monday-Friday 11:30-14:00 and 18:30-22:30, Saturday 18:30-23:00:

opening_hours=Mo-Fr 11:30-14:00,18:30-22:30; Sa 18:30-23:00

Same restaurant, closed on Christmas 2026 and with reduced hours during the summer holidays:

opening_hours=Mo-Fr 11:30-14:00,18:30-22:30; Sa 18:30-23:00; 2026 Dec 25 off; 2026 Jul 15-30 18:30-22:30

Opening date

When a business has a future opening or reopening date, the opening_date tag is published.

Business Status	Condition	OSM Tag	Value
Temporarily closed	Reopen date is set and in the future	opening_date	YYYY-MM-DD (the expected reopening date)
Open	Opening date is set and in the future	opening_date	YYYY-MM-DD (the planned opening date)
Open	Opening date is in the past or not set	(none)	Tag is not published
Temporarily closed	No reopen date set	(none)	Tag is not published
Permanently closed	(any)	(none)	Business is unpublished from OSM

Notes:

• Past dates are never published — only future dates are set as opening_date.
• Permanently closed businesses are handled upstream (unpublished from OSM entirely), so no closing-related tag is set.

Categories and cuisine

Business categories are mapped to secondary OSM tags. Multiple values are joined with semicolons.

Cuisine tags

Business Category	cuisine=* Value
sandwich_shop	sandwich
pizza_restaurant	pizza
sushi_restaurant	sushi
burger_restaurant	burger
kebab_shop	kebab
chinese_restaurant	chinese
japanese_restaurant	japanese
italian_restaurant	italian
french_restaurant	french
mexican_restaurant	mexican
indian_restaurant	indian
thai_restaurant	thai
vietnamese_restaurant	vietnamese
lebanese_restaurant	lebanese
turkish_restaurant	turkish
korean_restaurant	korean
seafood_restaurant	seafood
steak_house	steak_house
crepe_restaurant	crepe
coffee_shop	coffee_shop
cafe	coffee_shop
coffee_stand	coffee_shop
espresso_bar	coffee_shop
tea_house	tea
bubble_tea_store	bubble_tea
donut_shop	donut
cake_shop	cake
chocolate_cafe	chocolate
juice_shop	juice
ramen_restaurant	ramen
fish_and_chips_restaurant	fish_and_chips
falafel_restaurant	falafel
greek_restaurant	greek
spanish_restaurant	spanish
portuguese_restaurant	portuguese
moroccan_restaurant	moroccan
african_restaurant	african
caribbean_restaurant	caribbean
peruvian_restaurant	peruvian
brazilian_restaurant	brazilian
argentinian_restaurant	argentinian

A business with categories "pizza_restaurant" and "italian_restaurant" would produce: cuisine=pizza;italian

Note: Several categories map to the same cuisine value: cafe, coffee_stand, and espresso_bar all map to coffee_shop. Duplicates are removed automatically.

Diet tags

Business Category	OSM Tag	Value
vegetarian_restaurant	diet:vegetarian	only
vegan_restaurant	diet:vegan	only
halal_restaurant	diet:halal	yes
kosher_restaurant	diet:kosher	yes
gluten_free_restaurant	diet:gluten_free	yes

Boolean category tags

Business Category	OSM Tag	Value
pastry_shop	pastry	yes
ice_cream_shop	ice_cream	yes
organic_shop	organic	yes
second_hand_store	second_hand	yes
repair_service	repair	yes

Primary category tag

When creating a new element, Digitaleo sets the primary classification tag (amenity, shop, tourism, leisure, office, or craft) based on the business's primary category. This tag is not set during updates — existing primary tags are always preserved.

The mapping was built by analysing businesses already present on OpenStreetMap to determine the most appropriate OSM primary tag for each category. It covers the most common business types (restaurants, shops, services, hotels, etc.).

Examples:

Category	OSM Tag
bakery	shop=bakery
restaurant	amenity=restaurant
hotel	tourism=hotel
hair_salon	shop=hairdresser
gym	leisure=fitness_centre
real_estate_agency	office=estate_agent
roofing_contractor	craft=roofer

If no mapping exists for the business's primary category, no primary tag is set and the element is created without a classification tag.

Services

Digitaleo Attribute	OSM Tag	Value	Notes
Delivery available	delivery	yes
Takeout available	takeaway	yes
Drive-through	drive_through	yes
Dine-in service	indoor_seating	yes
Outdoor seating	outdoor_seating	yes
Serves breakfast	breakfast	yes
Wheelchair-accessible entrance	wheelchair	yes	Highest positive priority — set when no wheelchair attribute is explicitly negative (see below)
Wheelchair-accessible seating	wheelchair	limited	Set when entrance is not accessible (or absent), and no wheelchair attribute is explicitly negative
Any wheelchair attribute explicitly marked as not accessible (entrance / seating / restroom / parking)	wheelchair	limited	Override. If the business owner has declared that any single accessibility aspect is not accessible (false), Digitaleo emits wheelchair=limited regardless of other positive attributes. Aligns with the OSM wiki definition of limited ("some areas are accessible, others are not") and avoids overwriting Wheelmap.org contributors' downgrades. no is never emitted because the binary nature of the source data does not justify the strong "impossible/dangerous" claim.
Wheelchair-accessible restroom	toilets:wheelchair	yes	Set only when explicitly accessible. The negative form (no) is not emitted.
Free Wi-Fi	internet_access + internet_access:fee	wlan + no
Paid Wi-Fi	internet_access + internet_access:fee	wlan + yes
Appointment required	reservation	required
Booking URL	website:booking	(URL)	Sanitized URL (forced https)

Payment methods

Digitaleo Attribute	OSM Tag	Value
Cash only	payment:cash	yes
Credit card accepted	payment:credit_cards	yes
Debit card accepted	payment:debit_cards	yes
Cheque accepted	payment:cheque	yes
Contactless payment	payment:contactless	yes
Visa	payment:visa	yes
Mastercard	payment:mastercard	yes
American Express	payment:american_express	yes
Discover	payment:discover	yes
Diners Club	payment:diners_club	yes
JCB	payment:jcb	yes

Note: Only payment methods marked as "accepted" by the business owner are published. If a payment method is not enabled, no tag is set (we do not set =no values).

Social media

Digitaleo Attribute	OSM Tag	Notes
Facebook URL	contact:facebook	URL sanitized (forced https, validated, query string and fragment stripped — see Tag sanitization)
Twitter/X URL	contact:twitter
Instagram URL	contact:instagram
LinkedIn URL	contact:linkedin
YouTube URL	contact:youtube
TikTok URL	contact:tiktok
Pinterest URL	contact:pinterest

Tag sanitization

Before any tag is written to OSM, the following sanitization rules are applied to ensure compliance with OSM conventions and avoid unnecessary changesets.

Tag remapping

Deprecated or non-standard tag forms are remapped to their preferred equivalents according to the OSM wiki:

Source Tag	Remapped To	Reason
phone	contact:phone	Preferred contact namespace
fax	contact:fax	Same
email	contact:email	Same
url	website	website is the preferred form
contact:website	website	Same
facebook	contact:facebook	Short forms are deprecated
twitter	contact:twitter	Same
instagram	contact:instagram	Same
linkedin	contact:linkedin	Same
youtube	contact:youtube	Same
tiktok	contact:tiktok	Same
pinterest	contact:pinterest	Same
payment:amex	payment:american_express	Full name preferred

If the target tag already exists on the element, the remapped value is not applied (the existing value takes precedence).

Website URL preservation

When an existing OSM element already has a more specific website URL on the same domain as the one Digitaleo would publish, the more specific URL is preserved.

Concretely: if the current element has contact:website=https://www.example.com/locations/store-123/ and Digitaleo sends website=https://www.example.com/ (the root domain from the business record), the published tag becomes website=https://www.example.com/locations/store-123/. This avoids silently replacing a precise per-location URL (often added by the business owner or an OSM contributor) with a generic brand-level URL.

URL comparison is canonical (lowercase, protocol / www. / trailing slash stripped). A URL is considered "more specific" when, after normalization, it starts with the candidate URL followed by / and additional path segments. If the domains differ, no preservation occurs — Digitaleo's value is used as-is.

All three website forms are considered on both sides of the comparison: website, contact:website, url.

Opening hours cosmetic equivalence

When publishing the opening_hours tag, cosmetic-only differences are treated as a no-op: if the value Digitaleo would publish is canonically equivalent to the value already on OSM (different spacing around , or ;, multiple whitespace, case differences), the existing OSM value is preserved and no changeset is sent.

This avoids triggering useless OSM revisions when another contributor has re-serialized the same schedule with a slightly different formatting (a common edit-war pattern between automated POI publishers).

Canonical comparison normalizes:

• leading and trailing whitespace
• multiple whitespace runs to a single space
• exactly one space after every , and ;
• lowercase for comparison purposes only (the published value preserves its original case)

For example, Mo-Fr 08:30-12:00,14:00-18:00 and Mo-Fr 08:30-12:00, 14:00-18:00 are considered equivalent and do not trigger a publish. Schedules that differ semantically (different times, different days) are still detected as a real change and pushed to OSM.

Opening hours rule-set equivalence (order-independent)

Beyond cosmetic equivalence of a single string, the final opening_hours value Digitaleo would publish is compared to the current OSM value as a set of rules — if both sides have the same rules (separated by ;) modulo cosmetic differences, just in a different order, the existing OSM value is preserved verbatim and no changeset is sent.

This avoids:

• Re-pushing every previously-published node when Digitaleo changes its emit order between two versions (ex: a new sort algorithm).
• Edit-war loops with contributors who prefer a specific rule order — if the rule set matches, we leave their ordering alone.

Canonical comparison normalizes each rule (lowercase, H:MM → HH:MM padding, whitespace trimming) and sorts both sides lexicographically before comparing. Equivalence is syntactic, not semantic: Mo-Fr 08:00-18:00 and Mo,Tu,We,Th,Fr 08:00-18:00 are not considered equivalent here — they are different surface forms.

Public holidays rule preservation

Digitaleo's data model has no concept of a recurring "public holiday" rule — only weekly schedules and date-scoped exceptions. When an OSM contributor adds a rule using the PH selector (e.g., PH off, Su,PH 0:00-24:00), Digitaleo preserves it instead of overwriting it.

Concretely: if the current OSM value of opening_hours contains one or more rules whose selector mentions PH and Digitaleo's new value does not, the existing PH rules are re-appended to Digitaleo's new value via ; . As per the spec, later rules take precedence for overlapping time spans.

Example:

OSM currently has opening_hours=Mo-Fr 00:00-08:00,19:00-24:00; Sa 00:00-08:00,12:00-24:00; Su,PH 0:00-24:00 (a veterinary emergency clinic, open 24/7 on Sundays and public holidays).

Digitaleo republishes its weekly schedule — reformatted with overnight-slot merging, and without any PH rule since our data model can't express it:

opening_hours=Mo 00:00-08:00,19:00-08:00; Tu-Fr 19:00-08:00; Sa 12:00-24:00; Su 00:00-24:00

After PH preservation, the published value becomes:

opening_hours=Mo 00:00-08:00,19:00-08:00; Tu-Fr 19:00-08:00; Sa 12:00-24:00; Su 00:00-24:00; Su,PH 0:00-24:00

The contributor's public-holidays information is kept — Digitaleo does not claim authority over a dimension of the data it cannot produce itself.

Future external dated rules preservation

A symmetrical policy applies to year-prefixed dated rules and year-less (annual) dated rules posted by an OSM contributor. These are rules like 2030 Jul 15-30 09:00-13:00, Dec 25 off, or 2030 Dec 24-2031 Jan 2 off — exceptions Digitaleo may not have in its own customSchedules.

When Digitaleo republishes opening_hours, each dated rule already present on OSM is handled as follows:

• Past year-prefixed rule (end date strictly before today): dropped. Past exceptions carry no useful information in opening_hours.
• Year-prefixed rule with the same selector as one of Digitaleo's own dated rules (e.g., OSM has 2030 Dec 25 off and Digitaleo publishes 2030 Dec 25 10:00-14:00): Digitaleo's version wins; the contributor's version is replaced. Digitaleo is authoritative for the date ranges it manages in customSchedules.
• Year-prefixed rule whose end date is today or later, with a selector that does NOT clash: preserved. The rule is re-injected into the published value between the weekly rules and Digitaleo's own dated rules.
• Year-less rule (e.g., Dec 25 off): treated as always valid (it applies every year) and preserved unless the same selector appears in Digitaleo's input.

Example:

OSM currently has opening_hours=Mo-Fr 08:00-18:00; 2030 Jul 15-30 09:00-13:00 (weekly + a contributor's summer rule).

Digitaleo publishes opening_hours=Mo-Fr 08:00-18:00; 2030 Dec 25 off (weekly + its own Christmas closure).

After merge, the published value becomes:

opening_hours=Mo-Fr 08:00-18:00; 2030 Jul 15-30 09:00-13:00; 2030 Dec 25 off

The contributor's summer rule survives alongside Digitaleo's Christmas rule.

Interaction with temporary open / close business statuses

Short-lived business lifecycle events (a business temporarily closed with a known reopening date, a business that will open in the future) are published through the separate opening_date tag, not through opening_hours dated rules. See Opening date above.

Rationale:

• opening_hours describes a recurring or date-scoped exception on the business's normal operating rhythm — a holiday closure, a seasonal schedule — once the business is back to normal, the dated rule is either filtered (past endDate) or updated. It is not designed to express "the place is completely shut until a specific future date".
• opening_date describes a lifecycle change — the business is not yet operational (or is currently closed) and will open (or reopen) on that date. Readers of the tag (rendering, routing, voice assistants) interpret it differently from a closure inside opening_hours.

Concretely, for a business that goes "temporarily closed, reopening 2026-09-01":

• Digitaleo publishes opening_date=2026-09-01.
• Digitaleo continues to publish the weekly opening_hours unchanged (it describes the rhythm once the business is back up — consumers combine both tags).
• Digitaleo does not emit a dated closure rule inside opening_hours for the temporary-closure window.

Once the business is marked permanently closed, the element is fully vacated from OSM (Digitaleo-written tags removed), not patched with a dated closure.

Social media URL reclassification

If the website tag contains a URL pointing to a social media platform, it is automatically reclassified to the appropriate contact:* tag:

Domain(s)	Reclassified To
facebook.com, fb.com	contact:facebook
twitter.com, x.com	contact:twitter
instagram.com	contact:instagram
linkedin.com	contact:linkedin
youtube.com, youtu.be	contact:youtube
tiktok.com	contact:tiktok
pinterest.com, pinterest.fr	contact:pinterest

This prevents the common case where a business owner enters their Facebook page as their "website", which would be incorrect per OSM conventions.

URL query string and fragment stripping

Before writing any URL-valued tag to OSM, Digitaleo strips the query string (?…) and fragment (#…) parts of the URL. Only the scheme, host and path are preserved.

Rationale: query parameters typically carry locale, tracking or share-source noise added by the source platform (e.g. LinkedIn's ?originalSubdomain=fr, Facebook's ?fbclid=…, X/Twitter's ?s=&t=). These parameters have no semantic meaning for an OSM contact tag and are routinely cleaned up by contributors. Re-publishing them on every sync would silently overwrite that cleanup.

Affected tags: website, contact:website, url, contact:facebook, contact:twitter, contact:instagram, contact:linkedin, contact:youtube, contact:tiktok, contact:pinterest (and their deprecated short forms, which are also remapped — see Tag remapping).

Example: https://www.linkedin.com/in/example-company/?originalSubdomain=fr is published as https://www.linkedin.com/in/example-company/.

Address conflict resolution

Digitaleo publishes address tags using the contact:* form by default (per OSM community recommendation: POIs should not define the address itself, as it is shared by multiple businesses at the same location).

After merging with existing OSM tags, all address tags are unified on a single form — no mixing of addr:* and contact:* on the same element:

• If the OSM element already has addr:* tags (set by a contributor): all address tags are aligned on addr:*, and any contact:* address duplicates are removed.
• Otherwise (no existing addr:*, or blank element): all address tags default to contact:*, and any addr:* duplicates are removed.

This respects the tagging style already established by contributors on the element, while defaulting to the recommended contact:* form for new or untagged elements.

Street name normalization

Street names are normalized following French OSM street naming conventions:

Abbreviation expansion:

Abbreviation(s)	Expanded Form
av, ave	Avenue
bd, bvd, blvd, bld	Boulevard
pl	Place
rte	Route
imp	Impasse
all	Allee
ch, chem	Chemin
crs	Cours
fg, fbg	Faubourg
sq	Square
pass	Passage
prom	Promenade
espl	Esplanade
res	Residence
lot	Lotissement
ham	Hameau
trav	Traverse
sent	Sentier
rpd, rpt	Rond-Point
carr	Carrefour

Capitalization rules:

• First word: always Title Case
• French articles and prepositions (de, du, des, la, le, les, au, aux, en, et, ou, sur): lowercase (except in first position)
• Elisions handled: d'Artagnan, l'Etoile
• Proper nouns: Title Case

Canonical comparison: If the current OSM value is canonically equivalent (same street after abbreviation expansion and lowercasing), the current OSM value is preserved to avoid an unnecessary changeset. For example, if OSM has Av. de Paris and Digitaleo sends Avenue de Paris, the existing value is kept.

Other sanitization rules

• City name normalization: All-uppercase city names are converted to Title Case (e.g., LYON → Lyon, AIX EN PROVENCE → Aix En Provence).
• Identity tag cleanup: If official_name is identical to name (case-insensitive), official_name is removed. Per the wiki, official_name should only be used when it differs from name.
• City suffix removal from name: If the business name ends with the city name, the city is stripped (e.g., Boulangerie Martin Lyon → Boulangerie Martin). Respects word boundaries (e.g., VetAmboise is not modified even though it ends with Amboise). French prepositions are also cleaned up (e.g., trailing "de", "du", "des", "d'" are removed).
• Blank value removal: Tags with empty or whitespace-only values are stripped before sending to OSM.

What Digitaleo does NOT do

• Does not delete OSM elements. Digitaleo never removes nodes, ways, or relations from OSM.
• Does not overwrite external modifications automatically. If a contributor changes a tag on an element managed by Digitaleo, the change is detected but not reverted. The user is notified.
• Does not create elements automatically by default. Automatic creation is blocked; the user must explicitly authorize it.
• Does not modify geometry. Nodes are not moved, way shapes are not changed, relation members are not modified. Only tags are updated.
• Does not overwrite the primary classification tag on existing elements. Tags like amenity=*, shop=*, tourism=*, healthcare=*, building=* set by other contributors are never modified or removed during updates. However, when creating a new element, Digitaleo sets the appropriate primary tag based on the business category (see Primary category tag).
• Does not set negative values. If a service or payment method is not enabled, no tag is written (we never set delivery=no or payment:visa=no).

Changeset conventions

All changesets created by Digitaleo follow a consistent pattern:

Changeset Tag	Value	Description
created_by	Digitaleo-OSM-API/1.0	Identifies the tool
source	digitaleo	Identifies the data source
comment	Add new business location	Used when creating a new node
comment	Update business information	Used when updating an existing element
comment	Mark business location as vacant	Used when vacating an element (see Element vacating)

Each create or update operation opens its own changeset, performs the single modification, and immediately closes the changeset. This ensures each changeset contains exactly one logical change for maximum traceability.

Training/instructions

Edits are performed programmatically by the Digitaleo platform, not by individual human mappers. The editing logic is maintained by the Digitaleo R&D team, which ensures:

• Compliance with OSM tagging conventions (see Tag sanitization)
• Proper tag merging (no deletion of unmanaged tags)
• One changeset per business update
• Accurate changeset comments and metadata
• Rate limiting (1 request per second)

Measuring our success

• Number of changesets and elements edited, tracked via OSMCha
• Community feedback via changeset comments and OSM messages
• Internal monitoring of edit success rate and API errors

Post-event clean-up

• Changeset comments from the OSM community are monitored and addressed.
• In case of reported issues, Digitaleo can identify and revert affected changesets.
• Internal quality checks are performed on the editing logic before deployment.

Community feedback

We welcome feedback from the OSM community on our editing practices. If you notice:

• Incorrect tag usage that does not follow OSM conventions
• Missing tag mappings that we should add
• Incorrect data on a specific element (please note that data corrections should be reported to the business owner via Digitaleo, as we do not overwrite external changes)
• Suggestions for improvement to our sanitization rules or matching algorithm

Please use the discussion page of this wiki page, the dedicated topic on the French OSM forum, or contact us at serviceclient@digitaleo.com.

Results

Results and statistics may be shared on this page periodically. Community members are welcome to reach out via the contact methods listed above for any questions or concerns.

See also

• Organised Editing Policy
• Automated Edits code of conduct
• French street naming conventions
• Contact namespace
• Opening hours format
• Opening date
• ref:FR:SIRET