Hi all, I've postponed the problems regarding --lower-case and looked at other problems in the index. I've noticed that some restaurants do not show up where expected. I am not sure if this is caused by wrong data in the index or simply by style rules, probably both. For example: I have a small test file containing some amenity=restaurant, but none has cuisine=international (0x2a06) , still the search menu shows an entry for that category but finds no entry. On the other hand, many restaurants are found where not expected, for example in category pizza I find all 0x2a00 The default style contains rules to add POI with type 0x2a and it seems to work for many of them, but at least these last two rules look suspicious: amenity=restaurant & cuisine=* [0x2a13 resolution 24] amenity=restaurant [0x2a00 resolution 24] Why do we use two different types for these "mop up" rules? Gerd
Hi Gerd 2a13 is Dining African r Nick -- View this message in context: http://gis.19327.n8.nabble.com/amenity-restaurant-and-search-index-tp5895969... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Not on my etrex, the last defined subtype is 0x2b12 = Speciality Food Products, then 13 onwards are 'Other' If some garmin devices do understand more beyond 0x12 in a consistent way, can they be added to the default style and the catchall then use a value a few beyond that. Ticker On Thu, 2017-04-27 at 04:47 -0700, nwillink wrote:
Hi Gerd
2a13 is Dining African
r
Nick
-- View this message in context: http://gis.19327.n8.nabble.com/amenity- restaurant-and-search-index-tp5895969p5895971.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi I had suspicions that the line: amenity=restaurant & cuisine ~ '.*pizza.*' [0x2a0a resolution 24] doesn't work, but never bother looking in detail. It would fall through to: amenity=restaurant & cuisine=* [0x2a13 resolution 24] There is a slight reason to use a subtype when cuisine is specified and not matched and no subtype (0x2a00) when no cuisine specified, in that you can find these unknown cuisines by select-category:other An improvement to the default style would be to change above to: amenity=restaurant & cuisine=* {add name='${cuisine|subst:"_=> "}'} [0x2a13 resolution 24] and there are a few other places that would benefit from similar changes Ticker On Thu, 2017-04-27 at 11:18 +0000, Gerd Petermann wrote:
Hi all,
I've postponed the problems regarding --lower-case and looked at other problems in the index. I've noticed that some restaurants do not show up where expected. I am not sure if this is caused by wrong data in the index or simply by style rules, probably both. For example: I have a small test file containing some amenity=restaurant, but none has cuisine=international (0x2a06) , still the search menu shows an entry for that category but finds no entry. On the other hand, many restaurants are found where not expected, for example in category pizza I find all 0x2a00
The default style contains rules to add POI with type 0x2a and it seems to work for many of them, but at least these last two rules look suspicious: amenity=restaurant & cuisine=* [0x2a13 resolution 24] amenity=restaurant [0x2a00 resolution 24] Why do we use two different types for these "mop up" rules?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I think the categories in which you find something are probably sometimes wrong, and that might be caused by wrong index data. For example, in MapSource I have a subcategory "international" in "Food & Drink" which shows no entries. When I right click on a restaurant with type 0x2a13 it has two properties : Food & Drink - "Ratskeller " Marine - "Ratskeller" When I left click the first entry and select "Feature Properties" I see Category Food&Drink, Subcategory International I have no idea yet where this Marine entry comes from, looks completely wrong. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 27. April 2017 13:49:43 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] amenity=restaurant and search index Hi I had suspicions that the line: amenity=restaurant & cuisine ~ '.*pizza.*' [0x2a0a resolution 24] doesn't work, but never bother looking in detail. It would fall through to: amenity=restaurant & cuisine=* [0x2a13 resolution 24] There is a slight reason to use a subtype when cuisine is specified and not matched and no subtype (0x2a00) when no cuisine specified, in that you can find these unknown cuisines by select-category:other An improvement to the default style would be to change above to: amenity=restaurant & cuisine=* {add name='${cuisine|subst:"_=> "}'} [0x2a13 resolution 24] and there are a few other places that would benefit from similar changes Ticker On Thu, 2017-04-27 at 11:18 +0000, Gerd Petermann wrote:
Hi all,
I've postponed the problems regarding --lower-case and looked at other problems in the index. I've noticed that some restaurants do not show up where expected. I am not sure if this is caused by wrong data in the index or simply by style rules, probably both. For example: I have a small test file containing some amenity=restaurant, but none has cuisine=international (0x2a06) , still the search menu shows an entry for that category but finds no entry. On the other hand, many restaurants are found where not expected, for example in category pizza I find all 0x2a00
The default style contains rules to add POI with type 0x2a and it seems to work for many of them, but at least these last two rules look suspicious: amenity=restaurant & cuisine=* [0x2a13 resolution 24] amenity=restaurant [0x2a00 resolution 24] Why do we use two different types for these "mop up" rules?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
The index may be sometimes confusing: there are categories which sum up other categories, and that also depends on the device type. See http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types E.g. 0x2a04 is shown under - All Categories - Asian - Chinese on an Oregon 600, but the category "Asian" is missing on some other devices. According to that site, "International" shows 0x2a06 only on most Garmin devices, but additionally 0x2a13-0x2a1f on Oregon 600. The categories are hard-coded by Garmin (well, you can edit the language file and change their meaning), so they will show up on your device even if there is no POI available for that category. Am 27.04.2017 um 13:18 schrieb Gerd Petermann:
Hi all,
I've postponed the problems regarding --lower-case and looked at other problems in the index. I've noticed that some restaurants do not show up where expected. I am not sure if this is caused by wrong data in the index or simply by style rules, probably both. For example: I have a small test file containing some amenity=staurant, but none has cuisine=international (0x2a06) , still the search menu shows an entry for that category but finds no entry. On the other hand, many restaurants are found where not expected, for example in category pizza I find all 0x2a00
The default style contains rules to add POI with type 0x2a and it seems to work for many of them, but at least these last two rules look suspicious: amenity=staurant & cuisine=* [0x2a13 resolution 24] amenity=staurant [0x2a00 resolution 24] Why do we use two different types for these "mop up" rules?
Gerd
Hi Bernhard, yes, that is understood. My problem seems to be caused by the fact that the index is wrong so that 0x2a00 does not appear where it should. This is my guess because when I create a gmapsupp in MapSource and analyse the index I see that it doesn't contain the entry for 0x2a00. I think the problem is that we don't fully understand some bytes in the index. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Bernhard Hiller <bhil@gmx.de> Gesendet: Donnerstag, 27. April 2017 19:41:44 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] amenity=restaurant and search index The index may be sometimes confusing: there are categories which sum up other categories, and that also depends on the device type. See http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types E.g. 0x2a04 is shown under - All Categories - Asian - Chinese on an Oregon 600, but the category "Asian" is missing on some other devices. According to that site, "International" shows 0x2a06 only on most Garmin devices, but additionally 0x2a13-0x2a1f on Oregon 600. The categories are hard-coded by Garmin (well, you can edit the language file and change their meaning), so they will show up on your device even if there is no POI available for that category. Am 27.04.2017 um 13:18 schrieb Gerd Petermann:
Hi all,
I've postponed the problems regarding --lower-case and looked at other problems in the index. I've noticed that some restaurants do not show up where expected. I am not sure if this is caused by wrong data in the index or simply by style rules, probably both. For example: I have a small test file containing some amenity=staurant, but none has cuisine=international (0x2a06) , still the search menu shows an entry for that category but finds no entry. On the other hand, many restaurants are found where not expected, for example in category pizza I find all 0x2a00
The default style contains rules to add POI with type 0x2a and it seems to work for many of them, but at least these last two rules look suspicious: amenity=staurant & cuisine=* [0x2a13 resolution 24] amenity=staurant [0x2a00 resolution 24] Why do we use two different types for these "mop up" rules?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, think I fixed the bug with r3919 in the branch. I am now looking for an option to say which POI should NOT be indexed. Will repopen this thread later: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/025945.html Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 27. April 2017 20:14:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] amenity=restaurant and search index Hi Bernhard, yes, that is understood. My problem seems to be caused by the fact that the index is wrong so that 0x2a00 does not appear where it should. This is my guess because when I create a gmapsupp in MapSource and analyse the index I see that it doesn't contain the entry for 0x2a00. I think the problem is that we don't fully understand some bytes in the index. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Bernhard Hiller <bhil@gmx.de> Gesendet: Donnerstag, 27. April 2017 19:41:44 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] amenity=restaurant and search index The index may be sometimes confusing: there are categories which sum up other categories, and that also depends on the device type. See http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types E.g. 0x2a04 is shown under - All Categories - Asian - Chinese on an Oregon 600, but the category "Asian" is missing on some other devices. According to that site, "International" shows 0x2a06 only on most Garmin devices, but additionally 0x2a13-0x2a1f on Oregon 600. The categories are hard-coded by Garmin (well, you can edit the language file and change their meaning), so they will show up on your device even if there is no POI available for that category. Am 27.04.2017 um 13:18 schrieb Gerd Petermann:
Hi all,
I've postponed the problems regarding --lower-case and looked at other problems in the index. I've noticed that some restaurants do not show up where expected. I am not sure if this is caused by wrong data in the index or simply by style rules, probably both. For example: I have a small test file containing some amenity=staurant, but none has cuisine=international (0x2a06) , still the search menu shows an entry for that category but finds no entry. On the other hand, many restaurants are found where not expected, for example in category pizza I find all 0x2a00
The default style contains rules to add POI with type 0x2a and it seems to work for many of them, but at least these last two rules look suspicious: amenity=staurant & cuisine=* [0x2a13 resolution 24] amenity=staurant [0x2a00 resolution 24] Why do we use two different types for these "mop up" rules?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Bernhard Hiller -
Gerd Petermann -
nwillink -
Ticker Berkin