Add address field to amenity=parcel_locker in HU

[gy-mate]

Description, Motivation & Context

amenity=parcel_lockers often have an address associated with them. This is usually available on the operator's website.

Related issues

None.

Links and data

Relevant OSM Wiki links:

• https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparcel_locker#:~:text=addr%3D

Relevant tag usage stats:
https://taginfo.openstreetmap.org/tags/amenity=parcel_locker#combinations

Checklist and Test-Documentation Template

Read on to get your PR merged faster…

Follow these steps to test your PR yourself and make it a lot easier and faster for maintainers to check and approve it.

This is how it works:

1. After you submit your PR, the system will create a preview and comment on your PR:

   🍱 You can preview the tagging presets of this pull request here.
   If this is your first contribution to this project, the preview will not happen right away but requires a click from one of the project members. We will do this ASAP.

2. Once the preview is ready, use it to test your changes.

3. Now copy the snippet below into a new comment and fill out the blanks.

4. Now your PR is ready to be reviewed.

## Test-Documentation

### Preview links & Sidebar Screenshots

<!-- Use the preview to find examples, select the feature in question and **copy this link here**.
     Find examples of nodes/areas. Find examples with a lot of tags or very few tags. – Whatever helps to test this thoroughly.
     Add relevant **screenshots** of the sidebar of those examples. -->

