Ik denk dat je ** use_sidepath** bedoelt
Naar mijn mening alleen als het fietspad niet apart op de kaart staat.
Staat het fietspad wel op de kaart dan zou ook brouter dat als route moeten herkennen en staat bicycle=no terecht op de hoofdweg.
Bij menige rondweg is er zelfs helemaal geen fietspad en moet de fietser door de bebouwde kom navigeren.
Het massaal omzetten naar bicycle=use_sidepath maakt de situatie nog erger omdat brouter dan gaat routeren over allerlei wegen waar toch echt geen fietser mag komen.
Nog even:
Ooit is hier op het forum in een discussie of meerdere discussies het volgende afgesproken:
- bij een C13, C14, C15 op de hoofdweg wordt het bicycle=no, resp. mofa=no, moped=no
- Als er bij het fietspad een G11 of G12a staat en geen C13, C14, C15 bij de hoofdweg wordt het bicycle=use_sidepath, mofa=use_sidepath, moped=use_sidepath Dit omdat bepaalde categoriën fietsers dan gebruik mogen maken van de hoofdweg. De fijne details heb ik niet paraat, maar het heeft iets met breedtes en zo te maken.
Onze specialist op het gebied van regels, multimodaal, kan daar vast meer over zeggen.
Even kort door de bocht… bij een verbodsbord bicycle=no. En zonder bord bicycle=use_sidepath. Wel voorzichtig ermee want voor je het weet routeert het niet meer.
Dit is ook naar mijn idee de correcte uitleg binnen OSM
Ik was er destijds niet bij betrokken, maar er is inderdaad een juridisch verschil tussen die twee situaties (expliciet fietsverbodsbord op de weg vs een naastgelegen fietspad -dat in RVV-perspectief tot dezelfde weg behoort):
Op een fiets als onderstaande (of een snellere liggende variant) mag je -als je het vlaggestokje dwars monteert ook op de rijbaan fietsen als er op het bijbehorende fietspad een bord G11 (verplicht fietspad) staat
Dit dankzij het vierde lid van artikel 5 RVV:
http://wetten.overheid.nl/BWBR0004825/2018-07-01#HoofdstukII_Paragraaf1_Artikel5
Door de rijbaan te taggen met [bicycle=use_sidepath] ipv [bicycle=no] kunnen routeerders hier dus onderscheid maken in profielen tussen gewone fietsen en bijvoorbeeld brede driewielige velomobielen: gewone fietsen worden dan -als het goed is- het fietspad opgestuurd, terwijl de velomobiel over de rijbaan wordt gerouteerd.
Daarnaast wordt met deze tag in OSM ook duidelijk dat de weg een naastgelegen fietsvoorziening heeft (die voor de verkeersregels als behorend tot dezelfde weg wordt gerekend).
ps ideetje voor op de racefiets om zonder boete op de rijbaan naast een G11 te kunnen fietsen?
paar zijwieltjes en twee fiberglasstokjes achter de zitbuis die normaal omhoog staan en die je opzij scharniert -eentje links, eentje rechts- als je de rijbaan op wilt.
Of gewoon 80cm naar links, dan houden auto’s wat afstand 
Ik ben het hier met Martin eens.
Hoewel Brouter ook mijn favoriete router is, lijkt deze hier toch niet helemaal goed om te gaan met de data:
Deze weg (oostelijk deel van Brechtzijde) heeft terecht een [bicycle=use_sidepath] vanwege het naastgelegen G12a-pad:
https://www.openstreetmap.org/way/7442034
Toch worden normale fietsen (trekking-profiel) over de rijbaan ipv het fietspad geleid:
Ik hoopte dat op te lossen in het routeringsplrofiel, door als experiment ook
|use_sidepath
toe te voegen aan deze regel
else not bicycle=private|no|dismount
Dat gaf na upload echter deze foutmelding
Ik heb in deze geen uitputtende kennis van de offline-bestanden onder de motorkap (wil me nog verder verdiepen in het offline-routeren), maar mijn beeld is dat Brouter in de extract die het van OSM-data maakt voor zijn routeringsdatabase (waarin veel data wordt samengevoegd of weggelaten voor ruimtebesparing) de tag use_sidepath weggooit (en kennelijk in de categorie “yes” veronderstelt, waarschijnlijk als een vorm van default in de routering bij het -na weggooien- ontbreken van informatie)
Nu is het negeren van obscure tags natuurlijk onvermijdelijk, maar in dit geval lijkt me het toch niet terecht:
Bicycle=use_sidepath is uitstekend gedocumenteerd, veel gebruikt (op meer dan 65.000 ways) en -in tegenstelling tot veel andere tags- ook met positief resultaat -met dank aan PeeWee32- het hele proposal-proces met stemming doorlopen vanwege het doortimmerde voorstel en aangetoonde nut:
Wiki
https://wiki.openstreetmap.org/wiki/Tag:bicycle%3Duse_sidepath
Proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/use_sidepath
Als tag is dit volgens mij as good as it gets.
Ik vind dat je bij gebruik van nieuwe tags op bestaande keys (dus in plaats van iets anders, ook als is het nog niet ingevuld -en des te meer bij omtaggen) zeker rekening moet houden met de vraag in hoeverre datagebruikers hiermee overweg kunnen.
Maar in dit geval lijkt de oplossing me toch veel meer te zitten om bij Brouter te vragen of ze deze tag correct kunnen gaan verwerken in hun routing in plaats van deze “tag voor gevorderden” t egaan vermijden ten faveure van een “no”.
Ik vermoed dat de maker van Brouter dat wel interessant kan vinden gelet op hun focus op fietsroutering, streven naar flexibele routing en profielen voor velomobiels.
Ik krijg de melding: “No valid JVM found to run JOSM.”
Weet iemand wat dit betekent? Ik vermoed dat JVM staat voor Java Virtual Manager maar daar ben ik nog niet veel mee opgeschoten.
Als je in een 64-bits Windows werkt, moet ook een 64-bits Java aanwezig zijn voor JOSM.
Ik heb van Java zowel de 32-bits als de 64-bits versie geïnstalleerd.
Verder kan de snelkoppeling op het bureaublad beschadigd zijn. Dan verwijst deze niet meer naar de juiste locatie van het bestand van JOSM.
H’m ik heb een 64 bits windows, 32 bits Java en draai JOSM lokaal geïnstalleerd… 
$ java -version
openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.3)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.3, mixed mode)
Voor zover ik weet is alles 64 bit op mijn systeem. Ik heb josm geïnstalleerd door “apt-get install josm” te gebruiken en dat leek goed te gaan.
$ which josm
/usr/bin/josm
Welke Ubuntu release gebruik je?
Gebruikt je de josm package uit Ubuntu, of uit de JOSM PPA?
Welke JREs zijn er geinstalleerd en welke is als default geconfigureerd?
De antwoorden zijn te vinden in de output van deze commando’s:
$ lsb_release -sd
$ apt-cache policy josm
$ ls -l /etc/alternatives/java
$ sudo update-java-alternatives -l
/usr/bin/josm is een simpel bash script wat de omgeving voor de JOSM opzet.
Het checked aan de hand van een lijst paden welke JRE geinstalleerd is, en geeft de voorkeur aan de via het alternatives systeem geconfigureerd is.
Mogelijk is Java in Ubuntu geupdate naar OpenJDK 11 (omdat dit de nieuwe LTS is), maar de josm package in Ubuntu niet, en heeft het alleen de lijst van JREs die destijds (toen Ubuntu de package uit Debian gesynced heeft) beschikbaar waren.
In Ubuntu worden de GIS & OSM packages niet actief onderhouden (daarom zitten ze in de universe repository) omdat helaas geen van de Ubuntu gebruikers zich geroepen voelt bij te dragen, kan je voor JOSM op Ubuntu beter de packages uit de PPA gebruiken, zie hiervoor:
https://josm.openstreetmap.de/wiki/Download#Ubuntu
Daarmee heb je ook altijd de meeste recente tested of latest snapshot.
Dat is duidelijk maar dan begrijp ik niet waar ‘het echte progamma’ zit en waarom ik dit binnenkreeg via apt-get.
Ik maak uit jouw verhaal op dat ik er niet omheen kan om de ppa-versie te gebruiken. Ik heb slechte ervaringen met een ander pakket waar ik elke dag de nieuwste fouten binnenkreeg maar ik kan het altijd nog uitschakelen (dan moet ik dat wel even uitzoeken) als dat nodig mocht zijn.
$ lsb_release -sd
Linux Mint 19 Tara
$ apt-cache policy josm
josm:
Geïnstalleerd: 0.0.svn13576+dfsg-3
Kandidaat: 0.0.svn13576+dfsg-3
Versietabel:
*** 0.0.svn13576+dfsg-3 500
500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
500 http://archive.ubuntu.com/ubuntu bionic/universe i386 Packages
100 /var/lib/dpkg/status
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 43 nov 7 11:01 /etc/alternatives/java -> /usr/lib/jvm/java-11-openjdk-amd64/bin/java
$ sudo update-java-alternatives -l
java-1.11.0-openjdk-amd64 1101 /usr/lib/jvm/java-1.11.0-openjdk-amd64
Volgens mij zijn de laatste twee niet helemaal hetzelfde.
Dat begreep ik ook niet bij het installeren wanneer nou het moment was dat de daadwerkelijke software werd binnen gehaald.
Overigens, ik heb het Ubuntu paket gewoon onder Debian draaien, ook via apt-get gewoon geinstalleerd, en werkt prima!
Ik heb trouwens voor updates wel alle sources aan staan (dus ook voor derde “niet open” partijen).
Sterker nog, ik heb Debian op een tablet draaien (Acer Iconia W700), alleen WiFi doet nog niet, anders had ik ook op locatie kunnen werken.
De code van JOSM zit in een JAR (/usr/share/josm/josm.jar), deze wordt gestart met java door het /usr/bin/josm script:
$JAVACMD $JAVA_OPTS -jar /usr/share/josm/josm.jar "$@"
Welk pad voor java wordt gebruikt is afhankelijk van welke JRE er eerder in het script is gevonden.
Het gebruik van meer dan een PPA is niet aan te raden omdat PPAs zelden op elkaar zijn afgestemd, zodra verschillende versies van dependencies in meerdere PPAs beschikbaar zijn is de kans op ellende groot.
De josm package heeft echter amper dependencies, alle dependencies zijn in de JAR opgenomen:
Depends: openjdk-11-jre | java11-runtime | openjdk-8-jre | java8-runtime,
proj-data
Recommends: openjfx
De eerste dependency is een van ondersteunde JREs, de tweede een data package for grid shift files t.b.v. ondersteuning voor andere projecties, en de openjfx recommends is voor MP3 support.
Support voor openjdk-11 is toegevoegd in josm (0.0.svn14163+dfsg-1) en deze is uitgebracht na de release van Ubuntu bionic.
Je kan de gewenste JRE specificeren in een environment variable:
JAVACMD=/usr/lib/jvm/java-11-openjdk-amd64/bin/java /usr/bin/josm
Het script zal dan niet de lijst van bekende JREs afgaan om te kijken welke beschikbaar is en in het alternatives system is geselecteerd.
Het eerste commando toont welke java executable in het alternatives system geselecteerd is, het tweede toont elke openjdk versies op het systeem beschikbaar zijn, dit kunnen er meer dan 1 zijn (op bepaalde systemen):
# update-java-alternatives -l
java-1.10.0-openjdk-amd64 1101 /usr/lib/jvm/java-1.10.0-openjdk-amd64
java-1.11.0-openjdk-amd64 1111 /usr/lib/jvm/java-1.11.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64
java-1.9.0-openjdk-amd64 1091 /usr/lib/jvm/java-1.9.0-openjdk-amd64
De meeste recente tested snapshot van josm is beschikbaar voor Debian stretch in de stretch-backports repository:
apt-get install -t stretch-backports josm
Het is over het algemeen onwenselijk om Ubuntu packages op Debian te installeren.
Ik ben weer even vanaf het begin opnieuw begonnen en kwam josm-tested.jar tegen. Downloaden, executierechten geven en aanklikken en JOSM draait. Ik weet niet waarom dat nu wel werkt maar het is in elk geval gelukt. Hartelijk bedankt voor alle hulp.
Volgens de makers van Josm is dit wel “wenselijk”.
Ze zeggen:
Niet volledig getest, enz, maar hier werkt het in die paar dagen dat ik het nu gebruik vooralsnog probleemloos.
Ik ben al lang blij dat ik niet in Spycrosoft hoef te werken :P.
De JOSM ontwikkelaars zijn Java developers, hun specialisatie is software ontwikkeling, niet packaging. Als Debian Developer is mijn specialisatie juist wel packaging. Aan jou de keus aan wiens woord je meer waarde hecht.
Zoals altijd in Open Source: If it breaks, you get to keep the pieces 
(edit) Nu ik dit bericht toch al heb geplaatst,
Waar vind ik de documentatie over de BAG-importtool?