Nieuwe geaccepteerd tag - shop as post partner

Lijkt me van wel want die zijn nu overbodig geworden. Uiteraard niet als het een fysiek los postkantoor is met een eigen adres.

Ik denk dat er in eerste instantie geen noodzaak is om rendering aan te passen. Neem Bij jou bekende Qwant maps als voorbeeld. Als je dan op een winkel klikt en je links het informatieventer krijgt dan komt daar gewoon een extra rij te staan dat deze winkel een post servicepunt is. Je zou bijvoorbeeld ook een speciale kaart/filter maken die die postservice punten speciaal weergeeft.

Ik ben dus niet van plan om amenity=post_office van de kaart te verwijderen en te vervangen door een subkey.
het gevolg daarvan is dus dat het symbool van de kaart verdwijnt.

De nieuwe tag heeft mijns inziens dus geen toegevoegde waarde en lijkt geheel overbodig.

Als het een echt, losstaand postkantoor is dan kan de tag blijven ja. Voor die servicepunten heeft de overgrote meerderheid op Wiki er voor gestemd om het op de betreffende winkel te gaan taggen. Het niet verwijderen van amenity=post_office voor deze service punten lijkt mij dan taggen voor de renderer want het gaat er om dat de informatie in de database staat. Kijk maar eens naar deze [1]. Het staat nu gewoon netjes in de database. Renderers en kaartendiensten kunnen er dan voor kiezen om dat speciaal te gaan renderen of weer te geven. Het feit dat het in de osm database staat betekend dat het opzoekbaar is. Als de nieuwe tag niet genoeg gebruikt gaat worden gaat Carto in ieder geval het nooit overwegen om misschien apart te renderen.

Het is overigens mogelijk dat andere mappers in jou gebied die punten met amenity=post_office wel gaan taggen als servicepunt met post_office=post_partner.

[1] https://www.openstreetmap.org/node/3013391086

Het is nog steeds een postkantoor maar dan in iets andere vorm.

Ik begrijp niet welk punt je hiermee duidelijk probeert te maken.

Eigenlijk is het toch vreemd dat een plek waar je post kunt brengen en postzegels kopen een postkantoor is als de eigenaar PostNL is, maar geen postkantoor mag heten als de eigenaar niet PostNL is.

Voor mij als klant maakt het geen verschil of de balie voor de postzaken in een winkel staat of in een apart gebouw.

Het vervangen van de key amenity=post_office lijkt mij niet wenselijk.
Een subkey toevoegen kan zinvol zijn (al weet ik zelf niet voor wie), maar voor mij voegt het niets toe.
Op het moment dat de openingstijden van het postagentschap afwijkt van de winkel maak je alles alleen onnodig complex.

In Nederland hebben we niet echt veel grote, zelfstandige postkantoren meer. Nu zijn het meer nevendiensten van een winkel. Die servicepunten hebben niet echt vaak een apart adres en vaak gewoon de zelfde openingstijden als de winkel. Deze tag maakt het mogelijk alle informatie te bundelen op 1 punt. Dat voorkomt dat je ook 2x een adres in de DB hebt, 1x van de winkel en 1x van het postkantoor. Zodra de zoekmachines en kaarten apps zich hebben aangepast is de tag post_office=post_partner op de winkel node prima te gebruiken.

Daarvoor is de tag post_office:opening_hours=* mochten dat afwijken. Als ze het zelfde zijn kun je gewoon opening_hours=* gebruiken.

Een adres op een servicepunt was al overbodig, iemand zou misschien een brief naar een winkel willen sturen maar niet naar een servicepunt.

En daar heb ik dus geen vertrouwen meer in.

We wachten ook nog steeds op het renderen van public_transport=platform, bus=yes.
Als ik het goed begrijp zal dat er nooit komen.

Dus amenity=post_office verwijderen van de kaart is geen vooruitgang.
En de nieuwe tag voegt niets toe.

Als je mapt voor Carto rendering, dan kun je in veel gevallen wachten tot je een ons weegt. Er zijn veel meer diensten die gebruik maken van onze data en voor hen mappen we net zo goed.

Deze nieuwe tag kan erg nuttig blijken zodra iemand ermee aan de haal gaat, maar als je de ontwikkelingen van Carto een beetje volgt, dan moet je dat daarvan niet verwachten. Daarbij, Carto rendert voor ons, wij mappen niet voor Carto. Dat zou de omgekeerde wereld zijn.

Dat is dus een perfect voorbeeld van hoe het niet moet.
Het is een vestiging van DHL.
Dan is dus gelijk duidelijk dat de 3 tags post_office:parcel… volkomen overbodig zijn.
Het zal altijd yes zijn en het zal nooit no zijn.
Het is dus 3x non-informatie.

Het wordt ook aangemerkt als post_office, maar het is geen postkantoor.
Ik kan er mijn post niet aanbieden/afhalen.
Ik kan er geen kentekenbewijs overschrijven.
Ik kan er geen studentenreisbewijs inleveren/afhalen.
Of zijn dat inmiddels achterhaalde diensten ?

We gooien dus 10 verschillende koeriersbedrijven in de mixer, schudden eens flink en noemen alles postkantoor.

Dat wordt dus een chaos die vooral voortkomt uit het feit dat er onvoldoende geanalyseerd is wat een postkantoor is.
En er is dus een groot verschil met een koeriersdienst.

En als de definities niet kloppen dan loopt het automatiseringsproject altijd fout.

Ik heb straks de keus uit een x aantal post_office, maar ik weet niet waar ik het postkantoor kan vinden.

