change inc/address to be a standalone ?

Hi experts, I am not happy with the current code regarding address data. My understanding so far: - we have the --bounds option to specify precompiled bounds - we have the LocationHook that is used to assign tags mkgmap:admin_level2 to. mkgmap:admin_level10 and mkgmap:postcode. - we have inc/address to which uses either the data from the LocationHook or that from the OSM element to set mkgmap:city, mkgmap:region etc. The file inc/address in the default style doesn't care about any other tags, means, the result doesn't depend on the exstence of a highway tag or whether the element is a node, way, or polygon. I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address. Gerd

sorry, pressed the send button too early. The 2nd advantage of this approach is that the HousenumberGenerator can easily create "pseudo nodes" to evaluate the tags for a given point on the road. This would be much better than cutting roads into peaces. Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Thu, 16 Apr 2015 08:35:41 +0200 Subject: [mkgmap-dev] change inc/address to be a standalone ? Hi experts, I am not happy with the current code regarding address data. My understanding so far: - we have the --bounds option to specify precompiled bounds - we have the LocationHook that is used to assign tags mkgmap:admin_level2 to. mkgmap:admin_level10 and mkgmap:postcode. - we have inc/address to which uses either the data from the LocationHook or that from the OSM element to set mkgmap:city, mkgmap:region etc. The file inc/address in the default style doesn't care about any other tags, means, the result doesn't depend on the exstence of a highway tag or whether the element is a node, way, or polygon. I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi, On Thu, Apr 16, Gerd Petermann wrote:
I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address.
Currently I include inc/address in the "middle" of a rules file, so that I can "fix" highway names and so on. Like: name!=* & place_name=* { name '${place_name}' } name!=* & loc_name=* { name '${loc_name}' } or: tiger:name_base=* & tiger:name_type=Rd & name!=* {name '${tiger:name_base} Road'} If address becomes a standalone file executed before, I have to put all rules from lines, points and polygons (yes, I use inc/address in polygons, too, for mkgmap:city and mkgmap:country specific rules) before inc/address into address. This does not make it easier to maintain the style. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Hi Thorsten, my thinking was that inc/address does not set any tags which are not prefixed with mkgmap: I see that your inc/address is a bit different to that in the default style, but the only significant difference that I found is this rule: mkgmap:country=DEU | mkgmap:country=AUT | mkgmap:country=CHE {set style:lang=german} So, I see no problem as your inc/address also doesn't set name or place_name. What do I miss? Gerd
Date: Thu, 16 Apr 2015 08:44:18 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
Hi,
On Thu, Apr 16, Gerd Petermann wrote:
I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address.
Currently I include inc/address in the "middle" of a rules file, so that I can "fix" highway names and so on. Like: name!=* & place_name=* { name '${place_name}' } name!=* & loc_name=* { name '${loc_name}' }
or: tiger:name_base=* & tiger:name_type=Rd & name!=* {name '${tiger:name_base} Road'}
If address becomes a standalone file executed before, I have to put all rules from lines, points and polygons (yes, I use inc/address in polygons, too, for mkgmap:city and mkgmap:country specific rules) before inc/address into address. This does not make it easier to maintain the style.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Thu, Apr 16, Gerd Petermann wrote:
Hi Thorsten,
my thinking was that inc/address does not set any tags which are not prefixed with mkgmap: I see that your inc/address is a bit different to that in the default style, but the only significant difference that I found is this rule: mkgmap:country=DEU | mkgmap:country=AUT | mkgmap:country=CHE {set style:lang=german}
So, I see no problem as your inc/address also doesn't set name or place_name.
What do I miss?
This were only examples, the result is used by me to set mkgmap:street in some cases to prevent inc/address from setting it (workaround for some bad tagging, where people add addr:street to a highway, e.g.). So in this special case I could add: highway=* & name=* & addr:street=* {delete addr:street} to address, but I'm afraid that we loose a lot of flexible to "fix" wrong data by rules. And I'm not sure if adding the workarounds from points/lines/polygons to address is really always a good thing or can work. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Hi Thorsten, okay, I think I understand now. You don't use any of the possible tricks in your style, but you don't want to loose the possibility to do it. Right? I think that is a good point against my proposal. Gerd
Date: Thu, 16 Apr 2015 09:08:22 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
On Thu, Apr 16, Gerd Petermann wrote:
Hi Thorsten,
my thinking was that inc/address does not set any tags which are not prefixed with mkgmap: I see that your inc/address is a bit different to that in the default style, but the only significant difference that I found is this rule: mkgmap:country=DEU | mkgmap:country=AUT | mkgmap:country=CHE {set style:lang=german}
So, I see no problem as your inc/address also doesn't set name or place_name.
What do I miss?
This were only examples, the result is used by me to set mkgmap:street in some cases to prevent inc/address from setting it (workaround for some bad tagging, where people add addr:street to a highway, e.g.).
So in this special case I could add: highway=* & name=* & addr:street=* {delete addr:street} to address, but I'm afraid that we loose a lot of flexible to "fix" wrong data by rules. And I'm not sure if adding the workarounds from points/lines/polygons to address is really always a good thing or can work.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Thu, Apr 16, Gerd Petermann wrote:
Hi Thorsten,
okay, I think I understand now. You don't use any of the possible tricks in your style, but you don't want to loose the possibility to do it. Right?
No, I already use some of the tricks to prevent that inc/address set mkgmap:street is set wrongly due to bad tagging. I can workaround them, but yes, I don't want to loose the possibility to fix them. Thorsten
I think that is a good point against my proposal.
Gerd
Date: Thu, 16 Apr 2015 09:08:22 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
On Thu, Apr 16, Gerd Petermann wrote:
Hi Thorsten,
my thinking was that inc/address does not set any tags which are not prefixed with mkgmap: I see that your inc/address is a bit different to that in the default style, but the only significant difference that I found is this rule: mkgmap:country=DEU | mkgmap:country=AUT | mkgmap:country=CHE {set style:lang=german}
So, I see no problem as your inc/address also doesn't set name or place_name.
What do I miss?
This were only examples, the result is used by me to set mkgmap:street in some cases to prevent inc/address from setting it (workaround for some bad tagging, where people add addr:street to a highway, e.g.).
So in this special case I could add: highway=* & name=* & addr:street=* {delete addr:street} to address, but I'm afraid that we loose a lot of flexible to "fix" wrong data by rules. And I'm not sure if adding the workarounds from points/lines/polygons to address is really always a good thing or can work.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) _______________________________________________ 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
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Hi Thorsten, okay, got it. Did not think about mkgmap:street and even the default style has to use this trick. Sorry for the noise. I think what I was looking for is a set of rules which depend only on the tags created by the LocationHook. After the latest news regarding the img format I try to change the --housenumber code to group roads and houses by city/region/country (and maybe also zip code), so I was looking for an efficient way to calculate these values based on the coords of a road point, but probably the only relavant data is in the houses near the road, so we just have to make sure that each element with addr:housenumber has the relavent tags. Gerd
Date: Thu, 16 Apr 2015 09:28:52 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
On Thu, Apr 16, Gerd Petermann wrote:
Hi Thorsten,
okay, I think I understand now. You don't use any of the possible tricks in your style, but you don't want to loose the possibility to do it. Right?
No, I already use some of the tricks to prevent that inc/address set mkgmap:street is set wrongly due to bad tagging. I can workaround them, but yes, I don't want to loose the possibility to fix them.
Thorsten
I think that is a good point against my proposal.
Gerd
Date: Thu, 16 Apr 2015 09:08:22 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
On Thu, Apr 16, Gerd Petermann wrote:
Hi Thorsten,
my thinking was that inc/address does not set any tags which are not prefixed with mkgmap: I see that your inc/address is a bit different to that in the default style, but the only significant difference that I found is this rule: mkgmap:country=DEU | mkgmap:country=AUT | mkgmap:country=CHE {set style:lang=german}
So, I see no problem as your inc/address also doesn't set name or place_name.
What do I miss?
This were only examples, the result is used by me to set mkgmap:street in some cases to prevent inc/address from setting it (workaround for some bad tagging, where people add addr:street to a highway, e.g.).
So in this special case I could add: highway=* & name=* & addr:street=* {delete addr:street} to address, but I'm afraid that we loose a lot of flexible to "fix" wrong data by rules. And I'm not sure if adding the workarounds from points/lines/polygons to address is really always a good thing or can work.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) _______________________________________________ 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
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi experts,
Hi Gerd,
I am not happy with the current code regarding address data.
My understanding so far: - we have the --bounds option to specify precompiled bounds - we have the LocationHook that is used to assign tags mkgmap:admin_level2 to. mkgmap:admin_level10 and mkgmap:postcode. - we have inc/address to which uses either the data from the LocationHook or that from the OSM element to set mkgmap:city, mkgmap:region etc. The file inc/address in the default style doesn't care about any other tags, means, the result doesn't depend on the exstence of a highway tag or whether the element is a node, way, or polygon.
I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address.
I think that's hard to realize. Other style implementors do not need to use the same name inc/address. It is also possible that the address rules are written in a mixed style file. So it's not easy to detect which include file contains address rules only. What is the major problem you have? Is it that inc/address does not differ between nodes, ways and polygons? You might change that (function type() returns node, way, relation depending on its type). The major advantage of an included address file is that other style implementors can easily use it as it is so it would be good if its usage is not weaved into the default style too much. WanMil
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi WanMil, yes, not a good idea, see also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2015q2/023332.html I try to sovle the problem that I see elements with addr:housenumber which have all the mkgmap:adminlevel tags but they don't have the mkgmap:city tag. It seems that RuleSet.merge() doesn't merge the finalize rules. I think that's would be an error although I am not sure how a merge would work. Gerd
Date: Thu, 16 Apr 2015 10:09:49 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
Hi experts,
Hi Gerd,
I am not happy with the current code regarding address data.
My understanding so far: - we have the --bounds option to specify precompiled bounds - we have the LocationHook that is used to assign tags mkgmap:admin_level2 to. mkgmap:admin_level10 and mkgmap:postcode. - we have inc/address to which uses either the data from the LocationHook or that from the OSM element to set mkgmap:city, mkgmap:region etc. The file inc/address in the default style doesn't care about any other tags, means, the result doesn't depend on the exstence of a highway tag or whether the element is a node, way, or polygon.
I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address.
I think that's hard to realize. Other style implementors do not need to use the same name inc/address. It is also possible that the address rules are written in a mixed style file. So it's not easy to detect which include file contains address rules only.
What is the major problem you have? Is it that inc/address does not differ between nodes, ways and polygons? You might change that (function type() returns node, way, relation depending on its type).
The major advantage of an included address file is that other style implementors can easily use it as it is so it would be good if its usage is not weaved into the default style too much.
WanMil
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

Hi all, I try to sovle the problem that I see elements with addr:housenumber which have all the mkgmap:adminlevel tags but they don't have the mkgmap:city tag. It seems that RuleSet.merge() doesn't merge the finalize rules. I think that's would be an error although I am not sure how a merge would work. this problem is solved with r3540. See also http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3540 Gerd
participants (3)
-
Gerd Petermann
-
Thorsten Kukuk
-
WanMil