Re: [mkgmap-dev] Routing with the eTrex 30

2011-10-19 Thread Thorsten Kukuk
On Tue, Oct 18, Felix Hartmann wrote: As I already wrote long time ago on the Basecamp forum, I don't think Garmin cares at all. Cause NO single map Garmin ever published does use bicycle or related settings. Hence not mkgmap does something wrong, but Garmin just eliminated sthg they never

[mkgmap-dev] Strange routing issue when joining a through_route

2011-10-19 Thread Steve Hosgood
The following oddity happens around node 86872929 (lat 51.448272, lon 3.49579W): I've got yesterday's maps running on a Streetpilot i3. I approach the problem area from the west on unclassified road (way 22883317) expecting to go south on the secondary route B4270 (way 4597013). Normally I'd

Re: [mkgmap-dev] Strange routing issue when joining a through_route

2011-10-19 Thread Steve Hosgood
On 2011-10-19 10:10, Steve Hosgood wrote: The following oddity happens around node 86872929 (lat 51.448272, lon 3.49579W): I should have posted a link - sorry. Try: http://www.openstreetmap.org/?mlat=51.448272mlon=-3.49579zoom=16layers=M Steve ___

Re: [mkgmap-dev] [PATCH v1] Extend tags for poi placement for the add-pois-to-areas option

2011-10-19 Thread Olaf Hasemann
Hello WanMil Am Dienstag 18 Oktober 2011, 23:06:50 schrieb WanMil: The patch adds a new option pois-to-areas-placement. This option defines on which node the POI generated from a polygon is placed preferrably. Example: pois-to-areas-placement=entrance=main;entrance=yes;building=entrance

Re: [mkgmap-dev] [PATCH v1] Extend tags for poi placement for the add-pois-to-areas option

2011-10-19 Thread WanMil
Hello WanMil Am Dienstag 18 Oktober 2011, 23:06:50 schrieb WanMil: The patch adds a new option pois-to-areas-placement. This option defines on which node the POI generated from a polygon is placed preferrably. Example: pois-to-areas-placement=entrance=main;entrance=yes;building=entrance

[mkgmap-dev] Commit: r2050: Add option pois-to-area-placement to configure the placement of POIs created from areas

2011-10-19 Thread svn commit
Version 2050 was commited by wanmil on 2011-10-19 19:56:55 +0100 (Wed, 19 Oct 2011) Add option pois-to-area-placement to configure the placement of POIs created from areas The options defines an ordered tag-value list to configure which node of a polygon tagged with one of the tags from the

[mkgmap-dev] Commit: r2051: Boundary precompiler uses a finer detection if a boundary is usable

2011-10-19 Thread svn commit
Version 2051 was commited by wanmil on 2011-10-19 20:17:17 +0100 (Wed, 19 Oct 2011) Boundary precompiler uses a finer detection if a boundary is usable The detection if a boundary is usable now checks also if a name tag (a tagname containing the string 'name') is set which is mandatory to be

[mkgmap-dev] Commit: r2052: Country names are assigned by the name-tag-list option when using precompiled bounds

2011-10-19 Thread svn commit
Version 2052 was commited by wanmil on 2011-10-19 20:32:35 +0100 (Wed, 19 Oct 2011) Country names are assigned by the name-tag-list option when using precompiled bounds The precompiled bounds contain the country names in many languages. When using them the name-tag-list option is now used

[mkgmap-dev] [PATCH v1] Further reduction of the builtin-tag-list

2011-10-19 Thread WanMil
The patch removes the two tags type and maxspeed from the builtin-tag-list. This reduces memory requirements (a few) if these tags are not required. Tag type: The tag is mandatory for relations. So I think it's ok to implement a rule in the relation loader that keeps the type tag. For nodes

Re: [mkgmap-dev] [PATCH v1] Further reduction of the builtin-tag-list

2011-10-19 Thread Felix Hartmann
On 19.10.2011 22:36, WanMil wrote: The patch removes the two tags type and maxspeed from the builtin-tag-list. This reduces memory requirements (a few) if these tags are not required. Tag type: The tag is mandatory for relations. So I think it's ok to implement a rule in the relation