On Mon, Apr 19, 2010 at 12:53:46AM +0200, Daniela Duerbeck wrote:
>No, each POI can be selected in the Oregon and I also would appreciate
>the information that is added in the osm database. E.g. which bus halts
>at the particular busstop and where it would go to.
This is already part of the defaul
Hi,
(posting this discussion to the list, hoping others have an idea on this topic)
--- addr:street & addr:city
seems to work well with mkgmap & garmin mapsource
at the moment, all others tags doesnt matter, like addr:state,
addr:village, addr:country (they don't seem to affect mapsource's find
Marko Mäkelä wrote:
> In the Edge, it is under Community/Utility. In German, perhaps
> Gemeinde/Versorgungsbetrieb. The POI is a white square on the Edge. Did you
> check http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types
> already? I have filled in most details for the Edge, and oth
Felix Hartmann wrote:
> Your addition dit it, and removed the fix_my_adress, however now there
> appears the "name" instead or the name of the POI type from the
> typfile. Is this just the standard behaviour, or is now the name
> really included?
>
> I'm kinda wondering, cause the whole patch on
Felix Hartmann wrote:
> As a second patch I think we would really need an option to switch of
> the "fix my address" nonsense. It only takes up space. So either
> replace that text by a simple dot "." or get rid of adding contact
> info alltogether if there is no address/or other info we want to
Felix Hartmann wrote:
>
> No you don't see the point.
You are right. I thought from my point of view: A sd-card with lots of
space ...
But in the meantime this seems to be fixed. But the other part: to add
useful information to each other POI is much more difficult. To comment
out the fix-my-add
When looking at the code I'm not so sure anymore that this patch does what I
expect it to do. So please do *not* include it into trunk. I'll think about it
and will come up with another one.
Regards
Thilo
___
mkgmap-dev mailing list
mkgmap-dev@lists.m
On 18.04.2010 20:42, Thilo Hannemann wrote:
Am 18.04.2010 um 19:15 schrieb Felix Hartmann:
On 18.04.2010 10:46, Thilo Hannemann wrote:
I'm not sure about the ID range 0x64xx to 0x66xx - has anybody tested this and
knows whether there are additional IDs that won't have their inform
On 18.04.2010 21:35, WanMil wrote:
>> Hi Felix,
>> yes that's exactly what the patch does and should do. Up to now the
>> boundary information is available at many different places. For some
>> boundaries the tags are in the relation. For some the tags are in the
>> relation and some lines are ad
>
> Hi Felix,
> yes that's exactly what the patch does and should do. Up to now the
> boundary information is available at many different places. For some
> boundaries the tags are in the relation. For some the tags are in the
> relation and some lines are additionally (and iconsistently) tagged wi
On Apr 18, 2010, at 21:12, Valentijn Sessink wrote:
> Mkgmap seems to crash on my brand new Ubuntu 10.04 installation with
> "OpenJDK" and I can't make anything of it (not being a Java wizard, that is).
> What does the attachment say? (I just hope it doesn't say "Switch to Oracle
> Java for €1,
>
>
> On 17.04.2010 20:00, WanMil wrote:
>>> I am thinking about how to handle boundary multipolygons and want get
>>> some feedback and ideas from you.
>>>
>>> There are two possible ways to use boundary information:
>>> 1. Draw the boundaries as lines
>>> 2. Draw the boundaries as polygons with d
Hi list,
Mkgmap seems to crash on my brand new Ubuntu 10.04 installation with
"OpenJDK" and I can't make anything of it (not being a Java wizard, that
is). What does the attachment say? (I just hope it doesn't say "Switch
to Oracle Java for €1,837,838 per seat" ;)
Best regards,
Valentijn
#
Op 16-04-10 09:34, Felix Hartmann schreef:
[...]
>> highway=motorway {add bicycle = no; add foot = no} [0x16 road_class=4
>> road_speed=1 resolution 14 continue]
>> highway=motorway {add access = no; add bicycle = yes; add foot = yes}
>> [0x16 road_class=4 road_speed=1 resolution 14]
> Well you h
Am 18.04.2010 um 19:15 schrieb Felix Hartmann:
> On 18.04.2010 10:46, Thilo Hannemann wrote:
>> I'm not sure about the ID range 0x64xx to 0x66xx - has anybody tested this
>> and knows whether there are additional IDs that won't have their information
>> shown?
>>
>> Regards
>> Thilo
> Actually
On 18.04.2010 10:46, Thilo Hannemann wrote:
The attached patch will prevent writing the additional POI information
(address, phone number) if
- it won't be shown (POIs with IDs 0x64xx to 0x66xx won't have their
information shown)
- there is no street given for that POI
This reduces
Thanks to both steve and clinton's suggestions
On Sun, Apr 18, 2010 at 6:22 PM, Steve Ratcliffe wrote:
> On 18/04/10 08:37, maning sambale wrote
>> 1. Even though the points style includes only places=*, osb and
>> keepright code assignment, I still get other POIs in the map (hotels,
>> shops, e
On 18/04/10 08:37, maning sambale wrote
> 1. Even though the points style includes only places=*, osb and
> keepright code assignment, I still get other POIs in the map (hotels,
> shops, etc). Why is this so?
Your info file includes the lines:
# This uses the default style as a base
On Apr 18, 2010, at 9:37, maning sambale wrote:
> 2. I activated the transparent switch in order to integrate the map
> into the regular maps. However, in etrex is see the keepright POIs
> underneath the roads.
I think you might want to use the draw-priority option to ensure that your
FIXME map
The attached patch will prevent writing the additional POI information
(address, phone number) if
- it won't be shown (POIs with IDs 0x64xx to 0x66xx won't have their
information shown)
- there is no street given for that POI
reduce_unnecessary_poi_infos.patch
Description: Binary data
This r
20 matches
Mail list logo
