even wat frustratie kwijt ..

Soms loop je toch wel tegen de beperking van OSM aan. Zo wil ik een printbare kaart renderen met de nadruk op fietspaden. Technisch geen punt. Maar dan besluit je om de wegen op lagere zoomnivo’s wat dikker aan te zetten, zoals gebruikelijk bij wegenkaarten … en worden allerlei plaatsen witte kluwens omdat de wegen in zo’n plaats helemaal niet op residential staan. Sterker nog, in Haren (gr) staan de woonwijken op unclassified en de doorgaande wegen op residential, precies omgekeerd aan wat je zou verwachten.
Mapnik maakt geen onderscheid dus in de standaard kaart ziet alles er prachtig uit …

Denkend aan een ander draadje hier waar ZMWandelaar en Martien Sch zich op het stylesheetpad willen begeven … weet waar je aan begint, het genereert werk!

Ik heb met de Garmin kaarten hier ook mee te maken. Op http://forum.openstreetmap.org/viewtopic.php?id=15544 heeft Peewee daar nog een vraag over gesteld hoe die highway=unclassified nu om te zetten binnen de bebouwde kom (landuse=residential) naar highway=residential maar tot nu toe hebben we daar nog geen oplossing voor gevonden.

Scriptmatig is het ook een onmogelijke taak denk ik. Want als het al lukt moet je na afloop de doorgaande wegen weer op unclassified zetten.
Overigens moeten routers hier toch ook tegenaan lopen? Die zouden in eerste instantie de voorkeur aan unclassified moeten geven en pas op het laatst naar residential gaan.
In het topic wat je aanhaalt ligt idd de nadruk op het manipuleren van de stylesheet voor Garmin, maar het onderliggend probleem haalt het niet weg natuurlijk.

Mij lijkt de enig werkbare oplossing het degelijke handwerk … helaas.

Die truc met mkgmap die je onderin het topic ziet maakt het ook mogelijk om de unclassified wegen binnen de bebouwde kom de routerende eigenschappen van residential te geven (een lagere road_class en road-speed). Ik heb ze alleen rood gekleurd om aan te geven dat het werkt. Helaas is me dat voor een groot gebied als Nederland niet gelukt vanwege de grote hoeveelheid data (JOSM loopt dan vast) dus het moet op een andere manier, ik kan me niet voorstellen dat dat niet geautomatiseerd kan (het kan namelijk met mkgmap ook), maar ik heb daar te weinig verstand van.

Ja, ik loop met mijn router en garmin-kaarten daar ontzettend tegen aan. Ik heb dat ook al vaker aanhangig gemaakt. en volgens mij is het ook wel mogelijk:
http://forum.openstreetmap.org/viewtopic.php?id=13734

Wat ik bedoelde was dat wegen die doorlopend zijn op unclassified zouden moeten blijven. Dus in bijvoorbeeld een dorp zou de hoofdweg unclassified moeten blijven en de overige wegen residential moeten worden, in overeenstemming de highway definitie. En daarvoor bestaat geen discriminerende tag. Dus het deel om unclassified binnen boundary=* naar residential om te zetten moet kunnen, maar hoe behoud je de unclassified die ook werkelijk als zodanig bedoeld zijn?

Dat zou handmatig aangepast moeten worden ja. Maar het gros van alle unclassifieds zijn residential dus de fout is kleiner dan dat ie nu is als het kan worden omgezet.
De vraag is of zo’n hoofdweg dan eigenlijk niet tertiary moet zijn ipv unclassfied.

Meestal wel lijkt me, maar het is helaas geen wetmatigheid. Er zijn ook dorpen/gehuchten waar de ene weg wel tertiary is en de andere unclassified.
Dus enige handarbeid zal er blijven.
Punt is natuurlijk … wat andere mappers er van zouden vinden. Want met zo’n omzetting beinvloed je ook hun werk.

Je kan zo’n script natuurlijk ook loslaten op de geofabrik extract ipv de OSM database, zodat andere mappers er geen last van hebben.

Daarom zou een weg ook volledig in landuse=residential moeten liggen. Wegen die daar buiten ook lopen zijn dan vaak doorgaande wegen. Teminste, ik heb dat in een paar gemeenten in mijn buurt handmatig gecontroleerd.

Dit is een typisch Nederlands begrip en vele soorten paden vallen eronder. De mapnik style is simpel, evenals de mkgmap style. Maar we willen dat er verschillen zichtbaar worden en dan wordt het ingewikkeld. We mappen wat we zien en veelal zijn er meerdere interpretaties mogelijk.

