[mkgmap-dev] mergeroads branch

Fri Sep 13 09:41:02 BST 2013

On 13.09.2013 08:46, Felix Hartmann wrote:
>
> On 12.09.2013 20:58, WanMil wrote:
>
>>> Felix, you're welcome :-)
>>> Getting such comments is the reason to implement and test these new
>>> features in a branch.
>>> I can easily add handling for mkgmap:access=no into the java sources.
>>>
>>> That requires to cleary define an order the access tags are handled. 
>>> The
>>> order is defined as follows:
>>>
>>> 1. mkgmap:access=no
>>>      => all access fields in the map are set to no
>>> 2. mkgmap:carpool=yes
>>>      => all access fiels are set to no, except carpool, emergency 
>>> and bus.
>>>         The through route bit is set to no.
>>>         This rule already existed in the java source code before my 
>>> changes
>>> 3. In all other cases all mkgmap:* access tags are evaluated.
>>>
>>> WanMil
>> I have comitted the changes. So you can start with adapting your style
>> and with testing.
>>
>> WanMil
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> Very good, however....
>
> I should have been more clear. I not only need mkgmap:access=no, but 
> also mkgmap:access=yes...
> For some special circumstances I want to make sure, that access rights 
> set to no beforehand, are reset to yes.
> I assumed the implementation would be done anyhow for yes and no - 
> however I think if I read the changed passage, only no will work.
>
> as for carpool - setting mkgmap:carpool=no is not logical regarding 
> the way garmin implements this. So maybe there should be a little note 
> in the inc/access that due to the way mkgmap:carpool works, setting it 
> to no is not possible (it wouldn't be clear what access rights to set).
>
> Oh yeah, I hope not only set but also add works for 
> mkgmap:access=yes/no.... (in order to set something explicit for 
> further treatment - as yes is not the same as "default/unset" while 
> working down the lines file (of course in the end in the garmin .img 
> yes is identical to default/unset - but before explicit vs implicit 
> could make a difference).
>
> Also the default inc/access should use that mkgmap:access=no IMHO (or 
> at least include a line "# you could also replace the following block 
> with mkgmap:access=no").
>
oh what happens if I do
{delete mkgmap:access=no/yes}  -- will it only delete the tag per se, or 
will it set mkgmap:bicycle or mkgmap:motorcar as well? I hope it does 
the same as until now, namely just deleting the tag (as the 
actions/consequences of the tag should only be evaluated once the 0x?? 
part is handled.....

what happens if I have the following line
bicycle=* {set mkgmap:bicycle='${bicycle}' }
will only bicycle=no be regarded, or will bicycle=private also be set as no?
will mkgmap crash/produce an error if bicycle=dismount or any other non 
recognised values is present?

I must say, the new access handling is really complicated - at least on 
my style. I'm trying to rewrite it to produce the old behaviour since 
well 3-4 hours, but still not near halfway...