Het lijkt mij dus weer een historische vergissing, maar ik heb intussen geleerd dat het zinloos is om hier tegen in te gaan.

Hier realiseerde ik me achteraf ook dat dit niet klopt. Ik had de wiki even verkeerd geïnterpreteerd dit wou en ga ik nog aanpassen. Kan gebeuren bij een nieuwe tag.

Ja, ik zei al eerder dat we bijna geen voltallige postkantoren meer hebben maar vooral servicepunten voor het ophalen en afgeven van post en pakketjes.

Dat weet je wel. Je weet dadelijk waar de servicepunten zijn van de verschillende aanbieders waar je je pakketje kunt ophalen of achterlaten. Dit is een prima tag die de situatie in NL goed omschrijft. En in andere landen hebben ze misschien nog geen servicepunten maar gewoon postkantoren. Dit tagginschema geeft de mogelijkheid voor ieder land te gebruiken wat van toepassing is.

@Leo Slager Als je een ander voorstel hebt, dan kun je daarmee naar de tagging mailing list. Wellicht kunnen we dat eens ter stemming brengen. Tot die tijd stel ik voor dat we servicepunten als nevenfuncties van andere bedrijven mappen als de goedgekeurde tag post_office=post_partner: https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpost_office#Shop_as_post_partner

Tja, je hebt natuurlijk volkomen gelijk. Maar na 40 jaar moeilijke stukken schrijven geniet ik van een pensioen en ik heb dus absoluut geen zin om op een mailing list nog weer moeilijke stukken te gaan schrijven.

Voor de servicepunten van de koeriersdiensten moest er een oplossing komen. Dat die nu ook post_office worden genoemd is betreurenswaardig.

Het is zeker geen aanleiding om amenity=post_office in NL van de kaart te verwijderen.
amenity=post_office, operator=PostNL is voor mij het postagentschap van PostNL met een veel uitgebreider dienstenpakket als de servicepunten van de koeriersdiensten.

Interessante discussie. Ben zelf actief in planning van bezorgroutes voor koeriers. Ik heb laatst zelf wel een node aangemaakt voor een parcel-locker die wij gebruiken, wat natuurlijk iets compleet anders is. Maar wat mij opviel is dat hier dan al wel weer geschikte tags voor bestaan: https://www.openstreetmap.org/node/7757543604
Je zou zeggen dat zoiets als extra “service” moet kunnen worden toegevoegd aan de bestaande diensten van de betreffende winkel, en dan het liefst natuurlijk met het betreffende koeriersbedrijf erbij. En dat lijkt deze nieuwe tag op zich goed te doen. Wellicht kan in de subtags nog een optie “post_office:delivery_times” toegevoegd worden omdat sommige diensten eerst bezorgen en later op de dag pas afhalen.

Naar mijn mening is de term “postkantoor” eigenlijk bijna nergens meer op van toepassing in nederland. Winkels die zulke diensten hebben doen het vrijwel allemaal “erbij” als aparte dienst naast hun eigen winkeldiensten.

Ik volg in ieder geval de ontwikkelingen hier :slight_smile:

En wat als in een pand, zowel DPD, UPS en DHL services worden verstrekt.

Als ik de theorie goed begrijp wordt dat dan:
post_office=post_partner
post_office:service_provider=DHL;DPD;UPS

en los daarvan op een eigen node:
amenity=post_office
operator=PostNL

Maar die laatste is voor mijn eigen rekening !
Duidelijk en simpel genoeg voor de meeste onwetende mappers !

DIt klopt. Mocht de dienstverlening per aanbieder verschillen, dan kun je dat via onderstaande tags aangeven.

Als het een servicepunt is dan moet ook postNL als post_office=post_partner worden getagd op de winkel

Ik bekeek even goed de wiki pagina’s maar er zijn een paar tegenstrijdige tags in omloop.

Wat ik nu begrijp is dat

post_office:parcel_to

betekent dat je dit punt kan gebruiken om een pakket dat onderweg is ipv naar huis daar naartoe kan laten sturen.

post_office:parcel_pickup

komt dan eigenlijk toch neer op hetzelfde?

En er lijken drie verschillende tags te zijn om aan te duiden dat je pakketten kan versturen

post_office:parcel_mail_in
post_office:parcel_send_in
post_office:parcel_from

https://wiki.openstreetmap.org/wiki/Key:post_office
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpost_office#Shop_as_post_partner

Misschien als je heel nauwkeurig gaat kijken dat er een verschil is. Je zou het zo kunnen zien post_office:parcel_to=dat je als klant kunnen zeggen lever het bij dat punt af en post_office:parcel_pickup bijvoorbeeld dat als je niet thuis bent de pakketbezorger het niet nog eens probeert maar het bij een servicepunt afgeeft. Dat laatste is dus wat onvrijwilliger zegmaar. Maar goed, dat is hoe ik het nu zou interpreteren op basis van de tags.

Maar de verschillen liggen dicht bij elkaar. Mee eens

post_office:parcel_to

Dit kan nooit een subtag van een servicepunt zijn.
Deze dienst maakt namelijk deel uit van het contract tussen afzender en vervoerder.
De afzender geeft dan aan dat deze dienst gebruikt kan worden.
Als de afzender een ander (goedkoper) contract afsluit met de vervoerder heeft de ontvanger dus niets te kiezen.

post_office=parcel_pickup is in de praktijk dus de enige mogelijke subtag.
Maar is tegelijkertijd volledig overbodig, het is altijd van toepassing en is zelfs het bestaansrecht van zo’n servicepunt.