logo separator

[mkgmap-dev] type numbers , again...

From nwillink osm at pinns.co.uk on Tue Sep 23 22:39:04 BST 2014

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 
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.



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==>.
> <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140923/8275ffc9/attachment.html>

More information about the mkgmap-dev mailing list