date:20150106

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: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

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 

On Wed, Jan 7, 2015 at 5:11 PM, Gerd Petermann 
 wrote:



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 about routing?

2) Your cmd file contains the option --pois-to-areas-placement=tagelist 
I think this is a very old typo which overrides a good default:
pois-to-areas-placement=entrance=main;entrance=yes;building=entrance

Please check the docu about the meaning:
http://www.mkgmap.org.uk/doc/options

Gerd

Date: Wed, 7 Jan 2015 16:57:41 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

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 
 wrote:



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 6, 2015 at 10:18 AM, GerdP  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 your style files so that I can reproduce the problem.

Maybe your style still adds one POI for each point of each highway?



Gerd





steve sgalowski wrote

> canada splitter log file

> as expected ,  looks like i was correct

> the size of the split has to be smaller

> stephen

>

> On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila <



> cdavilam@



> >

> wrote:

>

>> Final file size depends on the amount of data in the input, not on the

>> value of max-nodes. If you need a final img smaller than a given size you

>> have to reduce the area covered by the input file or reduce the number of

>> osm elements from the input that go into the map playing with your style

>> files.

>>

>> El 05/01/15 a las 22:07, Steve Sgalowski escribió:

>>

>>> gerd and carlos

>>> i am now running the splitter log file setup on my canada map

>>> and see what it does , the end result on this map = 6.8 gb img file

>>> wonder why some country can exceed and others not

>>> stephen

>>>

>>>

>>> On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila <



> cdavilam@



> >>  cdavilam@



> >> wrote:

>>>

>>> Not sure what you mean. If you split a given country in a higher

>>> number of tiles (lower max-nodes) final size will be the same or

>>> slightly bigger, as there are more duplicated info due to overlap.

>>> Or you are loosing some information in the process to reduce final

>>> file size.

>>>

>>> El 05/01/15 a las 21:34, Steve Sgalowski escribió:

>>>

>>> in some of the countries i do , if i dont make the node count

>>> small , the map size exceedds , size limit of 3 gb

>>> then unshure how , canada has done this ok

>>>

>>> stephen

>>>

>>>

>>> On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann

>>> <



> gpetermann_muenchen@



> >>  gpetermann_muenchen@



> >

>>>  gpetermann_muenchen@



> >>  gpetermann_muenchen@



> >>> wrote:

>>>

>>> Hi all,

>>>

>>> I wonder what splitter should do in this case:

>>>

>>> Stephen uses paramter --max-nodes=8

>>> and splitter reports

>>> "Highest node count in a single grid element is 557,084"

>>>

>>> It is obvious that at least one tile will have much more

>>> than the

>>> requested 80.000 nodes,

>>> on the other hand, the file africa.osm.pbf contains large

>>> nearly

>>> empty areas,

>>> and that makes it very difficult to find a good split.

>>> The current version r416 fails because it doesn't accept

>>> tiles

>>> with less than 5% of

>>> the max-nodes value, so it

Re: [mkgmap-dev] Problem in splitter (Africa)

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


On Wed, Jan 7, 2015 at 5:11 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> 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 about routing?
>
> 2) Your cmd file contains the option --pois-to-areas-placement=tagelist
> I think this is a very old typo which overrides a good default:
> pois-to-areas-placement=entrance=main;entrance=yes;building=entrance
>
> Please check the docu about the meaning:
> http://www.mkgmap.org.uk/doc/options
>
> Gerd
>
> --
> Date: Wed, 7 Jan 2015 16:57:41 +1000
> From: steve.sgalow...@gmail.com
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Problem in splitter (Africa)
>
> 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> wrote:
>
> 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 6, 2015 at 10:18 AM, GerdP 
> 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 your style files so that I can reproduce the
> problem.
> Maybe your style still adds one POI for each point of each highway?
>
> Gerd
>
>
> steve sgalowski wrote
> > canada splitter log file
> > as expected ,  looks like i was correct
> > the size of the split has to be smaller
> > stephen
> >
> > On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila <
>
> > cdavilam@
>
> > >
> > wrote:
> >
> >> Final file size depends on the amount of data in the input, not on the
> >> value of max-nodes. If you need a final img smaller than a given size
> you
> >> have to reduce the area covered by the input file or reduce the number
> of
> >> osm elements from the input that go into the map playing with your style
> >> files.
> >>
> >> El 05/01/15 a las 22:07, Steve Sgalowski escribió:
> >>
> >>> gerd and carlos
> >>> i am now running the splitter log file setup on my canada map
> >>> and see what it does , the end result on this map = 6.8 gb img file
> >>> wonder why some country can exceed and others not
> >>> stephen
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila <
>
> > cdavilam@
>
> > >> 
> > cdavilam@
>
> > >> wrote:
> >>>
> >>> Not sure what you mean. If you split a given country in a higher
> >>> number of tiles (lower max-nodes) final size will be the same or
> >>> slightly bigger, as there are more duplicated info due to overlap.
> >>> Or you are loosing some information in the process to reduce final
> >>> file size.
> >>>
> >>> El 05/01/15 a las 21:34, Steve Sgalowski escribió:
> >>>
> >>> in some of the countries i do , if i dont make the node count
> >>> small , the map size exceedds , size limit of 3 gb
> >>> then unshure how , canada has done this ok
> >>>
> >>> stephen
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
> >>> <
>
> > gpetermann_muenchen@
>
> > >> 
> > gpetermann_muenchen@
>
> > >
> >>> 
> > gpetermann_muenchen@
>
> > >> 
> > gpetermann_muenchen@
>
> > >>> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I wonder what splitter should do in this case:
> >>>
> >>> Stephen uses paramter --max-nodes=8
> >>> and splitter reports
> >>> "Highest node count in a single grid element is 557,084"
> >>>
> >>> It is obvious that at least one tile will have much more
> >>> than the
> >>> requested 80.000 nodes,
> >>> on the other hand, the file africa.osm.pbf contains large
> >>> nearly
> >>> empty areas,
> >>> and that makes it very difficult to find a good split.
> >>> The current version r416 fails because it doesn't accept
> >>> tiles
> >>> with less than 5% of
> >>> the max-nodes value, so it searches for a solution where
> >>> every
> >>>

