Commit: r953: Create POIs inside areas if they do not already have one.

Version 953 was commited by steve on 2009-03-01 00:18:42 +0000 (Sun, 01 Mar 2009) BRANCH: poi Create POIs inside areas if they do not already have one. Bernhard Heibler: I have integrated Ben Konrath's Area POI patch into my code. I did the following changes to Ben's code: - Replaced the hard coded area to poi type mapping with the build in rule sets. Shapes are checked against the point rules to add missing pois. - Replaced the linear search (to avoid duplicated pois) with tile based search - Add buildings to polygons style - Moved my helper classes to general directory You have to add the --add-pois-to-areas to enable the Area POIs generation. I'm not sure if we should generate a new rule set in the style folder for this purpose. It works pretty good using the point rules but it might be confusing. - Original patch by Ben Konrath, itegrated by Bernhard Heibler

Hi Steve, thanks for updating the poi branch. It seams that the base of the poi branch is outdated. Could you re base it to the trunk ? How do we go on with the integration of this code ? I know it is a lot of stuff. My original plan was also to break it up in different chunks to speed up integration. Then I noticed that most of the stuff is required to make the whole thing working. From my point of view this are the different modules: * Data Gathering. (StyledConverter.java, PolishMapDataSource.java). This modules reads in the required additional tags. is_in and openGeoDB tags: Used for Region and Country Info. Karlsruhe addr: tags used for POI addressing. Question is can we leave it like this our should we add some configuration file to define the tags ? * Data Storage. (imgfmt/app/lbl) Extensions to support storage of POI addresses and sorting stuff of city lists. I think this should be easy to integrate. * Helper Classes (general) Add multi map and tile based point search map. Also some additions to some existing classes for additional data storage. * Region Data Processing (build/Locator.java and build/LocatorConfig.java) Analysis of the is_in tags to gather country and region info. This data is used to provide country region info to the city list and the pois. This module already be configured in ressources/LocatorConfig.xml. This module is also used to translate different spellings of country info and to get the country abbreviation tag. * POI and City Data Processing (build/MapBuilder.java) Fills in info into the Locator. Builds up the city and poi lists. Thanks Berni. svn commit schrieb:
Version 953 was commited by steve on 2009-03-01 00:18:42 +0000 (Sun, 01 Mar 2009) BRANCH: poi
Create POIs inside areas if they do not already have one.
Bernhard Heibler: I have integrated Ben Konrath's Area POI patch into my code. I did the following changes to Ben's code:
- Replaced the hard coded area to poi type mapping with the build in rule sets. Shapes are checked against the point rules to add missing pois. - Replaced the linear search (to avoid duplicated pois) with tile based search - Add buildings to polygons style - Moved my helper classes to general directory
You have to add the --add-pois-to-areas to enable the Area POIs generation. I'm not sure if we should generate a new rule set in the style folder for this purpose. It works pretty good using the point rules but it might be confusing.
- Original patch by Ben Konrath, itegrated by Bernhard Heibler _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Berni
thanks for updating the poi branch. It seams that the base of the poi branch is outdated. Could you re base it to the trunk ?
Yes I will merge in from trunk next.
How do we go on with the integration of this code ? I know it is a lot of stuff. My original plan was also to break it up in different chunks to speed up integration. Then I noticed that most of the stuff is required to make the whole thing working.
In an ideal world I would have liked to have this done in much smaller chunks too. But I am just going to merge in the trunk, ask people to test very well. And as long as there are no problems when no new options are given then I will just integrate it back to the trunk and take it from there. Cheers, ..Steve
participants (3)
-
Bernhard Heibler
-
Steve Ratcliffe
-
svn commit