Hi, I observe badly looking lines. I have attached some pictures and xml objects that doesn't look good on Garmin map. My guess is that there is no proper simplifications for resolution 24bit. Points too dense are removed in a non optimal way which can lead to jagged curves. This could be the reason for bad looking tram railways (file tram1.osm in test.zip). Other reason could be removing of short lines. I think in this case some nodes are moved. It looks like instead of creating a new node in a middle of removed line, first point is used. This can lead to bigger distortion. This is probably the case of road example (file road1.osm). -- Best regards, Andrzej
Hi Andrzej, I think there is no way to avoid the rounding errors caused by the 24b bit limit, but some problems are definetely caused by the short-arc-removal routine which merges nodes which are too close. The weakness of the algo is that it doesn't care about the "importance" of a road nor about the effect on straight lines. I will need a few days to dig into this again. Gerd Date: Sun, 1 Sep 2013 03:48:17 +0200 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Distorted lines Hi, I observe badly looking lines. I have attached some pictures and xml objects that doesn't look good on Garmin map. My guess is that there is no proper simplifications for resolution 24bit. Points too dense are removed in a non optimal way which can lead to jagged curves. This could be the reason for bad looking tram railways (file tram1.osm in test.zip). Other reason could be removing of short lines. I think in this case some nodes are moved. It looks like instead of creating a new node in a middle of removed line, first point is used. This can lead to bigger distortion. This is probably the case of road example (file road1.osm). -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I noticed that remove-short-arcs=5.4 can in some cases even break routing, remove-short-arcs on default (I think 2.8) is fine though. I could well believe there are some fundamental flaws in it, especially in combinaton with reduce-point-density (--reduce-point-density=3.4 --reduce-point-density-polygon=6). Maybe remove-short-arcs may not be bigger than the reduce-point-density values? On 20.09.2013 09:47, Gerd Petermann wrote:
Hi Andrzej,
I think there is no way to avoid the rounding errors caused by the 24b bit limit, but some problems are definetely caused by the short-arc-removal routine which merges nodes which are too close. The weakness of the algo is that it doesn't care about the "importance" of a road nor about the effect on straight lines. I will need a few days to dig into this again.
Gerd
Date: Sun, 1 Sep 2013 03:48:17 +0200 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Distorted lines
Hi,
I observe badly looking lines. I have attached some pictures and xml objects that doesn't look good on Garmin map.
My guess is that there is no proper simplifications for resolution 24bit. Points too dense are removed in a non optimal way which can lead to jagged curves. This could be the reason for bad looking tram railways (file tram1.osm in test.zip).
Other reason could be removing of short lines. I think in this case some nodes are moved. It looks like instead of creating a new node in a middle of removed line, first point is used. This can lead to bigger distortion. This is probably the case of road example (file road1.osm).
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, Felix Hartmann-2 wrote
I noticed that remove-short-arcs=5.4 can in some cases even break routing, remove-short-arcs on default (I think 2.8) is fine though. I could well believe there are some fundamental flaws in it, especially in combinaton with reduce-point-density (--reduce-point-density=3.4 --reduce-point-density-polygon=6).
Maybe remove-short-arcs may not be bigger than the reduce-point-density values?
I don't think so. Up to now the reduce-* values are only used for the simplifications that are used for resoultions < 24, while the remove-short-arcs value is used with the 24 bit value. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5778223.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, GerdP wrote:
Up to now the reduce-* values are only used for the simplifications that are used for resoultions < 24
That is the first problem I have described. In my opinion, simplification should be performed on original floating point data too. This would preserve shape of the curve and eliminate small jaggies after rounding to integer. Second problem with deleted short lines is difficult to avoid but maybe could be optimized for better visual result. Position of the point that is replacing removed line could vary depending on topology of other lines. Or sometimes instead of removing line, it could be extended a bit with less impact on other lines. -- Best regards, Andrzej
Hi Andrzej,
Second problem with deleted short lines is difficult to avoid but maybe could be optimized for better visual result. Position of the point that is replacing removed line could vary depending on topology of other lines. Or sometimes instead of removing line, it could be extended a bit with less impact on other lines.
yes, that is what I am trying to implement. There is a third option: Sometimes mkgmap creates short arcs by changing the meaning of points, eg. with the --link-pois-to-ways option. Some weeks ago I've posted a patch regarding this, but I got no feedback. Did you try it? See also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/018344.html Gerd
Hi Gerd, Gerd wrote:
Sometimes mkgmap creates short arcs by changing the meaning of points, eg. with the --link-pois-to-ways option. Some weeks ago I've posted a patch regarding this, but I got no feedback.
I didn't know about this patch. Now I have tried it but I can't see any changes at places that I have provided in my first post. Maybe your patch deals with other case. -- Best
Hi Andrzej , possible. I tried to describe the patch here: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778385.html I am working on a new patch for the short-arc-removal-algo. In some cases, the algo can select which one of the two nodes that build the short arc is to be merged. I try to implement rules for these cases, e.g. prefer to move the endpoint of a road rather than a point in the middle (easy to implement). If the roads have different road class, prefer to move the smaller class (less easy) Gerd
Date: Sat, 21 Sep 2013 16:17:04 +0200 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
Gerd wrote:
Sometimes mkgmap creates short arcs by changing the meaning of points, eg. with the --link-pois-to-ways option. Some weeks ago I've posted a patch regarding this, but I got no feedback.
I didn't know about this patch. Now I have tried it but I can't see any changes at places that I have provided in my first post. Maybe your patch deals with other case.
-- Best _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, since Garmin started to create OSM maps, we can directly compare different processing of input data. Please look at railways on both attached pictures. Mkgmap version (simp-mkg.png) is created with branch high-prec-coord-r3053. -- Best regards, Andrzej
A link to OSM would be useful: http://www.openstreetmap.org/way/234118154#map=19/52.24497/21.08463
Am 15.02.2014 17:32, schrieb Andrzej Popowski:
since Garmin started to create OSM maps, we can directly compare different processing of input data. Please look at railways on both attached pictures. Mkgmap version (simp-mkg.png) is created with branch high-prec-coord-r3053.
In order to compare, the same TYP file should be used, because this also has some effect on how distorted the lines appear. Chris
Hi Andrzej, thanks for the hint. This is a good reason for optimizing non-routable ways as well, which is not yet done. Gerd popej wrote
Hi,
since Garmin started to create OSM maps, we can directly compare different processing of input data. Please look at railways on both attached pictures. Mkgmap version (simp-mkg.png) is created with branch high-prec-coord-r3053.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
simp-mkg.png (56K) <http://gis.19327.n5.nabble.com/attachment/5796455/0/simp-mkg.png>; simp-mpc.png (50K) <http://gis.19327.n5.nabble.com/attachment/5796455/1/simp-mpc.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796515.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Andrzej, I've added the code to optimize non-routable ways in r3059. Your example looks much better now. Gerd Date: Sat, 15 Feb 2014 17:32:23 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines Hi, since Garmin started to create OSM maps, we can directly compare different processing of input data. Please look at railways on both attached pictures. Mkgmap version (simp-mkg.png) is created with branch high-prec-coord-r3053. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
I've added the code to optimize non-routable ways in r3059. Your example looks much better now.
That was fast. Result is much better, thanks! Can we fine-tune effect using option --reduce-point-density? Some observation: Map size seems to be nearly 10% less, compared to latest release r3057. I get many warnings like this: SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: non-routable way 101876024 was removed And some like this: SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: Removing wrong angles - didn't finish in 10 passes, giving up! There is difference in processing of non-routable lines and polygons, now outline of a building doesn't match polygon shape. I guess one change leads to another and probably would be good to apply your updates to processing polygons too. -- Best regards, Andrzej
Hi Andrzej,
That was fast. Result is much better, thanks!
Can we fine-tune effect using option --reduce-point-density?
no, but maybe I will add parameters for the hard coded threshold values later.
Some observation:
Map size seems to be nearly 10% less, compared to latest release r3057.
yes, that is intended.
I get many warnings like this: SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: non-routable way 101876024 was removed
that is not intended :-( Please let me know how I can reproduce that.
And some like this: SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: Removing wrong angles - didn't finish in 10 passes, giving up!
that also should not happen. Please let me know how I can reproduce that.
There is difference in processing of non-routable lines and polygons, now outline of a building doesn't match polygon shape. I guess one change leads to another and probably would be good to apply your updates to processing polygons too.
Yes, the algorithm for lines is different to that for shapes, and I can't simply use the same at this moment. I plan a big change later to allow it, but will not do it in the high-prec-coord branch. Gerd
Hi Andrzej, sorry, the 10% smaller size is also not intended, I thought you compared with trunk. The way 101876024 is an extremely small building, but you seem to map it as a line? The algo is not prepared for that. Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Mon, 17 Feb 2014 22:07:28 +0100 Subject: Re: [mkgmap-dev] Distorted lines Hi Andrzej,
That was fast. Result is much better, thanks!
Can we fine-tune effect using option --reduce-point-density?
no, but maybe I will add parameters for the hard coded threshold values later.
Some observation:
Map size seems to be nearly 10% less, compared to latest release r3057.
yes, that is intended.
I get many warnings like this: SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: non-routable way 101876024 was removed
that is not intended :-( Please let me know how I can reproduce that.
And some like this: SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: Removing wrong angles - didn't finish in 10 passes, giving up!
that also should not happen. Please let me know how I can reproduce that.
There is difference in processing of non-routable lines and polygons, now outline of a building doesn't match polygon shape. I guess one change leads to another and probably would be good to apply your updates to processing polygons too.
Yes, the algorithm for lines is different to that for shapes, and I can't simply use the same at this moment. I plan a big change later to allow it, but will not do it in the high-prec-coord branch. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
sorry, the 10% smaller size is also not intended, I thought you compared with trunk.
I have compared with trunk, 3057 is current release.
The way 101876024 is an extremely small building, but you seem to map it as a line?
Yes, I'm trying to create a light map for car navigation. I hope that building outlines are as usable as polygons but less taxing to device. -- Best regards, Andrzej
Hi Andrzej,
sorry, the 10% smaller size is also not intended, I thought you compared with trunk.
I have compared with trunk, 3057 is current release.
okay, seems I was too tired yesterday ;-)
The way 101876024 is an extremely small building, but you seem to map it as a line?
Yes, I'm trying to create a light map for car navigation. I hope that building outlines are as usable as polygons but less taxing to device.
hmm, it will require more bytes because the closing point has to be saved as well, and shape merge filter can't help as well, but maybe it requires fewer cpu cycles for rendering. I think for the given example it is okay to remove the way. That leaves the question why you see "didn't finish in 10 passes, giving up! " messages. Gerd
Hi Andrzej, I've fixed one serious in the WrongAngleFixer that removed lines without good reason. With r3063 I've increased the max. number of passes to 20, as this doesn't seem to require much more time. The message "non-routable way xyz was removed" is now only printed if the original way has different points in map units, and now it is just a warning. The algo is still subject to optimization, as it repeats trying to fix errors where it can't. It is not as simple as the standard algos like Douglas-Peucker, as it also moves points to correct angles in favour of positional errors. Up to now shapes are optimized with a much simpler algo which doesn't move points . The complex algo would require that it knows all points of all merged(!) shapes, and that doesn't fit well into the current chain of splitting and merging algos. Gerd
Date: Mon, 17 Feb 2014 22:54:00 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
sorry, the 10% smaller size is also not intended, I thought you compared with trunk.
I have compared with trunk, 3057 is current release.
The way 101876024 is an extremely small building, but you seem to map it as a line?
Yes, I'm trying to create a light map for car navigation. I hope that building outlines are as usable as polygons but less taxing to device.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, sounds good. Are you also satisfied with the results? Gerd
Date: Tue, 18 Feb 2014 20:13:47 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
The message "non-routable way xyz was removed" is now only printed if the original way has different points in map units, and now it is just a warning.
no more error or warning messages with r3063.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
Are you also satisfied with the results?
Sure, thanks. Railways look good. I'm a bit worried about inconsistency. See this building: http://www.openstreetmap.org/way/256598227 I have attached screenshot building-mkgmap.png. On my map this building is drawn as an outline and a polygon. I know that other people use this kind of presentation too. I would preffer similar simplification for polygons. See building-garmin.png. Garmin is using more extreme simplification, maybe even dedicated algorithm for buildings. -- Best regards, Andrzej
Hi Andrzej, seems that the garmin data is older. Reg. polygon optimization: When I started to implement that, I noticed problems with buildings that share lines. Sometimes the lines were moved apart because the algo optimized one poly after the other. So I started to code that ShapeMergeFilter which connects the polygon and removes points where possible. The open problem now is that I merge the polys of each sub division. If I optimize them, I see again the "move apart" problem at places where one poly is in one sub div and another neighbour poly is in a different sub div. Maybe I can implement an algo that optimizes at least those polygons which can't share any points with others in other sub divisions with some kind of reference counter. The correct solution that I have in mind requires a big change in data structures, so I'd like to postpone that because I want to merge the branch to trunk first. Gerd popej wrote
Hi Gerd,
Are you also satisfied with the results?
Sure, thanks. Railways look good.
I'm a bit worried about inconsistency. See this building: http://www.openstreetmap.org/way/256598227
I have attached screenshot building-mkgmap.png. On my map this building is drawn as an outline and a polygon. I know that other people use this kind of presentation too. I would preffer similar simplification for polygons.
See building-garmin.png. Garmin is using more extreme simplification, maybe even dedicated algorithm for buildings.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
building-mkgmap.png (20K) <http://gis.19327.n5.nabble.com/attachment/5796805/0/building-mkgmap.png>; building-garmin.png (17K) <http://gis.19327.n5.nabble.com/attachment/5796805/1/building-garmin.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796807.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, committed with r3064. Gerd ligfietser wrote
Gerd, can you commit your coastline patch in the branch version?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796839.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I think this might cause problems. In case you want to use polygons tagged with place=island you will lose all islands that are also tagged as natural=coastline. This tagging is described on the wiki page (http://wiki.openstreetmap.org/wiki/Tag:place%3Disland). I think the patch can be extended in such a way that the coastline way is copied. The copy need to be processed by the polygon rules only and the natural=coastline is removed. This should catch all cases? Sorry for having a look into the patch late! WanMil
Hi Minko,
committed with r3064.
Gerd
ligfietser wrote
Gerd, can you commit your coastline patch in the branch version?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796839.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, I see. Wouldn't it be better to add also a tag so that the style can find out that Seagenerator deleted the natural=coastline tag? If yes, what would be a good tag for this? Gerd
Date: Wed, 19 Feb 2014 21:00:46 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will lose all islands that are also tagged as natural=coastline. This tagging is described on the wiki page (http://wiki.openstreetmap.org/wiki/Tag:place%3Disland).
I think the patch can be extended in such a way that the coastline way is copied. The copy need to be processed by the polygon rules only and the natural=coastline is removed. This should catch all cases?
Sorry for having a look into the patch late!
WanMil
Hi Minko,
committed with r3064.
Gerd
ligfietser wrote
Gerd, can you commit your coastline patch in the branch version?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796839.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, mkgmap:natural=coastline? For my example I don't see a good reason having that tag. Can you give one where you need this information? WanMil
Hi WanMil,
I see. Wouldn't it be better to add also a tag so that the style can find out that Seagenerator deleted the natural=coastline tag? If yes, what would be a good tag for this?
Gerd
Date: Wed, 19 Feb 2014 21:00:46 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will lose all islands that are also tagged as natural=coastline. This tagging is described on the wiki page (http://wiki.openstreetmap.org/wiki/Tag:place%3Disland).
I think the patch can be extended in such a way that the coastline way is copied. The copy need to be processed by the polygon rules only and the natural=coastline is removed. This should catch all cases?
Sorry for having a look into the patch late!
WanMil
Hi Minko,
committed with r3064.
Gerd
ligfietser wrote
Gerd, can you commit your coastline patch in the branch version?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796839.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, I just want to avoid the situation that Minko had in the first place: A rule that checks for a tag that mkgmap has removed. I think that if we do this, it is a good idea to allow the style to ask for the removed info. Attached is a patch that implements your proposal and changes the natural=coastline tag to removed_natural=coastline. coastline-v2.patch <http://gis.19327.n5.nabble.com/file/n5796845/coastline-v2.patch> Gerd WanMil wrote
Hi Gerd,
mkgmap:natural=coastline?
For my example I don't see a good reason having that tag. Can you give one where you need this information?
WanMil
Hi WanMil,
I see. Wouldn't it be better to add also a tag so that the style can find out that Seagenerator deleted the natural=coastline tag? If yes, what would be a good tag for this?
Gerd
Date: Wed, 19 Feb 2014 21:00:46 +0100 From:
wmgcnfg@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will lose all islands that are also tagged as natural=coastline. This tagging is described on the wiki page (http://wiki.openstreetmap.org/wiki/Tag:place%3Disland).
I think the patch can be extended in such a way that the coastline way is copied. The copy need to be processed by the polygon rules only and the natural=coastline is removed. This should catch all cases?
Sorry for having a look into the patch late!
WanMil
Hi Minko,
committed with r3064.
Gerd
ligfietser wrote
Gerd, can you commit your coastline patch in the branch version?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796839.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796845.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, at the moment I have no Java environment so I can only comment on the patch without testing my changes. The tags of the original way need to be copied to the new coastlineWay. After that you have a typo so that you delete the natural tag from the original way instead of coastlineWay. It should look like (on both places): // add a copy of this way to be able to draw the coastline which is not possible with precompiled sea Way coastlineWay = new Way(FakeIdGenerator.makeFakeId(), way.getPoints()); coastlineWay.copyTags(way); coastlineWay.deleteTag("natural"); coastlineWay.addTag("mkgmap:removed_natural",natural); // tag that this way is used as polygon only coastlineWay.addTag(MultiPolygonRelation.STYLE_FILTER_TAG, MultiPolygonRelation.STYLE_FILTER_POLYGON); saver.addWay(coastlineWay); Some small nit-picking: All tags added by mkgmap should start with "mkgmap:". So the tag need to be named mkgmap:removed_natural=coastline or mkgmap:removed:natural=coastline or ??. WanMil
Hi WanMil,
I just want to avoid the situation that Minko had in the first place: A rule that checks for a tag that mkgmap has removed. I think that if we do this, it is a good idea to allow the style to ask for the removed info. Attached is a patch that implements your proposal and changes the natural=coastline tag to removed_natural=coastline.
coastline-v2.patch <http://gis.19327.n5.nabble.com/file/n5796845/coastline-v2.patch>
Gerd
WanMil wrote
Hi Gerd,
mkgmap:natural=coastline?
For my example I don't see a good reason having that tag. Can you give one where you need this information?
WanMil
Hi WanMil,
I see. Wouldn't it be better to add also a tag so that the style can find out that Seagenerator deleted the natural=coastline tag? If yes, what would be a good tag for this?
Gerd
Date: Wed, 19 Feb 2014 21:00:46 +0100 From:
wmgcnfg@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will lose all islands that are also tagged as natural=coastline. This tagging is described on the wiki page (http://wiki.openstreetmap.org/wiki/Tag:place%3Disland).
I think the patch can be extended in such a way that the coastline way is copied. The copy need to be processed by the polygon rules only and the natural=coastline is removed. This should catch all cases?
Sorry for having a look into the patch late!
WanMil
Hi Minko,
committed with r3064.
Gerd
ligfietser wrote
Gerd, can you commit your coastline patch in the branch version?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796839.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796845.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, good catch. I'll commit the corrected version tomorrow. Gerd WanMil wrote
Hi Gerd,
at the moment I have no Java environment so I can only comment on the patch without testing my changes.
The tags of the original way need to be copied to the new coastlineWay. After that you have a typo so that you delete the natural tag from the original way instead of coastlineWay. It should look like (on both places):
// add a copy of this way to be able to draw the coastline which is not possible with precompiled sea Way coastlineWay = new Way(FakeIdGenerator.makeFakeId(), way.getPoints()); coastlineWay.copyTags(way); coastlineWay.deleteTag("natural"); coastlineWay.addTag("mkgmap:removed_natural",natural); // tag that this way is used as polygon only coastlineWay.addTag(MultiPolygonRelation.STYLE_FILTER_TAG, MultiPolygonRelation.STYLE_FILTER_POLYGON); saver.addWay(coastlineWay);
Some small nit-picking: All tags added by mkgmap should start with "mkgmap:". So the tag need to be named mkgmap:removed_natural=coastline or mkgmap:removed:natural=coastline or ??.
WanMil
Hi WanMil,
I just want to avoid the situation that Minko had in the first place: A rule that checks for a tag that mkgmap has removed. I think that if we do this, it is a good idea to allow the style to ask for the removed info. Attached is a patch that implements your proposal and changes the natural=coastline tag to removed_natural=coastline.
coastline-v2.patch <http://gis.19327.n5.nabble.com/file/n5796845/coastline-v2.patch>;
Gerd
WanMil wrote
Hi Gerd,
mkgmap:natural=coastline?
For my example I don't see a good reason having that tag. Can you give one where you need this information?
WanMil
Hi WanMil,
I see. Wouldn't it be better to add also a tag so that the style can find out that Seagenerator deleted the natural=coastline tag? If yes, what would be a good tag for this?
Gerd
Date: Wed, 19 Feb 2014 21:00:46 +0100 From:
wmgcnfg@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will lose all islands that are also tagged as natural=coastline. This tagging is described on the wiki page (http://wiki.openstreetmap.org/wiki/Tag:place%3Disland).
I think the patch can be extended in such a way that the coastline way is copied. The copy need to be processed by the polygon rules only and the natural=coastline is removed. This should catch all cases?
Sorry for having a look into the patch late!
WanMil
Hi Minko,
committed with r3064.
Gerd
ligfietser wrote > Gerd, can you commit your coastline patch in the branch version? > > _______________________________________________ > mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796839.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796845.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796852.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi all, I've changed the code again, and also changed the options docu: * the original OSM way is only passed through the lines rules * if the way is closed a copy is created, the natural=* tag is replaced with mkgmap:removed_natural=* and this copy is only passed through the polygon rules @WanMil: Please review also the changes in the docu files, I am not sure about the formatting rules. Gerd
Date: Wed, 19 Feb 2014 21:57:26 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
at the moment I have no Java environment so I can only comment on the patch without testing my changes.
The tags of the original way need to be copied to the new coastlineWay. After that you have a typo so that you delete the natural tag from the original way instead of coastlineWay. It should look like (on both places):
// add a copy of this way to be able to draw the coastline which is not possible with precompiled sea Way coastlineWay = new Way(FakeIdGenerator.makeFakeId(), way.getPoints()); coastlineWay.copyTags(way); coastlineWay.deleteTag("natural"); coastlineWay.addTag("mkgmap:removed_natural",natural); // tag that this way is used as polygon only coastlineWay.addTag(MultiPolygonRelation.STYLE_FILTER_TAG, MultiPolygonRelation.STYLE_FILTER_POLYGON); saver.addWay(coastlineWay);
Some small nit-picking: All tags added by mkgmap should start with "mkgmap:". So the tag need to be named mkgmap:removed_natural=coastline or mkgmap:removed:natural=coastline or ??.
WanMil
Hi WanMil,
I just want to avoid the situation that Minko had in the first place: A rule that checks for a tag that mkgmap has removed. I think that if we do this, it is a good idea to allow the style to ask for the removed info. Attached is a patch that implements your proposal and changes the natural=coastline tag to removed_natural=coastline.
coastline-v2.patch <http://gis.19327.n5.nabble.com/file/n5796845/coastline-v2.patch>
Gerd
WanMil wrote
Hi Gerd,
mkgmap:natural=coastline?
For my example I don't see a good reason having that tag. Can you give one where you need this information?
WanMil
Hi WanMil,
I see. Wouldn't it be better to add also a tag so that the style can find out that Seagenerator deleted the natural=coastline tag? If yes, what would be a good tag for this?
Gerd
Date: Wed, 19 Feb 2014 21:00:46 +0100 From:
wmgcnfg@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Distorted lines
Hi Gerd,
I think this might cause problems.
In case you want to use polygons tagged with place=island you will lose all islands that are also tagged as natural=coastline. This tagging is described on the wiki page (http://wiki.openstreetmap.org/wiki/Tag:place%3Disland).
I think the patch can be extended in such a way that the coastline way is copied. The copy need to be processed by the polygon rules only and the natural=coastline is removed. This should catch all cases?
Sorry for having a look into the patch late!
WanMil
Hi Minko,
committed with r3064.
Gerd
ligfietser wrote > Gerd, can you commit your coastline patch in the branch version? > > _______________________________________________ > mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796839.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796845.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Henning, yes, I see only two draw backs with the branch: - precomp-sea data and boundary files generated with it are ~1/3 larger. Maybe this can be reduced if I change the code to use the WrongAngleFixer before writing the data, as this removes a lot of points. - calculation time is ~10% higher I am working on a patch that adds arcs to major roads (as in Garmin maps), this will increase size by maybe ~1% again. Gerd Date: Wed, 19 Feb 2014 17:54:58 +0100 From: osm@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines Am 19.02.2014 10:26, schrieb Gerd Petermann: Are you also satisfied with the results? Absolutly! Looks smoother and maps are smaller, win-win-situation. Thanks a lot, Henning _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Excuse me, please what exactly I have to do against distorted lines? THANKS. --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5798543.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Enrico, you should use mkgmap-high-prec-coord-r3075 or wait until I've merged this branch to trunk (tomorrow). Look at the bottom of this page: http://www.mkgmap.org.uk/download/mkgmap.html Gerd
Date: Tue, 4 Mar 2014 14:25:08 -0800 From: e.rossini73@alice.it To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Distorted lines
Excuse me, please what exactly I have to do against distorted lines? THANKS. --enrico
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5798543.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
So I have only to use this mkgmap.jar (mkgmap-high-prec-coord-r3078) instead of the "official" 3072 release? There isn't any particular option to set? What is exactly the benefit? Thanks very much. --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5798603.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Enrico, yes, just use that binary reg. the changes please read this post: http://gis.19327.n5.nabble.com/high-prec-branch-ready-for-trunk-tp5798370.ht... Gerd demon.box wrote
So I have only to use this mkgmap.jar (mkgmap-high-prec-coord-r3078) instead of the "official" 3072 release? There isn't any particular option to set? What is exactly the benefit? Thanks very much. --enrico
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5798612.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Chriss, yes, it is not possible in the trunk. Gerd Chris66 wrote
Am 17.02.2014 10:12, schrieb Gerd Petermann:
I've added the code to optimize non-routable ways in r3059. Your example looks much better now.
Hi Gerd, I assume it's in the high-precision branch, and not in trunc?
Chris
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761p5796718.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (10)
-
Andrzej Popowski -
chris66 -
demon.box -
Felix Hartmann -
Gerd Petermann -
GerdP
-
Henning Scholland -
Minko -
Steve Ratcliffe -
WanMil