Hi Stephen,
yes, you should have received an answer a now.
Gerd
Date: Tue, 6 Jan 2015 19:15:51 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)
gerd P
did you get my direct e-mail to you sir
stephen
On Tue, Jan
yes gerd p i did
will try it ok gerd p
ty
stephen
On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann
gpetermann_muenc...@hotmail.com wrote:
Hi Stephen,
yes, you should have received an answer a now.
Gerd
--
Date: Tue, 6 Jan 2015 19:15:51 +1000
From:
gerd P
did you get my direct e-mail to you sir
stephen
On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com
wrote:
Hi Stephen,
the log shows no problems. Why do you think that max-nodes=40 doesn't
work?
Do you see an error message in mkgmap?
If yes, please provide
Version mkgmap-r3393 was committed by gerd on Tue, 06 Jan 2015
improve error message when a sub option like floodblocker is
used in combination with --precomp-sea
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
I am trying to use an extended line type for an overlay but I'm not
successfull.
The following information I found in style-manual.pdf on page 30:
2. If a type is = 0x01, it is an extended type, which can be used
for points, lines, and polygons.
This means, extended types for lines
Hi Walter,
I am not sure about the marine types, but
you may look at Minkos Openfietsmap style and map making procedure here:
http://www.openfietsmap.nl/procedure
which shows how to use extended types with a type file.
I think Marine Devices do not support typ files.
Gerd
From:
Hi,
I coded the described algo, it contained a small error, but seems to work,
but it is much slower than the simple existing algo, esp.
in those cases were the simple algo works fine,
as it requires tons of rather complex distance calculations
for each polygon.
I will look for some optimization,
Hi Walter,
I have tried with linetype 0x1901, but I could not address it neither
as 0x1901 nor as 0x11901.
I think there is no subtypes for line 0x19. Line 0x1901 is probably
created as 0x19 (or 0x1900). You can use lines from 0x01 to 0x2b and
then from 0x10001 up. Try for example 11901.
Hi Mike,
I think Steve has to permit that you can commit directly to trunk.
I don't know if you are allowed to create a branch.
If you don't mind, I suggest to use this procedure for now:
1) post a patch file and upload a binary to
http://files.mkgmap.org.uk/
Let all users know what the patch
I have a working solution for ensuring that the created point is placed
within the polygon when using --add-pois-to-areas, based on drawing the
polygon on to a small monochrome bitmap and then looking for the point that
is furthest from the surrounding area. I used a 9x9 bitmap for polygons
having
I can't seem to commit any changes, because I think Tortoise SVN is using a
guest account to retrieve the data and I can't work out how to get it to use
my account details instead (which I assume are the same as the email
subscription details). I have the following in my Tortoise SVN servers file:
Hi Mike,
50% sounds better than my algo, but still quite a lot. I'll have a closer look
at your
algo later.
Please note that your change has a side effect on the house number generator.
Up to now this doesn't contain a filter for generated POI, so each polygon
with a house number is processed
Hi Gerd, thanks for the quick reply. I'm happy to post patch files for now.
I already posted one suggested change, although I didn't use the create
patch file option.
I have another small patch to improve the message when there are too many
POIS at the same place - two patch files attached.
As
In the past I did not use a background polygon on my Oregon.
But since the default green color was not the best,
I defined a background with a light beige color.
Since this change the blue color for the see is gone. (Lakes are still shown)
I’m sure there is a solution to show the see togethere
Hi Mike,
I like the idea, but it seems to be slow.
Is it possible that your algo suffers when no fast graphics card is
available?
On my netbook the performance is very poor, did not yet
try on the PC, but that also has no high speed graphics.
Gerd
GerdP wrote
Hi Mike,
50% sounds better
Hi Mike,
the content of the patch looks ok to me. In the future, please try to use a
command like
svn diff path/xyz.patch
in the mkgmap directory.
to produce one patch file containing all changes that belong together.
The result should look like the attached file.
This allows others to apply
gerd , have tried some of your ideas
no not all worked for me
however have worked out and are combining my poi strings
am re checking now with the new poi test file you have just uploaded to
mkgmap server
stephen
On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann
gpetermann_muenc...@hotmail.com
Hi Stephen,
okay, I forgot to ask you about other details:
1) You use options like --process-exits and other used for routing, but your
style doesn't set any of the access attributes like mkgmap:car, mkgmap:foot etc
which are needed to get proper routing info in the map.
I guess you don't care
Version mkgmap-r3394 was committed by gerd on Wed, 07 Jan 2015
improve the message when there are too many POIS at the same place
- Mike Baggaley
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Mike,
on my PC the performance of your algo is quite good.
Attached is a patch that contains your patch as well as my quick implementation
of the algo described here:
http://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf
The patch tests only performance, it computes the center with the 3
gerd p
would love more on the routing mate in my map
but when i tried before to upgrade the script file , it did not work
may be i send the script file i use , so you can help me convert it over
to the new scripting you do mate
or provide me with plenty of examples and i can try gerd
stephen
Hi Steve,
I suggest to look at the rules in the default style and the style
manual:
http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf
I am not that familiar with style rules, and I prefer java coding.
Gerd
Date: Wed, 7 Jan 2015 17:15:59 +1000
From: steve.sgalow...@gmail.com
To:
Hi Mike,
I'll have a look at the patches. Reg. the admin stuff:
Please wait for a comment from Steve, it is his project and
I don't know his opinion about this. I just described the process
that I went through a few years ago.
Gerd
From: m...@tvage.co.uk
To: mkgmap-dev@lists.mkgmap.org.uk
I tried now switching the levels,
sea with prio 1 and land with prio 2,
but still the sea is not shown.
From: Walter Schlögl
Sent: Tuesday, January 06, 2015 10:50 PM
To: Development list for mkgmap
Subject: [mkgmap-dev] How to show land and see
In the past I did not use a background polygon on
Hi Walter,
I think Minkos style contains samples for that as well:
type=route route=bicycle network=ncn
{
apply {
set ncn_from_relation=yes;
set nname='${name}';
set nref='$(nref)/${ref}' | '${ref}';
}
}
Gerd
From:
Hi Gerd,
thanks for your help, it’s working.
Using mkgmap makes a lot of fun,
because it’s a perfect software
and because of this premium support.
I think it would be worth to add this also to the default style.
type=route route=road
{
apply
{
set network='${network}';
Ive tested the new europe extract from this night. And now it works.
Many thanks again to Hanspeter.
Regards,
Gert
Gesendet:Montag, 05. Januar 2015 um 12:23 Uhr
Von:thesurve...@wolke7.net
An:mkgmap-dev@lists.mkgmap.org.uk
Betreff:Re: [mkgmap-dev] Lake Geneva is dry - fixed
Thank you
The following command
highway=* network=e-road
works fine, if the tag network=e-road is directly attached to the road.
But in most cases it is attached via a relation,
and in these cases it is not evaluated.
In my relations file there are only rules for
type=boundary | type=multipolygon
28 matches
Mail list logo
