type numbers , again...

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

type numbers , again...

nwillink
 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


 
Reply | Threaded
Open this post in threaded view
|

Re: type numbers , again...

Steve Ratcliffe
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]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: type numbers , again...

nwillink
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]
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.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: type numbers , again...

Steve Ratcliffe




>
>This is news to me - I'm following Mechalas who I must admit at times
>doesn't seem to be that reliable.
>
Yes forgot to mention that his document says that, but his imgdecode software uses the bit in the lbl offset field.  

Steve
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: type numbers , again...

nwillink
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



Reply | Threaded
Open this post in threaded view
|

Re: type numbers , again...

Steve Ratcliffe
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]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: type numbers , again...

nwillink
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]
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.
NAML