Re: [mkgmap-dev] Problem in splitter (Africa)

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 about routing?

2) Your cmd file contains the option --pois-to-areas-placement=tagelist 
I think this is a very old typo which overrides a good default:
pois-to-areas-placement=entrance=main;entrance=yes;building=entrance

Please check the docu about the meaning:
http://www.mkgmap.org.uk/doc/options

Gerd

Date: Wed, 7 Jan 2015 16:57:41 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

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 
 wrote:



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 6, 2015 at 10:18 AM, GerdP  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 your style files so that I can reproduce the problem.

Maybe your style still adds one POI for each point of each highway?



Gerd





steve sgalowski wrote

> canada splitter log file

> as expected ,  looks like i was correct

> the size of the split has to be smaller

> stephen

>

> On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila <



> cdavilam@



> >

> wrote:

>

>> Final file size depends on the amount of data in the input, not on the

>> value of max-nodes. If you need a final img smaller than a given size you

>> have to reduce the area covered by the input file or reduce the number of

>> osm elements from the input that go into the map playing with your style

>> files.

>>

>> El 05/01/15 a las 22:07, Steve Sgalowski escribió:

>>

>>> gerd and carlos

>>> i am now running the splitter log file setup on my canada map

>>> and see what it does , the end result on this map = 6.8 gb img file

>>> wonder why some country can exceed and others not

>>> stephen

>>>

>>>

>>> On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila <



> cdavilam@



> >>  cdavilam@



> >> wrote:

>>>

>>> Not sure what you mean. If you split a given country in a higher

>>> number of tiles (lower max-nodes) final size will be the same or

>>> slightly bigger, as there are more duplicated info due to overlap.

>>> Or you are loosing some information in the process to reduce final

>>> file size.

>>>

>>> El 05/01/15 a las 21:34, Steve Sgalowski escribió:

>>>

>>> in some of the countries i do , if i dont make the node count

>>> small , the map size exceedds , size limit of 3 gb

>>> then unshure how , canada has done this ok

>>>

>>> stephen

>>>

>>>

>>> On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann

>>> <



> gpetermann_muenchen@



> >>  gpetermann_muenchen@



> >

>>>  gpetermann_muenchen@



> >>  gpetermann_muenchen@



> >>> wrote:

>>>

>>> Hi all,

>>>

>>> I wonder what splitter should do in this case:

>>>

>>> Stephen uses paramter --max-nodes=8

>>> and splitter reports

>>> "Highest node count in a single grid element is 557,084"

>>>

>>> It is obvious that at least one tile will have much more

>>> than the

>>> requested 80.000 nodes,

>>> on the other hand, the file africa.osm.pbf contains large

>>> nearly

>>> empty areas,

>>> and that makes it very difficult to find a good split.

>>> The current version r416 fails because it doesn't accept

>>> tiles

>>> with less than 5% of

>>> the max-nodes value, so it searches for a solution where

>>> every

>>> tile has at least 4000 nodes,

>>> and that might not exist.

>>>

>>> I see these options:

>>> 1) splitter can continue trying to split the data, accepting

>>> almost empty output files

>>> (e.g. some with < 5 nodes and very high aspect ratios like

>>> 32)

>>> 2) if that fails,  splitter can set the max-nodes value to

>>> 557,084

>>> and try again

>>> 3) or stop with an error message that tells the user that

>>> it is

>>> not possible

>>> to split with the used resolution

>>> 4) or restart using a higher r

Re: [mkgmap-dev] Problem in splitter (Africa)

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> wrote:

