Re: [mkgmap-dev] [mkgmap-svn] Commit: r1707: Fix NPE when no explicit bounding box was given.
On 26/09/10 22:58, Greg Troxel wrote: > > I'm seeing comits to what I think is the same mkgmap svn with different > version numbers. So am I just missing something obvious, or is there > something unusual going on, or ?? > >Version 1707 was commited by steve on 2010-09-26 21:23:54 +0100 (Sun, 26 > Sep 2010) >Version 230 was commited by steve on 2010-09-26 21:47:16 +0100 (Sun, 26 > Sep 2010) If you are subscribed to the mkgmap-svn list (which you are :) you see the commits from the both the splitter and the display repositories. As you point out it is not obvious where the commit is happening. I'll see if I can include something in the message. The display repo contains programs that display the contents of various type of files. The 3 repos are: http://svn.mkgmap.org.uk/mkgmap/trunk http://svn.mkgmap.org.uk/splitter/trunk http://svn.mkgmap.org.uk/display/trunk Most of the commit messages to mkgmap are also sent to mkgmap-dev ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Torsten Leistikow (de_m...@gmx.de) wrote: > WanMil schrieb am 24.09.2010 19:29: >>> My understanding of the multipolygons is, that the tags may EITHER be >>> in the >>> relation OR on the outer polygons. So the outerpoylgons are only to be >>> used, >>> when there are no tags on the relation. >>> If the relation itself is tagged and there is a tag on the >>> outerpolygons, this >>> does logical mean, that the outerpolygon tags apply to the complete area >>> including the inner-area. >> >> You càn check yourself if it's now the time to remove this polygon list. >> I have attached a patch that follows your proposal. Just test it and let >> us know. > > I tried your patch today, and I think it looks quite promising. Implementing > such a strict scheme will certainly show some faulty multipolygon (e.g. > Aussenalster in Hamburg), but perhaps this will encourage a cleaner > tagging of > such relations. > > I think the patch has still one problem: If the tags of the > outerpolygon are not > used for the multipolygon area, they must still be used as a > stand-alone polygon. > > As an example take a nature reserve consisting of a wood with a lake inside. > This migth be mapped with two polygons and a relation: > polygon A: leisure=nature_reserve (the complete area) > polygon B: natural=water (only the inner area) > multipolygon relation: natural=wood and outer=polygon A and inner=polygon B > (only the surrounding area) > > Right now polygon A seems to be missing in the resulting map. > But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)? -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
char...@cferrero.net schrieb am 27.09.2010 15:20: >> As an example take a nature reserve consisting of a wood with a lake inside. >> This migth be mapped with two polygons and a relation: >> polygon A: leisure=nature_reserve (the complete area) >> polygon B: natural=water (only the inner area) >> multipolygon relation: natural=wood and outer=polygon A and inner=polygon B >> (only the surrounding area) >> >> Right now polygon A seems to be missing in the resulting map. >> > But how would mkgmap know which of the two outer polygon types to use > (ie nature reserve or wood)? It should use both: The nature reserve should cover the complete area. The wood should cover only the area defined by the multipolygon. This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be: 1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B 2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B 3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B 4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area). Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Torsten Leistikow (de_m...@gmx.de) wrote: > char...@cferrero.net schrieb am 27.09.2010 15:20: >>> As an example take a nature reserve consisting of a wood with a >>> lake inside. >>> This migth be mapped with two polygons and a relation: >>> polygon A: leisure=nature_reserve (the complete area) >>> polygon B: natural=water (only the inner area) >>> multipolygon relation: natural=wood and outer=polygon A and inner=polygon B >>> (only the surrounding area) >>> >>> Right now polygon A seems to be missing in the resulting map. >>> >> But how would mkgmap know which of the two outer polygon types to use >> (ie nature reserve or wood)? > > It should use both: > > The nature reserve should cover the complete area. > > The wood should cover only the area defined by the multipolygon. > > This is (one of) the intended tagging of the multipolygons. Allowed > alternatives > (with the same logical interpretation) would be: > > 1. You could use an additional polygon for the outer limit of the > multipolygon > (polygon C) which would have the same nodes as polygon A. Polygon A > and B would > stay unchanged. > multipolygon relation: natural=wood and outer=polygon C and inner=polygon B > > 2. You could put all tags from the relation on polygon C, polygon A > and B would > stay unchanged. > polygon B: natural=wood > multipolygon relation: outer=polygon A and inner=polygon B > > 3. You could move the nature reserve tag into the multipolygon area and the > inner area. > polygon A: > polygon B: natural=water and leisure=nature_reserve > multipolygon relation: natural=wood and leisure=nature_reserve and > outer=polygon > A and inner=polygon B > > 4. And you could move the tags from the relation of variant 3 to the > outer polygon. > polygon A: natural=wood and leisure=nature_reserve > polygon B: natural=water and leisure=nature_reserve > multipolygon relation: outer=polygon A and inner=polygon B > > I think these five possibilities are all allowed under the actual accepted > multipolygon scheme and they should all result in nearly the same garmin map. > (Alternative 3 and 4 split the nature reserve into to areas, but in > the end it > covers teh same area). > > Gruss > Torsten OK, but in practical terms if mkgmap generated a nature reserve polygon, a wood multipolygon and an inner water polygon, wouldn't the visible results be undefined? In other words, you could end up with either: a) Wood multipolygon & water polygon hidden underneath a nature reserve polygon, or b) A nature reserve polygon hidden underneath the wood mp and water polygon depending on draw order of the polygons (which afaik you can't control). -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
char...@cferrero.net schrieb am 27.09.2010 16:49: > OK, but in practical terms if mkgmap generated a nature reserve > polygon, a wood multipolygon and an inner water polygon, wouldn't the > visible results be undefined? In other words, you could end up with > either: > a) Wood multipolygon & water polygon hidden underneath a nature > reserve polygon, or > b) A nature reserve polygon hidden underneath the wood mp and water polygon > depending on draw order of the polygons (which afaik you can't control). You can control the draw order of the polygons via the style file. So depending on the targeted use of your map, the result will look differently but clearly defined. In case of the example: My map style would display the wood and the water next to each other. The nature reserve is displayed on top of both, but it is a semi transparent texture. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit: r1707: Fix NPE when no explicit bounding box was given.
Steve Ratcliffe writes: > If you are subscribed to the mkgmap-svn list (which you are :) you see > the commits from the both the splitter and the display repositories. > As you point out it is not obvious where the commit is happening. I'll > see if I can include something in the message. > > The display repo contains programs that display the contents of > various type of files. > > The 3 repos are: > > http://svn.mkgmap.org.uk/mkgmap/trunk > http://svn.mkgmap.org.uk/splitter/trunk > http://svn.mkgmap.org.uk/display/trunk Thanks. I had no idea 'display' existed, but it sounds very useful. pgpLfwixCmN0Z.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
