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