> 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 6, 2015 at 10:18 AM, GerdP 
> 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 your style files so that I can reproduce the
> problem.
> Maybe your style still adds one POI for each point of each highway?
>
> Gerd
>
>
> steve sgalowski wrote
> > canada splitter log file
> > as expected ,  looks like i was correct
> > the size of the split has to be smaller
> > stephen
> >
> > On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila <
>
> > cdavilam@
>
> > >
> > wrote:
> >
> >> Final file size depends on the amount of data in the input, not on the
> >> value of max-nodes. If you need a final img smaller than a given size
> you
> >> have to reduce the area covered by the input file or reduce the number
> of
> >> osm elements from the input that go into the map playing with your style
> >> files.
> >>
> >> El 05/01/15 a las 22:07, Steve Sgalowski escribió:
> >>
> >>> gerd and carlos
> >>> i am now running the splitter log file setup on my canada map
> >>> and see what it does , the end result on this map = 6.8 gb img file
> >>> wonder why some country can exceed and others not
> >>> stephen
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila <
>
> > cdavilam@
>
> > >> 
> > cdavilam@
>
> > >> wrote:
> >>>
> >>> Not sure what you mean. If you split a given country in a higher
> >>> number of tiles (lower max-nodes) final size will be the same or
> >>> slightly bigger, as there are more duplicated info due to overlap.
> >>> Or you are loosing some information in the process to reduce final
> >>> file size.
> >>>
> >>> El 05/01/15 a las 21:34, Steve Sgalowski escribió:
> >>>
> >>> in some of the countries i do , if i dont make the node count
> >>> small , the map size exceedds , size limit of 3 gb
> >>> then unshure how , canada has done this ok
> >>>
> >>> stephen
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
> >>> <
>
> > gpetermann_muenchen@
>
> > >> 
> > gpetermann_muenchen@
>
> > >
> >>> 
> > gpetermann_muenchen@
>
> > >> 
> > gpetermann_muenchen@
>
> > >>> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I wonder what splitter should do in this case:
> >>>
> >>> Stephen uses paramter --max-nodes=8
> >>> and splitter reports
> >>> "Highest node count in a single grid element is 557,084"
> >>>
> >>> It is obvious that at least one tile will have much more
> >>> than the
> >>> requested 80.000 nodes,
> >>> on the other hand, the file africa.osm.pbf contains large
> >>> nearly
> >>> empty areas,
> >>> and that makes it very difficult to find a good split.
> >>> The current version r416 fails because it doesn't accept
> >>> tiles
> >>> with less than 5% of
> >>> the max-nodes value, so it searches for a solution where
> >>> every
> >>> tile has at least 4000 nodes,
> >>> and that might not exist.
> >>>
> >>> I see these options:
> >>> 1) splitter can continue trying to split the data,
> accepting
> >>> almost empty output files
> >>> (e.g. some with < 5 nodes and very high aspect ratios like
> >>> 32)
> >>> 2) if that fails,  splitter can set the max-nodes value to
> >>> 557,084
> >>> and try again
> >>> 3) or stop with an error message that tells the user that
> >>> it is
> >>> not possible
> >>> to split with the used resolution
> >>> 4) or restart using a higher resolution  (15 would be
> >>> required
> >>> here instead of 13),
> >>>
> >>> @Stephen
> >>> What reason do you have to use such a small max-nodes
> value?
> >>> Would it be ok for you to use a higher one?
> >>>
> >>> Gerd
> >>>
> >>>
> >> ___
> >> mkgmap-dev mailing list
> >>
>
> > mkgmap-dev@.org
>
> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>
> >
> > ___
> > mkgmap-dev maili

Re: [mkgmap-dev] small issue with Way.getCofG()




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 different 
algos,
I've commented the part that prints times and GPX data for debug purposes.

I noticed that the results between both algos are very different, I did not
yet try to find out which one is better, but mine is much slower on my PC.
I also noticed that your algo doesn't always calculate a point in the polygon,
see e.g.   way 178708143.

If you like, please try to find a better compromise, I like to fix a problem in
splitter first.
I also did not yet look at the effect on the house number code, as there are 
many
more small open problems, but I think it should be easy to sort that out.

Gerd


> Date: Tue, 6 Jan 2015 13:23:57 -0700
> From: gpetermann_muenc...@hotmail.com
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] small issue with Way.getCofG()
> 
> 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 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 twice, once because of the POI, once
> > because the Generator uses Way.getCofG(). If both have different positions
> > this might have a negative impact.
> > 
> > Gerd
> > 
> > 
> > From: 
> 
> > mike@.co
> 
> > To: 
> 
> > mkgmap-dev@.org
> 
> > Date: Tue, 6 Jan 2015 14:56:30 +
> > Subject: Re: [mkgmap-dev] small issue with Way.getCofG()
> > 
> > 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 a small number of points and 15x15 for longer polygons. There is
> > however a performance penalty. My standard map takes about 1 hour 20
> > minutes; using this algorithm the time increases by about 50% to about 2
> > hours. I am not currently able to commit changes to SVN (perhaps someone
> > can
> > help out with that) but I have attached the code changes. I suggest that
> > due
> > to the performance penalty, if we adopt this, then the --add-pois-to-areas
> > option be extended to be --add-pois-to-areas[=centre|optimised] or
> > something
> > similar, with the default being centre and functioning as now and the
> > optimised option invoking the new code. Please try out the suggested
> > change.
> > Note I don't expect this to work properly where a polygon is formed from a
> > multiploygon relation, but the code could quite easily be adapted for this
> > circumstance.
> >  
> >  
> > Regards,
> > Mike
> > 
> > ___
> > mkgmap-dev mailing list
> 
> > mkgmap-dev@.org
> 
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >   
> > ___
> > mkgmap-dev mailing list
> 
> > mkgmap-dev@.org
> 
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5829247.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

  

pointInPolygon-v0.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r3394: improve the message when there are too many POIS at the same place

2015-01-06 Thread svn commit


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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] SVN commit problem

Hi Mike,

the content of the patch looks ok to me. In the future, please try to use a 
command like 
svn diff > /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 it with this simply command:
svn patch > /xyz.patch

It was also agreed that patch files should have unix style line endings
to avoid mixtures. Steve has implemented a hook in svn to check for 
the line endings and files containing dos style are refused.

Gerd

From: m...@tvage.co.uk
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Wed, 7 Jan 2015 00:58:16 +
Subject: Re: [mkgmap-dev] SVN commit problem

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 the change is only one line of code in each module, I suggest I skip
uploading a binary (I don't have one with only that change in it at
present).
 
Can I also suggest adding something to the developer web page indicating
that you have to be separately approved before you can upload code changes,
how to apply for approval and the procedure to follow before approval?
 
Cheers,
Mike
 
-Original Message-
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 does and wait for reports.
If we see positive feedback, you may want to 
post a 2nd version to make sure that comments are okay,
unit tests are passed, doc files contain the new feature etc. 
Finally one will commit your change.
If we get the feeling that you know what to do Steve will
probably give you write permits for trunk.
 
