Talk:Key:post office/postal service provider
Jump to navigation
Jump to search
Old Version
As the update made by @Mueschel: is several months old, may be it's time for clean-up? --Nospam2005 (talk) 21:16, 2 February 2022 (UTC)
Overlaps with NSI
This page largely duplicates the Name Suggestion Index:
- https://nsi.guide/index.html?t=brands&k=amenity&v=post_office
- https://nsi.guide/index.html?t=brands&k=amenity&v=parcel_locker
It would probably be better to refer readers to the NSI instead of this page. --Push-f (talk) 10:30, 27 September 2022 (UTC)
- I do have neither much experience with NSI nor considerable insight into the organisation & working of NSI, so maybe someone could explain what that comment targets at for this specific wiki page? :-) I did compare wiki page and NSI. Of first 7 table rows, I did only find 2 in NSI, so at least in that random sample, the overlap is very limited. Moreover, I did not find in NSI many of the required details, e.g. whether a provoider offers parcel and mail or only one, there is only a search in Wikipedia instead a direct link to the according article, there is no hint that brand=* or post_office:brand=* shall be used, keys service_provider and ref are missing,... So for me, the NSI is of far less help while mapping than the wiki. --Schoschi (talk) 11:40, 27 September 2022 (UTC)
- The NSI is machine readable and many editors integrate it, so when you search for a name the editor automatically adds the tags from the NSI.
- So I think the NSI is probably used more often by mappers (indirectly but nonetheless) than some wiki page. I think it would be good to add the missing tags to the NSI if possible.
- I think ideally the info whether a provider offers parcel and/or mail / what regions it serves should be added to Wikidata, which would allow a join between Wikidata & the NSI to create such a table automatically.
- --Push-f (talk) 14:11, 27 September 2022 (UTC)
- @Push-f: While I understand and really appreciate the theoretical advantages of NSI, in my everday mapping practice, it is (a little provoking but mainly ment to be very illustrative) "that mysterious thing that floods the preset search result list with loads of noise entries that just hide the desired 'general, brand-independant presets' while it nearly never offers anything helpful for what I want to map". For exmaple, in Vespucci, I want to map a "Deutsche Post" postal partner and thus search for "Post", I get "Kirkburton Post Office" (a UK based shop selling paint) for a place in Germany (sic!), but not "Deutsche Post" which is the major postal services player in Germany thus is expected to appear. Besides the obvious regional bias of NSI, I usually do not map brands/chains – what NSI seems to be most helpful for, so it is quite clear why my personal experience is exactly the opposite to yours. I hope, in the future, NSI will become helpful for me as well because it makes mapping easier, e.g. mapping access restrictions that are common.
- Back to post offices for which NSI could show it's advantages. I really considered moving the wiki table to NSI. I did read https://github.com/osmlab/name-suggestion-index/wiki/Contributing (revision 25) and have the impression that I'd not be able to move this tiny table's content into NSI/WikiData within one evening, not even a really long evening. Making NSI "know" more stuff and produce more accurate content seems quite complicated and abstract compared to editing a wiki page: You need to understand which pieces need to be edited in NSI and which in WikiData, you need to understand the inner structure of NSI to grab the right JSON file, you need to edit JSON source in a proper way (general syntax and specific JSON schema and finding appropriate values), you need a github account, you need to be able to create a pull request, you need an account for WikiData, you need to know how to add details in WikiData in a way that NSI can use these details to create a key-value-pair. Sorry, as of now, that's too many prerequisites I'd need to dig myself into for such a simple thing as postal service providers. If someone else does, I am thankful and do hope that maintaining existing data is much easier than adding data. --Schoschi (talk) 23:10, 27 September 2022 (UTC)
- Right, no worries :) Wikidata is quite easy to edit once you know which properties to use. But yeah contributing to GitHub is of course way more involved than editing a wiki page. I am just a big fan of machine readability because it opens up many possibilities and wiki pages unfortunately are notoriously unreadable to machines ... wikitext is a mess ;) I am currently stuck in some other rabbit holes but once I get out of them I might come back to this and think about it some more. Hahah, yeah the Vespucci integration of NSI is far from perfect. Right now I am just happy that other people would support some more machine readable alternative if it was easy to edit ... I get that NSI isn't :) --Push-f (talk) 23:20, 27 September 2022 (UTC)
- I agree with Schoschi, moreover, I don't use wikidata or NSI but this wiki table, and as long as it has a lot of info that are not in NSI it makes sense to be there. I did the same, I took the last 7 lines and I couldn't find them in NSI --Lenny (talk) 11:40, 27 September 2022 (UTC)
- @Push-f: I would very much like to replace this table with entries in the NSI. Biggest problem with this: The NSI does not support the use of only post_office=partner with the data and always requires an amenity=post_office. So not all data here is also necessarily compatible. See also the problem on Git: https://github.com/osmlab/name-suggestion-index/pull/6939 -SafetyIng (talk) 15:56, 27 September 2022 (UTC)
- You can create two pages, one for NSI known brands/operators and another for yet to be integrated ones. So you get the best of both worlds. Not a big fan of current NSI usage either (as all mail boxes get a useless warning in Osmose to add the NSI related information, that could/should be properly done with a bot), but at least it's machine and human readable. --Nospam2005 (talk) 17:00, 1 October 2022 (UTC)
Change to lowercase "ref"?
Since the last edits, the table lists the values for the "ref" key in lowercase. A quick check in taginfo shows that e.g. ref:DHL is used 127 times, and ref:dhl is not used at all. Shouldn't such a change be discussed first, and a plan should be made to change the existing tagging? I think the Wiki should reflect the actual key usage, and the table should be changed back to the spelling that is in use. --Mueschel (talk) 08:20, 31 October 2023 (UTC)
I agree, we have the same for ref:FR:LaPoste used 17,877 times and ref:la_poste never, I corrected the wiki --Rodrig (talk) 18:50, 31 October 2023 (UTC)
- It's very clear in the proposal which was approved: Service providers must be named like in post_office:service_provider=*, but all characters in lower case and spaces must be replaced with underscores '_' (because it's the key not the value). Example: "Deutsche Post" -> "deutsche_post". See Proposal:Shop_as_post-partner. Where is a discussion and a decision, that there should be a change in this point? I didn't find one. In addition, the use of lowercase letters also corresponds to the syntax convention/recommendation for keys (see for example Any_tags_you_like#Syntactic_conventions_for_new_tags). And at least, there shouldn't be spaces in a key (they should be replaced with underscores). So the definition of the proposal makes a lot of sense. Goodidea (talk) 17:23, 6 November 2023 (UTC)
- I understand that this rule concerns new tags Any_tags_you_like#Syntactic_conventions_for_new_tags but when the proposal was made, there was no study of what already existed. The tag ref:FR:LaPoste=* hare not spaces, it was set up in 2012 https://taginfo.openstreetmap.org/keys/ref%3AFR%3ALaPoste#chronology, it is in https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dpost_office#France; used to link to the public file (opendata), it is also used in quality assurance checks and ... Rodrig (talk) 13:20, 07 November 2023 (UTC)