Me viel op dat veel wegen uit losse stukjes bestaan en dat ieder stukje’s naam gerenderd wordt. Zoals hier:
waarbij ik alle stukjes Casinoweg heb samengevoegd tot één weg en de Kruisbekweg uit losse stukjes bestaat.
Ik vind dat de kaart veel rustiger wordt als niet honderdduizend namen worden weergegeven.
Nu vraag ik me af of ik geen script kan laten runnen of zo iets of dit allemaal handmatig ga doen. In Venlo heb ik al wat gedaan, oplettende dat ik geen busroutes e.d. verziek. Kan dit met een mechanical edit?
<---- sick
Mooi streven…maar,…die kleine stukjes met die aparte namen zijn nog een erfenis uit het AND - tijdperk. Wanneer de wegen dezelfde kenmerken hebben kun je ze gewoon samenvoegen, maar met een mechanical edit zie ik wel leeuwen en beren. Sommige stukken hebben cycleway=lane of een andere max. snelheid, de richting van de weg waardoor de roles backward en forward door elkaar gaan. Josm wil al dat de richting dezelfde kant uit loopt bij samenvoegen. Ben benieuwd wat er dan gebeurt met oneway=-1
Daar moet je dus al op letten lijkt mij als je al “gewoon” in JOSM samenvoegt.
Niet doen!
En zeker niet mechanisch.
Mijn eerste beginnersfout was het samenvoegen van wegstukjes.
Kreeg al snel op mijn falie: wat bleek: onderliggende routerelaties (fiets, wandel, bus, mtb etc) die juist vaak maar een stukje van die weg pakken raakten volledig gecorrumpeerd.
Samenvoegen kan je dus alleen doen als alle tags, links en rechts van de gemeenschappelijke node gelijk zijn (wegklassen, wegdek, helling etc.) en er geen routerelaties aan de weg vast zitten.
Wat je wel kunt doen is bijvoorbeeld op een klein stukje weg dat een brug vormt de naam weglaten voor een rustiger kaartbeeld.
Martin
Op elke kruising knip ik bewust de weg!
En vlakbij de kruising op elke weg een punt.
Dit om de zaak goed uit te lijnen.
Het is een taak van de render op de namen erop te zetten.
Als er teveel namen staan, moet je de vraag bij OSM carto neerleggen.
Leg eens uit waarom je de weg moet opknippen om uit te lijnen?
Ik onderschrijf de wens van Kogacarlo. maar…
Mijns inziens moet het mogelijk zijn om dit mechanisch te doen waarbij we met dit soort gegevens rekening moeten houden.
Opknippen gebeurt ook omdat mappers (zoals ik) soms een stuk weg opknippen omdat we een key/value willen toevoegen voor een deel van de weg. (bv surface=asphalt) Dat komt weer omdat je bv al fietsend afslaat en niet zeker weet dat deze key/value ook geldt voor het gehele resterende stuk weg waar je niet hebt gefietst. Als ik (of iemand anders) later constateer dat dit resterende deel ook een surface =asphalt moet krijgen dan hebben we 2 losse stukken weg die eigenlijk prima samengevoegd zouden kunnen worden (even afgezien van een mogelijke routerelatie.
Ik zou het dus toejuichen als hier een oplossing voor zou komen.
Wanneer je ondergrond hebt, zie je even verderop het straatbeeld (10-15 meter), tussen stoeprand en stoeprand, is het midden van de weg beter te zien, te bepalen, daar zet ik een node. Deze is correcter te plaatsen. Dat doe ik bij een T splitsing op de drie toekomende wegen. Dan knip ik midden op de kruising en kan de node zo schuiven dat goed ligt.
Wil je de kruisingsnode, wanneer deze niet geknipt is goed leggen, dan is dat vele malen lastiger.
Vooral bij wegen, waar de wegen niet haaks op elkaar staan. En dat zijn er nogal, wat in Nederland. Er vaak sprake van net een ander hoekje dan 90°.
Maar je kunt toch ook in een highway een extra node zetten, zonder de HW te knippen en daarmee de gewenste bocht/oriëntatie verwezenlijken? Je behoeft dan toch niet twee separate highways (met identieke tags) te creëren?
Hebben we in deze discussie last van begripsverwarring?
Ander bijkomende zaak is als andere de weg verschuiven door, wat ze ook aan het doen zijn, dan is alleen op de kruising een klein verschil.
Dat heb ik dan al vaker meegemaakt, nu moest ik alleen een kleiner stukje straat weer recht leggen en zag ik ook eerder, waar de fout vandaan kwam. Fouten worden niet zo groot.
Je zou natuurlijk ook kunnen besluiten om van een weg waarvan je alleen bij het langsrijden maar een heel klein stukje gezien hebt, de surface-tag niet te plaatsen of aan te passen? Veel informatie mis je niet, toch?
Of op die 10(?) meter geen name te plaatsen natuurlijk 
Maar ik kan het mis hebben…
Ik stoor me ook wel eens aan al die opgeknipte stukjes weg, als ik ze tegen kom plak ik ze aan elkaar. Als er met een mechanische edit iets aan gedaan kan worden dan graag.
Uiteraard moet er niet worden samengevoegd als de tags niet voor 100% overeenkomen. Een uitzondering hier op is dat de richting van de weg omgekeerd mag worden als er geen richtinggevoelige tags in het spel zijn.
Een ander probleem dat ik zie is wanneer er meer dan twee identieke wegen bij elkaar komen. Bijvooorbeeld hier. In dat geval zou ik de twee doorgaande wegen aan elkaar plakken
Dit lijkt mij onmogelijk te automatiseren, dus ik stel voor situaties waarin er meer dan twee identieke wegen samenkomen uit te sluiten van een mechanische edit.
We zouden ook kunnen besluiten tot een semi geautomatiseerd proces, waarbij we gelijk de andere problemen met de AND data oplossen door de wegen mbv luchtfoto’s te recht te leggen en waar nodig highway=unclassified te veranderen in highway=residential.
Ik ben echter niet goed op de hoogte wat technisch mogelijk en haalbaar is, dus misschien kan iemand daar een toelichting op geven?
Het grappige is dan wel, dat een andere zeer actieve mapper straten weer opknipt met als commentaar “Meer detaillering in het stratenverloop” en zo blijf je bezig 
Persoonlijk vind ik het als ik een route aan in het leggen ben, wel prettig als een weg in losse stukjes verdeeld is. Maar als stukjes wegen compleet gelijk zijn, kun je vaak net zo goed doorverbinden, zeker als het splitspunt ergens tussen zijwegen in ligt. Wat ook ergerlijk is, wegen in woonwijken, die wel in tich stukjes verdeeld zijn zonder enige noodzaak en vaak ook nog met tegengestelde richting.
Maar voor “Meer detaillering in het stratenverloop” zetten we toch gewoon een extra node en ‘knippen’ we toch niet.
Of begrijp ik het even niet?
Precies. Dat knippen snap ik niet.
Op zich zou een “overkoepelende oplossing” inderdaad zijn dat de renderaar de naam niet drie keer rendert als de weg overgaat van asfalt naar zand en terug naar asfalt. Dat moet toch in de software te bouwen zijn.
Daarnaast gebruik ik JOSM als trackdesigner, dan heb ik behoefte aan om alle stukken weg zo uit OSM te halen.
Even een voorbeeld. Een provinciale weg van 10 KM lang met een fietspad ernaast. Ik rij de eerste 5 KM en registreer dat alles asfalt is. Daarna sla ik rechtsaf een andere weg in. Thuisgekomen zie ik dat er geen surface tag is en ook het fietspad 10KM lang is. Dan knip ik dat fietpad op omdat de volgende 5 KM niet met zekerheid ook asfalt is. Als later blijkt dat die andere 5 KM ook asfalt is en ook zo wordt getagt hebben we een identieke weg maar wel opgeknipt in delen. Dat zou m.i. samengevoegd mogen worden.
Denk dan dat je iets te voorzichtig bent. In die situatie durf ik het aan om de hele weg als asfalt te taggen. Als je ziet dat een weg als 1 doorlopend stuk door een dorpskern gaat of door bosgebied kun je wat voorzichter zijn aangezien het dan aannemelijk is dat er ergens 30x30 tegels opduiken of in een verhard zandpad onder je wielen komen.
Met een beetje geluk zijn er nog Mapillary beelden van de rest van de weg of bij een paar kruisingen om te bevestigen dat het nog steeds asfalt is.
Mochten er halverwege een paar meter tegels zijn omdat ze daar een leiding oid ingegraven hebben ga ik dat stukje er ook niet uitknippen. Met het eerstvolgende vernieuwing of nadat de grond voldoende is ingeklonken komt er dan vast gewoon weer asfalt overheen. Dat zijn gewoon tijdelijke dingetjes.
Misschien ben ik wat te voorzichtig en een afwijkend stukje surface van 10 meter ga ik ook niet aanpassen. Dit was even een voorbeeld van hoe het kan dat aansluitende wegdelen identiek getagd zijn. Dat kan beter denk ik dan 
Ik ben zelfs zo lomp dat als ik in een stad op een wijkonstluitingsweg een bordje “zone 30” naast me zie (rechts de wijk in dus) dat ik rucksichtlos die hele wijk als maxspeed=30 tag en er van uit ga dat idd die hele wijk 30-zone is
Zeg maar op dit straatbeeld durf ik er vanuit te gaan dat al die wegen die nu nog zonder maxspeed zijn wel zone 30 zijn, als ik ergens aan de rand van zo’n blok een bord zie staan is dat genoeg voor mij.
Ik ga dan ook niet het hele blok doorlopen om er achter te komen of er niet stiekem een woonerf in zit. En zo ga ik ook met andere dingen om. Waar gehakt wordt vallen spaanders.
Overigens zag ik vandaag een geneste 30 km/h-zone: ik was al een bordje 30 km-zone voorbijgereden toen ik er nog een in reed
Helemaal mee eens, bij het invoeren van routenetwerkwerken (wat toch al behoorlijk arbeidsintensief is) ben je soms eerst al flink bezig om de boel op te knippen.
Of dat betekent dat alles maar van weg tot weg losgeknipt zou moeten worden weet ik niet, maar het zou wel consequenter zijn.
Nu zijn wegen soms heel langs en soms niet, terwijl het enige verschik soms niet zozeer eigenschappen van de weg zelf zijn, maar de routes/netwerken waartoe ze behoren of de voorkeur van de mapper in kwestie.
Het eerder aangehaalde voorbeeld om een bepaald wegdeel/brug geen naam te geven vanwege het kaartbeeld vind ik eigenlijk wel te ver gaan: het probleem van een te druk kaartbeeld is een probleem van rendering en zou daar moeten worden opgelost. Om dan maar de naam te verwijderen is vorm van “untagging for the renderer” waarbij de database minder correct/compleet wordt met het oog op rendering.