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 <[email protected]> im Auftrag
von Ticker Berkin <[email protected]>
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 <[email protected]> im Auftrag
von Ticker Berkin <[email protected]>
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
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
