I noticed that some roundabouts are rendered very badly, like this one: http://img153.imageshack.us/img153/1677/rotonde.jpg http://www.openstreetmap.org/browse/way/81912267 Can I improve the rendering by changing some settings (reduce-point-density, merge-lines or remove-short-arcs)? Or is it just the way those roundabouts are mapped that causes this behaviour?
Can nobody explain why those jagged lines occur in those roundabouts? Is it because the grid of garmin is too rough and mkgmap makes mistakes aligning the nodes in a circle? I wrote: I noticed that some roundabouts are rendered very badly, like this one: http://img153.imageshack.us/img153/1677/rotonde.jpg http://www.openstreetmap.org/browse/way/81912267 Can I improve the rendering by changing some settings (reduce-point-density, merge-lines or remove-short-arcs)? Or is it just the way those roundabouts are mapped that causes this behaviour?
"Minko" ligfietser@online.nl wrote on 28/11/2010 at 01:31:40 +1100 subject "[mkgmap-dev] rendering roundabouts" :
I noticed that some roundabouts are rendered very badly, like this one: http://img153.imageshack.us/img153/1677/rotonde.jpg http://www.openstreetmap.org/browse/way/81912267
Can I improve the rendering by changing some settings (reduce-point-density, merge-lines or remove-short-arcs)? Or is it just the way those roundabouts are mapped that causes this behaviour?
I have looked on it in JOSM. It is IMHO quite wrong data: a roundabout with a node every 30cm is not really correct. I have removed plenty of its nodes at it has still more then enough. http://www.openstreetmap.org/browse/way/81912267/history The rendering issue is gone after the correction of the data? -- Sincerely Hendrik Oesterlin - email hendrikmail2002@yahoo.de
Looks a bit better but still not quite a round circle: http://img543.imageshack.us/img543/1677/rotonde.jpg Hendrik Oesterlin wrote: I have looked on it in JOSM. It is IMHO quite wrong data: a roundabout with a node every 30cm is not really correct. I have removed plenty of its nodes at it has still more then enough. http://www.openstreetmap.org/browse/way/81912267/history The rendering issue is gone after the correction of the data?
"Minko" ligfietser@online.nl wrote on 01/12/2010 at 02:26:51 +1100 subject "[mkgmap-dev] rendering roundabouts" :
Hendrik Oesterlin wrote: I have looked on it in JOSM. It is IMHO quite wrong data: a roundabout with a node every 30cm is not really correct.
I have removed plenty of its nodes at it has still more then enough.
The rendering issue is gone after the correction of the data?
Looks a bit better but still not quite a round circle: http://img543.imageshack.us/img543/1677/rotonde.jpg
I think that there are no round elements in OSM nor in Garmin. In order to display a roundabout there are several strait segments. You seem to use a quite thin line to display your roads. I am using bigger lines, so it is less evident to see the segments and optically it displays smoother. On the top (north) side of your roundabout appears a dent. I do not know why, but I think that there are still much to many nodes to describe this small roundabout. -- Sincerely Hendrik Oesterlin - email hendrikmail2002@yahoo.de
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
"Minko" ligfietser@online.nl wrote on 01/12/2010 at 02:26:51 +1100 subject "[mkgmap-dev] rendering roundabouts" :
Hendrik Oesterlin wrote: I have looked on it in JOSM. It is IMHO quite wrong data: a roundabout with a node every 30cm is not really correct.
I have removed plenty of its nodes at it has still more then enough.
The rendering issue is gone after the correction of the data?
Looks a bit better but still not quite a round circle: http://img543.imageshack.us/img543/1677/rotonde.jpg
I think that there are no round elements in OSM nor in Garmin.
In order to display a roundabout there are several strait segments.
You seem to use a quite thin line to display your roads. I am using bigger lines, so it is less evident to see the segments and optically it displays smoother.
On the top (north) side of your roundabout appears a dent. I do not know why, but I think that there are still much to many nodes to describe this small roundabout.
Yes, this one for instance: http://tile.openstreetmap.nl/?zoom=18&lat=52.1696&lon=5.39063&layers=B000000... http://img137.imageshack.us/img137/1024/rotonde2.jpg It has nodes every 10m or so, so I think I'll recommend it to the guy who draw that roundabout instead of every 30cm ;-) Thanks! Minko WanMil wrote: 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
On the dutch osm forum this particular roundabout has raised some questions about how mkgmap deals with filtering those nodes. Does it calculate an avarage position of a cluster of nodes that are (too) close to each other and group them into one node? Is this the reason why those jagged lines show up on the garmin img?
On Thu, Dec 02, 2010 at 12:37:39PM +0100, Minko wrote:
On the dutch osm forum this particular roundabout has raised some questions about how mkgmap deals with filtering those nodes. Does it calculate an avarage position of a cluster of nodes that are (too) close to each other and group them into one node? Is this the reason why those jagged lines show up on the garmin img?
Are you using the option remove-short-arcs? I do not know how it works, but in the worst case, it does not calculate any averages, but just merges nodes that are too close together, until no too-close nodes remain. A random node would end up being selected as the representative of the cluster. Marko
Yes, I'm using remove-short-arcs. If I don't use it, mkgmap generates a lot of error messages. However, the roundabouts with too many nodes remain jagged like a drunkard has mapped them ;-) If I specify remove-short-arcs with a high number (say 5 or 10) the results gets worse. ----- Oorspronkelijk bericht ----- Van: "Marko Mäkelä" Are you using the option remove-short-arcs? I do not know how it works, but in the worst case, it does not calculate any averages, but just merges nodes that are too close together, until no too-close nodes remain. A random node would end up being selected as the representative of the cluster.
If you use the option reduce-point-density then the line is straightened using the douglas peucker algorithm. All segments between two endpoints or T-crossings are straightened. The points of crossings are not touched. Find a description of the algorithm at wikipedia. http://de.wikipedia.org/wiki/Douglas-Peucker-Algorithmus Regards, Johann Minko schrieb:
On the dutch osm forum this particular roundabout has raised some questions about how mkgmap deals with filtering those nodes. Does it calculate an avarage position of a cluster of nodes that are (too) close to each other and group them into one node? Is this the reason why those jagged lines show up on the garmin img? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev .
Thanks Johann, I already tried several settings of reduce-point-density, but this seems to have no effect on the shape of the roundabout at all. Regards, Minko
Once again: Garmin coordinates have a much lower resolution than OSM coordinates. The roundabout is quite small (~25m), so I do not wonder if this roundabout will not be as round as you might expect. Do you know another roundabout with the same dimension that is rendered as you expect? WanMil Am 03.12.2010 19:15, schrieb Minko:
Thanks Johann, I already tried several settings of reduce-point-density, but this seems to have no effect on the shape of the roundabout at all.
Regards, Minko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
When I create a map of Cambodia with the default style I get garbage in the boundary names (a mixture of Thai and other regional script which will not display correctly). Looking at the data I can see that this comes from the name tag so I need to select name:en and only use name where no name:en exists. I first tried using the option --name-tag-list=name:en, name expecting that the boundaries would now use the name:en tag, but this had no effect that I could see. Next I tried editing the line style, and I got the tags to display in English by commenting out this line: boundary=administrative { name '${mkgmap:boundary_name}' } This appears to be setting the name of administrative boundaries to mkgmap:boundary_name, so I was wondering where mkgmap:boundary_name gets its value? Garvan
On 04/12/2010 09:48, garvan&maew wrote:
When I create a map of Cambodia with the default style I get garbage in the boundary names (a mixture of Thai and other regional script which will not display correctly). Looking at the data I can see that this comes from the name tag so I need to select name:en and only use name where no name:en exists.
I first tried using the option --name-tag-list=name:en, name
expecting that the boundaries would now use the name:en tag, but this had no effect that I could see. Next I tried editing the line style, and I got the tags to display in English by commenting out this line:
boundary=administrative { name '${mkgmap:boundary_name}' }
This appears to be setting the name of administrative boundaries to mkgmap:boundary_name, so I was wondering where mkgmap:boundary_name gets its value?
Garvan
Most likely from the relations style file.
On Sat, Dec 04, 2010 at 12:48:10PM +0700, garvan&maew wrote:
I first tried using the option --name-tag-list=name:en, name
I have never tried that option, so I don't know if it affects relations. I guess I could easily test it by checking Finnish/Russian boundary on my map. For what it is worth, I would not use the option in 'production', because some areas in Finland use Swedish name (and may have name:fi) while most areas use Finnish name (and may have name:sv). I would want to keep the name, except maybe when it is neither Swedish nor Finnish (e.g., the Russian names that even require a character set conversion). I do not know how to express this in --name-tag-list. And even then, I could get problems with foreign-language objects, such as embassies and historic things like name='Deutscher Soldatenfriedhof' (name==name:de, not name:fi or name:sv). I guess that we could benefit from a 'black list' of languages. If transliteration is needed for name, try to use another name:*, e.g., --replacement-name-list=name:en,name:fi,name:sv.
expecting that the boundaries would now use the name:en tag, but this had no effect that I could see. Next I tried editing the line style, and I got the tags to display in English by commenting out this line:
boundary=administrative { name '${mkgmap:boundary_name}' }
This appears to be setting the name of administrative boundaries to mkgmap:boundary_name, so I was wondering where mkgmap:boundary_name gets its value?
As Charlie Ferrero suggested, it should get the value from the name of the boundary relation. The question is if relations ignore the name-tag-list option. # Names of administrative boundaries. # We could want to sort the relations in ascending order of admin_level # and alphabetically by name first. # Currently, the matching relations will be processed and the names # appended to the boundary lines in an arbitrary order. (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } } As a workaround for the possible --name-tag-list bug, you could try replacing ${name} in the above rule with ${name:en}. If it does not help, check that relations actually carry a name:en. Ideas for tweaking the style language so that the resulting name list will be sorted are welcome. Best regards, Marko
On Sat, Dec 04, 2010 at 12:37:59PM +0200, Marko Mäkelä wrote:
The question is if relations ignore the name-tag-list option.
This seems to be the case. I just added the following to my mkgmap.args: name-tag-list: name:fi,name:sv,name:en,name It did something, because I saw many Swedish names in Helsinki and Espoo, instead of the usual Finnish. They are (in my opinion incorrectly) tagged as name=Finnish_name, name:sv=Swedish_name, missing name:fi. However, the name of the Finnish-Russian border line segment that I checked still contained the Russian ${name}s "Leningradskaja Oblast" and "Rossiskaja Federacia", even though the relations in question do carry ${name:fi}, which should have been selected instead of the ${name}: http://www.openstreetmap.org/browse/relation/176095 http://www.openstreetmap.org/browse/relation/60189 Best regards, Marko
On Sat, 2010-12-04 at 12:37 +0200, Marko Mäkelä wrote: <snip>
As Charlie Ferrero suggested, it should get the value from the name of the boundary relation. The question is if relations ignore the name-tag-list option.
# Names of administrative boundaries. # We could want to sort the relations in ascending order of admin_level # and alphabetically by name first. # Currently, the matching relations will be processed and the names # appended to the boundary lines in an arbitrary order. (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } }
As a workaround for the possible --name-tag-list bug, you could try replacing ${name} in the above rule with ${name:en}. If it does not help, check that relations actually carry a name:en.
Ideas for tweaking the style language so that the resulting name list will be sorted are welcome.
Best regards,
Marko
The relations are tagged consistently in my case (better than the tag in the ways), so your idea of using ${name:en} in the relations rule works perfectly. Thanks for your help. And it does look like there is a bug in handling the --name-tag-list. Apologies to those who group messages by thread in their email program, I just realized that I inserted my first post into an existing thread by mistake. Garvan
Roundabouts with nodes >8m from each other are rendered fine. But if the nodes are closer to each other mkgmap doesn't seem to translate them very well to the lower resulution of the Garmin grid. This not only happens to roads but other elements as well, even straight lines are converted into jagged structures (if the nodes are very close). See for instance the buildings and lakes on this map (my Openfietsmap): http://picasaweb.google.com/101124410619265439590/Openfietsmap#5546803050381... Here a screenshot of Merkaartor: http://picasaweb.google.com/101124410619265439590/Openfietsmap#5546803053933... Here is the link to the osm map: http://www.openstreetmap.org/?lat=52.189706&lon=5.400034&zoom=18&layers=M The mkgmap settings that I use are shown here: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/osm_bnl.arg... "WanMil" wrote: Once again: Garmin coordinates have a much lower resolution than OSM coordinates. The roundabout is quite small (~25m), so I do not wonder if this roundabout will not be as round as you might expect. Do you know another roundabout with the same dimension that is rendered as you expect? WanMil
On Fri, Dec 03, 2010 at 06:51:44PM +0100, Johann Gail wrote:
If you use the option reduce-point-density then the line is straightened using the douglas peucker algorithm. All segments between two endpoints or T-crossings are straightened. The points of crossings are not touched. Find a description of the algorithm at wikipedia.
Is the mkgmap implementation of the algorithm aware of the Garmin map grid? Should it be? I just noticed some jagged lines on this straight way, and recompiling with reduce-point-density does not help. I seem to remember that the Douglas-Peucker algorithm would not be applied on the closest zoom level (resolution 24). Is that correct? Here is the way in question: http://www.openstreetmap.org/browse/way/37837385 The problem is caused by the role=vehicle nodes that I added next to the bus stops: http://www.openstreetmap.org/browse/node/616855877 http://www.openstreetmap.org/browse/node/616855878 These nodes should simply be removed. Could the Douglas-Peucker algorithm simply use a tighter error bound on resolution 24? Marko
participants (7)
-
Charlie Ferrero -
garvan&maew -
Hendrik Oesterlin -
Johann Gail -
Marko Mäkelä -
Minko -
WanMil