Wat is het verschil tussen: highway=track, surface=gravel en highway=track, surface=gravel, tracktype=grade3?

Hoe renderen we: highway=path, bicyle=yes, foot=yes, surface=grass, trail_visiblity=bad?

Wat is een halfverharde weg?

Moeten we highway=service anders renderen dan highway=service, surface=gravel?

Dit zijn allemaal vragen waaover je moet nadenken om tot een betrouwbare kaart te komen. Het kost vele uren tijd.

Dat ligt het meest voor de hand. Dan zelf corrigeren vooor het hele land … En daaruit uiteindelijk een changeset extraheren waarbij je de wegen die van unclassified naar residential zijn gegaan in de OSM database injecteert. Pfff, zoveel vrije tijd heb ik nou ook weer niet.

Klopt Mattheus. Maar dat zijn persoonlijke keuzes, het gaat me niet om Mapnik. Ik render bijvoorbeeld fietspaden als rode lijn, tracktype 4/5 als rode dash, tracktype 3 als oranje dash en tracktype 4/5 als oranje dot. Tenzij verboden voor fietsen, dan wordt het bruin ( zeldzaam ). In mijn eigen kaart dus… een ander zal het anders willen doen. .
En dan renderen, omzetten naar Orux, beoordelen op de telefoon, printen en beoordelen op papier … yep , arbeidsintensief.
Het eindresultaat is gewoon voor eigen gebruik, alhoewel je het natuurlijk ook beschikbaar kunt stellen, zoals Ligfietser doet. En waaruit weer mensen hun eigen typefile maken.

Waar je tegen aan loopt is dat de database helemaal niet zo compleet en precies is als we denken. Dat zie je niet in Mapnik, maar als je besluit een andere weergave te kiezen dan komt het tevoorschijn. Zo wilde ik surface=gravel | surface=shell anders renderen. Maar in mijn proefgebied bleken die tags niet toegevoegd. Nou is dat niet halsbrekend. Maar de fouten in residential/unclassified vind ik wel storend.

Het woord ‘proefgebied’ is een valkuil. Want heb je alle oplossingen sluitend gemaakt en je tevreden gaat achteroverleunen in je stoel, denk je een goede kaart te hebben. Tot je in een ander gebied komt, waar de oplossingen absoluut niet sluitend zijn.

In mijn opmerkingen had ik enkele voorbeelden gezet die in Duitsland voorkomen. Het voorbeeld van highway=track, surface=gravel, tracktype=grade3 was voor mij een teleurstellend fietspad. Er was vrijwel geen ‘gravel’ te bekennen. Ik trof er wel veel grond, plassen en vriendelijk zwaaiende boeren aan die op dat pad prima konden rijden met hun tractoren. Het gaat hier om een ANWB fietsroute. Een weergave als halfverhard pad was een beetje overdreven en wekte te hoge verwachtingen.

In mijn aangepaste stylesheet laat ik grade2 renderen als halfverhard pad en grade3 en lager als gewoon (onverhard) pad. Dat er fouten worden gemaakt bij het taggen, is vrij logisch. We zijn allemaal amateurs die proberen zo goed mogelijk te mappen. Helaas zijn sommigen wegen/paden op meerdere manieren te taggen. Ik ken enkele fietspaden die ook toegangspad zijn (voor de boeren die daar hun grond aan hebben liggen). Er staat een duidelijk bord bij: Fietspad (met daaronder de tekst, toegang vrij voor aanwonenden, o.i.d.). Dit betreft veelal fietspaden die met Europese subsidie zijn aangelegd. Het oorspronkelijke pad was een onverhard toegangspad. Als de boer ermee instemde dat het een fietspad werd, kreeg hij een mooi verhard pad ervoor terug. Het is echter wel officieel een fietspad geworden.

Dit probleem met die unclassified wegen betreft al snel vele recreatieve kaarten. De mooie kleine achterafweggetjes moeten de voorkeur krijgen boven de hoofdwegen. Probleem is dat hij vervolgens juist door de woonwijken gaat navigeren :(.

Proefgebied voor mij, om te zien of ik een helder beeld op mijn telefoon kan krijgen. En een gebied dat ik goed ken, dus snel kan zien of mijn rendering deugt.

Tracktype is ook een ongelukkige tag. Neem het fietspad aan de oostzijde van de A28 langs Sassenhein. Halverwege is dat geen asfalt maar een grade1 track … of wel een fietspad maar dan met tracktype grade1 ?