[mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

Mon May 12 07:17:08 BST 2014

Hi Gerd, 

I certainly was not envisioning anything with SQL! More like an
"ini-file". At present the program itself and the default styles have to
address all kinds of devices, so they probably play it safe. Users can
customise the program and styles or develop their own, but there is no
mechanism to support sharing the nuances of each type of device within
the distribution. What I am suggesting will allow some of the
differences to be collected, and 

Let's see if I can work through an example. 

1) the command line 

java -jar mkgmap.jar ........ --target-device=oregon450t 

2) the "device capability database", let's call it "devcap" 

[oregon450t] 

camp_site_poi_type=0x2b03 

routable_types=1,2,3,4,5 

has_extended_icons=true 

3) the styles 

tourism=campsite & mkgmap:device=oregon450t {} [0x2b05 resolution 24] 

tourism=campsite & mkgmap:device!=oregon450t {} [0x2b03 resolution 24] 

tourism=campsite & devcap:has_extended_icons=true {} [0x2b05 resolution
24] 

4) the styles, if we could use variables in the last block 

tourism=campsite {} [$(devcap:camp_site_poi_type) resolution 24] 

5) the style checker 

respects the routable_types information from devcap to generate/suppress
warnings 

6) some kind of simple 'include' function in the devcap file to allow
device families to be used 

[oregon] 

camp_site_poi_type=0x2b04 

routable_types=1,2,3,4,5 

[oregon450t] 

include oregon 

camp_site_poi_type=0x2b04 

All pretty simple basic functions, which when you combine them, open a
world of possibilities. You can keep it really simple by just
implementing the option plus exposing that in the styles, or you can
make it really complex by putting all the information about POI icons,
supported features etc in the devcap file. Once the framework is there,
it can be leveraged (I hate that word) for many things limited only by
imagination. 

I'm afraid my experience is limited to various Nuvi models plus the
wealth of vicarious experience gained from following this list! 

Colin 

On 2014-05-12 07:04, Gerd Petermann wrote: 

> Hi Colin,
> 
> I am not sure what you mean. Let me try an example:
> I am aware that my Oregon 450t needs e.g.
> tourism=camp_site [0x2b05 resolution 24]
> instead of
> tourism=camp_site [0x2b03 resolution 24]
> which is used in the default style.
> 
> If I got you right, you want to create some kind of database to keep track of these 
> differences and a style that uses a symbol to reference the database.
> So, for my example, we would have a database with a symbol
> "camp_site_poi_type" and a default value 0x2b03 and a special value 
> for the Oregon 450t containing 0x2b05.
> The style would then use something like
> 
> tourism=camp_site [db:camp_site_poi_type resolution 24]
> 
> When reading the style, mkgmap could look up the database to find 
> the right value.
> 
> If the database would use SQL, we probably need a few tables 
> for device types, groups of device types, firmware versions, etc.
> Without SQL, it might be another XML file. 
> 
> Any ideas how many differences we have and how they could be stored?
> 
> Gerd
> 
> -------------------------
> Date: Sun, 11 May 2014 12:22:50 +0200
> From: colin.smale at xs4all.nl
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
> 
> As there are clearly differences in features supported by various models, would it maybe be an idea to externalise the differences in some way? How about a file to contain the capabilities of device types, an option to target a particular entry in that file, and a way to expose the selected device in the style files? That could also help address the differences in supported POI categories and icons.
> Colin
> 
> On 2014-05-11 11:52, Gerd Petermann wrote:
> 
>> Hi Minko,
>> 
>> thanks for your help. This is now implemented with r3269.
>> 
>> Gerd
>> 
>>> Date: Sun, 11 May 2014 11:45:47 +0200
>>> From: ligfietser at online.nl
>>> To: mkgmap-dev at lists.mkgmap.org.uk
>>> Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
>>> 
>>>> what about 0xa ? Or was that meant to be 0x1a ?
>>> 
>>> Hi Gerd
>>> 
>>> 0x0a gives also a routing error, so everything in the range 
>>> 0x01-0x13, 0x16 and 0x1b
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
>> 
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev [1]
> 
> _______________________________________________ mkgmap-dev mailing list mkgmap-dev at lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev [1]

Links:
------
[1] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140512/d73df1a3/attachment-0001.html>