[mkgmap-dev] [PATCH v1] - Do not write unnecessary POI information
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 reduces the size of the map by about 5% for my map (with a lot of POIs actually generated in the range 0x64xx to 0x66xx). It may be questionable to write no address information if there is no street given. IMHO though, what I want to have from that additional information is the street address. I can see on the map in which city and region the POI is in and in most cases I can also see the distance to my current location. So if I don't have at least a street name the information about the city and region alone (which is most likely autogenerated and therefore error-prone anyway) doesn't help. For my maps the additional size reduction of this is less than 1 % (which I don't understand BTW, should be more). 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___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a FIXME map style
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 is drawn on top of your other maps. Example: --draw-priority=30 Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a FIXME map style
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 base-style: default This makes the style inherit from the default style, so that you get everything from there too. Just remove that line and you will just see the things that you defined. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a FIXME map style
Thanks to both steve and clinton's suggestions On Sun, Apr 18, 2010 at 6:22 PM, Steve Ratcliffe st...@parabola.me.uk 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, etc). Why is this so? Your info file includes the lines: # This uses the default style as a base base-style: default This makes the style inherit from the default style, so that you get everything from there too. Just remove that line and you will just see the things that you defined. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - Do not write unnecessary POI information
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 the size of the map by about 5% for my map (with a lot of POIs actually generated in the range 0x64xx to 0x66xx). It may be questionable to write no address information if there is no street given. IMHO though, what I want to have from that additional information is the street address. I can see on the map in which city and region the POI is in and in most cases I can also see the distance to my current location. So if I don't have at least a street name the information about the city and region alone (which is most likely autogenerated and therefore error-prone anyway) doesn't help. For my maps the additional size reduction of this is less than 1 % (which I don't understand BTW, should be more). 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 it is much more. 0x4100 and bigger show no contact Information (this of course also includes all 0x1 ) - Or has someone found any POI above 0x4099 show any kind of contact information We would also need to exclude all cities (0x0*) to 0x1199 do not show any contact information (I'm not sure whether 0x13?? to ox1f?? do show contact information - as I never used any POI inside this range). I don't know how to adapt your patch to ONLY put contact information for 0x1300 - 0x4099 - but that is what we essentially need (maybe it is even 0x2000 - 0x4099). Plus we need to exclude 0x0 (e.g. 0x01709) 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 put once we have several keys that are added! ___ 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
Re: [mkgmap-dev] [PATCH v2] - Do not write unnecessary POI information
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 it is much more. 0x4100 and bigger show no contact Information (this of course also includes all 0x1 ) - Or has someone found any POI above 0x4099 show any kind of contact information I've changed it so that now there is no contact information for 0x1Cxx and for everything starting from 0x4100. I've found somewhere on the internet that POIs with 0x1Cxx don't have their contact information shown. We would also need to exclude all cities (0x0*) to 0x1199 do not show any contact information (I'm not sure whether 0x13?? to ox1f?? do show contact information - as I never used any POI inside this range). I don't know how to adapt your patch to ONLY put contact information for 0x1300 - 0x4099 - but that is what we essentially need (maybe it is even 0x2000 - 0x4099). Plus we need to exclude 0x0 (e.g. 0x01709) Cities are already excluded. They are handled separately and don't get any contact information. 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 put once we have several keys that are added! My patch gets rid of it, because it will only create the contact information if a street is given. That part of the code won't be executed anymore, so I removed it in v2. reduce_unnecessary_poi_infos.patch Description: Binary data Regards Thilo___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] garmin directives in different blocks?
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 have continue vs continue_with_actions, I don't see where your
[...]
Thanks. I now understand how it works. (Before, I didn't).
Best regards,
Valentijn
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Java crash - any idea?
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 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x010df786, pid=2517, tid=1161292656 # # JRE version: 6.0_18-b18 # Java VM: OpenJDK Server VM (14.0-b16 mixed mode linux-x86 ) # Derivative: IcedTea6 1.8 # Distribution: Ubuntu lucid (development branch), package 6b18-1.8-0ubuntu1 # Problematic frame: # V [libjvm.so+0x4f1786] # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ # --- T H R E A D --- Current thread (0x09dff800): GCTaskThread [stack: 0x452fe000,0x4537f000] [id=2520] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0xccd94790 Registers: EAX=0xccd94790, EBX=0x0125cff4, ECX=0x09e5c768, EDX=0x4537e070 ESP=0x4537de30, EBP=0x4537de48, ESI=0x4d415b64, EDI=0x01276638 EIP=0x010df786, CR2=0xccd94790, EFLAGS=0x00210206 Top of Stack: (sp=0x4537de30) 0x4537de30: 45639578 45639450 4537de68 0125cff4 0x4537de40: 4d415b60 4537df6c 4537ded8 00e985ae 0x4537de50: 4537e070 4d415b64 4537e070 4537e070 0x4537de60: 4537df40 b785bf80 4537ded8 00e9956d 0x4537de70: 0398c608 4537df84 01858fc8 456a5430 0x4537de80: 01a4 09dff800 0001 09dffdc0 0x4537de90: 456a5430 45370025 0005 0x4537dea0: 0001 b785bf78 Instructions: (pc=0x010df786) 0x010df776: 73 08 8d 65 f4 5b 5e 5f 5d c3 8b 55 08 8b 4a 0c 0x010df786: 8b 10 83 e2 03 83 fa 03 74 50 52 31 d2 8a 51 78 Stack: [0x452fe000,0x4537f000], sp=0x4537de30, free space=511k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x4f1786] V [libjvm.so+0x2aa5ae] V [libjvm.so+0x2aaa69] V [libjvm.so+0x57fba0] V [libjvm.so+0x4f10c3] V [libjvm.so+0x2cf42e] V [libjvm.so+0x4a6621] C [libpthread.so.0+0x596e] --- P R O C E S S --- Java Threads: ( = current thread ) 0x44f18400 JavaThread Low Memory Detector daemon [_thread_blocked, id=2527, stack(0x44d1d000,0x44d6e000)] 0x44f16000 JavaThread CompilerThread1 daemon [_thread_blocked, id=2526, stack(0x44d6e000,0x44def000)] 0x44f14800 JavaThread CompilerThread0 daemon [_thread_blocked, id=2525, stack(0x44def000,0x44e7)] 0x44f13000 JavaThread Signal Dispatcher daemon [_thread_blocked, id=2524, stack(0x44e7,0x44ec1000)] 0x44f00800 JavaThread Finalizer daemon [_thread_blocked, id=2523, stack(0x45016000,0x45067000)] 0x09e80800 JavaThread Reference Handler daemon [_thread_blocked, id=2522, stack(0x45067000,0x450b8000)] 0x09df7400 JavaThread main [_thread_blocked, id=2518, stack(0xb780c000,0xb785d000)] Other Threads: 0x09e7d800 VMThread [stack: 0x450b8000,0x45139000] [id=2521] 0x44f1a000 WatcherThread [stack: 0x44c9c000,0x44d1d000] [id=2528] =0x09dff800 (exited) GCTaskThread [stack: 0x452fe000,0x4537f000] [id=2520] VM state:at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0x09df51e0] Threads_lock - owner thread: 0x09e7d800 [0x09df55f0] Heap_lock - owner thread: 0x09df7400 Heap PSYoungGen total 154432K, used 128880K [0xabb2, 0xb75f, 0xb780) eden space 117952K, 100% used [0xabb2,0xb2e5,0xb2e5) from space 36480K, 29% used [0xb2e5,0xb38fc030,0xb51f) to space 35008K, 13% used [0xb53c,0xb5846080,0xb75f) PSOldGentotal 407680K, used 176324K [0x4d40, 0x6622, 0xabb2) object space 407680K, 43% used [0x4d40,0x580312a0,0x6622) PSPermGen total 16384K, used 8274K [0x4540, 0x4640, 0x4d40) object space 16384K, 50% used [0x4540,0x45c14b98,0x4640) Dynamic libraries: 0011-00263000 r-xp 08:01 14401813 /lib/tls/i686/cmov/libc-2.11.1.so 00263000-00264000 ---p 00153000 08:01 14401813 /lib/tls/i686/cmov/libc-2.11.1.so 00264000-00266000 r--p 00153000 08:01 14401813 /lib/tls/i686/cmov/libc-2.11.1.so 00266000-00267000 rw-p 00155000 08:01 14401813 /lib/tls/i686/cmov/libc-2.11.1.so 00267000-0026a000 rw-p 00:00 0 0026a000-0028e000 r-xp 08:01 14401819 /lib/tls/i686/cmov/libm-2.11.1.so 0028e000-0028f000 r--p 00023000 08:01 14401819 /lib/tls/i686/cmov/libm-2.11.1.so 0028f000-0029 rw-p 00024000 08:01 14401819 /lib/tls/i686/cmov/libm-2.11.1.so 0029-00297000 r-xp 08:01 14401831 /lib/tls/i686/cmov/librt-2.11.1.so 00297000-00298000 r--p 6000 08:01 14401831 /lib/tls/i686/cmov/librt-2.11.1.so 00298000-00299000 rw-p 7000 08:01 14401831 /lib/tls/i686/cmov/librt-2.11.1.so 00299000-002b rwxp 00:00 0 002b-00359000 rwxp 00:00 0
Re: [mkgmap-dev] [PATCH v1] Handling of boundary multipolygons
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 different colours for different administrative levels I think the 2nd option cannot be realized (at the moment). I see no way how to define a style that differently colours adjoining polygons with rather identical tags (e.g. boundary=adminstrative, admin_level=2). So let's concentrate on the 1st option. One way may be part of different boundary relations. (admin_level=2 admin_level=3 admin_level=4 ). To be able to process all of them with the style system the way must be duplicated for each relation. The multipolygon handling of boundaries might work as follows: For all ways (role=outer and inner) part of the boundary relation - Clone the original way - Tag the cloned way with the boundary information of the mp - Remove all tags from the original way that are also contained in the mp (with the same value) - Split all closed ways (polygons) in two ways to ensure that only ways are tagged with the boundary information What do you think? If no one really complains I will start implementing this (and expect that it will be accepted when I am ready :-). In case other multipolygon type also require such a processing we might add a config file in future which types are handled in this way. So this is ready to be more generic. WanMil Why talking so long? Implementation was quite easy so please try this patch and post what you think about this patch. I will post v2 with some more comments in the source code if it should be committed. WanMil Hallo WanMil Well I do think the patch is working as supposed. However that is not really what I find useful. Now on country boundaries there are sometimes 10 boundaries on top of each other - is this what you want to achieve? 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 with the boundary information. Other relations are not tagged and get their tags from the outer ways. And in all situations some ways contain other tags like highway=residential and so on. From my point of view the situation is quite chaotic. The patch standardizes the above situation in the way that for each boundary a line is created with the boundary tags and these tags are removed from the source lines. So in the end I get distinct lines for each boundary. As you have observed this results in overlapping lines if you have multiple boundaries (which is usual). So far so good. That's a good base to discuss what is really needed by you and other style implementors. My knowledge of the style system is quite basic so I don't know what's useful. But I am quite sure that's not the chaotic situation described above. WanMil I'ld much rather have only the boundary with the highest admin level - and have taken quite a bit of code into the style-file to make sure ONLY the boundary with the lowest admin_level is put inside the map. Your patch makes my style-file useless. I don't really understand what this patch is trying to achieve. There is a patch by Thilo Hanneman (I'm attaching it for you) that makes it possible to directly render relations from the relations file, I think that is more useful - or don't I understand something here that you intend to achieve??? BTW - I'ld much rather have a patch that disables sea, if there are more than 500 highway=residential inside the sea polygone, or something similar to detect that nothing is flooding. Just day before yesterdays alp extract from Geofabrik had one tile inside flooded, and there is the dreaded flooding inside Germany as allways (well this one due to geofabrik cutting). Maybe you could write a patch for that problem. I get tons of comments on my website about sea flooding, no matter in how many places I write that this is not solvable and any comment regarding sea flooding will get into the trashbin... ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java crash - any idea?
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,837,838 per seat ;) I think it says Don't use OpenJDK (although I have not actually looked at the log file). Other users indicated that switching to the Sun JVM solved such problems. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Handling of boundary multipolygons
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 with the boundary information. Other relations are not tagged and get their tags from the outer ways. And in all situations some ways contain other tags like highway=residential and so on. From my point of view the situation is quite chaotic. The patch standardizes the above situation in the way that for each boundary a line is created with the boundary tags and these tags are removed from the source lines. So in the end I get distinct lines for each boundary. As you have observed this results in overlapping lines if you have multiple boundaries (which is usual). So far so good. That's a good base to discuss what is really needed by you and other style implementors. My knowledge of the style system is quite basic so I don't know what's useful. But I am quite sure that's not the chaotic situation described above. WanMil I have one other idea that might be useful: If the relations are more useful for style writers than the line information the specialized multipolygon code could ensure that the boundary tagging is always and completely in the relation. Boundary information from the lines would be removed. Example: Relation 1: mp: type=multipolyon, boundary=administrative way 1: role=outer, boundary=administrative, admin_level=4, name=ABC region, ... way 2: role=outer, boundary=administrative, admin_level=4, highway=residential, name=ABC region way 3: role=inner, boundary=administrative, admin_level=4, name=ABC region, ... After processing: mp: type=multipolyon, boundary=administrative, admin_level=4, name=ABC region way 1: ... way 2: highway=residential way 3: ... Relation 2: mp: type=multipolygon, boundary=administrative, admin_level=5, name=Other region way 1: role=outer, boundary=administrative, admin_level=5, ... way 2: role=outer, boundary=administrative, admin_level=5, highway=residential, name=Weaverstreet way 3: boundary=administrative, ... After processing: mp: type=multipolygon, boundary=administrative, admin_level=5, name=Other region way 1: ... way 2: highway=residential, name=Weaverstreet way 3: ... So with other words: Style implementors can alway rely on the relation information and need not to filter out boundary information from the lines. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Handling of boundary multipolygons
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 additionally (and iconsistently) tagged with
the boundary information. Other relations are not tagged and get their
tags from the outer ways. And in all situations some ways contain other
tags like highway=residential and so on. From my point of view the
situation is quite chaotic.
The patch standardizes the above situation in the way that for each
boundary a line is created with the boundary tags and these tags are
removed from the source lines. So in the end I get distinct lines for
each boundary. As you have observed this results in overlapping lines if
you have multiple boundaries (which is usual).
So far so good. That's a good base to discuss what is really needed by
you and other style implementors. My knowledge of the style system is
quite basic so I don't know what's useful. But I am quite sure that's
not the chaotic situation described above.
WanMil
I have one other idea that might be useful:
If the relations are more useful for style writers than the line
information the specialized multipolygon code could ensure that the
boundary tagging is always and completely in the relation. Boundary
information from the lines would be removed.
Example:
Relation 1:
mp: type=multipolyon, boundary=administrative
way 1: role=outer, boundary=administrative, admin_level=4, name=ABC
region, ...
way 2: role=outer, boundary=administrative, admin_level=4,
highway=residential, name=ABC region
way 3: role=inner, boundary=administrative, admin_level=4, name=ABC
region, ...
After processing:
mp: type=multipolyon, boundary=administrative, admin_level=4, name=ABC
region
way 1: ...
way 2: highway=residential
way 3: ...
Relation 2:
mp: type=multipolygon, boundary=administrative, admin_level=5,
name=Other region
way 1: role=outer, boundary=administrative, admin_level=5, ...
way 2: role=outer, boundary=administrative, admin_level=5,
highway=residential, name=Weaverstreet
way 3: boundary=administrative, ...
After processing:
mp: type=multipolygon, boundary=administrative, admin_level=5,
name=Other region
way 1: ...
way 2: highway=residential, name=Weaverstreet
way 3: ...
So with other words:
Style implementors can alway rely on the relation information and need
not to filter out boundary information from the lines.
WanMil
Well IMHO the best would be to have
a) the possibility to directly create (routable) lines from the
relations style-file file.
b) the possibility to have the relations being added to the lines - so
you can choose i.e. to only display boundary=administrative
admin_level=4 if boundary=adminstrative admin_level=2 does not exist.
One can do this currently really nicely by not applying directly from
the relations file, but by using boundary=administrative admin_level=4
{set adminboundary4=exist; set adminboundary4name={$name};...}
Then inside the lines file one can put rules like
adminboundary2!=exist adminboundary4=exist {set
boundary=administrative; set admin_level=4; set name={$adminboundary4name} }
adminboundary2!=exist adminboundary4!=exist adminboundary5=exist
{set boundary=administrative; set admin_level=5; set
name={$adminboundary5name} }
.
What is missing here is that if there are several relations of type
admin_level=4 on the same way and you want all of them. Then you will
only have one. Therefore for things were one would like to have all
displayed (e.g. route=bicycle network=ncn) - one directly includes
them into the map from the relations file.
Therefore I propose to use, instead of your patch, the patch by Thilo,
and (if consensus) change the relations file in the default style to
directly write boundaries from the relations file, and not from the
lines file.
What I don't understand is why you want to filter out boundary
information from the lines, that what we have the rules section for and
the continue/continue_with_actions command. So I don't see any benefit
in your other idea over implementing the patch by Thilo into the main
trunk.
___
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
Re: [mkgmap-dev] [PATCH v2] - Do not write unnecessary POI information
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 information shown?
Regards
Thilo
Actually it is much more. 0x4100 and bigger show no contact Information (this
of course also includes all 0x1 ) - Or has someone found any POI above
0x4099 show any kind of contact information
I've changed it so that now there is no contact information for 0x1Cxx and for everything
starting from 0x4100. I've found somewhere on the internet that POIs with
0x1Cxx don't have their contact information shown.
We would also need to exclude all cities (0x0*) to 0x1199 do not show any
contact information (I'm not sure whether 0x13?? to ox1f?? do show contact
information - as I never used any POI inside this range). I don't know how to
adapt your patch to ONLY put contact information for 0x1300 - 0x4099 - but that
is what we essentially need (maybe it is even 0x2000 - 0x4099). Plus we need to
exclude 0x0 (e.g. 0x01709)
Cities are already excluded. They are handled separately and don't get any
contact information.
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 put once we have several keys that are added!
My patch gets rid of it, because it will only create the contact information if
a street is given. That part of the code won't be executed anymore, so I
removed it in v2.
Well I figured out the first part mysel by using:
else if(!p.isCity() !p.hasExtendedType()
(p.isRoadNamePOI() || poiAddresses)
((p.getType() 0x4100)) ((p.getType() = 0x2000))) {
because I think there are no sensible POI to be put besides cities on
0x2000.
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 only reduces the size of my
map (tested on Austria) by 0.5% - well better than nothing but I had
hoped for more. I would like to have this patch included into trunk,
cause .5% is better than nothing, but after your talking about 5% I had
hoped for more (the main difference is IMHO that I allways used extended
types extensively - so this patch has not much to do (I use very few POI
in the 4x range)
Regards
Thilo
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - Do not write unnecessary POI information
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.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Description text
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-address was easy, I do know that with mkgmap, each point gets this added. But for POI that don't have contact information the fix my address is added, but complete waste of space, as neither the GPS nor Mapsource/Basecamp will read it. It's like making non routable lines routable - there is simply no sense in doing it, as the GPS won't read it. Hence we increase map size without any benefit. It's like adding 200 pages Chinese Characters to the back of a telephone book. Only 1°% of people will ever read it. Hence you waste resources. Please forgive me, I didn't consider the devices with a limited built in flash. But the former question did mix it up. (just go into Mapsource or your GPS and try to see for which POI there is a popup, you'll notice that for most there is none (exclude cities/shopping and the few listed). 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. At restaurant I would appreciate the cuisine tag since Garmin offers too few coices. The same at shops.There are just a few different kind of shops listed at Garmin, but there is no possibility to find the next butcher, greengrocer, etc. But all these wishes would mean to dive into the Garmin maps structure ... Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - Do not write unnecessary POI information
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 put once we have several keys that are added! I thought that is was just added to remind mappers to add the missing information. But from the user's point of view just information that is in the database should be displayed and if there is no information there is no need to display that there is no further information. So I would suggest to add the info if it is supplied and else do nothing. Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - Do not write unnecessary POI information
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 only reduces the size of my map (tested on Austria) by 0.5% - well better than nothing but I had hoped for more. I would like to have this patch included into trunk, cause .5% is better than nothing, but after your talking about 5% I had hoped for more (the main difference is IMHO that I allways used extended types extensively - so this patch has not much to do (I use very few POI in the 4x range) Perhaps all the Fix my address-infos were summarized to one string that is now not shown? OK, then the difference should be even more smaller ... Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recycling menu items in the Oregon
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 others have filled in data for other units. I want to fill out the missing infos for the Oregon 450. But I think, I understand correct that screenshots of Garmin Icons are a Nogo, since there a copyrighted rights on them? So I have to describe what IMHO the Icon seems to mean? Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] addr or is_in tags
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 function), but one thing I think is important (which is currently missing in osmph): there is a state/province dropdown menu i discovered in mapsource, that mkgmap can supply using osm data, if said POI has tag: is_in='(province),(leaveblank),Philippines' eg. is_in=Rizal,,Philippines the particular POI will be searchable under (State/Province dropdown)=Rizal, but will be shown as capitalized RIZAL, followed by PH or PHI (wherein Philippines is automatically replaced by the country code defined in mkgmap. Definitely, this is intended for U.S. maps where the 2-letter codes of States are always capitalized. But since the search-function is already there, it's possible for garmin to narrow down the search of cities town in OSMPH if any distinctive province-tag is available, which will make us garmin user very happy :-) Advantage: while addr:state doesn't seem to work with mkgmap (at the moment when I tried it), i think we should still push for it on osm (considering there are lots of towns cities in the philippines with similar name (isabela, rizal, taytay...), and it's a bit tricky when filtering them out. addr:state or addr:province can easily be converted to is_in='(province),(blank),Philippines' fprmat (for the mean time that it is not supported by mkgmap just yet) -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
