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.
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.
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.
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
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.