OK?
 
Gerd
 

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  

xyz.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] SVN commit problem

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
Date: Wed, 7 Jan 2015 00:58:16 +
Subject: Re: [mkgmap-dev] SVN commit problem

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 the change is only one line of code in each module, I suggest I skip
uploading a binary (I don't have one with only that change in it at
present).
 
Can I also suggest adding something to the developer web page indicating
that you have to be separately approved before you can upload code changes,
how to apply for approval and the procedure to follow before approval?
 
Cheers,
Mike
 
-Original Message-
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 does and wait for reports.
If we see positive feedback, you may want to 
post a 2nd version to make sure that comments are okay,
unit tests are passed, doc files contain the new feature etc. 
Finally one will commit your change.
If we get the feeling that you know what to do Steve will
probably give you write permits for trunk.
 
OK?
 
Gerd
 

___
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] How to show land and see

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 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 with a background, but 
all articles I found wer not helpful.
The land polygon is defined as 0x4b and it is the only polygon with draw-prio = 
1.
The sea polygon is defined as 0x32 and it has draw-prio = 2.
The last commands in polygons file are 
natural=sea[0x32 resolution 14]
natural=land   [0x4b resolution 14]
Splitter Option
--keep-complete=true
mkgmap Option
precomp-sea=sea_20141027.zip
generate-sea=multipolygon

Is there anything else I could check?

Walter



___
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] SVN commit problem

2015-01-06 Thread Mike Baggaley

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 the change is only one line of code in each module, I suggest I skip
uploading a binary (I don't have one with only that change in it at
present).

Can I also suggest adding something to the developer web page indicating
that you have to be separately approved before you can upload code changes,
how to apply for approval and the procedure to follow before approval?

Cheers,
Mike

-Original Message-
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 does and wait for reports.
If we see positive feedback, you may want to 
post a 2nd version to make sure that comments are okay,
unit tests are passed, doc files contain the new feature etc. 
Finally one will commit your change.
If we get the feeling that you know what to do Steve will
probably give you write permits for trunk.

OK?

Gerd

