Rendering rotondes (was: Probleem met NAP route (LF9))

ZMWandelaar · 2010-11-27T16:31:06.000Z

Dit is inderdaad een interessant probleem.

Eerste even de twee uitgangspunten van mijn analyse:
1- http://tile.openstreetmap.nl/?zoom=18&lat=52.25709&lon=5.59039&layers=B000000FFFF Putten
2- http://tile.openstreetmap.nl/?zoom=18&lat=52.1696&lon=5.39063&layers=B000000FFFF Amersfoort

Als ik goed kijk staat 1 beter op de kaart dan 2. De rotonde 1 is ronder dan 2. Verder kunnen we in JOSM constateren dat de rotondes in Putten zijn opgebouwd uit een veelvoud aan nodes dan het aantal op de rotonde van Amersfoort. Deze bestaat namelijk uit 9 nodes.

Kijken we echter op de Garmin kaarten van Lambertus en wellicht ook van Ligfietser (niet gecontroleerd) dan moet ik toegeven dat de beoordeling andersom gegeven moet worden. De rotonde in Amersfoort ziet ronder dan het zooitje in Putten.

Concluderend kan ik twee dingen stellen:

Wanneer de mapper een rotonde uitvoert met een beperkt aantal nodes, dan is de kans dat deze op de huidige Garmin kaarten acceptabel worden afgebeeld groter.
De huidige routines voor het vertalen van OSM data naar Garminkaarten met betrekking tot rotondes zijn niet optimaal.

Aanbeveling:
Ik denk dat dit probleem opgelost kan worden om naar een oplossing te zoeken binnen het maken van de Garmin kaarten. de huidig gebruikte filtering van nodes binnen rotondes moet aangepast worden.

ligfietser · 2010-11-27T16:50:44.000Z

De rotondes op de Garmin kaarten van Lambertus en die van mij zien er identiek uit. Ik vraag me af wat trouwens het nut is van zoveel nodes, dat neemt alleen extra ruimte in beslag en vertraagt de opbouw van de kaart. Aanbeveling: gebruik zo min mogelijk nodes dan noodzakelijk, die rotonde in Amersfoort ziet er rond genoeg uit en heeft maar 10 nodes, 8 zou ook nog wel kunnen volstaan.

ZMWandelaar · 2010-11-27T18:55:18.000Z

De reden waarom ik meer nodes gebruik is dat het er beter en natuurlijker uit ziet. Wanneer de routine van jullie kaart goed zou zijn, dan zou het resultaat gelijk moeten zijn als wanneer ik nu naar JOSM ga en om de andere node er een verwijder.
Door zo te doen zal ik nooit zo’n zooitje maken als er nu van is gemaakt op de Garmin kaarten.
Het lijkt net of er nodes zijn verplaatst tijdens het filteren. Zo’n kartelrand is toch gek zoals die zichtbaak is bij de rotonde van de Nijkerkerstraat/van Gheenstraat?
Kun jij die kartels verklaren?

ZMWandelaar

fsteggink · 2010-11-27T19:37:45.000Z

De enige verklaring die ik zou kunnen verzinnen is dat er sprake is van afronding op X decimalen achter de komma. Bij 8 nodes valt het niet zo op, maar als je heel veel nodes hebt, dan juist wel. Door de afronding krijg je feitelijk een soort van grid. Met de afronding wordt een node “verplaatst” naar een gridpunt.

fsteggink · 2010-11-27T19:38:15.000Z

De afronding kan met het bestandsformaat van Garmin te maken hebben.

ZMWandelaar · 2010-11-28T10:28:45.000Z

Dan stel ik voor om niet meer af te ronden. Ik heb getest maar Garmin vind het niet erg om 10 cijfers achter de komma terug te krijgen. Grid is niet erg, maar je moet hem wel werkbaar klein houden.
Weten we wat het kleinste grid/afronding is die Garmin aan kan?

Zal het vanavond testen.

ligfietser · 2010-11-28T10:38:34.000Z

