Een specifieke url is door een dataconsument vrij eenvoudig te reduceren tot een domeinnaam, andersom niet.
In het geval van de Kruidvat is het wel borishag zelf, die in zo’n geval relatief eenvoudig de zaak kan omzetten of iemand kan vragen om het te doen/te helpen omdat hij van zijn it/pr afdeling de omzettingstabel kan krijgen.
Bij het Kruidvat kan dat alleen door gebruik te maken van google maps. Dat lijkt me het paard achter de wagen spannen. Juist daarom voegt de website van het object zelf (de vestiging dus) relevante informatie toe.
Ere wie ere toekomt: Ik besteed zelf als ik onderweg ben geen aandacht aan Kruidvat/Trekpleister etc, want ik weet bij voorbaat dat die er al in staan. Dat heeft Watson/borishag erg goed voor elkaar.
Desondanks eens met Kogacarlo dat de woorden die borishag kiest weinig sociaal en constructief zijn.
Even terzijde: ik kom bij het zoeken naar de filiaalpagina tegenwoordig bij best veel ketens websites tegen die het gewoonweg niet doen of half werken als je ook maar een paar privacytools gebruikt. Met alleen al een ad-blocker doet de helft het al niet lijkt het. Of wel informatie per filiaal, maar geen URL waar je naar toe kan linken (Lidl bijvoorbeeld).
Het is verfrissend als een keten een overzichtspagina heeft van de filialen die wel gewoon werkt met duidelijke URL’s per filiaal.
Openstreetmap is een geografische database, het geeft zaken aan op die locatie. Informatief karakter.
Informeert over die locatie.
Die homepage website heeft de layout van een webwinkel, het karakter van deze pagina, dat is bepalend voor de verwijzing, deze webwinkel/webshop/online_shop is niet gevestigd op deze locatie. Dat wordt met het opnemen van deze pagina gesuggereerd, zo kan je het opvatten.
Hier wordt als marketingstrategie de verschillende winkellocaties gebruikt om de webshop te promoten.
De gebruiker van Openstreetmapdata verwacht dat niet, dit is ongewenst, tenzij…
In zo weinig mogelijk stappen verwezen worden naar de locatie informatie.
Wanneer het een afhaalpunt of retourpunt is zou dat kunnen worden vermeld.
Als dat het geval is dan kunnen er tags op, die de functies beschrijven.
Nu is kruitvat onderwerp van discussie, je zou dit zeker over het geheel moeten bekijken. Webshop en hoe er mee om te gaan.
Eerst alle voorwaarden goed doorlezen, de valkuilen bij webshops (algemeen)
Webshop, er lijkt geen ophaal functie te zijn.
:parcel_pickup=yes etc.
retour? afgiftefunctie, :parcel_send_in, ontvangst servicebalie functie, via een postoffice of bij een aangegeven locatie, balie shop.
Dan is het wellicht wel acceptabel om ook een verwijzing naar een webshop te gebruiken, maar niet als website=* deze gebruiken voor de filiaalpagina.
Voor webshop/online_shop, dan een key die duidelijk aan geeft dat de verwijzing een webshop/online_shop is.
webshop:website=/online_shop:website= gebruik mits er een functie van de webshop aanwezig is op de locatie.
Is een alleen een retour (gedeeltelijk) functie genoeg? RMA procedure, vooraf.
Laatst kwam ik deze key tegen, jong, ontstaan vanwege de afgelopen tijd. website:orders=
Je order opgeven is breder dan webshop functionaliteit.
Het geeft aan dat OSM voor deze manieren van werken nog niet over de juiste tags beschikken om de functies op de locatie aan te geven.
Ik bestel brood al jaren bij de bakker (telefoon) en kom het later ophalen, een functionaliteit, die aangegeven kan worden in OSM, nog geen goede OSM tag aanwezig. Je zou haast denken aan phone:orders=
Het bovenstaande heeft veel overeenkomst met de post_office in een shop.
Waarbij de shop een functie uit voert voor een andere bedrijf.
Hoe omschrijf je dat bij online_shop structuren.
Met al die holding structuren, wil je weten met welk bedrijf je te maken hebt. KvK nummer.
Een brand, dat vertegenwoordigt wordt door meerdere bedrijven.
En dan is er een naam gekozen voor een online_shop, die niks zegt over brand of bedrijf, welk bedrijf zit er achter.
Ik heb even op de Nederlandse Taginfo pagina gekeken, en blijkbaar hebben we best wat algemene websites van winkelketens e.d. die als website=* gemapt zijn. Zie hiervoor https://taginfo.geofabrik.de/europe/netherlands/keys/website. Het lijkt het mij logisch om hier consistent brand:website=* dan wel operator:website=* van te maken. Hoe denken jullie hierover?
Ik zou dat per keten doen als je toch al een keten bijwerkt. Ik heb zelf Dille & Kamille een tijdje terug gedaan in heel Nederland: Voorbeeld in Leeuwarden en Changeset met de rest.
Ik liet brand:website toen achterwege, maar die had er dus bij gekund. Als je zo’n keten integraal aanpakt kun je gelijk de spelling en tags gelijktrekken en de vestigingen nalopen. Je komt vaak ook op plekken waar nog veel basisdingen niet in de haak zijn, dus dat is mooi meegenomen. Met alleen het aanpassen van de website-key is er niet zo veel winst.
Is het wenselijk om brand=, brand:wikidata= en brand:website=* tags op de vestigingen van verschillende ketens te hebben? Deze tags zijn best makkelijk mechanisch (allemaal in één keer) toe te voegen als ik/we hier toch mee bezig is/zijn, maar ik vraag het even voordat ik dit op grote schaal ga doen.
Tip: voor zaken waar een operator van toepassing op is in plaats van een brand kun je operator:website gebruiken voor de algemene website, net als bij winkelketens.
Bijvoorbeeld bij vestigingen van een bibliotheek: voorbeeld
Hoe gaan we trouwens verder met de vestigingen van Kruidvat, ICI Paris, en Trekpleister? Herrieman is niet de enige wiens edits worden teruggedraaid door borishag. Ik vermoed dat de meeste mappers niet door hebben dat een link naar de filiaalinformatiepagina bij deze ketens consequent teruggezet wordt naar de generieke ketenwebsite. Hier een edit door LucGommans, hier smootheFiets, en ikzelf. Dat is jammer, want ik vind de link erg nuttig als mapper bij het bijwerken van kaartdelen, en ook voor kaartgebruikers is het handig (en in overeenstemming met het doel van website).
Dit soort edits zijn trouwens ook een beetje raar. Ja, die tag voegt niet veel waarde toe, maar hij is wel correct.
Ik snap dat een commerciële partij graag de feiten kloppend heeft, maar dit gedrag neigt wat mij betreft naar vandalisme en een nare vorm van gatekeeping over deze winkelketens. Ik vind het jammer dat borishag geen ruimte geeft voor overleg en voortschrijdend inzicht met betrekking tot het gebruik van tags in OSM.
Bovendien is het meestal helemaal niet erg als een filiaalpagina een keer verdwijnt, want dan krijg je doorgaans gewoon een ‘niet gevonden’ pagina op de website zelf. Bij Kruidvat wordt je zelfs naar https://www.kruidvat.nl/store-finder doorverwezen als de filiaalpagina niet bestaat, wat een bijzonder nette terugvaloptie is.
Ja lastig. Ik vind het ook jammer dat borishag niet even op het forum wil reageren, ik had hem destijds ook naar dit topic verwezen. Wat mij betreft is die filiaalpagina veel nuttiger. Zeker in deze tijden veranderen de openingstijden zo vaak, en de opening_hours=* wordt niet of pas veel later bijgewerkt.
Vervangen door toilets=no zou in dit geval het beste zijn denk ik. Met die wheelchair tag wordt er gesuggereerd dat er wel toiletten zijn, maar niet toegankelijk.
Zojuist keek ik even naar deze NL taginfo pagina en er staan nogal wat websites bij die best makkelijk te veranderen zijn naar brand:website=*. De methode die ik voorstel is als volgt:
Krijg voldoende goedkeuring hier op het forum en documenteer alles op de Wiki onder de automatische edits.
Zoek de winkels op die deze tags hebben met Overpass (zie onderaan).
Pas in JOSM de website=* tags aan naar brand:website=*
Voeg missende brand=* en brand:wikidata=* tags toe.
Gebruik de validator van JOSM om overige problemen op te sporen.
Upload de wijzigingen en documenteer dit op het forum en de Wiki.
Naar mijn insziens kan hier weinig fout mee gaan, aangezien we hier specifiek de websites van winkelketens bewerken die op de filialen gemapt zijn.
Het doel hiervan is om incorrect gemapte tags te verbeteren zonder iets te doen wat mogelijk nog omstreden is (zoals het grootschalig aanpassen van shop=* tags).
De Overpass query die hiervoor gebruikt kan worden:
area(3612728888)->.a;
node["shop"]["website"="https://www.kruidvat.nl/"](area.a);
out meta;
Wat mis kan gaan is dat wij mogelijk winkels aanpassen die OTG niet meer bestaan. Ik verwijder er regelmatig tijdens BAG-onderhoud (als het adres is opgeheven, anders krijg ik het niet mee). Kruidvat zit daar weliswaar niet vaak bij (of zelfs helemaal niet?). Blijkbaar worden die goed onderhouden.
Een voor de hand liggende aanwijzing is dat de hele website of URL naar het filiaal het niet meer doet. Als ik OSMOSE-meldingen naloop open ik sowieso dergelijke websites. Maar bij “oudere” nodes kan de URL-notatie natuurlijk door de websitebeheerder vervangen zijn.
Commentaar / vragen / suggesties
Op gebouw in plaats van op adresnode getagde shops worden niet meegenomen in query
De verouderde tag url= wordt niet meegenomen in query
Denk aan onderscheid algemene website (brand) en filiaal (contact:website). Dit kan terug te zien zijn in URL’s als “utrecht.winkelketen.nl” of “winkelketen.nl/utrecht”
Er wordt geen onderscheid http en https gemaakt in query. Niet iedereen houdt rekening met https en je zou het meteen kunnen verbeteren
Fixme tag zou aanwijzing zijn voor sluiting / verhuizing
Bedrijven als Brezan, Bakker Bart, Subway, banken, verzekeringsinformatiepunten, loketten/stations NS e.d. worden niet meegenomen. Een aantal hiervan zitten ook gewoon in wikidata.
Overweeg het laaghangend fruit zelf te doen en voor de lastiger zaken toevoeging queries bij Osmose aan te vragen
@smootheFiets
Borishag onderhoudt Kruidvat en enkele andere ketens goed, maar de website=* tag wordt misbruikt voor de algemene pagina van de keten. Dit wil ik corrigeren.
Niet meer bestaande winkels verwijderen is een proces dat niet beïnvloed wordt door wat geschuif met tags. Ik kan wel de winkels met een note=* en fixme=* tag individueel bekijken voor mogelijk relevante informatie.
winkels die niet op adresnodes gemapt zijn corrigeren vereist wat meer aandacht en is iets wat sowieso één voor één gedaan moet worden, daarom laat ik dit express buiten beschouwing.
url=* en contact:website=* kan ik best meenemen in de query.
Ik ben sowieso alleen van plan om grotere ketens aan te pakken waarvan ik veel incorrecte website tags in Taginfo terug kan vinden. De rest kan ook zeker aangepakt worden, maar dat kan wellicht beter op individuele basis.
Mijn query was een voorbeeld. Ik kan makkelijk meerdere varianten van eenzelfde website in één query stoppen. Regular expressions snap ik (nog) niet, maar ook zonder die kennis kom ik best ver in Overpass.
Complexe situaties laat ik uiteraard links liggen zodat een meer lokale mapper hier een betere blik op kan werpen dan ik met mijn digitale bezem kan doen.
De meeste fouten komen enkele tientallen tot honderden keren voor. Tegen de tijd dat ik daarover overeenstemming met de beheerders van Osmose heb bereikt, heb ik ook de meeste van die tags al zelf verbeterd. Dat is waarom ik dit zo voorstel.
Ik denk dat deze fout zich veel vaker voordoet dan het door jou genoemde aantal.
Het kan voorkomen dat je tijdens je werk bepaalde “foute patronen” observeert die bijvoorbeeld óók kunnen optreden bij amenities, offices of parkeergarages. Het is bij klussen zoals die van jou altijd zinvol om opgedane kennis van bepaalde fouten te destillerren in een algemene query om die op te laten nemen in Osmose of een andere validator.
Die dien je in bij het betreffende project in (meestal) GitHub. En ja, er kan de nodige tijd overheen gaan voordat iemand zin heeft je verzoek aan te passen of genoeg stemmen / input van andere users heeft.
Omgekeerd is het zinvol om regelmatig een kijkje te nemen bij de issues die gelogd worden bij Omose/validators, misschien is er al een ticket aangemaakt voor het probleem wat jij op zou willen oplossen. In dat geval kun je erop stemmen en je opschoonactie even uitstellen.
Zoals ik de hele website issue van dit topic bekijk zou een nuttige validatorregelset als volgt kunnen zijn
ALS tag= (amenity OF company OF shop)
EN tag = (website OF url) bevat (subdomain OF path)
DAN toon waarschuwing "Tag "website" kan mogelijk verder gespecificeerd worden naar tag "contact:website" in combinatie met "brand:website" "
(Waarbij geldt subdomain = “http(s)://vestiging.bedrijf.nl” of path “https:www.bedrijf.nl/vestiging”) Ik hoop dat mijn pseudocode begrijpelijk en leesbaar is
Dan borg je namelijk dat - geheel automatisch - identieke issues buiten jouw opschoonwerk om ook inzichtelijk worden én in de toekomst afwijkingen ten opzichte van jouw voorstel gedetecteerd worden.
Gebruiker borishag reageert helaas niet (meer) op changesetcomments (ondanks herhaalde verzoeken hier ook uitleg te geven over zijn/haar standpunt) en is van mening dat hoe hij/zij website=* gebruikt correct is. Borishag lijkt ook een zekere mate van automatisering te gebruiken, waardoor wijzigingen door andere mappers (naar de filiaalpagina) weer rücksichtslos worden teruggezet bij wijzigingen in de openingstijden, maar brand:website (wanneer deze is ingesteld op de algemene website) laat hij/zij dan weer staan.
Om dit te laten slagen zou ik aanraden in ieder geval even contact zoeken met hem/haar over wat je gaat doen.
Voor Kruidvat kun je voor elk filiaal trouwens de filiaalpagina geautomatiseerd samenstellen door de al aanwezige ref=* te gebruiken:
@Tilia_J
Het algemene concept van websites van ketens die onder website=* getagd worden is zeker een groter en internationaal probleem, maar ik ben niet degene die Taginfo afgaat om Osmose aan te vullen. Ik fix liever de OSM data direct. Mijn plan is om aan een behapbaar aantal winkelketens in Nederland te werken waarvan ik dankzij Taginfo weet dat ze vaak foutief getagd zijn.
Als ik een goede website=* onder url=* of contact:website=* tegenkom zal ik deze zeker aanpassen, alsmede enige andere nuttige info die ik tegenkom in de tags.
@JeroenHoek
Zodra de discussie hier wat verder gevorderd is zal ik Borishag informeren, maar gezien zijn/haar gebrek aan medewerking en gemeenschapsgevoel met OSM ben ik niet van plan om hem/haar om toestemming te vragen, als je dat niet erg vindt.
Dankje voor de tip m.b.t. filiaalpagina’s. Ik weet niet of ik de vaardigheden heb om dit te doen, dus als iemand anders zich geroepen voelt is die bij deze van harte uitgenodigd om mee te helpen.
Ik hou deze discussie zeker nog even aan en ik ga nog niet tot actie over. Iedereen moet immers de tijd krijgen om te reageren als ze dit willen.
Oh nee, toestemming zeker niet. Maar er is wel een kans dat je in een edit-war terecht komt en de DWG moet ingrijpen. Dan is het zaak dat aan onze kant alles klopt. Het zou ook jammer zijn als borishag stopt, want de data is op zich prima los van deze incorrecte tags.
Ik kan wel even kijken of ik daar een changeset voor kan maken te zijner tijd. Kwestie van even een scriptje maken. Maar ik wacht de communicatie met borishag eerst af.
Ik ben begonnen aan een mechanical edit pagina voor m’n eigen OSM account. Het is nu nog een draft versie, dit wordt echt nog wel uitgewerkt met details zoals Overpass queries, maar geef vooral commentaar om de edits die hier uiteindelijk uit moeten rollen nog kwalitatiever te maken.
