logo separator

[mkgmap-dev] Restaurant+hotel not appearing in nuvi

From Torsten Leistikow de_muur at gmx.de on Thu Apr 2 20:45:14 BST 2009

Marko Mäkelä schrieb:
> I'm an OSM newbie, and the only bits of mkgmap I have studied so far are
> the style files.  There are limitations in the way how tags are assigned
> in OSM too.  For example, a fuel station that also acts as a post office
> can't be declared both amenity=fuel and amenity=post_office, because key
> names must be unique.  Two separate nodes would be needed, or the tagging
> would have to change to something like amenity:fuel=Shell,
> amenity:post_office=01480 Vantaa.  I think it'd be clearer to have two
> separate nodes at least in this case.

Yes, such cases are already a problem in OSM. In the german talk-list
the tendency seems to be, to tag such dual uses as amenity=fuel;post_office
But this is not the point here. There are already many cases, where a
single OSM element has more than one function, which you would like to
have in a map.

>> The usability of such a feature wouldn't be limited to points. If you
>> have a street with an access restriction, you could draw the street
>> normally as the first line and add the restriction as a second line. The
>> benefit of this approach would be, that you only need one extra line
>> type to draw the restrictions for all existing road types.
> 
> Would that break routing?  What kind of restrictions do you have in mind?
> As far as I understand, oneway=yes/no is a line property in the Garmin
> format.  Possibly likewise for the speed limit.  Access to footways and
> cycleways is restricted from powered vehicles, but you surely don't suggest
> that all footways and cycleways be drawn twice.

For example you have to streets with highway=service. Street A is free
for public use, street B has the restriction access=no.

In the routing this is not a problem. You can build your style file with
the following two lines:

1. highway=unclassified & access!=no [0x01 road_class=1 road_speed=1
resolution=20]
2. highway=unclassified [0x01 resolution=20]

and the routing will work ok.
But what I also want to have, that the user can see on the map-display,
that the road is not usable. One solution would be, to use a different
line-type in such case, e.g. change the second line in the above style
file to

2. highway=unclassified [0x02 resolution=20]

The dissadvantage of this solution is, that you have to double each line
style, since each kind of road might have the access=no addition. And
you do not have only access additions to all the street types, you can
also have additional tags like cycleway=lane, bridge=yes, tunnel=yes
which would be nice to see in the map display.

So my idea is, to add two lines in such cases, so the style file might
look like

0. access=no <0x03 resolution=20>
1. highway=unclassified & access!=no [0x01 road_class=1 road_speed=1
resolution=20]
2. highway=unclassified [0x01 resolution=20]

With the above example I also propose a solution, how I think the
problem of multiple functions of single OSM elements could be solved.

A style line has in principle the following syntax:

key=value [0x00 resolution=00]

This means:
If the osm element has the key-value combination, then add a map element
with the number 0x00 which should be displayed at resolution 20 onwards
and afterwards continue with the next osm element.
Otherwise check the next key-value combination in the style file.

I would like to have an extension of this syntax:

key=value <0x00 resolution=00>

With the following meaning:
If the osm element has the key-value combination, then add a map element
with the number 0x00 which should be displayed at resolution 20 onwards
and afterwards check the next key-value combination in the style file.
Otherwise check the next key-value combination in the style file.

For the hotel and restaurant problem the style file would look like the
following:

tourism=hotel <0x0001 resolution=20>
amenity=restaurant [0x0002 resolution=20]

So you would get two map elements at the same position. My understanding
is, that this should generate automatically two POI entries. And you
would also get two symbols in the map, one of them could be designed
with a transparent background, so that you would also see the whole
information in the map display.

What do you think about such an extension? Would it be a feasible
solution? Can mkgmap be extended in such a way?

Gruss
Torsten



More information about the mkgmap-dev mailing list