Ik denk dat Frank gelijk heeft, je zou eens de bewuste Garmin tile kunnen editten met GPSmapedit. Dan zie je dat het grid van Garmin niet zo fijnmazig is dat al die nodes netjes op het cirkeltje passen. Ik kan het niet in getallen uitdrukken, misschien dat er Garmin experts op het gps.nl forum van Waypoint zijn die dat weten.

ligfietser · 2010-11-30T14:43:32.000Z

Ik heb het even nagevraagd op het mkgmap forum, ipv antwoord te geven op mijn vraag is er iemand die de rotonde heeft aangepakt. :-/
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07468.html

De rotonde ziet er nou zo uit op Garmin Basecamp:

ZMWandelaar · 2010-11-30T19:15:00.000Z

Mee eens. Er waren wat te veel nodes. Ik ga mijn referentie verleggen van “in schaal 1:6+ geen halveringsplustekens meer” naar “in schaal 1:16+ geen halveringsplustekens meer”.

Helaas ben ik soms toch wat muggezifterig. wanneer ik naar de prachtige circels in JOSm kijk en ik zie het armezielige resultaat als rendering, dan schieten toch echt de tranen in mijn ogen. Dan heb ik plaatsvervangende schaamte voor het programma die dit heeft durven maken.

Hahaha, ik ben weer lekker aan het overdrijven.

Maar zeg nou zelf. Als je de twee circels met elkaar vergelijk dan mag je het daar als programmamaker toch niet tevreden mee zijn?

ZMWandelaar

fsteggink · 2010-11-30T21:47:31.000Z

Een GPS is geen volwaardige PC, dus als het reduceren van de nauwkeurigheid ervoor zorgt dat je meer data in je geheugen kwijt kunt, is dat acceptabel. Als programmeur zou ik het uiteraard wel jammer vinden dat het nodig is om bepaalde keuzes te maken, maar als het me lukt, ondanks de beperkingen, zou ik er wel tevreden mee zijn.

Ik ken het Garmin IMG formaat niet (heb wel een keer de gereversed-engineerde specs vluchtig bekeken), maar ik kan me wel voorstellen dat als het wel mogelijk is de resolutie te verhogen (ken mkgmap ook niet goed genoeg), dan betekent dit wel dat de bestandsgrootte omhoog gaat. Gevolg, langere downloadtijd, langere uploadtijd naar je GPS, en je geheugenkaart zit veel eerder vol.

Als ik een GPS gebruik, zit ik niet uren te staren om te bewonderen hoe rond de rotonde is. Niet echt lekker met een gevoelstemperatuur van -15. Het is ook niet noodzakelijk dat een rotonde precies rond is.

ZMWandelaar · 2010-12-01T07:54:10.000Z

Nou, Frank, dat moet je niet zeggen.

's Zomers kan ik toch best tijdens een rustpauze verliefd en bewonderend naar mijn Oragon staren en dan zijn mooie ‘rondingen’ altijd leuk.
Als mijn vrouws rondingen “Kartels” hadden, dan was dat ook niet zo aanterekkelijk dan ze nu zijn.
Waar of niet?

ligfietser · 2010-12-01T20:54:45.000Z

Hier nog een antwoord van de mkgmappers:

Do you have any roundabouts that look better?

I suppose that the “low” precision garmin coordinates are the reason for
this. I cannot give precise values but I think I remeber that the
precision is sometimes less than 4 meters which means two distinct
points have at least a distance of 4 meters. Otherwise they are mapped
to the same coordinate.

Have fun!
WanMil

ZMWandelaar · 2010-12-02T07:36:02.000Z

Helaas verklaart dat nog niet de rare bochten en ‘kartels’ in de circels.

Ik heb voor de gein de twee afdrukken eens op een transparant afgedrukt en over elkaar heen gelegd. Geconstateerd dat hij punten wegfiltert, maar ook dat hij andere punten lijkt te verplaatsen. Of worden meer punten die dicht bij elkaar liggen soms “gemiddeld”. Dat zou een verklaring kunnen zijn. Wel is dat dan een ‘verkeerde’ manier van omgaan met “teveel informatie”. en kunnen ze beter echt filteren.

