<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi Gerd,</p>
<p>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 </p>
<p>Let's see if I can work through an example.</p>
<p>1) the command line</p>
<p>java -jar mkgmap.jar ........ --target-device=oregon450t</p>
<p>2) the "device capability database", let's call it "devcap"</p>
<p>[oregon450t]</p>
<p>camp_site_poi_type=0x2b03</p>
<p>routable_types=1,2,3,4,5</p>
<p>has_extended_icons=true</p>
<p>3) the styles</p>
<p>tourism=campsite & mkgmap:device=oregon450t {} [0x2b05 resolution 24]</p>
<p>tourism=campsite & mkgmap:device!=oregon450t {} [0x2b03 resolution 24]</p>
<p>tourism=campsite & devcap:has_extended_icons=true {} [0x2b05 resolution 24] </p>
<p>4) the styles, if we could use variables in the last block</p>
<p>tourism=campsite {} [$(devcap:camp_site_poi_type) resolution 24]</p>
<p>5) the style checker</p>
<p>respects the routable_types information from devcap to generate/suppress warnings</p>
<p>6) some kind of simple 'include' function in the devcap file to allow device families to be used</p>
<p>[oregon]</p>
<p>camp_site_poi_type=0x2b04</p>
<p>routable_types=1,2,3,4,5</p>
<p>[oregon450t]</p>
<p>include oregon</p>
<p>camp_site_poi_type=0x2b04</p>
<p> </p>
<p>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.</p>
<p>I'm afraid my experience is limited to various Nuvi models plus the wealth of vicarious experience gained from following this list!</p>
<p>Colin</p>
<div> </div>
<p>On 2014-05-12 07:04, Gerd Petermann wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div dir="ltr">Hi Colin,<br /><br />I am not sure what you mean. Let me try an example:<br />I am aware that my Oregon 450t needs e.g.<br />tourism=camp_site [0x2b05 resolution 24]<br />instead of<br />tourism=camp_site [0x2b03 resolution 24]<br />which is used in the default style.<br /><br />If I got you right, you want to create some kind of database to keep track of these <br />differences and a style that uses a symbol to reference the database.<br />So, for my example, we would have a database with a symbol<br />"camp_site_poi_type" and a default value 0x2b03 and a special value <br />for the Oregon 450t containing 0x2b05.<br />The style would then use something like<br /><br />tourism=camp_site [db:camp_site_poi_type resolution 24]<br /><br />When reading the style, mkgmap could look up the database to find <br />the right value.<br /><br />If the database would use SQL, we probably need a few tables <br />for device types, groups of device types, firmware versions, etc.<br />Without SQL, it might be another XML file. <br /><br />Any ideas how many differences we have and how they could be stored?<br /><br />Gerd<br /><br />
<div><hr id="stopSpelling" />Date: Sun, 11 May 2014 12:22:50 +0200<br />From: colin.smale@xs4all.nl<br />To: mkgmap-dev@lists.mkgmap.org.uk<br />Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.<br /><br /> 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.<br /> Colin<br /> <br />
<div> </div>
On 2014-05-11 11:52, Gerd Petermann wrote:<br />
<blockquote style="padding-left: 5px; border-left: #1010ff 2px solid;">
<div dir="ltr">Hi Minko,<br /><br />thanks for your help. This is now implemented with r3269.<br /><br />Gerd<br /><br />
<div>> Date: Sun, 11 May 2014 11:45:47 +0200<br />> From: ligfietser@online.nl<br />> To: mkgmap-dev@lists.mkgmap.org.uk<br />> Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.<br />> <br />> > what about 0xa ? Or was that meant to be 0x1a ?<br />> <br />> Hi Gerd<br />> <br />> 0x0a gives also a routing error, so everything in the range <br />> 0x01-0x13, 0x16 and 0x1b<br />> _______________________________________________<br />> mkgmap-dev mailing list<br />> mkgmap-dev@lists.mkgmap.org.uk<br />> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div>
</div>
<br />
<pre>_______________________________________________
mkgmap-dev mailing list
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
</pre>
</blockquote>
<br />_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div>
</div>
<!-- html ignored --><br />
<pre>_______________________________________________
mkgmap-dev mailing list
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
</pre>
</blockquote>
</body></html>