--no-poi-address option handling broken
Hi, the --no-poi-address mkgmap option doesn't work anymore: Invalid option: 'poi-address' I assume this is the outcome of the changes in r2386. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On 12/12/12 09:29, Thorsten Kukuk wrote:
Hi,
the --no-poi-address mkgmap option doesn't work anymore:
Invalid option: 'poi-address'
I assume this is the outcome of the changes in r2386.
Yes, I was wondering if anyone would notice! So what does this option do? Nick's reason why --no-poi-address was needed is to avoid park benches etc getting addresses and appearing in the index. If that is case, then it seems to me that the bug is that park benches get addresses (with some option perhaps) and as a work around you turn off all POI addresses. As far as I can tell all the real POI addresses are removed too? ..Steve
Hi Steve, I'm not sure, but I think every object becomes mkgmap:city, mkgmap:country and mkgmap:postal_code while bounds-processing. Maybe a style-function remove-address would be a solution. So you can specify in style, if an address should be shown or not. Henning
On Wed, Dec 12, Steve Ratcliffe wrote:
On 12/12/12 09:29, Thorsten Kukuk wrote:
Hi,
the --no-poi-address mkgmap option doesn't work anymore:
Invalid option: 'poi-address'
I assume this is the outcome of the changes in r2386.
Yes, I was wondering if anyone would notice!
So what does this option do? Nick's reason why --no-poi-address was needed is to avoid park benches etc getting addresses and appearing in the index.
If that is case, then it seems to me that the bug is that park benches get addresses (with some option perhaps) and as a work around you turn off all POI addresses. As far as I can tell all the real POI addresses are removed too?
I use that option for special layers, where I want that all POI addresses are removed, not for the standard base map. So there are no "real" POI addresses in that layer and I don't want that some "crap" due to wrong/broken data appears. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Wed, Dec 12, Steve Ratcliffe wrote:
On 12/12/12 09:29, Thorsten Kukuk wrote:
Hi,
the --no-poi-address mkgmap option doesn't work anymore:
Invalid option: 'poi-address'
I assume this is the outcome of the changes in r2386.
Yes, I was wondering if anyone would notice!
So what does this option do? Nick's reason why --no-poi-address was needed is to avoid park benches etc getting addresses and appearing in the index.
If that is case, then it seems to me that the bug is that park benches get addresses (with some option perhaps) and as a work around you turn off all POI addresses. As far as I can tell all the real POI addresses are removed too?
I use that option for special layers, where I want that all POI addresses are removed, not for the standard base map.
So there are no "real" POI addresses in that layer and I don't want that some "crap" due to wrong/broken data appears.
Thorsten
Did you try to remove the address rules from the special layers style? I haven't looked into the code how --no-poi-addresses works but if you don't assign the mkgmap:country, mkgmap:city etc. tags mkgmap cannot create any address information. WanMil
On Wed, Dec 12, Steve Ratcliffe wrote:
So what does this option do? Nick's reason why --no-poi-address was needed is to avoid park benches etc getting addresses and appearing in the index.
Hm, how does this work? I would really like to get ride of park benches, etc, from the index, too, but without loosing any of the ones I really want to have. Reason: If the index is getting to big, MapSource and my 62s will ignore parts of it, which makes it impossible to find some citys, hotels, or whatever. See my mail about this some weeks ago. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On 12/12/12 09:29, Thorsten Kukuk wrote:
Hi,
the --no-poi-address mkgmap option doesn't work anymore:
Invalid option: 'poi-address'
I assume this is the outcome of the changes in r2386.
Yes, I was wondering if anyone would notice!
So what does this option do? Nick's reason why --no-poi-address was needed is to avoid park benches etc getting addresses and appearing in the index.
If that is case, then it seems to me that the bug is that park benches get addresses (with some option perhaps) and as a work around you turn off all POI addresses. As far as I can tell all the real POI addresses are removed too?
..Steve
I remember that there was an idea to be able to prevent small ways etc. to be added to the index, e.g. by adding the tag mkgmap:noindex=true. This would not prevent a bench to get address information but it should prevent to be searchable via the index. Steve, do you think this can be implemented easily? WanMil
On 13/12/12 09:55, WanMil wrote:
I remember that there was an idea to be able to prevent small ways etc. to be added to the index, e.g. by adding the tag mkgmap:noindex=true. This would not prevent a bench to get address information but it should prevent to be searchable via the index.
Steve, do you think this can be implemented easily?
Not in general, since creating the index works directly with the compiled img file. So the style is not used at all. You could create an "index style" that matches on things that are available in the img file, such as Garmin type and name. For things like benches, using an extended type will ensure that it stays out of the index. The main problem was when you want a routable line for footpaths, and want to name them all "Path" or similar, since an extended type can't be used. We have code to avoid placing all those names into the .img, but this is not correct as I just found out... it breaks searching for house numbers. ..Steve
We have code to avoid placing all those names into the .img, but this is not correct as I just found out... it breaks searching for house numbers.
What a pity... I don't think it's a very urgent task to solve. But maybe you can keep in mind that it would be useful to prevent having hundreds of "track"s in the index. Probably you will find a solution at any time in future :-) WanMil
On 14/12/12 18:21, WanMil wrote:
We have code to avoid placing all those names into the .img, but this is not correct as I just found out... it breaks searching for house numbers.
What a pity... I don't think it's a very urgent task to solve. But maybe you can keep in mind that it would be useful to prevent having hundreds of "track"s in the index. Probably you will find a solution at any time in future :-)
Actually the house-number issue doesn't mean that the existing solution has to be removed altogether, I just make sure that anything with house numbers is not combined. So all the 'tracks' should be still be combined under just the one name. ..Steve
On Fri, Dec 14, Steve Ratcliffe wrote:
For things like benches, using an extended type will ensure that it stays out of the index.
What do you mean with "out of the index", and what are extended types for POIs for you? Using 0x115xx/0x116xx types (which should be extended POI types), yes, they don't get adress informations added, but no, they are still listed in the index. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
participants (4)
-
Henning Scholland -
Steve Ratcliffe -
Thorsten Kukuk -
WanMil