Richtlijnen voor standaarvoorkeuzen

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

• The file format must be svg for lossless scaling. (Technically png is supported too but all preset icons are svg since August 2016.)
• The icon must be identifiable at a size of 16 pixels. This is the default size the icons are displayed in the Map View on standard dpi (not hidpi) screens.
• The license needs to be compatible with GPL3 (like PD or CC0). A good source for Icons is ​openclipart.org (all icons there are PD), ​publicdomainvectors.org (all icons CC0), ​freesvg.org (all icons CC0) or ​osm-icons.org (a lot are CC0). You can also check if JOSM already has a fitting unused icon in one of its icon folders: used icons and unused icons.
• If the tag applies to nodes, the icon in the MapView and the icon of the preset should be the same if possible. (It is not possible when different features use the same preset, e.g. crossing=island and crossing=traffic_signals have different icons, but are handled in only one preset "Pedestrian Crossing".)
• Icons with transparent background must not be only black or only white. Otherwise if one uses a black or white background (no aerial imagery as background) in the Map View black or white icons would be invisible. Workaround: if you want to use a black icon add a square white background to the icon instead of a transparent background or better use a white halo.
  Examples: Colored icons are preferred though.
• The icon should hide as less as possible in the mapview, so colourful icons with transparent background are preferred over black/white icons with square background.
• The icon should be understandable in all countries.
• Each preset should have its own icon and not borrow an existing icon from another preset so that you can know the tag from just seeing the icon in the mapview.
• To test your icon against these requirements within JOSM the mappaint style Icon tester (en) helps you.

Possible problems with svg in JOSM

Please check if the svg file correctly works within 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