--- C:/Users/mike/AppData/Local/Temp/MdrBuilder.java-revBASE.svn007.tmp.java
Tue Mar  4 22:44:24 2014
+++ 
C:/Users/mike/Documents/CreateIMG/src/mkgmap/src/uk/me/parabola/mkgmap/combiners/MdrBuilder.java
Wed Jan  7 00:34:21 2015
@@ -272,8 +272,7 @@ public class MdrBuilder implements Combiner {
for (Point p : list) {
Label label = p.getLabel();
if (p.getNumber() > 256) {
-   // I think we limit the number of 
points+ind-points, but just in case
-   System.out.println("point number too big");
+   // error message already shown in 
MapBuilder.java, so no need to repeat it
continue;
}
 
--- C:/Users/mike/AppData/Local/Temp/MapBuilder.java-revBASE.svn00f.tmp.java
Sun Dec 21 14:31:16 2014
+++ 
C:/Users/mike/Documents/CreateIMG/src/mkgmap/src/uk/me/parabola/mkgmap/build/MapBuilder.java
Wed Jan  7 00:50:15 2015
@@ -948,7 +948,7 @@ public class MapBuilder implements Configurable {
if(!point.hasExtendedType()) {
if(name != null && div.getZoom().getLevel() == 
0) {
if(pointIndex > 255)
-   log.error("FIXME - too many 
POIs in group");
+   log.error("Too many POIs at 
location " + div.getCenter().toOSMURL() + " - " + name + " will be ignored");
else if(point.isExit()) {
Exit e = 
((MapExitPoint)point).getExit();
if(e != null)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] How to show land and see

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 with a background, but 
all articles I found wer not helpful.
The land polygon is defined as 0x4b and it is the only polygon with draw-prio = 
1.
The sea polygon is defined as 0x32 and it has draw-prio = 2.
The last commands in polygons file are 
natural=sea[0x32 resolution 14]
natural=land   [0x4b resolution 14]
Splitter Option
--keep-complete=true
mkgmap Option
precomp-sea=sea_20141027.zip
generate-sea=multipolygon

Is there anything else I could check?

Walter___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] small issue with Way.getCofG()

2015-01-06 Thread GerdP

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 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 twice, once because of the POI, once
> because the Generator uses Way.getCofG(). If both have different positions
> this might have a negative impact.
> 
> Gerd
> 
> 
> From: 

> mike@.co

> To: 

> mkgmap-dev@.org

> Date: Tue, 6 Jan 2015 14:56:30 +
> Subject: Re: [mkgmap-dev] small issue with Way.getCofG()
> 
> 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 a small number of points and 15x15 for longer polygons. There is
> however a performance penalty. My standard map takes about 1 hour 20
> minutes; using this algorithm the time increases by about 50% to about 2
> hours. I am not currently able to commit changes to SVN (perhaps someone
> can
> help out with that) but I have attached the code changes. I suggest that
> due
> to the performance penalty, if we adopt this, then the --add-pois-to-areas
> option be extended to be --add-pois-to-areas[=centre|optimised] or
> something
> similar, with the default being centre and functioning as now and the
> optimised option invoking the new code. Please try out the suggested
> change.
> Note I don't expect this to work properly where a polygon is formed from a
> multiploygon relation, but the code could quite easily be adapted for this
> circumstance.
>  
>  
> Regards,
> Mike
> 
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev  
>   
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5829247.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How to evaluate network=e-road if it's in a relation

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}';
set ref='${ref}';
} 
}

Also for route=ski I added a copy of piste:type even if ref and name is missing.
But piste seems to be not used in default style.

Walter

From: Gerd Petermann 
Sent: Tuesday, January 06, 2015 5:45 PM
To: mkgmap-dev@lists.mkgmap.org.uk 
Subject: Re: [mkgmap-dev] How to evaluate network=e-road if it's in a relation

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: walter.schloegl-re...@aon.at
> To: mkgmap-dev@lists.mkgmap.org.uk
> Date: Tue, 6 Jan 2015 17:33:39 +0100
> Subject: [mkgmap-dev] How to evaluate network=e-road if it's in a relation
> 
> 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
> type=route & (route=bus | route=trolleybus | route=ferry | route=subway | 
> route=train | route=tram)
> type=route & (route=ski)
> 
> I am not very familier with the relations commands.
> Is there a way to refer to network=e-road via the relations file?
> 
> Walter 
> 
> ___
> 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___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How to evaluate network=e-road if it's in a relation

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: walter.schloegl-re...@aon.at
> To: mkgmap-dev@lists.mkgmap.org.uk
> Date: Tue, 6 Jan 2015 17:33:39 +0100
> Subject: [mkgmap-dev] How to evaluate network=e-road if it's in a relation
> 
> 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
> type=route & (route=bus | route=trolleybus | route=ferry | route=subway | 
> route=train | route=tram)
> type=route & (route=ski)
> 
> I am not very familier with the relations commands.
> Is there a way to refer to network=e-road via the relations file?
> 
> Walter 
> 
> ___
> 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

[mkgmap-dev] How to evaluate network=e-road if it's in a relation


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
type=route & (route=bus | route=trolleybus | route=ferry | route=subway | 
route=train | route=tram)

type=route & (route=ski)

I am not very familier with the relations commands.
Is there a way to refer to network=e-road via the relations file?

Walter 


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Lake Geneva is dry - fixed

2015-01-06 Thread thesurveyor

I've 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 very much, Hanspeter

I'll download the new file next night and rebuild my map. I'll keep you informed about the result.

One more question about that: how did you find the corrupt multipolygon?

I'm currently not able to find such things, but perhaps if I get some hints how to do that, I can learn it :-)

Regards,

Gert

Gesendet: Montag, 05. Januar 2015 um 03:03 Uhr
Von: "Hanspeter Gysin (bluewin)"
An: "'Development list for mkgmap'"
Betreff: [mkgmap-dev] Lake Geneva is dry - fixed

fixed a corrupt multipolygon section at Château de Glérolles (west of Saint-Saphorin).

unfortunately the tile in question is too large for download by overpass api

and the verification is not possible before 6th of january when europe-latest.osm.pfb at geofabrik is updated.

Hanspeter

___ 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] small issue with Way.getCofG()

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 twice, once because of the POI, once
because the Generator uses Way.getCofG(). If both have different positions
this might have a negative impact.

Gerd


From: m...@tvage.co.uk
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Tue, 6 Jan 2015 14:56:30 +
Subject: Re: [mkgmap-dev] small issue with Way.getCofG()

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 a small number of points and 15x15 for longer polygons. There is
however a performance penalty. My standard map takes about 1 hour 20
minutes; using this algorithm the time increases by about 50% to about 2
hours. I am not currently able to commit changes to SVN (perhaps someone can
help out with that) but I have attached the code changes. I suggest that due
to the performance penalty, if we adopt this, then the --add-pois-to-areas
option be extended to be --add-pois-to-areas[=centre|optimised] or something
similar, with the default being centre and functioning as now and the
optimised option invoking the new code. Please try out the suggested change.
Note I don't expect this to work properly where a polygon is formed from a
multiploygon relation, but the code could quite easily be adapted for this
circumstance.
 
 
Regards,
Mike

___
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] SVN commit problem

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 does and wait for reports.
If we see positive feedback, you may want to 
post a 2nd version to make sure that comments are okay,
unit tests are passed, doc files contain the new feature etc. 
Finally one will commit your change.
If we get the feeling that you know what to do Steve will
probably give you write permits for trunk.

OK?

Gerd


> From: m...@tvage.co.uk
> To: mkgmap-dev@lists.mkgmap.org.uk
> Date: Tue, 6 Jan 2015 15:00:07 +
> Subject: [mkgmap-dev] SVN commit problem
> 
> 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:
> 
> [groups]
> group1 = *.mkgmap.org.uk
> 
>  [group1]
> # store-plaintext-passwords = no
> username = mike.b
> 
> Can anyone help?
> 
> Regards,
> Mike
> 
> 
> ___
> 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

[mkgmap-dev] SVN commit problem

2015-01-06 Thread Mike Baggaley

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:

[groups]
group1 = *.mkgmap.org.uk

 [group1]
# store-plaintext-passwords = no
username = mike.b

Can anyone help?

Regards,
Mike


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] small issue with Way.getCofG()

2015-01-06 Thread Mike Baggaley

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 a small number of points and 15x15 for longer polygons. There is
however a performance penalty. My standard map takes about 1 hour 20
minutes; using this algorithm the time increases by about 50% to about 2
hours. I am not currently able to commit changes to SVN (perhaps someone can
help out with that) but I have attached the code changes. I suggest that due
to the performance penalty, if we adopt this, then the --add-pois-to-areas
option be extended to be --add-pois-to-areas[=centre|optimised] or something
similar, with the default being centre and functioning as now and the
optimised option invoking the new code. Please try out the suggested change.
Note I don't expect this to work properly where a polygon is formed from a
multiploygon relation, but the code could quite easily be adapted for this
circumstance.