groet
Robert

ligfietser · 2010-12-02T08:35:49.000Z

Ik denk dat het middelen van clusters tot bepaalde punten, waar vervolgens lijntjes tussen worden getrokken (het is immers een vector kaart) de oorzaak zijn tot deze afwijkingen. Kijk maar ook naar andere Garmin kaarten, de lijnen zijn nergens vloeiend, altijd hoekig. De kunst van het maken van een kaart is ook de kunst van het weglaten.

ZMWandelaar · 2010-12-02T10:54:38.000Z

En dat is een routine die in mkgmap ligt ingebakken? of heeft de kaartenmaker (wij) daar invloed op?

Het lijkt mij zo simpel om bij het voorkomen van 3 geschakelde nodes de middelste weg te laten, ipv heel intelligent gemiddeldes uit te gaan rekenen.

ligfietser · 2010-12-04T12:49:18.000Z

ZMWandelaar:

En dat is een routine die in mkgmap ligt ingebakken? of heeft de kaartenmaker (wij) daar invloed op?

Het lijkt mij zo simpel om bij het voorkomen van 3 geschakelde nodes de middelste weg te laten, ipv heel intelligent gemiddeldes uit te gaan rekenen.

Ik denk dat er iets niet klopt in de mgkmap routines, die zal verbeterd moeten worden, want het verschijnsel treedt niet alleen bij jouw rotondes op maar ook gebouwen, meren etc.

Zelfs rechte lijnen worden zig-zag lijnen, dus daar klopt iets niet. Zie bijvoorbeeld onderstaand gebouw. In de editor (merkaartor) ogenschijnlijk een rechte lijn:

01.jpg720×505 71.8 KB

http://www.openstreetmap.org/?lat=52.18959&lon=5.400747&zoom=18&layers=M

cartinus · 2010-12-04T13:57:28.000Z

ZMWandelaar:

En dat is een routine die in mkgmap ligt ingebakken? of heeft de kaartenmaker (wij) daar invloed op?

Het lijkt mij zo simpel om bij het voorkomen van 3 geschakelde nodes de middelste weg te laten, ipv heel intelligent gemiddeldes uit te gaan rekenen.

Er worden helemaal geen gemiddeldes uitgerekend. Er zijn ook geen ingewikkelde algoritmes gebruikt.

Zoals al eerder in dit draadje gequote: Het coördinatenstelsel is gewoon niet nauwkeuriger. (In normaal Nederlands: afrondingsfouten) Dat verklaart alles wat je ziet in bovenstaande afbeelding.

ZMWandelaar · 2010-12-04T14:47:21.000Z

@Cartinus: Ik kan me daar best in vinden, maar wat verklaart dan de extreem zware kartelvorming nadat een CIRCEL met veel nodes wordt verwerkt? Kun je me het proces daar naar toe uitleggen?

cartinus · 2010-12-05T11:25:39.000Z

Pak een vel ruitjespapier.
Pak een passer.
Teken een cirkel.
Zet om de millimeter een puntje op de cirkel.
Pak nu een andere kleur pen/potlood.
Zoek bij ieder puntje het dichtstbijzijnde kruispunt van de ruitjes en zet daar een nieuw puntje.
Verbind de nieuwe puntjes.

Als nu de cirkel vrij groot is t.o.v. de ruitjes, dan krijg je een “bobbelige” cirkel zoals het ronde gebouw Het Zwin hierboven.

Hoe kleinere cirkel (of grotere ruitjes) je neemt, hoe karteliger de afgeleide cirkel wordt. Zie het water in het midden van het gebouw.

Peter-almere-nl · 2010-12-14T15:55:28.000Z

OsmAnd heeft helaas hetzelfde probleem. Een voetpaadje bij een rotonde op z20 ziet er zo ui, Mapnik links en OsmAnd rechts:

Sja… OsmAnd is open source, dus dan maar een bugreport.
Van Garmin weet je nooit of iemand er wat aan gaat doen.

Edit: linkje naar bug