amenity=restaurant and search index

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

amenity=restaurant and search index

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=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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: amenity=restaurant and search index

nwillink
Hi Gerd

2a13 is Dining African

r

Nick
Reply | Threaded
Open this post in threaded view
|

Re: amenity=restaurant and search index

Ticker Berkin
In reply to this post by Gerd Petermann
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: amenity=restaurant and search index

Ticker Berkin
In reply to this post by nwillink
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: amenity=restaurant and search index

Gerd Petermann
In reply to this post by Ticker Berkin
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 <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Donnerstag, 27. April 2017 13:49:43
An: [hidden email]
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: amenity=restaurant and search index

Bernhard Hiller
In reply to this post by Gerd Petermann
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: amenity=restaurant and search index

Gerd Petermann
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 <[hidden email]> im Auftrag von Bernhard Hiller <[hidden email]>
Gesendet: Donnerstag, 27. April 2017 19:41:44
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: amenity=restaurant and search index

Gerd Petermann
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 <[hidden email]> im Auftrag von Gerd Petermann <[hidden email]>
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 <[hidden email]> im Auftrag von Bernhard Hiller <[hidden email]>
Gesendet: Donnerstag, 27. April 2017 19:41:44
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev