Correction of changeset comment: Update the opening hours of Albert Heijn stores in the ISO3166-2 region of NL-DR

Correction of changeset comment: Fix invalid phone number related values in the ISO3166-2 region of NL-NB

Correction of changeset comment: Fix invalid phone number related values in the ISO3166-2 region of NL-LI

It also mentions here on how to map multiple phone number values osm.wiki/Key:phone#How_to_map

Though over here it also mentions that there is indeed an inconsistency going on in OSM (as always) when it comes to white space padding osm.wiki/Semi-colon_value_separator

Hi, yeah this would be an edge case that I thought it wouldn't be a big deal.

With that said, if we're using the semicolon as a delimiter, I believe it would be weird (or dirty when talking in the context of data engineering) to have a leading or trailing white space in it. As we're essentially saying that one of the phone number would be " +31 6 30898025".

I've always understood OSM as a database of geographical data for apps (etc.), rather than a final frontend for the end user. So in this context, it would be up to the data user (apps) to decided how to format it.

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-GR according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-GE according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-FR according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-FL according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-DR according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-FL according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-FR according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-GE according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-GR according to the international notation of E.123

Changeset comment correction: Format valid phone number related values in the ISO3166-2 region of NL-LI according to the international notation of E.123

Hi there, thanks for your comment.

Yes, I am aware of the fact that the phone numbers aren't yet formatted according to the international notation of E.123.

My intention is to fix all invalid (non-dialable) phone numbers today along with doing some other clean ups in NL, and then to properly format the numbers all in one go in the end.

Hi, René

There was an issue where I thought that DIN 5008 and E.123 were equivalent, but apparently not.

See the following changeset comments:
osm.org/changeset/131441346
osm.org/changeset/131441184

Hi Rainer, yes I was aware of the osm.wiki/Automated_Edits_code_of_conduct, but was not explicitly aware of the fact that DIN 5008 was different from the rest of most of the world (E.123).

The way of how Key:phone page was formulated gives the impression that E.123 and DIN-5008 were interchangeable, and it wasn't until I saw (dug up) this page osm.wiki/Talk:Key:contact:*#Internal_phone_extension_number that I realised that there was a minor difference.

The edits I applied was simply formatted the phone numbers according to E.123, and left out invalid (simply just wrong) phone numbers untouched. No 'real' damage was done to the data, they are all still reachable to the same people before the edit.

Given the difference of going from DIN 5008 to E.123 is one way only (because of the removal of '-' when it comes to DiD), I could revert my changes later today if you would like that?

Hi all, I'm using Google's open sourced library (https://github.com/google/libphonenumber) used by Android's contacts etc. to parse, validate, and format a phone number.

@Map-Peter Could you elaborate the issue a bit further for the node that you've mentioned? Every (mobile) phone number has a prefix, '176' in the case of '+49 17687940097'. The formatted '+49 176 87940097' seems correct to me according to DE:Key:contact:* .

Take a look at this as well: https://de.wikipedia.org/wiki/Vorwahl_01_(Deutschland)

Great, thanks!

But those extension numbers aren't actually (technically correct) extension codes right? In the sense that a proper extension system would require you to first dial the landline number, wait for connection, then dial the extension code.

Rather the Bremen government have just arbitrarily reserved all phone numbers with the pattern '+49 421 361xxxxx' for governmental use only.

I've just tried dialing +49 421 361 and it wouldn't go through