Richtlijnen voor standaardvoorkeuzen

Deze pagina bevat ruwe richtlijnen voor de standaardvoorkeuzen​ en nieuwe pictogrammen.

Nieuwe tags en waarden

Controleer altijd eerst of er niet al een ticket is voor deze tag, bijv. door de zoekfunctie aan de rechterbovenkant van deze pagina te gebruiken.

We moeten er in de basis voor zorgen dat het menu Voorkeuzen niet te vol is, omdat het dan moeilijk zou worden om nuttige dingen voor "elke dag"-gebruik te vinden als we teveel exotische items hebben. Nieuwe tags en waarden zouden moeten hebben:

• een goede documentatie in de ​OSM-wiki
• goede aantallen voor gebruik (absolute en op aantal mappers)
• wereldwijd gebruik
• Controversiële gevallen (zoals contact:phone=* vs. phone=*) moeten geval voor geval worden bekeken.
• Als objecten slechts in kaart zijn gebracht door een handjevol specialisten, is het beter geschikt voor een externe voorkeuze. Gewoonlijk omvat dit schema's voor taggen die zijn beperkt tot één specifiek land, hobby, sport of beroep. In plaats van een eigen externe voorkeuze te maken zou u ook Presets/NewTags (en) uit kunnen breiden.

Opmerking:

• Het doel van de interne voorkeuze is om de tags en schema's voor taggen te ondersteunen die breed gedragen en gebruikt worden door de gemeenschap. Het is niet het doel om nieuwe tags of schema's voor taggen uit te vinden.
• Bij het onderzoeken ​taginfo, controleer ook waar ongebruikelijke waarden worden gebruikt.
• U kunt de Overpass API gebruiken om deze objecten in JOSM te laden en in de geschiedenis controleren wie ze gemaakt heeft.
• Bekijk ook ​dit voorbeeld om te zoeken naar de laatste bewerker van een specifieke tag.
• Een nuttig gereedschap om ook tags te controleren is ​taghistory. Als een tag bijvoorbeeld 50 keer per jaar globaal in kaart is gebracht, dan hebben we gewoonlijk geen voorkueze voor die tag nodig. U kunt nog altijd tags handmatig toevoegen via het dialoogvenster Tag toevoegen.
• Bij het aanpassen van de standaard voorkeuzen moeten waarschijnlijk ook hoofd kaarttekenstijl​ en misschien ook validator regels voor de consistentie worden gewijzigd.

Nieuwe pictogrammen

• De bestandsindeling moet svg zijn voor verliesloos op schaal brengen. (Technisch gezien wordt png ook ondersteund, maar vanaf augustus 2016 zijn alle pictogrammen voor voorkeuzen svg.)
• Het pictogram moet te identificeren zijn op een grootte van 16 pixels. Dit is de standaardgrootte waarop de pictogrammen worden weergegeven in de kaartweergave op standaard dpi (niet hidpi) schermen.
• De licentie moet compatibel zijn met GPL3 (zoals PD of CC0). Een goede bron voor pictogrammen is ​openclipart.org (alle pictogrammen daar zijn PD), ​publicdomainvectors.org (alle pictogrammen CC0), ​freesvg.org (alle pictogrammen CC0) of ​osm-icons.org (veel zijn CC0). U kunt ook controleren of JOSM al een passend niet gebruikt pictogram heeft in één van zijn mappen voor pictogrammen: gebruikte pictogrammen en niet-gebruikte pictogrammen.
• Als de tag van toepassing is op knopen, zouden, indien mogelijk, het pictogram in de kaartweergave en het pictogram van de voorkeuze hetzelfde moeten zijn. (Dit is niet mogelijk als verschillende objecten dezelfde voorkeuze gebruiken, bijv. crossing=island en crossing=traffic_signals hebben verschillend epictogrammen, maar worden in één voorkeuze afgehandeld "Pedestrian Crossing".)
• Pictogrammen met een transparante achtergrond moeten niet alleen zwart of alleen wit zijn. Anders zouden, als men een witte of zwarte achtergrond (geen luchtfoto als achtergrond) gebruikt in de kaartweergave, zwarte of witte pictogrammen niet zichtbaar zijn. Oplossing: als u een zwart pictogram wilt gebruiken, voeg dan een witte vierkante achtergrond toe aan het pictogram in plaats van een transparante achtergrond of beter nog: gebruik een witte halo.
  Voorbeelden: Gekleurde pictogrammen hebben echter de voorkeur.
• Het pictogram zou zo min mogelijk moeten bedekken in de kaartweergave, dus gekleurde pictogrammen met een transparante achtergrond hebben de voorkeur boven zwart/witte pictogrammen met een vierkante achtergrond.
• Het pictogram zou in alle landen moeten worden begrepen.
• Elke voorkeuze zou zijn eigen pictogram moeten hebben en geen bestaand pictogram moeten lenen uit een andere voorkeuze, zodat u de tag herkent door het zien van het pictogram in de kaartweergave.
• Testen van uw pictogram tegen deze vereisten in de JOSM kaarttekenstijl Icon tester (en) helpt u.

Mogelijke problemen met svg in JOSM

Controleer of het svg-bestand correct workt in JOSM.

• The base size of svg should be 16px or larger than 64px. Images with a base size between 16 and 64 px will not be scaled down to 16px.
• There are some svg libraries which do not work with JOSM (the images get deformed). If you have such a file try the following workaround: create a new svg document with Inkscape, copy the svg data to this new file, resize the page to the data and save.
• Resize your icon to 16px or an integer multiple size of it (not something like 458.1534) to avoid display inaccuracies due to rounding errors within java.
• Check the code of the file in a text editor. Search for viewBox value in the beginning of the file. If the icon is, for example, in 16x16 pixels, and if you made it in Inkscape (at least this happens in 0.91 version) and have defined in Document Properties 16,00000 by 16,00000 pixels, probably in the file code you have these values viewBox="0 0 16.000002 16.000001". Change it to viewBox="0 0 16 16" or you will have problems (see #12201 and the fix [o31865])
• svg icons are automatically cleaned up to reduce file size in the JOSM build. So there is no need to do this step manually before uploading svg files to svn. See comment:35:ticket:10479, comment:10:ticket:10877 and ticket:12201#comment:21 Uncleaned svgs are better for further editing.
• Due to a bug in svgcleaner however, the svg code shouldn't contain arguments starting with special characters in style codes e.g. -inkscape-font-specification:Sans;. This can lead to color changes (see #13158).
• If the icon includes gradients, the offset needs to increase at every stop, i.e. two stops with the same offset are not allowed, see ​svg salamander.
• CSS styles (<style type="text/css">) are not supported yet by svgSalamander.
• If possible don't use text elemets at all as this can lead to different display results based on e.g. os or installed fonts. To avoid this you can transform text into paths in the svg.
• Some of the named problems can be detected by executing this script​.

See also

• Starting point for these rules was ticket:10246#comment:14.

---

Back to Developers Guide (en)
Back to Main Help