The latest impressively detailed manual tells us that: If the type is not extended, it must be >= 0x0100 for a point, I might be wrong but looking at the img structure I come to a different conclusion: Non extended POIs have their 8th bit set to denote the possible inclusion of a subtype. If so I make the maximum for a non extended POI to be &7F and not &FF as perhaps was implied? '< 0x3f for a line, and < 0x7f for a polygon.' Perhaps explain why non extended lines can't be &40+ ( ie bits used for direction & length of bitstream) Regards nick -- View this message in context: http://gis.19327.n5.nabble.com/type-numbers-again-tp5818050.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick
Non extended POIs have their 8th bit set to denote the possible inclusion of a subtype. If so I make the maximum for a non extended POI to be &7F and not &FF as perhaps was implied?
The has_subtype bit is bit 23 of the LBL offset field and not the type field. Its always possible that the top bit of the type field is used for something else or is just ignored. Have you tried such values and do they work? ..Steve
Hi Steve 'The has_subtype bit is bit 23 of the LBL offset field and not the type field. ' This is news to me - I'm following Mechalas who I must admit at times doesn't seem to be that reliable. I have not as yet tried pois > &7f00 but have been looking at NT extended pois . I have my suspicion that such pois have a limit of &16F or even lower This is by examining extended pois with 8th bit of their subtypes set and by looking at the ' information stream' which follows a label if any. I notice that mkgmap sets this bit for ,say, bus stops and adds eo 09 00 00 00 Looking at NT imgs I'm surmising that the length of this information stream is often extended if t(third?) and or fourth byte after the text null terminator has a value> &70 There are 2 bytes that precede any label, ie F1 31 but these cannot by them selves provide the length of the total poi block as I've come across pois with identical f1 31setc but different lengths. Somehow if the fourth value <&70 ,( ?<&5F) it indicates the start of the next extended poi. My findings are not conclusive - you may know more. So if extended pois have a limit below 1FF then perhaps pois have as well. regards Nick On 23/09/2014 21:27, Steve Ratcliffe [via GIS] wrote:
Hi Nick
Non extended POIs have their 8th bit set to denote the possible inclusion of a subtype. If so I make the maximum for a non extended POI to be &7F and not &FF as perhaps was implied?
The has_subtype bit is bit 23 of the LBL offset field and not the type field.
Its always possible that the top bit of the type field is used for something else or is just ignored. Have you tried such values and do they work?
..Steve _______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5818286&i=0> 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/type-numbers-again-tp5818050p5818286.html To unsubscribe from type numbers , again..., click here <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5818050&code=b3NtQHBpbm5zLmNvLnVrfDU4MTgwNTB8MTM1NTM3MTE1MQ==>. 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/type-numbers-again-tp5818050p5818292.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
That is interesting about the extended bit is set in the lbl However, this still throws up a puzzle I have set bus stops to 1ff08 and yes, they all show up using default style There is an area where , as mentioned before, a bus stop gets the 7th bit set of the second byte resulting in e0 09 00 00 00 01 - this happens with bus stop type = 10208 However, when I change the type number to 1FF08 these bytes disappear and the 7th bit is unset. To me this is what I expected looking at various NT imgs. It might mean that POIs do have a maximum of 1FF only if 7th bit of subtype is not set? put both imgs at :www.pinns.co.uk/mps/1ff08.zip You'll see what I mean at &1F8EB BTW mkgmap issues no warning for POIs >1FF1F regards Nick -- View this message in context: http://gis.19327.n5.nabble.com/type-numbers-again-tp5818050p5818302.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 24/09/14 07:31, nwillink wrote:
To me this is what I expected looking at various NT imgs. It might mean that POIs do have a maximum of 1FF only if 7th bit of subtype is not set?
I don't know much about extended types. The mkgmap code says this for extended points: * type is written first, then subtype. * type has no flags so its possible range is 0x0 to 0xff * subtype has two flags: * 0x20 - has a label * 0x80 - has extra bytes after the label (describes marine buoy lights etc) so the possible subtype range is 0-0x1f (as expected) * There are no flags on LBL offset. Of course there may be other flags we don't know about and the possible range may not be fully utilised by any device. ..Steve
So far I 've gathered that when subtype has 0x80 set no lbl pointers are given ; instead if byte 7 >&EF , ie F0 or F1 then byte 8 and 7 contain an algo for calculating the size of label that follows terminated by 0. This is followed by 3 bytes which determine the length of the information stream , depending, possibly, on the 8th bit being set . It's still a mystery: btw 0x 40 flag when set always add an extra 3 bytes Perhaps like you , I have no idea what all these bytes mean. Nick On 24/09/2014 10:39, Steve Ratcliffe [via GIS] wrote:
On 24/09/14 07:31, nwillink wrote:
To me this is what I expected looking at various NT imgs. It might mean that POIs do have a maximum of 1FF only if 7th bit of subtype is not set?
I don't know much about extended types. The mkgmap code says this for extended points:
* type is written first, then subtype. * type has no flags so its possible range is 0x0 to 0xff * subtype has two flags: * 0x20 - has a label * 0x80 - has extra bytes after the label (describes marine buoy lights etc) so the possible subtype range is 0-0x1f (as expected) * There are no flags on LBL offset.
Of course there may be other flags we don't know about and the possible range may not be fully utilised by any device.
..Steve _______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5818312&i=0> 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/type-numbers-again-tp5818050p5818312.html To unsubscribe from type numbers , again..., click here <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5818050&code=b3NtQHBpbm5zLmNvLnVrfDU4MTgwNTB8MTM1NTM3MTE1MQ==>. 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/type-numbers-again-tp5818050p5818321.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (2)
-
nwillink -
Steve Ratcliffe