Restaurant+hotel not appearing in nuvi
Hello I have a node tagged as follows: amenity=restaurant name=some_name tourism=hotel If I search for it in my nuvi, it appears under Food, but not under Accommodation. Shouldn't it appear in both sections? Cheers Carlos
On Fri, Mar 20, 2009 at 05:08:54PM +0100, Carlos Dávila wrote:
Hello I have a node tagged as follows: amenity=restaurant name=some_name tourism=hotel If I search for it in my nuvi, it appears under Food, but not under Accommodation. Shouldn't it appear in both sections?
Is there a Garmin symbol code for that? The closest that I was able to find is 0x2b02 for bed&breakfast. I didn't check if it would show up in both menus. You can always define separate points for the hotel and the restaurant. The restaurant and the hotel reception probably are at slightly different locations (usually, both on the ground floor). Marko
Marko Mäkelä schrieb:
You can always define separate points for the hotel and the restaurant.
Can you do this with mkgmap when you only have one OSM-node? This is rather often the case, like the example with the hotel and the restaurant, or you often find a combination of a restaurant with a castle, windmill or watermill. What I would like ot have, is the possibility, to set in the style, whether a certain element shall be used exclusivly or whether the creation of another garmin map item from the same OSM element shall be allowed. 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. Gruss Torsten
On Wed, Apr 01, 2009 at 06:20:31PM +0200, Torsten Leistikow wrote:
Marko Mäkelä schrieb:
You can always define separate points for the hotel and the restaurant.
Can you do this with mkgmap when you only have one OSM-node? This is rather often the case, like the example with the hotel and the restaurant, or you often find a combination of a restaurant with a castle, windmill or watermill.
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.
What I would like ot have, is the possibility, to set in the style, whether a certain element shall be used exclusivly or whether the creation of another garmin map item from the same OSM element shall be allowed.
For nodes, that could be useful in some cases.
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. Marko
Hi, I can provide a patch to mkgmap for this problem. I just forgot to publish it but remembered when I saw your topic. I called it multi tag patch. It just duplicates POIs for points that match more then one rule. It also should work with tags like this: amenity=fuel;post_office. Tested with my nuvi 360. Please let me know if it works for you. To apply the patch us the following commands: cd mkgmap patch -p 0 < /tmp/mkgamp-multitags-R988.patch Thanks Berni. Marko Mäkelä schrieb:
On Wed, Apr 01, 2009 at 06:20:31PM +0200, Torsten Leistikow wrote:
Marko Mäkelä schrieb:
You can always define separate points for the hotel and the restaurant.
Can you do this with mkgmap when you only have one OSM-node? This is rather often the case, like the example with the hotel and the restaurant, or you often find a combination of a restaurant with a castle, windmill or watermill.
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.
What I would like ot have, is the possibility, to set in the style, whether a certain element shall be used exclusivly or whether the creation of another garmin map item from the same OSM element shall be allowed.
For nodes, that could be useful in some cases.
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.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/uk/me/parabola/mkgmap/osmstyle/SequenceRule.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/SequenceRule.java (revision 339) +++ src/uk/me/parabola/mkgmap/osmstyle/SequenceRule.java (working copy) @@ -42,6 +42,11 @@ } return null; } + + public List<GType> resolveTypes(Element el) + { + return null; + } /** * Add a rule to this sequence. We do a quick check for impossible Index: src/uk/me/parabola/mkgmap/osmstyle/ActionRule.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/ActionRule.java (revision 339) +++ src/uk/me/parabola/mkgmap/osmstyle/ActionRule.java (working copy) @@ -61,6 +61,11 @@ } return null; } + + public List<GType> resolveTypes(Element el) + { + return null; + } public String toString() { StringBuilder fmt = new StringBuilder(); Index: src/uk/me/parabola/mkgmap/osmstyle/RuleSet.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/RuleSet.java (revision 339) +++ src/uk/me/parabola/mkgmap/osmstyle/RuleSet.java (working copy) @@ -18,8 +18,10 @@ import java.util.Formatter; import java.util.LinkedHashMap; +import java.util.List; import java.util.Map; import java.util.Set; +import java.util.Vector; import uk.me.parabola.mkgmap.reader.osm.Element; import uk.me.parabola.mkgmap.reader.osm.GType; @@ -79,6 +81,36 @@ return foundType; } + public List<GType> resolveTypes(Element el) { + List<GType> foundTypes = null; + for (String tagKeys : el) { + + String keyValue[] = tagKeys.split("="); + + if(keyValue != null && keyValue.length > 1 && keyValue[1] != null) + { + String values[] = keyValue[1].split(";"); + + for(int i = 0; i < values.length ;i++) + { + String tagKey = keyValue[0].concat("=").concat(values[i]); + + Rule rule = rules.get(tagKey); + if (rule != null) { + GType type = rule.resolveType(el); + if(type != null) + { + if(foundTypes == null) + foundTypes = new Vector<GType>(); + foundTypes.add(type); + } + } + } + } + } + return foundTypes; + } + public void addAll(RuleSet rs) { for (Map.Entry<String, Rule> ent : rs.entrySet()) add(ent.getKey(), ent.getValue()); Index: src/uk/me/parabola/mkgmap/osmstyle/FixedRule.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/FixedRule.java (revision 339) +++ src/uk/me/parabola/mkgmap/osmstyle/FixedRule.java (working copy) @@ -16,6 +16,8 @@ */ package uk.me.parabola.mkgmap.osmstyle; +import java.util.List; + import uk.me.parabola.mkgmap.reader.osm.Element; import uk.me.parabola.mkgmap.reader.osm.GType; import uk.me.parabola.mkgmap.reader.osm.Rule; @@ -35,6 +37,11 @@ public GType resolveType(Element el) { return gtype; } + + public List<GType> resolveTypes(Element el) + { + return null; + } public String toString() { return gtype.toString(); Index: src/uk/me/parabola/mkgmap/osmstyle/ExpressionRule.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/ExpressionRule.java (revision 339) +++ src/uk/me/parabola/mkgmap/osmstyle/ExpressionRule.java (working copy) @@ -16,6 +16,8 @@ */ package uk.me.parabola.mkgmap.osmstyle; +import java.util.List; + import uk.me.parabola.mkgmap.osmstyle.eval.Op; import uk.me.parabola.mkgmap.reader.osm.Element; import uk.me.parabola.mkgmap.reader.osm.GType; @@ -42,6 +44,11 @@ return null; } + + public List<GType> resolveTypes(Element el) + { + return null; + } public String toString() { return exression.toString() + ' ' + gtype; Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 339) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy) @@ -179,21 +179,25 @@ public void convertNode(Node node) { preConvertRules(node); - GType foundType = nodeRules.resolveType(node); - if (foundType == null) + List<GType> foundTypes = nodeRules.resolveTypes(node); + if (foundTypes == null) return; + + for(int i=0; i < foundTypes.size(); i++) + { + GType foundType = foundTypes.get(i); + + // If the node does not have a name, then set the name from this + // type rule. + log.debug("node name", node.getName()); + if (node.getName() == null) { + node.setName(foundType.getDefaultName()); + log.debug("after set", node.getName()); + } - // If the node does not have a name, then set the name from this - // type rule. - log.debug("node name", node.getName()); - if (node.getName() == null) { - node.setName(foundType.getDefaultName()); - log.debug("after set", node.getName()); + postConvertRules(node, foundType); + addPoint(node, foundType); } - - postConvertRules(node, foundType); - - addPoint(node, foundType); } /** Index: src/uk/me/parabola/mkgmap/reader/osm/Rule.java =================================================================== --- src/uk/me/parabola/mkgmap/reader/osm/Rule.java (revision 339) +++ src/uk/me/parabola/mkgmap/reader/osm/Rule.java (working copy) @@ -16,6 +16,8 @@ */ package uk.me.parabola.mkgmap.reader.osm; +import java.util.List; + /** * A rule takes an element and returns the correct garmin type for it. * Immplementations can be simple or complex as needed. @@ -32,4 +34,5 @@ * @return Enough information to represent this as a garmin type. */ public GType resolveType(Element el); + public List<GType> resolveTypes(Element el); }
Hallo Bernhard, On Thu, Apr 02, 2009 at 08:22:20AM +0200, Bernhard Heibler wrote:
Hi,
I can provide a patch to mkgmap for this problem. I just forgot to publish it but remembered when I saw your topic. I called it multi tag patch. It just duplicates POIs for points that match more then one rule. It also should work with tags like this: amenity=fuel;post_office. Tested with my nuvi 360. Please let me know if it works for you.
Looking at the patch, it would not produce the desirable result for amenity=restaurant, cuisine=pizza;kebab With my restaurant-cuisine.patch, this would create two entries for such restaurants. (I've since revised my patch to say cuisine=pizza* so that pizza;kebab places will end up in the pizza restaurants menu instead of "other restaurants".) I think that the splitting of the node should be made explicit in the style file. Then, some special cases could still be handled differently. Something like this: amenity=fuel;shop [ 0x2e06 resolution 19 ] amenity=fuel;* { split amenity=fuel, amenity=+5 } The syntax is just a suggestion. The latter rule would discard the original node and create two new nodes: one with amenity=fuel, and the other with amenity=... (whatever follows the fuel; in the original string). The latter rule wouldn't match already processed nodes, such as amenity=fuel;shop. All rules would then be processed for each node again. What do you think? Marko
On Thu, Apr 02, 2009 at 10:00:24AM +0300, Marko Mäkelä wrote:
I think that the splitting of the node should be made explicit in the style file. Then, some special cases could still be handled differently. Something like this:
amenity=fuel;shop [ 0x2e06 resolution 19 ] amenity=fuel;* { split amenity=fuel, amenity=+5 }
The syntax is just a suggestion.
On a second thought, the +5 is a bad idea because of multi-byte characters and character set conversions (e.g., latin1 is 1 or 2 bytes per character in UTF-8 but 1 byte per charater in latin1). Come to think of it, the * on the right-hand-side could expand to what the * matched on the left-hand-side: amenity=fuel;* { split amenity=fuel, amenity=* } This would also allow you to say amenity=shop;*;fuel { split amenity=fuel;shop, amenity=* } amenity=*;fuel { split amenity=fuel, amenity=* } just to name crazy examples. I don't think that it's necessary to have the split operator create more than two nodes, but that could be done too. For simplicity, I'd limit it to one * on the left-hand-side, though. (Sorry that I'm just throwing ideas and not writing any code.) Marko
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
Torsten Leistikow wrote:
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
Another approach to this would be to create two map layers with two different TYP files. The lower, normal map layer contains the roads and the routing information. The second layer is transparent and only contains additional graphics for drawing on top of the map layer, e.g. colored bike route markings, tunnels, bridges and so on.
Ralf Kleineisel schrieb:
Another approach to this would be to create two map layers with two different TYP files. The lower, normal map layer contains the roads and the routing information. The second layer is transparent and only contains additional graphics for drawing on top of the map layer, e.g. colored bike route markings, tunnels, bridges and so on.
I thought about this, and I am going to try this approach next, since I don't have the time to implement the proposed extension of mkgmap by myself. But this solution will not help the POI problem. And the solution is also much less flexible: You have to decide before the map generation, which items shall be drawn on which layer. And you also need to decide before, how many layers you need. I think my proposal is much more flexible if you have different combination of multiple items (e.g. a street is on a bridge, has a cycle lane and is part of an relation) And I don't know, how the Garmin devices handle multiple transparent maps, In mapsource you always get only one map at a time. Gruss Torsten
As I wrote. All maps that have the same MapID will be shown at the same time. The higher the "mapname" (notice you can't change that by simply renaming but you have to compile with another "mapname" parameter) the higher the order for showing. All Polygons need to be in the base layer (the one with the lowest mapname) otherwise they are shown above lines and POI. Inside a single .img Polygons will allways show at the bottom. For POI that solution makes not much sense though as there are far to many sensible combinations. The problem with a second layer is that a second layer is not enough. Imagine a road being part of a cycling route, a mtb route and a hiking route. So now you would have to make ONE layer for EACH. Garmin devices are more flexible than mapsource, insofar that you can change the "transparent" bitset and show several maps with different mapID at the same time - this enables us to use more different types (as unluckily we still have no RGN2,3,4, support (also falsely known as 3-byte support)). In Mapsource you can only show maps of the same MapID at the same time (so only one mapset at a time). On the devices again you have to have on base map (not transparent) - and additional transparent mapsets best without polygons to be shown above in order of their mapnames. Having mkgmap double, tripple,... check every POI, Polyline the map generation would be more flexible and quicker. Greetings, Felix Torsten Leistikow wrote:
Ralf Kleineisel schrieb:
Another approach to this would be to create two map layers with two different TYP files. The lower, normal map layer contains the roads and the routing information. The second layer is transparent and only contains additional graphics for drawing on top of the map layer, e.g. colored bike route markings, tunnels, bridges and so on.
I thought about this, and I am going to try this approach next, since I don't have the time to implement the proposed extension of mkgmap by myself.
But this solution will not help the POI problem.
And the solution is also much less flexible: You have to decide before the map generation, which items shall be drawn on which layer. And you also need to decide before, how many layers you need. I think my proposal is much more flexible if you have different combination of multiple items (e.g. a street is on a bridge, has a cycle lane and is part of an relation)
And I don't know, how the Garmin devices handle multiple transparent maps, In mapsource you always get only one map at a time.
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Oh - forgot to tell. The Routing Information can be spread about all tiles. It's no problem if it goes from layer to layer as long as it is inside the same mapset. Torsten Leistikow wrote:
Ralf Kleineisel schrieb:
Another approach to this would be to create two map layers with two different TYP files. The lower, normal map layer contains the roads and the routing information. The second layer is transparent and only contains additional graphics for drawing on top of the map layer, e.g. colored bike route markings, tunnels, bridges and so on.
I thought about this, and I am going to try this approach next, since I don't have the time to implement the proposed extension of mkgmap by myself.
But this solution will not help the POI problem.
And the solution is also much less flexible: You have to decide before the map generation, which items shall be drawn on which layer. And you also need to decide before, how many layers you need. I think my proposal is much more flexible if you have different combination of multiple items (e.g. a street is on a bridge, has a cycle lane and is part of an relation)
And I don't know, how the Garmin devices handle multiple transparent maps, In mapsource you always get only one map at a time.
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (6)
-
Bernhard Heibler -
Carlos Dávila -
Felix Hartmann -
Marko Mäkelä -
Ralf Kleineisel -
Torsten Leistikow