invalid types in check-styles
Hi Interesting 'bug' when using check-styles. It had me foxed as it actually by chance highlighted lines I didn't use in my TYP file. invalid type 0x11f for POLYLINE It transpires that when replacing 11f with 11f00 the type number is correctly identified as valid. I checked it with several lines, with and without the zero subtypes. -- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, yes, 0x11f00 is recognized as an extended type. What bug do you mean? Should mkgmap interpret 0x11f as 0x11f00 when used in the lines or polygons file? Gerd
Date: Mon, 30 Dec 2013 02:07:24 -0800 From: osm@pinns.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] invalid types in check-styles
Hi
Interesting 'bug' when using check-styles.
It had me foxed as it actually by chance highlighted lines I didn't use in my TYP file.
invalid type 0x11f for POLYLINE
It transpires that when replacing 11f with 11f00 the type number is correctly identified as valid. I checked it with several lines, with and without the zero subtypes.
-- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157.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 Gerd 0x11f is the same as 0x11f00 - both have been valid expressions in the past. However, the style checker tells me that 11f is invalid. This applies to I think all extended types , ie it tells me 10A (without the 00) is invalid. It accepts 10A00 but not 10A It accepts 11F00 but not 11F I agree 10A00 is the more accurate way of defining an extended line but it might be confusing to flag them as invalid. r Nick On 30/12/2013 15:49, GerdP [via GIS] wrote:
Hi,
yes, 0x11f00 is recognized as an extended type. What bug do you mean? Should mkgmap interpret 0x11f as 0x11f00 when used in the lines or polygons file?
Gerd
Date: Mon, 30 Dec 2013 02:07:24 -0800
From: [hidden email] </user/SendEmail.jtp?type=node&node=5791203&i=0> To: [hidden email] </user/SendEmail.jtp?type=node&node=5791203&i=1> Subject: [mkgmap-dev] invalid types in check-styles
Hi
Interesting 'bug' when using check-styles.
It had me foxed as it actually by chance highlighted lines I didn't use in my TYP file.
invalid type 0x11f for POLYLINE
It transpires that when replacing 11f with 11f00 the type number is correctly identified as valid. I checked it with several lines, with and without the zero subtypes.
-- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5791203&i=2> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5791203&i=3> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912...
To unsubscribe from invalid types in check-styles, click here <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5791157&code=b3NtQHBpbm5zLmNvLnVrfDU3OTExNTd8MTM1NTM3MTE1MQ==>. NAML <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick, well, 0x11f00 is 256 * 0x11f, so it is not the same, but if I get you right you want mkgmap to interpret all values >= 0x100 and x as if they were written with a 00 at the end. What is the upper bound (x) ? See also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017797.html Gerd Date: Mon, 30 Dec 2013 08:04:31 -0800 From: osm@pinns.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] invalid types in check-styles Hi Gerd 0x11f is the same as 0x11f00 - both have been valid expressions in the past. However, the style checker tells me that 11f is invalid. This applies to I think all extended types , ie it tells me 10A (without the 00) is invalid. It accepts 10A00 but not 10A It accepts 11F00 but not 11F I agree 10A00 is the more accurate way of defining an extended line but it might be confusing to flag them as invalid. r Nick On 30/12/2013 15:49, GerdP [via GIS] wrote: Hi, yes, 0x11f00 is recognized as an extended type. What bug do you mean? Should mkgmap interpret 0x11f as 0x11f00 when used in the lines or polygons file? Gerd > Date: Mon, 30 Dec 2013 02:07:24 -0800 > From: [hidden email] > To: [hidden email] > Subject: [mkgmap-dev] invalid types in check-styles > > Hi > > Interesting 'bug' when using check-styles. > > It had me foxed as it actually by chance highlighted lines I didn't use in > my TYP file. > > invalid type 0x11f for POLYLINE > > It transpires that when replacing 11f with 11f00 the type number is > correctly identified as valid. > I checked it with several lines, with and without the zero subtypes. > > > > > > -- > View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list > [hidden email] > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list [hidden email] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev If you reply to this email, your message will be added to the discussion below: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912... To unsubscribe from invalid types in check-styles, click here. NAML View this message in context: Re: invalid types in check-styles 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 Gerd No , its only the style checker that throws up the anomaly. I might have missed something about mkgmap requiring 00 subtypes ? although I have not encountered any problems leaving them out for extended types The highest subtype is 1F and the highest type for lines/polylines, I think, &1FF making 1FF1F the highest number. On 30/12/2013 17:17, GerdP [via GIS] wrote:
Hi Nick,
well, 0x11f00 is 256 * 0x11f, so it is not the same, but if I get you right you want mkgmap to interpret all values >= 0x100 and x as if they were written with a 00 at the end. What is the upper bound (x) ?
See also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017797.html
Gerd
------------------------------------------------------------------------ Date: Mon, 30 Dec 2013 08:04:31 -0800 From: [hidden email] </user/SendEmail.jtp?type=node&node=5791215&i=0> To: [hidden email] </user/SendEmail.jtp?type=node&node=5791215&i=1> Subject: Re: [mkgmap-dev] invalid types in check-styles
Hi Gerd
0x11f is the same as 0x11f00 - both have been valid expressions in the past.
However, the style checker tells me that 11f is invalid. This applies to I think all extended types , ie it tells me 10A (without the 00) is invalid. It accepts 10A00 but not 10A It accepts 11F00 but not 11F I agree 10A00 is the more accurate way of defining an extended line but it might be confusing to flag them as invalid.
r
Nick
On 30/12/2013 15:49, GerdP [via GIS] wrote:
Hi,
yes, 0x11f00 is recognized as an extended type. What bug do you mean? Should mkgmap interpret 0x11f as 0x11f00 when used in the lines or polygons file?
Gerd
> Date: Mon, 30 Dec 2013 02:07:24 -0800
> From: [hidden email] <http:///user/SendEmail.jtp?type=node&node=5791203&i=0> > To: [hidden email] <http:///user/SendEmail.jtp?type=node&node=5791203&i=1> > Subject: [mkgmap-dev] invalid types in check-styles > > Hi > > Interesting 'bug' when using check-styles. > > It had me foxed as it actually by chance highlighted lines I didn't use in > my TYP file. > > invalid type 0x11f for POLYLINE > > It transpires that when replacing 11f with 11f00 the type number is > correctly identified as valid. > I checked it with several lines, with and without the zero subtypes. > > > > > > -- > View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list > [hidden email] <http:///user/SendEmail.jtp?type=node&node=5791203&i=2> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list [hidden email] <http:///user/SendEmail.jtp?type=node&node=5791203&i=3> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912...
To unsubscribe from invalid types in check-styles, click here <http://>. NAML <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble:email.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble:email.naml-instant_emails%21nabble:email.naml-send_instant_email%21nabble:email.naml>
------------------------------------------------------------------------ View this message in context: Re: invalid types in check-styles <http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p5791212.html> Sent from the Mkgmap Development mailing list archive <http://gis.19327.n5.nabble.com/Mkgmap-Development-f5324443.html> at Nabble.com.
_______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5791215&i=2> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5791215&i=3> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912...
To unsubscribe from invalid types in check-styles, click here <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5791157&code=b3NtQHBpbm5zLmNvLnVrfDU3OTExNTd8MTM1NTM3MTE1MQ==>. NAML <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick, nwillink wrote
Hi Gerd
No , its only the style checker that throws up the anomaly.
I can't confirm that. A line with type 0x11f is written as type 0x1f, so the test is right to complain. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi all, got no answer on the question what mkgmap should do with a type like 0x11f in the lines file. The current behaviour is that it quietly ignores the error because it treats 0x11f like 0x1f. I'd prefer to write an error message and completely ignore the corresponding line in the style. Gerd nwillink wrote
Hi Gerd
No , its only the style checker that throws up the anomaly.
I might have missed something about mkgmap requiring 00 subtypes ? although I have not encountered any problems leaving them out for extended types
The highest subtype is 1F and the highest type for lines/polylines, I think, &1FF making 1FF1F the highest number.
On 30/12/2013 17:17, GerdP [via GIS] wrote:
Hi Nick,
well, 0x11f00 is 256 * 0x11f, so it is not the same, but if I get you right you want mkgmap to interpret all values >= 0x100 and x as if they were written with a 00 at the end. What is the upper bound (x) ?
See also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017797.html
Gerd
------------------------------------------------------------------------ Date: Mon, 30 Dec 2013 08:04:31 -0800 From: [hidden email] </user/SendEmail.jtp?type=node&node=5791215&i=0> To: [hidden email] </user/SendEmail.jtp?type=node&node=5791215&i=1> Subject: Re: [mkgmap-dev] invalid types in check-styles
Hi Gerd
0x11f is the same as 0x11f00 - both have been valid expressions in the past.
However, the style checker tells me that 11f is invalid. This applies to I think all extended types , ie it tells me 10A (without the 00) is invalid. It accepts 10A00 but not 10A It accepts 11F00 but not 11F I agree 10A00 is the more accurate way of defining an extended line but it might be confusing to flag them as invalid.
r
Nick
On 30/12/2013 15:49, GerdP [via GIS] wrote:
Hi,
yes, 0x11f00 is recognized as an extended type. What bug do you mean? Should mkgmap interpret 0x11f as 0x11f00 when used in the lines or polygons file?
Gerd
> Date: Mon, 30 Dec 2013 02:07:24 -0800
> From: [hidden email] <http:///user/SendEmail.jtp?type=node&node=5791203&i=0>; > To: [hidden email] <http:///user/SendEmail.jtp?type=node&node=5791203&i=1>; > Subject: [mkgmap-dev] invalid types in check-styles > > Hi > > Interesting 'bug' when using check-styles. > > It had me foxed as it actually by chance highlighted lines I didn't use in > my TYP file. > > invalid type 0x11f for POLYLINE > > It transpires that when replacing 11f with 11f00 the type number is > correctly identified as valid. > I checked it with several lines, with and without the zero subtypes. > > > > > > -- > View this message in context:
http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list > [hidden email] <http:///user/SendEmail.jtp?type=node&node=5791203&i=2>; > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list [hidden email] <http:///user/SendEmail.jtp?type=node&node=5791203&i=3>; http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below:
http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912...
To unsubscribe from invalid types in check-styles, click here <http://>;. NAML
------------------------------------------------------------------------ View this message in context: Re: invalid types in check-styles <http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912...; Sent from the Mkgmap Development mailing list archive <http://gis.19327.n5.nabble.com/Mkgmap-Development-f5324443.html>; at Nabble.com.
_______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5791215&i=2> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5791215&i=3> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57912...
To unsubscribe from invalid types in check-styles, click here <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5791157&code=b3NtQHBpbm5zLmNvLnVrfDU3OTExNTd8MTM1NTM3MTE1MQ==>;. NAML <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>;
-- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57915... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 02/01/14 22:00, GerdP wrote:
got no answer on the question what mkgmap should do with a type like 0x11f in the lines file. The current behaviour is that it quietly ignores the error because it treats 0x11f like 0x1f.
I would say that it is an error. I break the full type down as follows: 0xXYYZZ X is a flag for 'extended type' (0 or 1) YY is the type ZZ is the subtype (max 0x1f) I would always recommend using the full types, since the short forms cause so much confusion. ..Steve
Hi Steve, yes, it is an error. But how do you suggest to change mkgmap? The default style uses 0xYY in lines and polygons file, as we don't use extended types, and the range for YY is 00 to 3f for lines and 00 to 7f for polygons, and sub types are not supported for them. Should we interpret 0x3f00 like 0x3f and 0x11f like 0x11f00 ? If yes, should this produce an error message like style abc, file lines, line xyz, interpreting type 0x3f00 as 0x3f style abc, file polygons, line xyz, interpreting type 0x11f as extended type 0x11f00. Or do you vote for a change so that the user always has to write 0xXYYZZ ? Gerd Steve Ratcliffe wrote
On 02/01/14 22:00, GerdP wrote:
got no answer on the question what mkgmap should do with a type like 0x11f in the lines file. The current behaviour is that it quietly ignores the error because it treats 0x11f like 0x1f.
I would say that it is an error.
I break the full type down as follows:
0xXYYZZ
X is a flag for 'extended type' (0 or 1) YY is the type ZZ is the subtype (max 0x1f)
I would always recommend using the full types, since the short forms cause so much confusion.
..Steve _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p57915... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd
yes, it is an error. But how do you suggest to change mkgmap?
I'm not suggesting any change to mkgmap, apart from flagging errors wherever we currently silently truncate or mask out bits. I realise that all this is ambiguous, but this is how I see it: 0x1f means: normal, type 0x1f, no subtype 0x11f means: normal, type 0x1, subtype 0x1f 0x1011f means: extended, type 0x1, subtype 0x1f I seems that some people see 0x1011f as type 0x101 and subtype 0x1f, but extended types are in a completely separate area to normal types and 0x101 is not written to the img, just 0x01. Two things to note: 1. 0x100 would logically mean "type 0x1, subtype 0x00", but (in points) it is interpreted as "type 0x1, no subtype", and if I remember correctly that was a deliberate change as subtype 0x0 is not allowed or has reported problems. (subtype 0x0 is allowed for extended types so 0x10100 is fine and means "extended, type 0x01, subtype 0x00) 2. You can't express "normal, type 0x0, subtype 0xYY".
The default style uses 0xYY in lines and polygons file, as we don't use extended types, and the range for YY is 00 to 3f for lines and 00 to 7f for polygons, and sub types are not supported for them.
Should we interpret 0x3f00 like 0x3f I think it would be OK to be an error (especially since anyone who is using that currently is not getting what they expect), but it does seem a bit harsh to error on 0x3f00 as it is not confusing, so I don't mind if you make that change.
... and 0x11f like 0x11f00 ?
No. I think it is well established that extended types are written like 0x1xxyy, and as the subtype is typically not 0 the proposed shortened form would be only rarely usable. So I don't see the benefit of the extra ambiguity and confusion.
If yes, should this produce an error message like style abc, file lines, line xyz, interpreting type 0x3f00 as 0x3f Either make it an error or accept it without a message.
..Steve
participants (4)
-
Gerd Petermann -
GerdP
-
nwillink -
Steve Ratcliffe