[mkgmap-dev] default style improvements

Sun Jan 6 08:53:01 GMT 2019

Hi Ticker,

I often travel on bike in "nowhere land", where hotels and restaurants 
are rare. So I think it is good to show both PoIs if a hotel contains a 
restaurant. Of course, it would be more relevant to know how other users 
of OSM Garmin maps think about this topic (I use my own style, so the 
changes to the default style are not relevant for me).

A different point I'd like to suggest is a new line type for unpaved 
highways (which are not tracks). Unpaved public highways may be not very 
common in Europe, but they are rather normal in other areas of the world.
The fact that they are rendered like paved highways makes many mappers 
think that it is useless to add this tag - and the little use of the 
surface tag in turn makes map makers think that it does not matter... 
Clouds of dust caused by other vehicles on that road or getting stuck in 
a muddy quagmire are not great user experiences.
Treating them differently for routing purposes is a good step, but that 
is not such visible to many users.

Regards,
Bernhard

Am 05.01.2019 um 18:18 schrieb Ticker Berkin:
> Hi Gerd
>
> I'd tried to get all the optical changes out of the way in the first 2
> patches, but I missed a few and it seemed easier to fix them as I
> spotted them.
>
> This last patch covered about 25 issues. I think it might take a long
> time to go through this process sequentially and, as it involves
> changes to just 3 or 4 files, it will be confusing do them in parallel,
> with multiple patches outstanding. I don't see any difficulty with
> having dialogs in parallel about individual aspects in a patch, based
> on my list of topics supplied with the first version of the patch.
>
> Regarding polygons and area tag:
>
> In the following, 'polygon' refers to a directly closed way or ways
> from a multipolygon relation.
>
> 'lines' can test if is dealing with a polygon with:
>     ... & (is_closed()=true | mkgmap:mp_created=true)
>
> If an element needs to be rendered as a line possibly also a polygon it
> needs a [... continue] in 'lines' in case it came from a closed way.
>
> In 'polygons', one cannot assume that the element has not already been
> rendered as a line.
>
> The area= tag is for OSM mappers to influence the meaning of polygons;
> mkgmap style should never set it.
>
> The treatment of polygons being rendered as lines and/or polygons in
> the absence of area=yes/no depends on the tag; for instance:
>
>   aeroway=runway is considered a line unless also has area=yes
>
>   highway=pedestrian always generates a line and, unless area=no, a
> polygon. This is the OSM representation of a square/plaza, and, in many
> cases, needs the routing given by the edge. The area tag is often
> missing, so assumed as yes.
>
>   highway=footway always generates a line and, if area=yes, a polygon.
> Again, the edge routing is might be needed. Some mappers use this for
> walking area that are joined to other walkways/paths, but it shouldn't
> be assumed to this, hence assumption of area=no.
>
> It seems reasonably safe and clearer to omit the polygon test if also
> testing area=yes. For instance, in 'lines'
>
>   aeroway=runway & area!=yes {name '${ref}'} [0x27 ...]
>
> in 'polygons' the polygon test is irrelevant anyway, but it needs the
> inverse of the additional clause in 'lines'
>
>   aeroway=runway & area=yes {name '${ref}'} [0x0e resolution 20]
>
> Obviously, a non-polygon with area=yes doesn't get rendered at all.
>
> Does this adequately explain my changes in this area?
>
>
> At the moment, only elements with internet_access= can generate
> multiple points. In your example of a hotel with a restaurant, I'd
> rather have the hotel POI than the restaurant one. Many hotels have
> restaurants, but most you wouldn't go out of your way to eat there or
> they are often for guests only. The same is true of some of the
> amenity/leisure/sport/tourist categories; they are more significant tha
> n any restaurant they contain.
>
> I must admit that this is an additional post-justification, I hadn't
> thought of this when I moved the rules down.
>
> Multiple POI from a single element, requiring massive reordering of the
> sections in 'points' and lots of [... continue]s looks a different
> problem that I don't want to address at the moment.
>
> Regards
> Ticker
>
> On Sat, 2019-01-05 at 08:43 +0000, Gerd Petermann wrote:
>> Hi Ticker,
>>
>> it would be easier to check if you would not mix simple optical
>> changes (additional/removed blanks) with functional changes ;)
>> I'd also prefer smaller patches, each one adressing only one problem.
>> This makes it easier to discuss the patch.
>>
>> 1) I do not yet understand the changes regarding area=yes and
>> multipolygons. Can you explain that, please?
>> 2) Why are the rules for food POI moved behind e.g.  tourism=hotel?
>>   I think you often find OSM objects tagged with both
>> amenity=restaurant and tourism=hotel,
>> and I'd prefer to find both. Probably a case for continue ?
>>
>> Gerd
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
>> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
>> Gesendet: Donnerstag, 3. Januar 2019 17:52
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] default style improvements
>>
>> Hi Gerd
>>
>> Here is another patch. I've made the changes as you suggested and the
>> following changes:
>>
>> When highway=path is converted into a cycleway or bridleway, add
>> foot=yes in case the inc/access[_country] rules don't allow foot on
>> the
>> resultant highway type
>>
>> Restrict which historic= are shown as polygons. The original patch
>> widened this too much.
>>
>> Regards
>> Ticker
>>
>> On Thu, 2019-01-03 at 14:56 +0000, Gerd Petermann wrote:
>>> Hi Ticker,
>>>
>>> yes please, my understanding was that the patch was not accepted.
>>>
>>> Gerd
>>>
>>> ________________________________________
>>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
>>> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
>>> Gesendet: Donnerstag, 3. Januar 2019 11:59
>>> An: Development list for mkgmap
>>> Betreff: Re: [mkgmap-dev] default style improvements
>>>
>>> Hi Gerd
>>>
>>> Do you want me to do another version of this patch before you
>>> commit
>>> it?
>>>
>>> I'd like to get on with the next set of changes; minor things like
>>> removing horse= can be done with these.
>>>
>>> Regards
>>> Ticker
>>>
>>> On Thu, 2018-12-13 at 10:54 +0000, Ticker Berkin wrote:
>>>> Hi Gerd
>>>>
>>>> My rationale was to see what highway= tags from various european
>>>> countries the default style didn't handle and hence generated:
>>>>
>>>> [0x07 road_class=0 road_speed=0 resolution 23]
>>>>
>>>> and then decide to:
>>>>
>>>> a) explicitly ignore.
>>>> b) handle as if they were a well defined highway type,
>>>>     with appropriate access control.
>>>> c) generate a new line type, with routing as appropriate.
>>>> d) allow mop-up as above.
>>>>
>>>> I removed escape/emergency_bay because I didn't think they added
>>>> anything useful to routing or the resultant map.
>>>>
>>>> footpath/foot looked like they should be footway or path, but if
>>>> you
>>>> think they should be ignored, I have no problem with that.
>>>>
>>>> What remained after this exercise was a few rubbish tags and lots
>>>> of
>>>> highway={real name of street} and I'd rather have these on my map
>>>>
>>>> The {add horse=xxx} I just changed a bit to be in keeping with
>>>> what
>>>> was
>>>> there already but happy to delete it.
>>>>
>>>> Ticker
>>>>
>>>> On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
>>>>> Hi Ticker,
>>>>>
>>>>> I think it is not a good idea to remove  highway=escape or
>>>>> highway=emergency_bay. The last time I looked at them most
>>>>> where
>>>>> correctly mapped.
>>>>> I'd also remove horse=yes or horse=no unless you want evaluate
>>>>> that
>>>>> somewhere in the style. Don't know why it is in the current
>>>>> default
>>>>> style.
>>>>> There is no code in mkgmap to evaluate it.
>>>>>
>>>>> Reg. rules like
>>>>> highway=footpath | highway=foot {set highway=footway}  # fix
>>>>> common
>>>>> bad tagging
>>>>> I think we don't need them. Most of those ways are mapped by
>>>>> HOT
>>>>> projects, it is very likely that they are not connected or self
>>>>> intersecting etc.
>>>>> I'd rather remove the mop up rule instead of adding a lot of
>>>>> "try
>>>>> to
>>>>> guess better" rules.
>>>>>
>>>>> Gerd
>>> _______________________________________________
>>> 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