inc/address and --housenumbers
Hi all, the default style uses the include inc/address in the finalize rules for points and lines. That means that OSM elements which are not added to the map do not have corresponding tags like mkgmap:city. The problem: For the --housenumber option we want to analyse all elements with addr:housenumber, we don't care if the house is displayed as a polygon or as a point or not at all. With the current default style most houses (= elements with addr:housenumber) do NOT have a tag like mkgmap:city or mkgmap:country. Now, this isn't a big problem in most cases because mkgmap has to attach the address information to a road, and the road is added to the map and therefor is passed through the inc/address rules. I faced two situations where this is not sufficient: 1) A road can connect two or more cities. The current code doesn't care about that. In the LocationHook we set the tags like mkgmap:admin_level8 only once for the road (typically for a point near the middle of the road), we don't recognize the case that different points on the roads are in different cities. A possible solution would be to call the LocationHook for each point on the road and split the road into parts before style processing. 2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed. I'll implement that in the housenumber2 branch. Please let me know when you see a better solution. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/inc-address-and-housenumbers-tp5840656.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Tue, Apr 14, GerdP wrote:
2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed.
My solution for my own style is quite simple here: I include 'inc/address' very early at the beginning of points/lines/polygons style files. Has also the advantage, that mkgmap:street is set to the original street name, before we add suffixes or prefixes like '(B101)' or something similar. And I can use mkgmap:country or something similar in my style files. 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, reg. mkgmap:street: The default style has this rule almost at the beginning: highway=* & name=* { set mkgmap:street='${name}' }, so there is no problem for address search here. I agree that your solution is also simple enough, but there should be no need to use inc/address in the relations rule. I don't know why inc/address was moved to the finalize rules, so I did not dare to change that. If the reason is performance we can ignore that , the evaluation of the rules in inc/address is very fast as they do not contain any regular expressions. BTW: with r3537 I've implemented the tag mkgmap:execute_finalize_rules=true (true, not 1 ) and I found no change in the throughput after adding addr:housenumber=* {set mkgmap:execute_finalize_rules=true} to the beginning of points and lines. I am now working on an algo that uses the mkgmap:city info. Gerd
Date: Wed, 15 Apr 2015 11:03:16 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
On Tue, Apr 14, GerdP wrote:
2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed.
My solution for my own style is quite simple here: I include 'inc/address' very early at the beginning of points/lines/polygons style files. Has also the advantage, that mkgmap:street is set to the original street name, before we add suffixes or prefixes like '(B101)' or something similar. And I can use mkgmap:country or something similar in my style files.
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
Hi Gerd, the address rules were included in the finalize section for performance reasons. I never measured the diff but because we didn't require the address tags in the other rules it was better (more or less) to place it in the finalize section. So if performance is not a problem it is no problem to move them back to the common rules. WanMil
Hi Thorsten,
reg. mkgmap:street: The default style has this rule almost at the beginning: highway=* & name=* { set mkgmap:street='${name}' }, so there is no problem for address search here.
I agree that your solution is also simple enough, but there should be no need to use inc/address in the relations rule.
I don't know why inc/address was moved to the finalize rules, so I did not dare to change that. If the reason is performance we can ignore that , the evaluation of the rules in inc/address is very fast as they do not contain any regular expressions.
BTW: with r3537 I've implemented the tag mkgmap:execute_finalize_rules=true (true, not 1 ) and I found no change in the throughput after adding addr:housenumber=* {set mkgmap:execute_finalize_rules=true} to the beginning of points and lines.
I am now working on an algo that uses the mkgmap:city info.
Gerd
Date: Wed, 15 Apr 2015 11:03:16 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
On Tue, Apr 14, GerdP wrote:
2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed.
My solution for my own style is quite simple here: I include 'inc/address' very early at the beginning of points/lines/polygons style files. Has also the advantage, that mkgmap:street is set to the original street name, before we add suffixes or prefixes like '(B101)' or something similar. And I can use mkgmap:country or something similar in my style files.
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
Hi WanMil, thanks for the info. I think performance was an issue before the merge of the performance2 branch (r3258), but now the evaluation of simple rules is very fast, it often simply means comparing an int value. So I think it's best to include the inc/address at the beginning of points and lines. I'll do that in the branch. Gerd
Date: Wed, 15 Apr 2015 11:57:52 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
Hi Gerd,
the address rules were included in the finalize section for performance reasons. I never measured the diff but because we didn't require the address tags in the other rules it was better (more or less) to place it in the finalize section.
So if performance is not a problem it is no problem to move them back to the common rules.
WanMil
Hi Thorsten,
reg. mkgmap:street: The default style has this rule almost at the beginning: highway=* & name=* { set mkgmap:street='${name}' }, so there is no problem for address search here.
I agree that your solution is also simple enough, but there should be no need to use inc/address in the relations rule.
I don't know why inc/address was moved to the finalize rules, so I did not dare to change that. If the reason is performance we can ignore that , the evaluation of the rules in inc/address is very fast as they do not contain any regular expressions.
BTW: with r3537 I've implemented the tag mkgmap:execute_finalize_rules=true (true, not 1 ) and I found no change in the throughput after adding addr:housenumber=* {set mkgmap:execute_finalize_rules=true} to the beginning of points and lines.
I am now working on an algo that uses the mkgmap:city info.
Gerd
Date: Wed, 15 Apr 2015 11:03:16 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
On Tue, Apr 14, GerdP wrote:
2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed.
My solution for my own style is quite simple here: I include 'inc/address' very early at the beginning of points/lines/polygons style files. Has also the advantage, that mkgmap:street is set to the original street name, before we add suffixes or prefixes like '(B101)' or something similar. And I can use mkgmap:country or something similar in my style files.
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I've just noted that the solution with addr:housenumber=* {set mkgmap:execute_finalize_rules=true} doesn't work for polygons because the polygons rules don't contain inc/address in the finalize section. This makes sense because the img format doesn't allow to store address info for polygons. On the other hand, this also means that it doesn't work when we add include 'inc/address'; to lines because the rules in lines are not evaluated for polygons. I think we should not add include 'inc/address'; at the beginning of polygons AND lines, because that would mean that we evaluate them twice for normal ways. So, I think this is the best compromise: 1) Keep include 'inc/address'; in the finalize section of lines and points 2) add it to the finalize section of polygons (with a comment that explains why) and 3) add addr:housenumber=* {set mkgmap:execute_finalize_rules=true} to the three files points, lines, and polygons. Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 15 Apr 2015 11:21:55 +0200 Subject: Re: [mkgmap-dev] inc/address and --housenumbers Hi Thorsten, reg. mkgmap:street: The default style has this rule almost at the beginning: highway=* & name=* { set mkgmap:street='${name}' }, so there is no problem for address search here. I agree that your solution is also simple enough, but there should be no need to use inc/address in the relations rule. I don't know why inc/address was moved to the finalize rules, so I did not dare to change that. If the reason is performance we can ignore that , the evaluation of the rules in inc/address is very fast as they do not contain any regular expressions. BTW: with r3537 I've implemented the tag mkgmap:execute_finalize_rules=true (true, not 1 ) and I found no change in the throughput after adding addr:housenumber=* {set mkgmap:execute_finalize_rules=true} to the beginning of points and lines. I am now working on an algo that uses the mkgmap:city info. Gerd
Date: Wed, 15 Apr 2015 11:03:16 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
On Tue, Apr 14, GerdP wrote:
2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed.
My solution for my own style is quite simple here: I include 'inc/address' very early at the beginning of points/lines/polygons style files. Has also the advantage, that mkgmap:street is set to the original street name, before we add suffixes or prefixes like '(B101)' or something similar. And I can use mkgmap:country or something similar in my style files.
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
Hi Gerd,
2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works.
A road at the border of 2 cities can have 2 different addresses, including road name, zip code, city and region. Maybe country too? I don't think that duplicating road object is a right solution. Road name can be added as a second label, I hope that other data can have multiple values too. Cgpsmapper allows for 2 addresses for a road, it probably doesn't duplicate road line, but I haven't checked. -- Best regards, Andrzej
Hi Andrzej, interesting. The current code in mkgmap doesn't allow multiple cities, regions, or countries for one road. I'd like to know when that is possible. Please post a link to such an img file. Reg. road names: we often have 3 of 4 possible labels filled when a ref existis. I don't know if a maximum of 4 labels is a limit in the IMG format or in mkgmap, AFAIK it is in IMG format. Gerd popej wrote
Hi Gerd,
2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works.
A road at the border of 2 cities can have 2 different addresses, including road name, zip code, city and region. Maybe country too? I don't think that duplicating road object is a right solution. Road name can be added as a second label, I hope that other data can have multiple values too.
Cgpsmapper allows for 2 addresses for a road, it probably doesn't duplicate road line, but I haven't checked.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/inc-address-and-housenumbers-tp5840656p584071... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd
interesting. The current code in mkgmap doesn't allow multiple cities, regions, or countries for one road. I'd like to know when that is possible.
That is correct it does not currently allow this. The format itself, allows you to specify a zip, city, region and country for the left and right hand side of the road. This information is in NET. Code to read those segments was included in the cgpsmapper GPL code release so it should be possible to work out how to write it. ..Steve
Hi Steve, would be great if you could help me with that. I don't know much about the cgpsmapper sources. Gerd
Date: Wed, 15 Apr 2015 15:06:36 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
Hi Gerd
interesting. The current code in mkgmap doesn't allow multiple cities, regions, or countries for one road. I'd like to know when that is possible.
That is correct it does not currently allow this.
The format itself, allows you to specify a zip, city, region and country for the left and right hand side of the road. This information is in NET.
Code to read those segments was included in the cgpsmapper GPL code release so it should be possible to work out how to write it.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I see that discussion has gone further, do you still need example of a map from cgpsmapper? -- Best regards, Andrzej
Hi Andrzej, I have to look at the latest changes in display tool first, but I think it would help to have an img file that contains the new features like multiple cities for one road and different cities on the left/right side. Gerd
Date: Wed, 15 Apr 2015 23:02:14 +0200 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
Hi Gerd,
I see that discussion has gone further, do you still need example of a map from cgpsmapper?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I have compiled example with a road that goes across 3 cities, see attached archive. Road has 2 names, which are the same for all cities. This is good for left/right cities, but rather unusual, when a road leads from one city to another. Road name is StreetLeft and StreetRight, first one is displayed on map. Numbering along road goes like this: numbers 1-9 for CityLeft and 2-10 for CityRight numbers 11-19 and 12-20, both sides in CityLeft numbers 1-19 and 2-20, both sides for CityThird I have noticed, that junction inside the road breaks numbering. I had to explicitly set numbering for junction point to get continuous numbering along whole road. Mapsource finds correctly addresses for each city, but search without city shows only one address from two available. Both street names can be used, there is no assignment to left/right city. -- Best regards, Andrzej
Hi Andrzej, thanks a lot. The display tool does not yet show the city names or zip codes, so I am not sure how they are stored, but I hope that Steve is already trying to (de)code that. I now have to think about the rules for my plausibility checks, some are obsolete, some new are required. Gerd Date: Thu, 16 Apr 2015 14:51:17 +0200 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers Hi Gerd, I have compiled example with a road that goes across 3 cities, see attached archive. Road has 2 names, which are the same for all cities. This is good for left/right cities, but rather unusual, when a road leads from one city to another. Road name is StreetLeft and StreetRight, first one is displayed on map. Numbering along road goes like this: numbers 1-9 for CityLeft and 2-10 for CityRight numbers 11-19 and 12-20, both sides in CityLeft numbers 1-19 and 2-20, both sides for CityThird I have noticed, that junction inside the road breaks numbering. I had to explicitly set numbering for junction point to get continuous numbering along whole road. Mapsource finds correctly addresses for each city, but search without city shows only one address from two available. Both street names can be used, there is no assignment to left/right city. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, I read the cgpsmapper manual, if I got that right the additional city names are only used in indexes, and I assume that there is no limit in those structures, so you are probably right, I don't have to split a road because it is in different cities, I just have to pass the information to the routines which build the indexes. @Steve: If wonder if we should change the data structures for this. Current code has the class MapElement with these fields: private String zip,country,region,city,street,phone,houseNumber,isIn; If we change zip, country,region, and city to String[] arrays as with String[] labels; we will waste a lot of memory when almost of them contain a single String reference. On the other hand, we probably have many objects with identical values in these fields. I think we can use a dictionary for this. The dictionary would contain one entry for each different combination of the values and MapElement would contain an index to the dictionary entry. I have to check that, but I think in the end we might safe memory with that. Gerd
Date: Wed, 15 Apr 2015 14:07:55 +0200 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
Hi Gerd,
2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works.
A road at the border of 2 cities can have 2 different addresses, including road name, zip code, city and region. Maybe country too? I don't think that duplicating road object is a right solution. Road name can be added as a second label, I hope that other data can have multiple values too.
Cgpsmapper allows for 2 addresses for a road, it probably doesn't duplicate road line, but I haven't checked.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
I don't have to split a road because it is in different cities, I just have to pass the information to the routines which build the indexes.
At the very least you will have to insert a non-routing node at the boundary if there is not one there already, so that the city change can be recorded at it.
If wonder if we should change the data structures for this. Current code has the class MapElement with these fields: private String zip,country,region,city,street,phone,houseNumber,isIn;
There seems to be some room for saving space as most elements will not use all of those. There could be a separate address structure perhaps consisting of (city, region, country) which could even be shared. But anyway it only roads that can have multiple city,region,country combinations so it could probably be added to the RoadDef in the same way as the Numbers are (and maybe even combined with them). ..Steve
Hi Steve,
I don't have to split a road because it is in different cities, I just have to pass the information to the routines which build the indexes.
At the very least you will have to insert a non-routing node at the boundary if there is not one there already, so that the city change can be recorded at it.
OK, that should be no problem.
But anyway it only roads that can have multiple city,region,country combinations so it could probably be added to the RoadDef in the same way as the Numbers are (and maybe even combined with them).
OK, I think I'll start changing the code in the Housenumber package. It should be easy to copy the data to the data structures once I have sorted out how to group houses and roads. I can probably remove > 25 % of the current code in the branch. Gerd
Hi Gerd I think that display now works for at least some cases. It is much simpler than I was thinking. There is a list of cities with some flags to say if it applies to the left or right hand side of the road or both and which node it applies from. The interpretation may not be completely correct, but at least the numbers look reasonable on one test file. ..Steve
Hi Steve, great, that was fast ! When you say city I understand it is an int that points to a table of cities, and this table also contains corresponding region and country info? What about zip codes? Line 217 in NetDisplay shows this printAddrInfo(d, addrFlags >> 2, "zip", zipSize); but I don't see corresponding code in printAddrInfo(). @Andrzej: It would also be very intersting to know how address search works when a road connects two different cities and both cities have equal numbers. Sample: Road X starts in city A and has numbers 1..19 in that city, it ends in city B and has numbers 1..7 in B. What happens if I search for number 5 in road X without specifying a city? What happens with A or B? Up to now we write data that will show the numbers in A or in B, but not both. Gerd
Date: Wed, 15 Apr 2015 23:46:40 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
Hi Gerd
I think that display now works for at least some cases. It is much simpler than I was thinking. There is a list of cities with some flags to say if it applies to the left or right hand side of the road or both and which node it applies from.
The interpretation may not be completely correct, but at least the numbers look reasonable on one test file.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
When you say city I understand it is an int that points to a table of cities, and this table also contains corresponding region and country info?
Yes, it is the index into LBL4, which is the section that is printed by LblDisplay. That contains a link to either a region or a country. If a region, then the corresponding region section links to the country.
What about zip codes?
Line 217 in NetDisplay shows this printAddrInfo(d, addrFlags >> 2, "zip", zipSize); but I don't see corresponding code in printAddrInfo().
Are you fully up to date? I implemented zip's earlier today, but I managed to label them the wrong way round in the display. I've just committed a fix for that. The zip integers are an index into LBL8 in the same way. So, unusually, the polish format is not an close match to the format in this case. It has names for city,region,country which would mean that we would have to look up and if necessary create a matching city. ..Steve
Hi Steve, I just tried r451 on the img file from Andrzej NetCheck complains, but NetDisplay seems to extract most of the infos (it just doesn't decode the offsets into the LBL file) I am now trying to change the housenumber code so that it produces the additional lists. If I got that right, we need a new data structure containing a) the list of Numbers (as we have now) b) an optional list of zip codes , each a class with two fields: int rNode; String zipCode; c) an optional list of city names, each a class with 4 fields: int rNode; String city,region,country; we can also attach the two new lists to RoadDef, probably easier, but I'd prefer to have one structure. I guess we need some code to set the indexes into LBL etc. I hope you help with that. Gerd
Date: Thu, 16 Apr 2015 14:57:34 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers
Hi Gerd
When you say city I understand it is an int that points to a table of cities, and this table also contains corresponding region and country info?
Yes, it is the index into LBL4, which is the section that is printed by LblDisplay. That contains a link to either a region or a country. If a region, then the corresponding region section links to the country.
What about zip codes?
Line 217 in NetDisplay shows this printAddrInfo(d, addrFlags >> 2, "zip", zipSize); but I don't see corresponding code in printAddrInfo().
Are you fully up to date? I implemented zip's earlier today, but I managed to label them the wrong way round in the display. I've just committed a fix for that.
The zip integers are an index into LBL8 in the same way.
So, unusually, the polish format is not an close match to the format in this case. It has names for city,region,country which would mean that we would have to look up and if necessary create a matching city.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
I just tried r451 on the img file from Andrzej NetCheck complains, but NetDisplay seems to extract most of the infos (it just doesn't decode the offsets into the LBL file)
I've just committed something to display the city names. Its likely that there are off-by-one errors, I will sit down this evening and try it out on Andrzej's file.
I am now trying to change the housenumber code so that it produces the additional lists. If I got that right, we need a new data structure containing a) the list of Numbers (as we have now) b) an optional list of zip codes , each a class with two fields: int rNode; String zipCode; c) an optional list of city names, each a class with 4 fields: int rNode; String city,region,country;
We need left and right versions of each. We only need the integer city index and the integer zip index, if that information is available when it is constructed. ..Steve
Hi Steve,
I am now trying to change the housenumber code so that it produces the additional lists. If I got that right, we need a new data structure containing a) the list of Numbers (as we have now) b) an optional list of zip codes , each a class with two fields: int rNode; String zipCode; c) an optional list of city names, each a class with 4 fields: int rNode; String city,region,country;
We need left and right versions of each. We only need the integer city index and the integer zip index, if that information is available when it is constructed.
good, almost forgot again that left and right can be different. reg. the field rNode : I think this can be any number node ? I think the calculation of the int value for the combination of city+region+country can only be done when the LBLfile is already written? My understanding is that the int is a value that corresponds to the field uk.me.parabola.imgfmt.app.ImgFileWriter.City.index ? Gerd
On 16/04/15 16:00, Gerd Petermann wrote:
reg. the field rNode : I think this can be any number node ?
Its the same as the house number nodes. So a routing node, or a non-routing node, but not just a point.
I think the calculation of the int value for the combination of city+region+country can only be done when the LBLfile is already written? My understanding is that the int is a value that corresponds to the field uk.me.parabola.imgfmt.app.ImgFileWriter.City.index ?
OK, it is probably too early, how about holding just a pointer to the City if that is available. The index is available at the time the NET section is written out. ..Steve
Hi
OK, it is probably too early, how about holding just a pointer to the City if that is available. The index is available at the time the NET section is written out.
I should have looked at the existing RoadDef. That is exactly how it is done now: there is a single City and Zip in RoadDef. We need instead an array of City and node/side information. When it comes to writing out, if there is only one city for the whole road then we just write the city field exactly as now, and if there is more than one we write it in the new way. ..Steve
ok steve and gerd and others i have the new mkgmap files in all is ok , just get these areas also steve and gerd , big question , has cuisine , been changed as all my things with cusiine have been nocked out Stephen G On Fri, Apr 17, 2015 at 4:58 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
Hi
OK, it is probably too early, how about holding just a pointer
to the City if that is available. The index is available at the time the NET section is written out.
I should have looked at the existing RoadDef. That is exactly how it is done now: there is a single City and Zip in RoadDef. We need instead an array of City and node/side information. When it comes to writing out, if there is only one city for the whole road then we just write the city field exactly as now, and if there is more than one we write it in the new way.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Stephen, your style produces too many POI for a small area. Please try to use the hints which I gave in previous posts and personal mails, esp. those regarding option --add-pois-to-lines and the evaluation of the mkgmap:line2poitype=* tag. Search http://www.mkgmap.org.uk/doc/options for details. If the above is not the reason I have no idea what happened to your cuisine POI. Gerd Date: Fri, 17 Apr 2015 17:06:21 +1000 From: steve.sgalowski@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] inc/address and --housenumbers ok steve and gerd and others i have the new mkgmap files in all is ok , just get these areas also steve and gerd , big question , has cuisine , been changed as all my things with cusiine have been nocked out Stephen G On Fri, Apr 17, 2015 at 4:58 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote: Hi OK, it is probably too early, how about holding just a pointer to the City if that is available. The index is available at the time the NET section is written out. I should have looked at the existing RoadDef. That is exactly how it is done now: there is a single City and Zip in RoadDef. We need instead an array of City and node/side information. When it comes to writing out, if there is only one city for the whole road then we just write the city field exactly as now, and if there is more than one we write it in the new way. ..Steve _______________________________________________ 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 Steve,
OK, it is probably too early, how about holding just a pointer to the City if that is available. The index is available at the time the NET section is written out.
I should have looked at the existing RoadDef. That is exactly how it is done now: there is a single City and Zip in RoadDef. We need instead an array of City and node/side information. When it comes to writing out, if there is only one city for the whole road then we just write the city field exactly as now, and if there is more than one we write it in the new way.
yes, I also came to that point. The housenumber code fills lists in RoadDef, the img write routines calculate the int values and finally write the additional data. Gerd
participants (7)
-
Andrzej Popowski -
Gerd Petermann -
GerdP
-
Steve Ratcliffe -
Steve Sgalowski -
Thorsten Kukuk -
WanMil