Regards,
Mike
Additions to Way.java:

import java.awt.image.BufferedImage;

/*
 * Find a point that is farthest from the edge of the shape
 * by drawing the shape onto a small monochrome bitmap and
 * then finding the point that is farthest from a black pixel.
 * The shape is scaled differently in X and Y to fit a square bitmap.
 * The size of the bitmap depends on the number of points in the shape.
 */
public Coord getPointWithinArea() {
// if shape is not closed or must be convex, use getCofG
if ((points.size() < 5) || !isClosed())
return getCofG();

// first get the coordinates of the rectangle containing the way
int minLat = Integer.MAX_VALUE;
int minLon = Integer.MAX_VALUE;
int maxLat = Integer.MIN_VALUE;
int maxLon = Integer.MIN_VALUE;
for(Coord p : points) {
int lat = p.getHighPrecLat();
int lon = p.getHighPrecLon();
minLat = Math.min(minLat, lat);
minLon = Math.min(minLon, lon);
maxLat = Math.max(maxLat, lat);
maxLon = Math.max(maxLon, lon);
}
if ((maxLon == minLon) || (maxLat == minLat))
return Coord.makeHighPrecCoord((maxLat + minLat) / 2, 
(maxLon + minLon) / 2);

// choose a bitmap resolution based on the number of points
int bitmapSize = points.size() < 10 ? 9 : 15;
int halfBitmapSize = bitmapSize / 2;
int halfBitmapSize2 = bitmapSize - halfBitmapSize;
// create a polygon scaled to fit the resolution
double xScale = (double)(bitmapSize - 1) / (double)(maxLon - 
minLon);
double yScale = (double)(bitmapSize - 1) / (double)(maxLat - 
minLat);
Polygon polygon = new Polygon();
for(Coord p : points)
polygon.addPoint((int)((p.getHighPrecLon() - minLon) * 
xScale), (int)((p.getHighPrecLat() - minLat) * yScale));
// draw the polygon as a white shape on a black background
BufferedImage image = new BufferedImage (bitmapSize, 
bitmapSize, BufferedImage.TYPE_BYTE_BINARY);
Graphics2D graphics = image.createGraphics();
graphics.setColor(Color.black);
graphics.fillRect(0, 0, bitmapSize, bitmapSize);
graphics.setColor(Color.white);
graphics.fillPolygon(polygon);
// set the default coordinate to the middle of the bitmap
int bestX = halfBitmapSize;
int bestY = halfBitmapSize;
// examine each point in the bitmap, to see whether it is 
farthest from a black pixel
// start at the centre point and move outwards in concentric 
squares
// we can stop looking when we are closer to the edge than the 
biggest distance
int biggestSquaredDistanceToBlack = 
getSquaredDistanceToBlack(image, bestX, bestY);
for (int start = 1; (start <= halfBitmapSize) && 
(biggestSquaredDistanceToBlack < (halfBitmapSize2 - start) * (halfBitmapSize2 - 
start)); start++) {
for (int i = 0; i <= start; i++) {
int x = halfBitmapSize + i;
int y = halfBitmapSize + start;
int squaredDistanceToBlack = 
getSquaredDistanceToBlack(image, x, y);
if (biggestSquaredDistanceToBlack < 
squaredDistanceToBlack) {
biggestSquaredDistanceToBlack =

Re: [mkgmap-dev] How to use extended line types


Thanks a lot for your help, now it's working fine.

Gerd, your tip with this website is very helpful, I will have to read and 
learn a lot from this description.


Andrzej, you got the point. When I switched from 0x1901 to 0x10001 it 
worked.


I think it would be a good idea to document this somewhere (maybe in 
style-manual.pdf)


Walter

-Ursprüngliche Nachricht- 
From: Andrzej Popowski

Sent: Tuesday, January 06, 2015 2:59 PM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] How to use extended line types

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.

--
Best regards,
Andrzej
___
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] How to use extended line types

2015-01-06 Thread Andrzej Popowski


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.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] small issue with Way.getCofG()

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, but I think the improvement
is too small for now.

Gerd

> Date: Sun, 4 Jan 2015 22:08:51 +0100
> From: wmgc...@web.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] small issue with Way.getCofG()
> 
> Hi Gerd,
> 
> yep, good catch. Seems to be a good solution for mkgmap!
> 
> WanMil
> 
> > Hi WanMil,
> >
> > I think the problem is similar to finding the "largest circle in a concave
> > polygon",
> > and we are not interested in the exact solution, any point close enough to
> > the center is
> > good. See e.g.
> > http://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf
> > which contains an iterative algo.
> >
> > Gerd
> >
> >
> > WanMil wrote
> >> Hi Gerd,
> >>
> >> a good algorithm to find a point for the --add-pois-to-areas option
> >> would be to use the straight skeleton algorithm
> >> (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012394.html). This
> >> might be used to find a point with maximum distance to the border of a
> >> polygon. Anyhow it seems to be a complex algorithm so maybe not the
> >> ideal solution for mkgmap.
> >>
> >> WanMil
> >>
> >>> Hi Steve,
> >>>
> >>> Steve Ratcliffe wrote
>  On 03/01/15 08:15, Gerd Petermann wrote:
> > @Steve:
> > The routine was initially created for the --check-roundabouts option.
> >
> > Later it was also used for --add-pois-to-areas and the --housenumbers
> > option.
> > I got the impression that it might be better to calculate the center
> > of the way bbox for those two, I am not so sure about the roundabout
> > code.
> > What do you think?
> 
>  Seems like the current method would tend to place the point near the
>  most complex part of the boundary.  This may not be bad, I would have
>  to see lots of real examples to be sure.
> >>>
> >>> Yes, correct. I compared these three algos:
> >>> 1) the existing
> >>> 2) my patched one
> >>> 3) center of bbox
> >>> For complex shapes (many points), 1) and 2) produce almost equal
> >>> results, and in fact the point was more often within the shape.
> >>> For simple polygons like small parks, buildings, etc. 1) is worst,
> >>> 2) is better and 3) is best.
> >>>
> >>> My conclusion: the patch is a simple and good improvement,
> >>> for housenumber location calculation maybe it would be better to use
> >>> algo 3).
> >>>
> >>>
> >>> Steve Ratcliffe wrote
>  Anyway there are no easy (or even any difficult!) methods that work in
>  all cases, so I would just keep it as it is and perhaps should the
>  calculated point be outside the box, move it to the closest point
>  inside.
> >>>
> >>> I already looked at the link provided by Andrzej.
> >>> If I got that right, we have two different problems regarding
> >>> the generated POI:
> >>> We calculate it once for the whole polygon, before clipping
> >>> it to the bbox of the tile, and it might be outside of the polygon
> >>> as well as outside of the bbox.
> >>>
> >>> This brought me back to the non-rectangular tile problem and I stop
> >>> searching for a solution for the POI problem.
> >>>
> >>> Reg. non-rectangular tiles: I fear we can't use any of the existing
> >>> algos in mkgmap to implement this, I'll report details in a different
> >>> post.
> >>>
> >>> Gerd
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>> http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5828952.html
> >>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> >>> ___
> >>> mkgmap-dev mailing list
> >>>
> >
> >> mkgmap-dev@.org
> >
> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>>
> >>
> >> ___
> >> mkgmap-dev mailing list
> >
> >> mkgmap-dev@.org
> >
> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> >
> >
> >
> >
> > --
> > View this message in context: 
> > http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5828986.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > ___
> > 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
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How to use extended line types

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: walter.schloegl-re...@aon.at
> To: mkgmap-dev@lists.mkgmap.org.uk
> Date: Tue, 6 Jan 2015 13:56:25 +0100
> Subject: [mkgmap-dev] How to use extended line types
> 
> 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 are supported, but I could not find any 
> further description in this document.
> 
> In the wiki 
> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Polyline_Types
> I found this information:
> 
> For use in mkgmap styles the type and subtype of a polyline are simply 
> concatenated: type 0x12 and subtype 0x34 become 0x1234.
> As the marine types are marked in mkgmap notation by adding 0x1 to them, 
> so the type 0x12 and subtype 0x34 become 0x11234 as a marine type.
> 
> I have tried with linetype 0x1901, but I could not address it neither as 
> 0x1901 nor as 0x11901.
> Does anybody have an example, how extended line types above 0x00-0x3f can be 
> used?
> 
> Walter 
> 
> ___
> 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

