[mkgmap-dev] default style improvements

Sun Jan 6 09:11:51 GMT 2019

Hi Ticker,

I think I understand the changes in the points file and in inc/accesss_country and they look okay to me. I agree that it is better to have the hotel POI
for those cases where a point has both amenity=restaurant and tourism=hotel.

In polygons I don't understand some of the changes.
Dubious to me are those for
- aeroway
- shop now being rendered at res 24 instead of 22. Why?
- highway=pedestrian
- the rule
highway=* & (area=yes | mkgmap:mp_created=true) [0x05 resolution 22]
was removed. In Italy and probably other countries as well I see many highway=residential + area=yes or highway=service+area=yes as an alternative
to map place=square (which is quite new)

Most of the changes in lines look OK to me.
- I don't like all the changes reg. area, see also Lorenzos comment.
- I think highway=access_ramp is equivalent to highway=footway, see
https://wiki.openstreetmap.org/wiki/Proposed_features/Access_Ramp
- not sure why you set bicycle=no for highway=trail?
- You see tmp:stopMopUp=yes in some rules but the rules that would evaluate that tag are commented. I'd rather remove all.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Samstag, 5. Januar 2019 18:18
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] default style improvements

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
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev