Hi all, I was able to reproduce the error messages reported by Felx : http://gis.19327.n5.nabble.com/SeaGenerator-in-overview2-branch-tp5761296p57... when I add something like this in the style\polygons file: natural=land [0x4a resolution 10] and use --precomp-sea. As I already wrote, the polygon type 0x4a is hardcoded in mkgmap: 1) mkgmap generates 0x4a polygons for the whole map when you don't use --transparent 2) polygons with type 0x4 are NOT divided by the PolygonSubdivSizeSplitterFilter I am not sure what to make of this. The default style doesn't assign 0x4a to a polygon, it doesn't even have a rule for the natural=land polygons generated by the SeaGenerator. I was already wondering why we generate them. I assume the special treatment of 0x4a in PolygonSubdivSizeSplitterFilter was added because of the bug that was fixed in r2612. This is what happens if I remove the special case for 0x4a: - With r2613 and the (unchanged) default style I see no change in any output file - With r2613 and the above modification I see that the error messages are gone So I guess I should just remove the special case? Gerd P.S. Felix, get well soon!
Uups, sorry, --transparent=false generates polygon type 0x4b. Type 0x4a seems to be reserved for polygons used in the overview map: * In addition to a low detail map, the overview map contains a number of type * 0x4a polygons. These definition areas a labeled after and correspond to * the detail map img files. I think that means that 0x4a should not be used in the style if an overview map is wanted ? Gerd GerdP wrote
Hi all,
I was able to reproduce the error messages reported by Felx : http://gis.19327.n5.nabble.com/SeaGenerator-in-overview2-branch-tp5761296p57...
when I add something like this in the style\polygons file: natural=land [0x4a resolution 10] and use --precomp-sea.
As I already wrote, the polygon type 0x4a is hardcoded in mkgmap: 1) mkgmap generates 0x4a polygons for the whole map when you don't use --transparent 2) polygons with type 0x4 are NOT divided by the PolygonSubdivSizeSplitterFilter
I am not sure what to make of this. The default style doesn't assign 0x4a to a polygon, it doesn't even have a rule for the natural=land polygons generated by the SeaGenerator. I was already wondering why we generate them.
I assume the special treatment of 0x4a in PolygonSubdivSizeSplitterFilter was added because of the bug that was fixed in r2612. This is what happens if I remove the special case for 0x4a: - With r2613 and the (unchanged) default style I see no change in any output file - With r2613 and the above modification I see that the error messages are gone
So I guess I should just remove the special case?
Gerd P.S. Felix, get well soon!
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5761432.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I thought 0x4a are the polygons that correspond with the tile borders so it shouldnt be used at all in the style file for other purposes.
--transparent=false generates polygon type 0x4b. Type 0x4a seems to be reserved for polygons used in the overview map: * In addition to a low detail map, the overview map contains a number of type * 0x4a polygons. These definition areas a labeled after and correspond to * the detail map img files.
I think that means that 0x4a should not be used in the style if an overview map is wanted ?
Gerd
GerdP wrote
Hi all,
I was able to reproduce the error messages reported by Felx : http://gis.19327.n5.nabble.com/SeaGenerator-in-overview2-branch-tp5761296p57...
when I add something like this in the style\polygons file: natural=land [0x4a resolution 10] and use --precomp-sea.
As I already wrote, the polygon type 0x4a is hardcoded in mkgmap: 1) mkgmap generates 0x4a polygons for the whole map when you don't use --transparent 2) polygons with type 0x4 are NOT divided by the PolygonSubdivSizeSplitterFilter
I am not sure what to make of this. The default style doesn't assign 0x4a to a polygon, it doesn't even have a rule for the natural=land polygons generated by the SeaGenerator. I was already wondering why we generate them.
I assume the special treatment of 0x4a in PolygonSubdivSizeSplitterFilter was added because of the bug that was fixed in r2612. This is what happens if I remove the special case for 0x4a: - With r2613 and the (unchanged) default style I see no change in any output file - With r2613 and the above modification I see that the error messages are gone
So I guess I should just remove the special case?
Gerd P.S. Felix, get well soon!
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5761432.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko, yes, thats what I wanted to say, but I don't know if Felix uses it. Anyway I think it is a good idea to flag this with --check-styles. Gerd
Date: Fri, 17 May 2013 08:55:41 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] polygon type 0x4a
Hi Gerd, I thought 0x4a are the polygons that correspond with the tile borders so it shouldnt be used at all in the style file for other purposes.
--transparent=false generates polygon type 0x4b. Type 0x4a seems to be reserved for polygons used in the overview map: * In addition to a low detail map, the overview map contains a number of type * 0x4a polygons. These definition areas a labeled after and correspond to * the detail map img files.
I think that means that 0x4a should not be used in the style if an overview map is wanted ?
Gerd
GerdP wrote
Hi all,
I was able to reproduce the error messages reported by Felx : http://gis.19327.n5.nabble.com/SeaGenerator-in-overview2-branch-tp5761296p57...
when I add something like this in the style\polygons file: natural=land [0x4a resolution 10] and use --precomp-sea.
As I already wrote, the polygon type 0x4a is hardcoded in mkgmap: 1) mkgmap generates 0x4a polygons for the whole map when you don't use --transparent 2) polygons with type 0x4 are NOT divided by the PolygonSubdivSizeSplitterFilter
I am not sure what to make of this. The default style doesn't assign 0x4a to a polygon, it doesn't even have a rule for the natural=land polygons generated by the SeaGenerator. I was already wondering why we generate them.
I assume the special treatment of 0x4a in PolygonSubdivSizeSplitterFilter was added because of the bug that was fixed in r2612. This is what happens if I remove the special case for 0x4a: - With r2613 and the (unchanged) default style I see no change in any output file - With r2613 and the above modification I see that the error messages are gone
So I guess I should just remove the special case?
Gerd P.S. Felix, get well soon!
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5761432.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ 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
sorry, I'm really not having had time the last 7 days, nor will I the next 7 days in future. I DO NOT use 0x4a or 0x4b in my polygons nor lines file. Most of the errors depend on the line file. Not sure if polygon file is responsible for any of the errors. Anyhow it only/still happens on the Australia-Oceania extract. The error is still there, I will track it down within 10-14 days (but no earlier than 10 days). On 17.05.2013 03:00, Gerd Petermann wrote:
Hi Minko,
yes, thats what I wanted to say, but I don't know if Felix uses it. Anyway I think it is a good idea to flag this with --check-styles.
Gerd
Date: Fri, 17 May 2013 08:55:41 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] polygon type 0x4a
Hi Gerd, I thought 0x4a are the polygons that correspond with the tile borders so it shouldnt be used at all in the style file for other purposes.
--transparent=false generates polygon type 0x4b. Type 0x4a seems to be reserved for polygons used in the overview map: * In addition to a low detail map, the overview map contains a number of type * 0x4a polygons. These definition areas a labeled after and correspond to * the detail map img files.
I think that means that 0x4a should not be used in the style if an overview map is wanted ?
Gerd
GerdP wrote
Hi all,
I was able to reproduce the error messages reported by Felx :
http://gis.19327.n5.nabble.com/SeaGenerator-in-overview2-branch-tp5761296p57...
when I add something like this in the style\polygons file: natural=land [0x4a resolution 10] and use --precomp-sea.
As I already wrote, the polygon type 0x4a is hardcoded in mkgmap: 1) mkgmap generates 0x4a polygons for the whole map when you don't use --transparent 2) polygons with type 0x4 are NOT divided by the PolygonSubdivSizeSplitterFilter
I am not sure what to make of this. The default style doesn't assign 0x4a to a polygon, it doesn't even have a rule for the natural=land polygons generated by the SeaGenerator. I was already wondering why we generate them.
I assume the special treatment of 0x4a in PolygonSubdivSizeSplitterFilter was added because of the bug that was fixed in r2612. This is what happens if I remove the special case for 0x4a: - With r2613 and the (unchanged) default style I see no change in any output file - With r2613 and the above modification I see that the error messages are gone
So I guess I should just remove the special case?
Gerd P.S. Felix, get well soon!
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context:
http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5761432.html
Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, yes, the error is printed when a polygon is written, and since you don't use 0x4a the error seems to be caused by the overview builder itself. I'll try to find out what happens. Gerd Date: Fri, 24 May 2013 23:23:31 -0400 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] polygon type 0x4a sorry, I'm really not having had time the last 7 days, nor will I the next 7 days in future. I DO NOT use 0x4a or 0x4b in my polygons nor lines file. Most of the errors depend on the line file. Not sure if polygon file is responsible for any of the errors. Anyhow it only/still happens on the Australia-Oceania extract. The error is still there, I will track it down within 10-14 days (but no earlier than 10 days). On 17.05.2013 03:00, Gerd Petermann wrote: Hi Minko, yes, thats what I wanted to say, but I don't know if Felix uses it. Anyway I think it is a good idea to flag this with --check-styles. Gerd > Date: Fri, 17 May 2013 08:55:41 +0200 > From: ligfietser@online.nl > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] polygon type 0x4a > > Hi Gerd, > I thought 0x4a are the polygons that correspond with the tile borders so it shouldnt be used at all in the style file for other purposes. > > > > --transparent=false generates polygon type 0x4b. > > Type 0x4a seems to be reserved for polygons used in the overview map: > > * In addition to a low detail map, the overview map contains a number > > of > > type > > * 0x4a polygons. These definition areas a labeled after and correspond > > to > > * the detail map img files. > > > > I think that means that 0x4a should not be used in the style if an > > overview > > map is > > wanted ? > > > > Gerd > > > > > > GerdP wrote > > > Hi all, > > > > > > I was able to reproduce the error messages reported by Felx : > > > http://gis.19327.n5.nabble.com/SeaGenerator-in-overview2-branch-tp5761296p57... > > > > > > when I add something like this in the style\polygons file: > > > natural=land [0x4a resolution 10] > > > and use --precomp-sea. > > > > > > As I already wrote, the polygon type 0x4a is hardcoded in mkgmap: > > > 1) mkgmap generates 0x4a polygons for the whole map when you don't > > > use > > > --transparent > > > 2) polygons with type 0x4 are NOT divided by the > > > PolygonSubdivSizeSplitterFilter > > > > > > I am not sure what to make of this. > > > The default style doesn't assign 0x4a to a polygon, it doesn't even > > > have a > > > rule for the > > > natural=land polygons generated by the SeaGenerator. I was already > > > wondering why > > > we generate them. > > > > > > I assume the special treatment of 0x4a in > > > PolygonSubdivSizeSplitterFilter > > > was added > > > because of the bug that was fixed in r2612. > > > This is what happens if I remove the special case for 0x4a: > > > - With r2613 and the (unchanged) default style I see no change in > > > any > > > output file > > > - With r2613 and the above modification I see that the error > > > messages are > > > gone > > > > > > So I guess I should just remove the special case? > > > > > > Gerd > > > P.S. Felix, get well soon! > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > > > mkgmap-dev@.org > > > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > -- > > View this message in context: > > http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5761432.html > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > _______________________________________________ > > 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 _______________________________________________ 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 Gerd This might have nothing to do with the issue but I've been curious why all basemaps ( in the past) & now overview maps cause Mapsource & Basecamp to crash when the tdb lock byte is set. This interestingly does not happen when cgpsmapper is used to create the basemap . One of the differences seems to be that the latter includes a 0x4b polygon to define the outline.(+ Background=Y) Am I correct that the main outline / frame (4b polygon) is not defined as such but presumably calculated by Mapsource? This might lead to unwanted effects? BW the overview maps work really well with reduced map windows. .. Nick -- View this message in context: http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5763111.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick, up to now the routine that creates the overview map doesn't add a 0x4b polygon, but normally, the tiles contain 0x4b polygons, and those are added. I think you are right that this can lead to problems if the combined tiles don't form a rectangle, so I should probably change the code so that the existing 0x4b polygons are ignored and a final new one is calculated. Gerd
Date: Tue, 28 May 2013 23:42:40 -0700 From: osm@pinns.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] polygon type 0x4a
Hi Gerd
This might have nothing to do with the issue but I've been curious why all basemaps ( in the past) & now overview maps cause Mapsource & Basecamp to crash when the tdb lock byte is set. This interestingly does not happen when cgpsmapper is used to create the basemap . One of the differences seems to be that the latter includes a 0x4b polygon to define the outline.(+ Background=Y) Am I correct that the main outline / frame (4b polygon) is not defined as such but presumably calculated by Mapsource? This might lead to unwanted effects?
BW the overview maps work really well with reduced map windows.
.. Nick
-- View this message in context: http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5763111.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I think others , ie Felix & Minko, have also hinted at 4a & 4b not to be used in a style - if one is creating an overview map . I see 4b functioning as an essential 'container' holding the various 4a polygons together ( its often used in NT maps to represent the sea/ocean). Interestingly, the error message caused by the 'locked flag,' is less severe when adding a 4b polygon. r Nick -- View this message in context: http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5763173.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick,
I think others , ie Felix & Minko, have also hinted at 4a & 4b not to be used in a style - if one is creating an overview map .
yes, I've added a check for this in --check-styles
I see 4b functioning as an essential 'container' holding the various 4a polygons together ( its often used in NT maps to represent the sea/ocean). Interestingly, the error message caused by the 'locked flag,' is less severe when adding a 4b polygon.
Please try r2627, this adds now the 4a background polygon. Gerd
Hi Gerd Thanks for that - will give it a go. Nick -- View this message in context: http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5763281.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
the latest overview2 branch (snapshot taken 24 hours ago) runs through fine for me. No more errors on australia-oceania. (because I can't find the thread right now - I do need more than 8 levels. So please keep the behavior of the overview maps restarting at level 0, and not continue-ing - that's also how most Garmin overview maps that I checked do it..) On 29.05.2013 12:23, Gerd Petermann wrote:
Hi Nick,
I think others , ie Felix & Minko, have also hinted at 4a & 4b not to be used in a style - if one is creating an overview map .
yes, I've added a check for this in --check-styles
I see 4b functioning as an essential 'container' holding the various 4a polygons together ( its often used in NT maps to represent the sea/ocean). Interestingly, the error message caused by the 'locked flag,' is less severe when adding a 4b polygon.
Please try r2627, this adds now the 4a background polygon.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 31/05/13 03:05, Felix Hartmann wrote:
(because I can't find the thread right now - I do need more than 8 levels. So please keep the behavior of the overview maps restarting at level 0, and not continue-ing - that's also how most Garmin overview maps that I checked do it..)
If you want to create a map that starts with 0, then just do it by specifying --overview-levels=0:17,... There is no reason for mkgmap to re-write a perfectly valid levels spec. ..Steve
Hi, Steve Ratcliffe wrote
On 31/05/13 03:05, Felix Hartmann wrote:
(because I can't find the thread right now - I do need more than 8 levels. So please keep the behavior of the overview maps restarting at level 0, and not continue-ing - that's also how most Garmin overview maps that I checked do it..)
If you want to create a map that starts with 0, then just do it by specifying --overview-levels=0:17,...
There is no reason for mkgmap to re-write a perfectly valid levels spec.
This will produce a warning. It would be impossible to use level in the style rules if both levels and overview-levels start with 0. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/polygon-type-0x4a-tp5761430p5763517.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Steve, I don't know which is the "correct" usage. But actual syntax in style does only allow to use each level once. For me actual stylesyntax is quiet logicaland should be kept. Otherwise you have overview_level=<number> and level=<number>and overview_level will also influence normal map. Henning Am 31.05.2013 13:56, schrieb Steve Ratcliffe:
On 31/05/13 03:05, Felix Hartmann wrote:
(because I can't find the thread right now - I do need more than 8 levels. So please keep the behavior of the overview maps restarting at level 0, and not continue-ing - that's also how most Garmin overview maps that I checked do it..) If you want to create a map that starts with 0, then just do it by specifying --overview-levels=0:17,...
There is no reason for mkgmap to re-write a perfectly valid levels spec.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (7)
-
Felix Hartmann -
Gerd Petermann -
GerdP
-
Henning Scholland -
Minko -
nwillink -
Steve Ratcliffe