Ook dat weer render i.p.v. database entry-problemen toch ?
Je kunt dit volgens mij niet op de renderer afschuiven. De renderer heeft niet de benodigde informatie om een behoorlijke keuze te maken welke naam op de kaart thuishoort. Dat lijkt me nu juist iets waar wij als mappers een intelligente keuze in moeten maken.
En ja, de on the ground rule is mooi, maar betekent niet dat we alles letterlijk maar zo moeten overnemen wat de eigenaar uit marketingoverwegingen op de gevel kalkt. Als ik een winkel begin met een bord 
Willem’s 
{{{SUPER}}}duper 
GPS 
ShoP , dan hoop ik toch dat er een mapper zijn/haar gezond verstand gebruikt en die emojirommel weghaalt in plaats van dit één op één over te nemen in de name-tag.
3 Likes
Breder. Ook iemand die in, bijvoorbeeld, OsmAnd een lijst van winkels in de buurt opvraagt krijgt die schreeuwer erin. Het werkt op veel niveaus door.
Correct, maar wel de weergave grootte daarvan en dus weer render probleem toch ?
Die filter is er al bij de editors hier want ik ben ze op OSM niet tegengekomen, slecht voorbeeld daardoor toch ?
Lijstje ook weer slecht voorbeeld want we zijn bezig met database entries… Hoe de lijst er uit gaat zien laat ik bij de lijst-software makers (op caps zoeken en aangepast weer laten geven bijvoorbeeld) en daardoor een unimforme lijstweergave creëren. Eigenlijk precies hoe krantenartikelen werken.
Want dan is de inhoud van in dit geval een lijstje belangrijker dan hoe bepaalde info op die lijst weergegeven wordt van belang.
Een lijst heeft daardoor niets met op OSM opgeslagen data te maken, toch ?
Wetgeving, artikel 2 16 en 17
Is niet toepasbaar op de OSM-database immers:
- Namen kunnen buitenlandse namen zijn die niet vallen onder Nederlandse regels.
- Teksten zijn niet te vergelijken met singel OSM-entry database items.
En ik mag aannemen dat als database entries in teksten verwerkt wordt dit net als in kranten artikelen aangepast worden om zodoende de nadruk te leggen op de tekst inhoud in plaats van de tekst weergave. Toch ?
Recap zoals ik het zie: database entries invoeren zoals in het veld zichtbaar en als je de database-entries in lijstjes, kaarten ,artikelen wil weergeven dan regels toe laten passen op die entries zodat voor die toepassingen de weergave niet verstorend werkt.
Wetgeving over spelling is hier totaal irrelevant. Namen mogen immers ook (bewuste) spelfouten bevatten. Dit is een stijlkwestie.
Uitstekend voorbeeld, want als je daar wel een grens trekt, is er dus blijkbaar wel behoefte aan een stijlregel. Je kan die naam met emoji zonder meer in name=* invoeren.
Dit gaat in eerste instantie om datakwaliteit en consistentie. Omdat je de vrijheid van naamskeuze niet te veel wil beperken is zo’n stijlregel iets wat kan wringen, maar de essentie van een naam verandert doorgaans niet door het toepassen van regels omtrent hoofdletters.
Vanuit de render-/opmaakkant kun je deze stijlregel niet zomaar toepassen, omdat alleen de mapper weet of iets klopt qua hoofdletters (ANWB Winkel) of niet (ICI PARIS XL). In de tags ontbreekt die kennis.
En de praktijk wijst uit:
- Zijn niet in het veld te vinden
- Als bijv. VOMAR een gevel bedrukt met reclame uitingen alleen de naam VOMAR terug te vinden is in OSM als name.
Dit is voor mij de reden om voor de eerste optie te kiezen. En dan niet naar het logo of de gevel kijken, maar hoe ze zichzelf in een tekst noemen. Dus wel HEMA en ALDI in hoofdletters, en Xenos en Lidl niet.
2 Likes
Over mappen/taggen voor de renderer
We mappen toepasbare kaartinformatie, dus dat is hoofdzakelijk voor renderen + zoeken, en routeren + navigeren inclusief allerlei soorten voorgerouteerde routes, en datatoepassingen gekoppeld aan de hoofdtoepassingen.
De harde regel is om niet te mappen en taggen om te zorgen dat één bepaald programma of stijl het naar jouw idee mooi weergeeft.
Maar we moeten wel zorgen dat onze mapping bruikbaar is voor renderers, routers/navigaties en datatoepassingen. In die zin mappen we dus altijd ook voor de toepassingen, waarbij de rendering er het meest uitspringt omdat alles om de kaart/geografie draait.
Toegepast op dit kapitalenprobleem: Voor renderers, routeerders etc maakt het technisch gezien niets uit. Ik heb niet het idee dat renderers in het algemeen vormen van capitalisatie toepassen op de labels. Het is een kwestie van stijl en voorkeur, en de tagging bepaalt hoe het eruit ziet bij de bulk van de renderers. Over stijlvoorkeuren valt altijd te twisten, en dat zien we nu ook gebeuren, met de meest wauwse argumenten!
Wat willen de tegenstanders van hoofdlettergebruik eigenlijk omtaggen:
- Alleen all-caps-namen (bijv. HEMA, SPAR en NAVO)
- Ook creatief hoofdlettergebruik (bijv. TinQ, KiK en ArenA)
Dit onderscheid wordt namelijk niet gemaakt in de peiling, maar ik lees in de commentaren dat dit onderscheid wel wordt gemaakt.
Voor CamelCase toestaan lijkt wel iedereen te zijn.
Ja, waarschijnlijk had ik dit beter buiten de poll gehouden, ik vraag me af of het een duidelijk verschil had gemaakt in de resultaten.
Ik vindt creatief hoofdlettergebruik nog wel kunnen maar niet echt logisch als je voor de rest de keus maakt hoofdletter+kleine letters aan houdt.
Waarom is creatief hoofdlettergebruik toestaan niet logisch? Het is toch niet schreeuwerig? Die scheeuwerigheid lijkt het belangrijkste argument tegen all-caps-namen te zijn.
Ik vind korte hoofdletternamen (afkorting of letterwoord, maakt niet uit) helemaal niet schreeuwerig of hinderlijk. Waarmee ik nog steeds geen standpunt inneem in deze dicussie, ik vind het alleen geen argument voor het een of het ander.
Ik weet niet of men nog zit te wachten op extra meningen, maar voor de liefhebber:
In eerste instantie vind ik dat bedrijven lekker hun eigen naam mogen kiezen, daar hoeven wij niet vervolgens politieagentje over te gaan spelen.
Daar wil ik wel de nuance in aanbrengen dat als er op een gevel iets in hoofdletters geschreven is, ik er niet automatisch vanuit ga dat dat dus overal zo toegepast moet worden. (Ik schrijf mijn naam ook wel eens met hoofdletters op een naamkaartje t.b.v. de leesbaarheid, maar dat maakt niet dat ik dat overal doe).
Als een bedrijf er echter voor kiest om consistent overal hoofdletters te gebruiken, zoals de HEMA en ALDI bijvoorbeeld doen, dan moeten wij dat ook overnemen vind ik.
Als je dat lelijk vindt moet je daar aankloppen, maar niet de kaart gaan aanpassen m.i.
12 Likes
Jouw inbreng wordt net zo goed gewaardeerd als die van ieder ander.
Met 5 duimen omhoog in 2 uur lijkt dit me een populair standpunt. Daar wil ik me best aan conformeren.
1 Like
Precies! Het gaat erom hoe de naam in lopende tekst wordt geschreven, niet op het bord. Dat is ook hoe je op HEMA, SPAR, TinQ, etc. komt.
We nemen niet alle typografische kenmerken van een logo over, dus geen all-caps, plaatsing van letters in vreemde richtingen, emoji’s, etc. Dat wordt wel gesuggereerd in sommige reacties, maar het is niet de achtergrond van namen als HEMA.
Helaas is de stemming opgesteld door een tegenstander van hoofdlettergebruik. Daarbij is de aanpassing van de schrijfwijze aan de spellingsregels uitvoerig beschreven, terwijl de schrijfwijze volgens de on the ground rule (foutief) is gereduceerd tot “Of wat op borden te vinden is.”
1 Like