<!-- FYI: What we will check:
     - Is the [icon](https://github.com/ideditor/schema-builder/blob/main/ICONS.md) well chosen.
     - Are the fields well-structured and have good labels.
     - Do the dropdowns (etc.) work well and show helpful data. -->

### Search

<!-- **Test the search** of your preset and share relevant **screenshots** here.
     - Test the preset name as search terms.
     - Also test the preset terms and aliases as search terms (if present). -->

### Info-`i`

<!-- **Test the info-i** for your fields and preset and share relevant **screenshots** here.
     The info needs to help mappers understand the preset and when to use it.
     [Learn more…](https://github.com/tordans/id-tagging-schema/blob/main/CONTRIBUTING.md#info-i)
 -->

### Wording

- [ ] American English
- [ ] `name`, `aliases` (if present) use Title Case
- [ ] `terms` (if present) use lower case, sorted A-Z
<!-- Learn more in https://github.com/openstreetmap/id-tagging-schema/blob/main/GUIDELINES.md#2-design-the-preset -->

[github-actions]

🍱 You can preview the tagging presets of this pull request here.

[gy-mate]

Test-Documentation

Preview links & Sidebar Screenshots

https://pr-1338--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&id=n12118214705&locale=en&map=21.51/47.58592/19.04546

[matkoniecz]

Relevant tag usage stats:
https://taginfo.openstreetmap.org/tags/amenity=parcel_locker#combinations

note that many are incorrectly added

amenity=parcel_lockers often have an address associated with them. This is usually available on the operator's website.

nope

at least in Poland they state closest address, which is not address of the parcel locker

[matkoniecz]

I would be against further encouraging such bad tagging, unless it is actually correct tagging more often than not

[gy-mate]

at least in Poland they state closest address, which is not address of the parcel locker

@matkoniecz This may be the case in Poland but not in Germany (https://www.dhl.de/de/privatkunden/dhl-standorte-finden.html), Czechia (https://www.rohlik.cz/tema/rohlikpoint), Slovakia (https://www.alza.sk/alzabox#kde-najdes-svoj-alzabox) or Hungary (https://wiki.openstreetmap.org/wiki/Hungary/Jelölési_példák#Csomagautomata). The amenity=parcel_locker wiki page also says that "Parcel lockers may have an official address".

@ITineris said the following about this on the OSM Hungary Matrix server, which I agree with:

If this is the case in Poland, do not use it there (if the two are different). But where it is, why not use it to help navigation?

@vasony also agrees with these.

[gy-mate]

@vasony also mentioned that "the branch=* is the actual branch which does not contain the full address. E.g. 'Bp. 11. ker. Mathias Corvinus Collegium', meanwhile the address is '1113 Budapest, Tas vezér utca 3-7. ' Both information are listed on the website [of the parcel locker operator]."

So these might be two different information. I think that iD could help users wanting to add the address by showing an Address moreField.

[matkoniecz]

I have no knowledge on address data for this POIs outside Poland. I agree with

If this is the case in Poland, do not use it there (if the two are different).

and AFAIK you can make it so it will appear in some regions and in some not, but I have no idea how to do this

[gy-mate]

AFAIK you can make it so it will appear in some regions and in some not

@matkoniecz I've changed the address field to only appear in Hungary. Other countries can be added later by the local communities.

[gy-mate]

@tordans Could you please review this PR? Many thanks in advance!

[tordans]

I am hesitant with regional presets. The discussion however sounds good to me.

Will wait for more input and put it on the agenda of the community meet to get some quick feedback.

[tordans]

I am hesitant with regional presets. Will wait for more input and put it on the agenda of the community meet to get some quick feedback.

We only talked about this very briefly in https://wiki.openstreetmap.org/wiki/ID/Community_Chats/2025#Agenda_/_Notes_2 but the gist was that we should use regional presets when needed.

---

Relevant tag usage stats:
https://taginfo.openstreetmap.org/tags/amenity=parcel_locker#combinations

https://taginfo.geofabrik.de/europe:hungary/tags/amenity=parcel_locker#combinations is a good comparison, it shows ~70%+ of addr:* tags in combination with the primary tag.

[tordans]

@gy-mate could you double check the test comment after the latest changes. I expected https://pr-1338--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&locale=en&map=21.51/47.58592/19.04546&id=n12118214705 to show the address, right?

Nothing jumped out to me when looking at the code or https://github.com/ideditor/schema-builder?tab=readme-ov-file#fieldsmorefields …

[gy-mate]

@tordans Is it possible to cross-reference terms and name to avoid duplication? Because I did that and maybe that's why the new parcel_locker-HU.json isn't included in the Netlify preview.

[tordans]

@tordans Is it possible to cross-reference terms and name to avoid duplication?

https://github.com/ideditor/schema-builder?tab=readme-ov-file#name sounds like maybe only name should have the reference and terms and aliases removed, because name actually references both.

[gy-mate]

I've removed the terms cross-reference but the Netlify preview still doesn't show the address field. I have no idea what goes wrong, mainly because all tests and builds pass. :(

@tordans Could you please give me some further help? Many thanks in advance!!

[tordans]

@k-yle do you have an idea why the address does not show?

[k-yle]

@tordans short answer: If you remove the brand:* tags from that example node, it will show the new address field correctly.

long answer: the example node has a brand:wikidata tag, so iD is using the NSI preset, not the normal preset.

NSI's presets are derived from a released version of id-tagging-schema. not sure how often the NSI team update their version of the tagging schema, but the system seems to work for existing regional presets.

[gy-mate]

So it's normal that the Netlify preview doesn't show the address field.

@tordans @k-yle Could you please re-review this PR? Many thanks in advance!

[k-yle]

from a technical persepective this looks good, I'll let others discuss whether a regional preset is appropriate here

[gy-mate]

I'll let others discuss whether a regional preset is appropriate here

@matkoniecz Would this regional preset be fine with you?

[matkoniecz]

I am still suspicious about it (some people claimed that parcel lockers have addresses in Poland - in reality they list closest existing address), but I lack local knowledge to confirm that suspicion.

Hmm, I guess that one may check existing data is it just listing closest real address.

[gy-mate]

@matkoniecz I have to correct my previous comment: the address of parcel lockers in Hungary is actually the address closest to them. But parcels delivered there are addressed to that address (it's written on parcels). So it's a mix of the two.

We import Hungarian parcel lockers with osm_poi_matchmaker. As we also import their addresses, this improves house number coverage in rural areas by a lot. And that helps people who want to navigate to these addresses.

So I think it's beneficial to add these addresses to parcel lockers, hence my PR.

I couldn't find anything on https://wiki.openstreetmap.org/wiki/Addresses that would be against this. I also checked if we could use https://wiki.openstreetmap.org/wiki/Key:object:* instead, but it says it's "Used to describe the position of man-made features where nothing will be delivered at." so it doesn't seem like a viable option to me.

[tordans]

@matkoniecz I think we have enough buy in (1, 2) here to go down this route. Should there be negative feedback later, we can always circle back. Unless you 👎 I would merge in a few days.

[matkoniecz]

I am still against putting claimed address on something where it is not its address.

I do not want to run with https://en.wikipedia.org/wiki/Liberum_veto but I still think this one is a mistake.

[gy-mate]

I am still against putting claimed address on something where it is not its address.

@matkoniecz Are you against adding addresses to parcel lockers at all, or do you dislike using the addr: prefix for this purpose?

[matkoniecz]

I think that if it really needs to be added it would be better to use a different keys.

But that is just my opinion.

[gy-mate]

Which keys would you suggest instead?

[matkoniecz]

https://wiki.openstreetmap.org/wiki/Key:object:* seems to be used for those

The key object:*=* was used by several mechanical edits in Germany in 2015 and afterward, to add address information to small man-made features such as lamp posts and memorials, which had no address (addr:*=) that was given out by officials. The subkeys use the Karlsruher Schema. The main feature tags used were public artworks, memorials, control boxes for traffic light- and telecommunication systems which were not assigned an address, but near to an object having an official address tagged with addr:*=.

[gy-mate]

@matkoniecz #1338 (comment):

I also checked if we could use https://wiki.openstreetmap.org/wiki/Key:object:* instead, but it says it's "Used to describe the position of man-made features where nothing will be delivered at." so it doesn't seem like a viable option to me.

[matkoniecz]

Oh, that is only in infobox summary - despite not being present in article, But note entire one:

Used to describe the position of man-made features where nothing will be delivered at. Address tagging for those features that shouldn't be tagged with the addr prefix.

in this case things are not delivered to this address - they are delivered to object referenced otherwise, with address only stated to help customers find it. Maybe this description can be adjusted? But that would require discussion, I guess

[matkoniecz]

I asked at https://wiki.openstreetmap.org/wiki/User_talk:MalgiK#object%3A%2A for start to check what is the source of this claim.

[gy-mate]

Thank you! :)

[matkoniecz]

https://community.openstreetmap.org/t/object-housenumber-can-it-be-used-for-parcel-lockers/138508

[gy-mate]

The Hungarian community agreed upon using object:* instead of addr:* for parcel lockers so I'm closing this PR.

Thank you for your thorough guidance, @matkoniecz! :)