[mkgmap-dev] How to use extended line types

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 are supported, but I could not find any 
further description in this document.


In the wiki 
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Polyline_Types

I found this information:

For use in mkgmap styles the type and subtype of a polyline are simply 
concatenated: type 0x12 and subtype 0x34 become 0x1234.
As the marine types are marked in mkgmap notation by adding 0x1 to them, 
so the type 0x12 and subtype 0x34 become 0x11234 as a marine type.


I have tried with linetype 0x1901, but I could not address it neither as 
0x1901 nor as 0x11901.
Does anybody have an example, how extended line types above 0x00-0x3f can be 
used?


Walter 


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r3393: improve error message when a sub option like floodblocker is

2015-01-06 Thread svn commit


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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

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: 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 6, 2015 at 10:18 AM, GerdP 
> 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 your style files so that I can reproduce the
> problem.
> Maybe your style still adds one POI for each point of each highway?
>
> Gerd
>
>
> steve sgalowski wrote
> > canada splitter log file
> > as expected ,  looks like i was correct
> > the size of the split has to be smaller
> > stephen
> >
> > On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila <
>
> > cdavilam@
>
> > >
> > wrote:
> >
> >> Final file size depends on the amount of data in the input, not on the
> >> value of max-nodes. If you need a final img smaller than a given size
> you
> >> have to reduce the area covered by the input file or reduce the number
> of
> >> osm elements from the input that go into the map playing with your style
> >> files.
> >>
> >> El 05/01/15 a las 22:07, Steve Sgalowski escribió:
> >>
> >>> gerd and carlos
> >>> i am now running the splitter log file setup on my canada map
> >>> and see what it does , the end result on this map = 6.8 gb img file
> >>> wonder why some country can exceed and others not
> >>> stephen
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila <
>
> > cdavilam@
>
> > >> 
> > cdavilam@
>
> > >> wrote:
> >>>
> >>> Not sure what you mean. If you split a given country in a higher
> >>> number of tiles (lower max-nodes) final size will be the same or
> >>> slightly bigger, as there are more duplicated info due to overlap.
> >>> Or you are loosing some information in the process to reduce final
> >>> file size.
> >>>
> >>> El 05/01/15 a las 21:34, Steve Sgalowski escribió:
> >>>
> >>> in some of the countries i do , if i dont make the node count
> >>> small , the map size exceedds , size limit of 3 gb
> >>> then unshure how , canada has done this ok
> >>>
> >>> stephen
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
> >>> <
>
> > gpetermann_muenchen@
>
> > >> 
> > gpetermann_muenchen@
>
> > >
> >>> 
> > gpetermann_muenchen@
>
> > >> 
> > gpetermann_muenchen@
>
> > >>> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I wonder what splitter should do in this case:
> >>>
> >>> Stephen uses paramter --max-nodes=8
> >>> and splitter reports
> >>> "Highest node count in a single grid element is 557,084"
> >>>
> >>> It is obvious that at least one tile will have much more
> >>> than the
> >>> requested 80.000 nodes,
> >>> on the other hand, the file africa.osm.pbf contains large
> >>> nearly
> >>> empty areas,
> >>> and that makes it very difficult to find a good split.
> >>> The current version r416 fails because it doesn't accept
> >>> tiles
> >>> with less than 5% of
> >>> the max-nodes value, so it searches for a solution where
> >>> every
> >>> tile has at least 4000 nodes,
> >>> and that might not exist.
> >>>
> >>> I see these options:
> >>> 1) splitter can continue trying to split the data,
> accepting
> >>> almost empty output files
> >>> (e.g. some with < 5 nodes and very high aspect ratios like
> >>> 32)
> >>> 2) if that fails,  splitter can set the max-nodes value to
> >>> 557,084
> >>> and try again
> >>> 3) or stop with an error message that tells the user that
> >>> it is
> >>> not possible
> >>> to split with the used resolution
> >>> 4) or restart using a higher resolution  (15 would be
> >>> required
> >>> here instead of 13),
> >>>
> >>> @Stephen
> >>> What reason do you have to use such a small max-nodes
> value?
> >>> Would it be ok for you to use a higher one?
> >>>
> >>> Gerd
> >>>
> >>>
> >> ___
> >> mkgmap-dev mailing list
> >>
>
> > mkgmap-dev@.org
>
> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>
> >
> > ___
> > mkgmap-dev mailing list
>
> > mkgmap-dev@.org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > splitter.log (356K)
> >

