Hi Steve,
The type id's I use for hospitals are:
0x6408 - accident emergency
0x3002 - other
Both these show in Mapsource in searching for hospitals.
Regards, Geoff.
On 30 January 2014 07:46:12 GMT, Steve Sgalowski steve.sgalow...@gmail.com
wrote:
that line , crashed the compiler
i am
No, my trunk roads are routable as many have pavements beside them and make a
useful link between footpaths.. It is only motorways and roads with motorway
like access restrictions I do not route down. It may well be down to the class
4 change though.
Next time I am on the laptop I will check
better to have a country exclusion list not to discard the likes
of Victoria and High in the UK if the counting algorithm is used.
Geoff.
Steve Ratcliffe st...@parabola.me.uk wrote:
On 06/08/13 18:57, Geoff Sherlock wrote:
Hi Steve,
When you collect the data for the index you could also
Hi Steve,
When you collect the data for the index you could also increment a count for
each word. Then only add the word to the index if the count is less than a
optional value (default say 1). This should work for most languages and
reduce the size of the index, although it will require
I have just tried Andrzej's test and I can confirm in many instances this
seems true. But I have found the odd case where routing does as expected as
well. Curious.
My settings where Pedestrian, so shortest distance.
Geoff
-Original Message-
From: Andrzej Popowski
Sent: Saturday,
This is possible, I used to combine maps of different countries at mkgmap
stage.
First split one map with --mapid=12310001, copy the resulting pbf files to
mkgmap directory. Then the second map with --mapid=12320001; again copying
the pbf files to mkgmap directory. Then call mkgmap with *.pbf,
Hi Henning,
I recompiled my maps this morning changing --max-nodes back to 150, but
could not find a inter-tile routing problem; so I think it must have been
something else that broke my routing before. It was probably using routable
overlays for trunk roads and primary roads at higher
I sent the attached mail a couple of weeks ago.
Reducing --max-nodes seems to make a difference; I tested another route this
morning in Basecamp after creating it in Mapsource and it worked fine (both
latest versions); and I have tested on my Dakota 20. My guess is Garmin
software uses fixed
Hi,
I suspect you have set your highest level at too high a resolution. My lowest
resolution (5:16 in the options style file) seems to show information when
zoomed far out. Obviously you need to show symbols at that level/resolution as
well (though far fewer the the higher resolution such as
Hi,
This is not a bug report, but something I found interesting.
I recently noticed a problem with polygon draw order in Mapsource; and on my
Dakota 20. Sometimes a polygon was drawn correctly above another (according
with the draw order specified in the TYP file), and at other times not. I
continue]
highway=trunk [0x02 road_class=3 road_speed=1 level 2]
highway=primary [0x10e0c level 3 continue]
highway=primary [0x03 road_class=2 road_speed=1 level 2]
Why does the routing on the roundabout (transparent line), followed by the
routing later on - work?
G
From: Geoff Sherlock
Sent
Not sure if anyone has spotted this before, as I have not been keeping a close
eye on the mailing list lately.
I had the following defined in my style file; to show thinner lines for primary
highways at different zoom levels:
highway=primary [0x1b road_class=2 road_speed=1 level 3-4 continue]
I think you are viewing in notepad. If viewed in wordpad or in any unix utility
it should look fine.
Geoff.
Bernd Weigelt weigelt.be...@web.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.04.2013 15:00, schrieb GerdP:
What problem do you have with the diff? If you use e.g. java
Just a thought.
If I wanted to remove the possibility of using a none-routable line type in
my style file for routable lines; would routing still work if you just used
a single line type for routing purposes? This could point to a transparent
line in the type file and would need a continue
I was intrigued enough to test this map. It certainly contains DEM data as a
test route of two points across a deep valley showed a lovely profile on my
device. But looking at the cgpsmapper manual DEM data cannot be created from
it, only DEM-like maps (see link below) which should be able to
: Monday, March 25, 2013 7:41 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Multiple relation names
On Mon, Mar 25, Geoff Sherlock wrote:
I’m sure I’ve read on this list that this is possible. For walking maps I
would the way name to consist of all possible related names for that way
OK, I managed to sort it out. Marko was right and the name combination
should have been in the relations file.
Now I have the following set in relations:
type=route name=* (route=bicycle | route=hiking | route=mtb |
route=walking | route=piste | route=horse | route=foot) {
apply {
names
On Mon, Mar 25, Geoff Sherlock wrote:
Hi Thorsten,
Apologies, this is the first time I have worked with relations and I need
some clarity.
Firstly:
set route_display_name='${route_display_name}'
This will overwrite the old route_display_name, you need to
add it.
I was under
: [mkgmap-dev] Multiple relation names
On Tue, Mar 26, 2013 at 05:44:05PM -, Geoff Sherlock wrote:
OK, I think I see how the concatenation is done now.
I changed my lines file to thus (relation tag route_display_name is set in
relations):
type=route route_display_name=* {
apply
Hi Marko,
I tried moving the first part to the relations file and saw no route names
come up. Reverted it to how it was, but I have tried to make it like the bus
route example in the style documentation as well (so more filtering for
walking routes, setting route=hiking etc in relations).
I’m sure I’ve read on this list that this is possible. For walking maps I would
the way name to consist of all possible related names for that way. For
instance for the relations named ‘Icknield Way’ and ‘Chiltern Way’, I would
like a way that is contained in both relations to be named
names
On Mon, Mar 25, Geoff Sherlock wrote:
I’m sure I’ve read on this list that this is possible. For walking maps I
would the way name to consist of all possible related names for that way.
For instance for the relations named ‘Icknield Way’ and ‘Chiltern Way’, I
would like a way
That is what I do. Alternatively if you have both in Mapsource, then select all
tiles from land maps, then switch to contours and select them as well. Then
transfer to device.
G
Carlos Dávila cdavi...@orangecorreo.es wrote:
El 19/03/13 15:44, prenard escribió:
Hi,
I would like to create a
it now.
Steve
On 16 March 2013 11:47, Geoff Sherlock
geoffrey_sherl...@btinternet.comwrote:
Hi,
I generate routable maps for walking in the UK, but have come across
a
couple of problems trying to route down certain ways in Mapsource.
These
ways do not cross any tile boundaries in Mapsource
page than in JOSM).
Cheers, Geoff.
From: Geoff Sherlock
Sent: Saturday, March 16, 2013 3:08 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Routing Problems in Mapsource
Steve, thanks for that, I do need glasses!
First routing problem now fixed (could see the change you made
Good work on fixing it.
Geoff
Steve Ratcliffe st...@parabola.me.uk wrote:
Hi Felix
I have now narrowed down the problem to 2335, which is confusingly the
first change *after* the last one that directly touched the MDR index
code.
There is a very obvious problem in that the sections MDR 20,
Regarding polygon draw order. Draw level can be defined in TYP file if one is
used. Draw level of sea should be that of land.
Geoff.
WanMil wmgc...@web.de wrote:
Hi WanMil,
Are you still working on the mp_cut branch or do you wait for
something
from me?
I assume that the
As Thorsten said phyghtmap. Pain to set up on 64 bit system but good results.
Geoff
GerdP gpetermann_muenc...@hotmail.com wrote:
WanMil wrote
do you know any other tool than SRTM2OSM? If it's only SRTM2OSM I
guess
there is no problem. The history of SRTM2OSM tells that version 1.10
starts
When I was doing some tests on which type codes were and were not routable, I
had inconsistent results with 0x05; sometimes you could route, other times not.
Due to this I started using another code for tertiary roads. I think this is a
Garmin problem, not mkgmap.
Happy New Year all.
Cheers,
Yes just corrected lines file and done another test. I did not make any changes
to 0x05 but it is now routable north to south???! I don't believe there are
any more mistakes, I am very puzzled.
Geoff.
Minko ligfiet...@online.nl wrote:
Geoff,
0x05 should route as good as other routable
Attached are the latest results test – 0x05 bothers me, sometimes it routes,
sometimes not. I will be avoiding it in mkgmap; although I think it is a
Basecamp/Mapsource problem. It is your choice.
Geoff.
From: Geoff Sherlock
Sent: Sunday, December 16, 2012 5:53 PM
To: Development list
Sorry typo, for 0x00-0x31 please read 0x00-0x1f
From: Geoff Sherlock
Sent: Saturday, December 15, 2012 11:22 PM
To: Development list for mkgmap
Subject: [mkgmap-dev] Useful routable line types
I’ve been experimenting with the first 32 type codes (0x00-0x31) in Basecamp to
see which types
Thanks Minko, I guess that is why the bridge worked - it was always an overlay.
Is there anywhere to say which codes are routeable, or is it try it and see (I
guess it needs to be a low number).
Cheers, Geoff.
Minko ligfiet...@online.nl wrote:
0x11501 is not a routable line type so thats
Thanks again Minko, I may have to do some swapping. I think I tried 0x0b before
but it did not show in basecamp, but as it's free I'll give it a go.
Cheers, Geoff.
Minko ligfiet...@online.nl wrote:
Thanks Minko, I guess that is why the bridge worked - it was always
an
overlay. Is there
Thanks guys (especially Minko for the second useful e-mail in a week), I now
have my maps not only routable, but as I wish to see them as well. Charlie,
your web site was one of the ones that got me into making my own maps,
thanks for the inspiration.
Cheers, Geoff.
-Original
Here are my thoughts:
-n name, --mapname=name
--description=text
--country-name=name
--country-abbr=abbreviation
--region-name=name
--region-abbr=abbreviation
--latin1, --code-page=number
--levels=levels code
--family-id
--family-name
--product-id
--product-version
--series-name
--area-name
Yes I've had similar issues in the past. I think I remember Steve saying in
some distant discussion that it is unknown behaviour the order Basecamp and
Mapsource display lines, so overlaying one line on top of another is
particularly difficult; and I tend to use an overlay map now if I need
Thanks Minko, I'll move that to a useful folder :-)
Geoff.
-Original Message-
From: Minko
Sent: Friday, December 07, 2012 8:39 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] line types not showing in basecamp
Geoff, Ctr-G (2x) clears the cache.
others. It also
If you can place yourself on the world, suddenly it is a smaller place.
Many happy returns thank you all.
Lambertus o...@na1400.info wrote:
Congratulations Steve and anyone on the list who contributed to this
great project! Mkgmap has really become a remarkable application.
On 26/11/2012
Steve,
My problem turned out to be a silly one. I had done some clean up of my
directory in the past and deleted the icenik.typ file the script was trying
to use.
Both splitter and mkgmap are now happy and processing data fine. I'll play
about with the with different splitter alignments to
Francois, you mention .osm.bz2 files. If you are only putting them through
splitter and mkgmap, it is much quicker to both download and process the
binary .pbf extracts.
Regards, Geoff.
-Original Message-
From: Francois
Sent: Friday, September 28, 2012 11:23 AM
Cc: 'Development list
400 is ok for ausralia
Stephen
On Fri, Sep 28, 2012 at 9:19 PM, Geoff Sherlock
geoffrey_sherl...@btinternet.com wrote:
Francois, you mention .osm.bz2 files. If you are only putting them through
splitter and mkgmap, it is much quicker to both download and process the
binary .pbf extracts
: [mkgmap-dev] geofabrik
true , but now when you use the splitter , it will not work on t he
new odbl license files
as it spits the dummy , when you have a map size of 0 x 200
0 x 400 is ok for ausralia
Stephen
On Fri, Sep 28, 2012 at 9:19 PM, Geoff Sherlock
geoffrey_sherl...@btinternet.com wrote
OK - had extra pbf files in the same directory - but mkgmap is still
failing. Getting late here, so I will get back the morrow.
Regards, Geoff.
-Original Message-
From: Geoff Sherlock
Sent: Friday, September 28, 2012 8:37 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev
Hi Maxim,
Data worked for me last night.
If you have not already done this try the following:
Zip file needs to be expanded, and all data stored in a directory (let's say
sea). Then point to the directory using --precomp-sea=sea
Regards, Geoff
On September 17, 2012 1:13 PM, Maxim wrote:
Would it be difficult to have precompiled water rather than sea?
It would save messing about with area files.
Regards, Geoff.
From: aighes
Sent: Monday, September 17, 2012 5:08 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Still problems with lakes
Am 17.09.2012 17:42, schrieb
Hi Greg,
The simplest way to test if it is the same error is to try the --latin1 flag
using the lastest (r2328) version of mkgmap. If this works then it will be
the same problem I was getting; which Steve now has a fix for. Once it has
been confirmed that the fix does not affect any other
I am interested in contributing to the development effort of mkgmap and have
come up with what should be a simple project to begin with. I am thinking of
adding a clip box to the splitter so that any nodes outside the box will be
ignored, and any lines, polygons will be clipped to the clip box
I must admit to not using osmosis or osmconvert before. The latter seems
ideal for the clipping a pbf file (I feel foolish to have not asked
earlier).
I would still like to add this functionality as part of the splitter as it
would make the whole process much faster (and give me a start in the
polygon clipping entirely.
Any thoughts?
WanMil, I will look at the bounds utility you mentioned.
Regards, Geoff.
-Original Message-
From: Geoff Sherlock
Sent: Sunday, September 16, 2012 2:42 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] New clip box functionality for splitter
.
-Original Message-
From: Geoff Sherlock
Sent: Monday, September 10, 2012 11:23 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Problem transferring maps from Mapsource
Thanks Steve,
I got the revisions and I'm currently testing them - I'll post the results
tomorrow.
Cheers
for mkgmap
Subject: Re: [mkgmap-dev] Problem transferring maps from Mapsource
On 09/09/12 16:38, Geoff Sherlock wrote:
--verbose; but as can be seen from the attached output no errors were
seen, ...
Just noticed, but there *is* an error in the attached output. Not sure
how it is happening, perhaps
On 07/09/12 07:33, Geoff Sherlock wrote:
Not quite Steve. It is happening as soon as I try and mark a map (error
pops
up as soon as I remove my finger from the mouse button - and hangs
Ahh, OK. Well it maybe something else then. I think that the
MPL_MAPDIRECTORY error usually means
On 05/09/12 20:38, Geoff Sherlock wrote:
Hhhmmm! Curiouser and curiouser.
r2274 of mkgmap works fine.
I have tried downloading 6.16.3 of Mapsource again. Reinstalled it, but it
still failed to transfer maps with mkgmap r2316 - with the same error.
I guess it is with my system if Henning is fine
-dev] Problem transferring maps from Mapsource
No...I tried it with 6.16.3 also with Win 7 64bit. I could send a map to
my Oregon300 without any problem. Map was generated with r2328.
Henning
Am 05.09.2012 20:35, schrieb Geoff Sherlock:
aighes, I guess you are using a different version of Mapsource
55 matches
Mail list logo
