January 2015 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] small issue with Way.getCofG()
by Mike Baggaley 09 Jan '15

09 Jan '15

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

4 9

SVN commit problem
by Mike Baggaley 08 Jan '15

08 Jan '15

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

3 2

How to display U. S. highway shields with numbers only
by Mark Bradley 08 Jan '15

08 Jan '15

Gerd, Thanks for the followup. Somehow I overlooked the Substitution filter that you suggest, which seems like a good idea. It looks like your idea also involves an Oracle Regex expression, with which I am not familiar. I thought about that, but the URL in the Conversion Style Manual for the Regex documentation is no longer correct. (Can someone on this mailing list see that it is corrected?) After a little searching on the Java website, I did not find the documentation, and did not want to take a lot of time looking, so I tried a different tack. After much thought, I came up with a series of commands that seems to produce the desired output. However, it looks like the idea of using the Substitution filter might produce a more elegant solution. I will probably look into that. Anyway, here is the sequence of commands I came up with that seemed to work. (I live in Indiana.) I have only included the commands that pertain to U. S. and state highways. The motorways (interstates) were more straightforward and a lot easier, because their ref values are much more consistent. The problem I had to overcome with the other highways is that the number of characters in the ref key value can vary, from none, to one or more. # Append extra characters to the end of the ref value to ensure it is more than one character in length, otherwise an error will be returned by the Substring filter later. # ("AB" are dummy characters.) highway = * & ref = * { set ref = '$(ref) AB' } # Create the letter_ref key that will determine later what type of symbol to display on the highway. highway = * & ref = * { set letter_ref = '$(ref|substring:0:2)' } # Extract the numbers only from the ref value, which will become the numbers inside the symbols. highway = * & ref = * { set number_ref = '$(ref|part:" :-2)' } #If the highway is a U. S. highway, use a shield symbol. letter_ref = 'US' {name '${number_ref|highway-symbol:shield:3} ${name}' | '${number_ref|highway-symbol:shield:3}' | '${name}'; addlabel '${name} (${ref})' } # If the highway is a state highway, use a round symbol. letter_ref = 'SR' | letter_ref = 'IN' {name '${number_ref|highway-symbol:round:3} ${name}' | '${number_ref|highway-symbol:round:3}' | '${name}'; addlabel '${name} (${ref})' } _____________________________________________ Hi Mark, okay, so your problem is not directly related to the highway symbols. What you need is a simple filter to return the part of a string which starts at the first digit. I guess this can be done with subst plus a regular expression, but I'm not sure how exactly. Something like ref=* {set my_ref = ${ref|subst:"[a-zA-Z]*~>"} Gerd

3 3

Issues with --housenumbers
by Gerd Petermann 08 Jan '15

08 Jan '15

Hi all, during the last weeks I tried to improve the --housenumber option. First of all: In most cases the existing code works quite well, but in many special cases it fails. I did not yet find a good solution, so I start to describe the problems with the existing code. 1) No support for random house numbers. In some areas there is no obvious order in house numbers. Nevertheless the current code in mkgmap always produces house number data that assumes that the numbers are either in ascending or descending order. We would need new data structures to support this, or at least ignore random housenumbers. The effect of the current code is that MapSource shows multiple possible places when you enter a road and a housenumber, and maybe none of the places is correct. 2) No plausibility check is done. The current code assigns a house (number element) to the closest road segment. It orders the houses by sorting these closest points. a) This doesn't work very well when multiple houses lie at the end of a road. As an effect, a house with number 12 maybe assigned to the left side of a road containing only odd numbers (or vice versa), or b) It also often fails when multiple houses are connected to the road with an unnamed service road. In many areas you have a group with odd numbers 1-9 followed by another group with numbers 11-17. Depending on the position of the houses, the calculated order might be 5,7,9,1,17,15,13,11 which results in an interval 5..11 instead of 1..17. The result also depends on whether the service road is in the map or not . c) In some areas, different road objects are created with the same road name, e.g. when a p-shaped road is split or the road forms some kind of grid like this a # sign. In such an area it is likely that some houses are assigned to the wrong (part of a )road. d) In some cases we might be able to detect wrong OSM data as such and print a corresponding message. Both points 1) and 2) are correlated. Without a plausibilty check we cannot detect the random house number case, so I think it is an interesting problem of pattern recognition. The human brain is very good with that, but it is difficult to find a quick and good algo for it. Gerd

4 4

prob in africa map 3
by Steve Sgalowski 08 Jan '15

08 Jan '15

here is the log file info said bb box is to big any ideas gerd and steve stephen

2 2

License of OsmosisRuntimeException.java copy in splitter source is outdated
by Sebastiaan Couwenberg 08 Jan '15

08 Jan '15

Hi all, While working on the Debian package for splitter, specifically the copyright file, I noticed that the copy of OsmosisRuntimeException.java included in the source still states that it's licensed under the GPL (without a version), whereas the recent osmosis source places it in the public domain like the rest of Osmosis. See: https://github.com/openstreetmap/osmosis/blob/master/osmosis-core/src/main/… The attached patch updates the OsmosisRuntimeException.java file included in the splitter source with the current version from the osmosis source. The only change is the license statement. Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

2 1

Problem in splitter (Africa)
by Gerd Petermann 07 Jan '15

07 Jan '15

Hi all, I wonder what splitter should do in this case: Stephen uses paramter --max-nodes=80000 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

5 20

Commit: r3393: improve error message when a sub option like floodblocker is
by svn commit 07 Jan '15

07 Jan '15

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

5 14

Commit: r3394: improve the message when there are too many POIS at the same place
by svn commit 07 Jan '15

07 Jan '15

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

1 0

Re: [mkgmap-dev] SVN commit problem
by Mike Baggaley 07 Jan '15

07 Jan '15

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

2 2