Re: [mkgmap-dev] Problem in splitter (Africa)

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 6, 2015 at 10:18 AM, GerdP  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 your style files so that I can reproduce the problem.

Maybe your style still adds one POI for each point of each highway?



Gerd





steve sgalowski wrote

> canada splitter log file

> as expected ,  looks like i was correct

> the size of the split has to be smaller

> stephen

>

> On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila <



> cdavilam@



> >

> wrote:

>

>> Final file size depends on the amount of data in the input, not on the

>> value of max-nodes. If you need a final img smaller than a given size you

>> have to reduce the area covered by the input file or reduce the number of

>> osm elements from the input that go into the map playing with your style

>> files.

>>

>> El 05/01/15 a las 22:07, Steve Sgalowski escribió:

>>

>>> gerd and carlos

>>> i am now running the splitter log file setup on my canada map

>>> and see what it does , the end result on this map = 6.8 gb img file

>>> wonder why some country can exceed and others not

>>> stephen

>>>

>>>

>>> On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila <



> cdavilam@



> >>  cdavilam@



> >> wrote:

>>>

>>> Not sure what you mean. If you split a given country in a higher

>>> number of tiles (lower max-nodes) final size will be the same or

>>> slightly bigger, as there are more duplicated info due to overlap.

>>> Or you are loosing some information in the process to reduce final

>>> file size.

>>>

>>> El 05/01/15 a las 21:34, Steve Sgalowski escribió:

>>>

>>> in some of the countries i do , if i dont make the node count

>>> small , the map size exceedds , size limit of 3 gb

>>> then unshure how , canada has done this ok

>>>

>>> stephen

>>>

>>>

>>> On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann

>>> <



> gpetermann_muenchen@



> >>  gpetermann_muenchen@



> >

>>>  gpetermann_muenchen@



> >>  gpetermann_muenchen@



> >>> wrote:

>>>

>>> Hi all,

>>>

>>> I wonder what splitter should do in this case:

>>>

>>> Stephen uses paramter --max-nodes=8

>>> and splitter reports

>>> "Highest node count in a single grid element is 557,084"

>>>

>>> It is obvious that at least one tile will have much more

>>> than the

>>> requested 80.000 nodes,

>>> on the other hand, the file africa.osm.pbf contains large

>>> nearly

>>> empty areas,

>>> and that makes it very difficult to find a good split.

>>> The current version r416 fails because it doesn't accept

>>> tiles

>>> with less than 5% of

>>> the max-nodes value, so it searches for a solution where

>>> every

>>> tile has at least 4000 nodes,

>>> and that might not exist.

>>>

>>> I see these options:

>>> 1) splitter can continue trying to split the data, accepting

>>> almost empty output files

>>> (e.g. some with < 5 nodes and very high aspect ratios like

>>> 32)

>>> 2) if that fails,  splitter can set the max-nodes value to

>>> 557,084

>>> and try again

>>> 3) or stop with an error message that tells the user that

>>> it is

>>> not possible

>>> to split with the used resolution

>>> 4) or restart using a higher resolution  (15 would be

>>> required

>>> here instead of 13),

>>>

>>> @Stephen

>>> What reason do you have to use such a small max-nodes value?

>>> Would it be ok for you to use a higher one?

>>>

>>> Gerd

>>>

>>>

>> ___

>> mkgmap-dev mailing list

>>



> mkgmap-dev@.org



>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

>>

>

> ___

> mkgmap-dev mailing list



> mkgmap-dev@.org



> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

>

> splitter.log (356K)

> 











--

View this message in context: 
http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html

Sent from the Mkgmap Development mailing list archive at Nabble.com.

___

mkgmap-dev mailing list

mkgmap-dev@lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailm

Re: [mkgmap-dev] Problem in splitter (Africa)