Re: [mkgmap-dev] How to show land and see
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. I have the opposite, sea prio 1 and land 2, maybe that helps? You could also try another polygon for land, 0x27 or an extended one like 0x10100 ___ 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 Gerd, the method I've used won't work if the polygon is thinner than the resolution of the bitmap. I hadn't considered that it might be used on rivers; my main testing has been on car parks, which although they may be irregularly shaped are not normally very long and very thin (I handle river names from the underlying lines). There are two possible problems that could occur - if a polygon is thin enough that it renders in the bitmap as a line that is nowhere wider than 2 pixels the POI could be placed just outside the polygon. I haven't checked what fillPolygon does if the points have no volume and form a line. If this renders nothing, then the algo will just return the centre point, which could be nowhere near the polygon. A simple solution to the first problem would be to examine the biggestSquaredDistanceToBlack figure before returning the coordinate and if the value is 1, repeat the operation on a small area around the point to get a better accuracy. I'll look into that. For the second problem I'll add an error message, so we can determine if it actually occurs (biggestSquaredDistanceToBlack is 0). I've also thought that having drawn the bitmap, it might be more efficient to then copy its contents out into an array so that finding the distances from pixels inside the polygon to those outside become simple array lookups instead of graphics function calls. I'll look into that as well. Cheers, Mike From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 07 January 2015 06:55 To: mkgmap-dev@lists.mkgmap.org.uk Subject: 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 mailto:gpetermann_muenc...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk mailto: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 mailto:mike@.co To: mkgmap-dev@.org mailto: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
Re: [mkgmap-dev] How to show land and see
Hi Walter, The last commands in polygons file are natural=sea[0x32 resolution 14] natural=land [0x4b resolution 14] Don't use object 0x4b in style, mkgmap should create it automatically. Use lowest priority for 0x4b in style or define only color without giving a priority to polygon 0x4b. -- 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] How to show land and see
Hi Andrzej,
I have corrected the errors in my TYP and style,
but the sea is still not visible.
Here are my last parameters.
polygons file
natural=sea { echo mapping natural=sea }[0x32
resolution 14]# level 1
natural=land [0x1 resolution 14]
# level 2
The echo command is shown in logfile, so natural=sea is available.
In TYP file I have deleted Polygon 4b (was used as background)
and added Polygon 100/00 with Prio 2.
0x32 (Sea) is the only Polygon with Prio 1.
Did you suggest these changes or did I understand you in a wrong way?
Best regards,
Walter
-Ursprüngliche Nachricht-
From: Andrzej Popowski
Sent: Wednesday, January 07, 2015 10:33 AM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] How to show land and see
Hi Walter,
The last commands in polygons file are
natural=sea[0x32 resolution 14]
natural=land [0x4b resolution 14]
Don't use object 0x4b in style, mkgmap should create it automatically.
Use lowest priority for 0x4b in style or define only color without
giving a priority to polygon 0x4b.
--
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 show land and see
Hi Walter, some clarifications: object 0x4b is a special kind of polygon, it is used as a map background and covers whole map area. You should not use it in style, because it is created by mkgmap (except for transparent maps). You can use polygon 0x4b in TYP to change background color of a map. Priorities that you set for polygons in TYP actually are draw orders. Polygon with draw order 1 is drawn before polygon with draw order 2. If polygons overlap, then polygon with higher draw order will be visible. I can't guess why you have problems with sea. I suggest that you revert to the solution, which worked for you and then only add polygon 0x4b to TYP file, without draw order or with lowest draw order. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] prob in africa map 3
here is the log file info said bb box is to big any ideas gerd and steve stephen splitter.log 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] Problem in splitter (Africa)
Hi all, I've committed r417 to fix a few rare problems in splitter: 1) The initial problem reported by Stephen: splitter printed Warning: No solution found for partition ... but did not stop when at least one partition was ok. 2) It tries a bit harder to find a solution when it turns out that no good solution is found. 3) It prints a warning when the user choses a rather bad combination of --max-nodes and --resolution. I've also removed the code that optimized parts of a solution, it did not really work in most cases. I'll try to find a solution for that again later. Gerd GerdP wrote 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.sgalowski@ To: mkgmap-dev@.org 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 lt; gpetermann_muenchen@ gt; 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.sgalowski@ To: mkgmap-dev@.org 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 lt; gpetermann_muenchen@ gt; wrote: Hi Stephen, yes, you should have received an answer a now. Gerd Date: Tue, 6 Jan 2015 19:15:51 +1000 From: steve.sgalowski@ To: mkgmap-dev@.org 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 lt; gpetermann_muenchen@ gt; 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@ mailto: 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@ mailto: gpetermann_muenchen@ mailto: gpetermann_muenchen@ mailto: gpetermann_muenchen@ wrote: Hi all,
[mkgmap-dev] PT rules in relations file
Hi
i'm playing around with the PT rules in relations, as example this node [1].
The node belongs to two route relations (RE8 and RB27) and one track relation
(2324)
When i enable the rules in relations i got the labels
Unkel (Re8,re8,rb27,rb27)
my wanted result is to get only one entry per relations, btw apply_once didn't
help
this is my code
# Public transportation routes.
type=route
(route=bus|
route=trolleybus|
route=ferry|
route=subway|
route=train|
route=tram)
(ref=* |
name=*)
{
add ref='${name}';
apply {
set route_ref='$(route_ref),${ref}' | '${ref}';
set mkgmap:relref='${ref}';
apply role=passengers {
set route_ref='$(route_ref),${mkgmap:relref}' | '${mkgmap:relref}';
}
delete mkgmap:relref;
}
}
How can get this result? And where is my error?
Bernd
[1] http://www.openstreetmap.org/way/58522211
___
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
Hi Andrzej, your suggestion to revert back to the last working version brought me directly to the solution. I had 2 maps in the same directory with the same TYP. All changes I made to the TYP of one map where ignored. The device just took the info from the TYP of the other map. The second error I made: When I deleted the prio of the default background 4b, TypViewer automatically gave it the lowest prio again. Now my sea is back, I'm having a custom background via Polygon 0x1 and one command in Style, natural=land [0x1 resolution 14] I could not bring it to work with the default Background Polygon 4b, but I don't care about that. It's working and I'm happy. Thanks a lot for your support. Best regards, Walter PS: Now also the overview map is working correct and visible. I am wondering, where mkgmap takes the info about the whole world. -Ursprüngliche Nachricht- From: Andrzej Popowski Sent: Wednesday, January 07, 2015 1:02 PM To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] How to show land and see Hi Walter, some clarifications: object 0x4b is a special kind of polygon, it is used as a map background and covers whole map area. You should not use it in style, because it is created by mkgmap (except for transparent maps). You can use polygon 0x4b in TYP to change background color of a map. Priorities that you set for polygons in TYP actually are draw orders. Polygon with draw order 1 is drawn before polygon with draw order 2. If polygons overlap, then polygon with higher draw order will be visible. I can't guess why you have problems with sea. I suggest that you revert to the solution, which worked for you and then only add polygon 0x4b to TYP file, without draw order or with lowest draw order. -- 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] PT rules in relations file
Am Mittwoch, 7. Januar 2015, 18:11:29 schrieb Bernd Weigelt: And where is my error? Found one of my errors, because the node belongs to four route relations. http://www.openstreetmap.org/node/31172863 ok, thats the reason for the double entries, but how can i filter them? Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
