Re: [mkgmap-dev] minxed-index branch ready for trunk?
Hi Gerd my impression was that everybody was happy with the results. What do you think? Yes I do want to push on and get it merged this time. I think that there may still be a problem with the gmapsupp index and I think we should have a way of dealing with removing common words, especially when they are first as in 'Rue', 'Calle' etc. Doesn't have to be complete, just ready to be used and improved. I'll write some more tomorrow. ..Steve ___ 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/WanMil, I now have a mechanism working that has no performance overhead. I have derived a new class from Node and have moved the evaluation of the location to when getLocation is first called in the new class. I have also improved the algorithm by progressively using bigger bitmaps if a small one doesn't produce a suitable result. I'm now looking at doing the same for multi-polygons before putting together a patch. I should have something for you to try shortly. Regards, Mike From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 08 January 2015 20:23 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] small issue with Way.getCofG() Hi WanMil, yes, I had something like this in mind. StyledConverter could call the POIGenerator for each polygon. The POIGenerator creates a dummy node, opies the tags, adds the mkgmap:area2poi=true tag and checks if the style produces a map element. If yes, it calculates the coords and returns the node which is than passed to addNode. Anyhow, this change is only useful when performance is a problem. I once had a similar idea for mp-processing. Gerd Date: Thu, 8 Jan 2015 20:55:46 +0100 From: wmgc...@web.de mailto:wmgc...@web.de To: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] small issue with Way.getCofG() Hi Gerd, I think there are many drawbacks to move the POI generation into the style code. At least it will complicate the style code. Maybe it is better to implement your idea directly in the POIGeneratorHook. If it has access to the point style it could check itself if the polygon will (probably) create a POI. Maybe it could first test if there is any overlap of the polygon tags with the tags used in the points file. Then it could pass an artifical POI through the points style and check if a POI is created (finally rules might be disabled to speed up the processing). The hook might also decide how to proceed dependent on the complexity of the polygon. By the way: Did you think of having different methods depending on the use case? So one getCofG() for POI placement, one getHouseNumberPoint() for housenumber processing etc. It sounds like it is hard to find one algorithm that fits all. WanMil Hi Mike, reg. POI for polygons like rivers etc: The current algo calculates a POI for each polygon before any style rule is applied. If the calculation of the Coord takes a lot of time, and many of the POI are later dropped in the points rules, maybe it is possible to create a dummy object first, pass it through the style rules, check if it produces a map object, and calculate the exact position only for those. I think we would have to change/remove the POIGeneratorHook and call it on the fly, but I don't see any big problem with that. Gerd From: m...@tvage.co.uk mailto:m...@tvage.co.uk To: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 7 Jan 2015 09:29:51 + Subject: 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 mailto: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
Re: [mkgmap-dev] random housenumbers
Hi Gerd
I guess we have to
1) add a flag to RouteNode which says whether or not the node is used
for routing. A RouteNode for housenumbers will have arcs
like a normal one, but they are only used to allow placing the
housenumber infos.
I don't think the change will involve RouteNode.
Currently we have road lines made up of Coord
and CoordNode. There should be something between those two.
Lets call it NumberCoord here for want of a better name.
Add a method to Coord that returns false.
class Coord {
public boolean isNumberNode() { return false; }
}
// Then NumberCoord extends that and overrides it to return true.
class NumberCoord extends Coord {
... isNumberNode() { return true; }
}
Then CoordNode extends NumberCoord.
Then in LinePreparer around line 380 where it says:
* Current thought is that the node indicator is set when
* the point is a node. There's a separate first extra bit
* that always appears to be false. The last points' extra bit
* is set if the point is a node and this is not the last
* polyline making up the road.
* Todo: special case the last bit
The comment needs the 'current thought' changing ;)
Then use co.isNumberNode() instead of co.getId()
2) change RoadDef.writeNod2()
to create the bitstream using this flag.
3) What happens with the complex
routing routines in RouteNode, e.g.
addArcsToMajorRoads() ?
I don't think you would have to change any of that so
long as there are no invalid assumptions in there.
Do we have to add arcs to the housenumber nodes ?
No. Well you could but then they would be routing nodes ;)
4) In StyledConverter I see a call
road.setStartsWithNode(nodeIndices.get(0) == 0);
which seems to always set the bit to true.
The code in RoadHelper may be work different.
Do you have an example that explains this?
I believe that code is intended to deal with the case
where the first node is a dead end.
Attached patch shows how I intend to implement the random
housenumbers, it doesn't do anything useful yet.
Maybe you can tell me if I am on the right way?
I think that is probably not the place to start as explained above.
Sorry I may have been misleading as there are so many things called
Node. We need some new terms!
The NetCheck program was written after this was understood so
it will correctly display housenumbers in this case. The output
is a bit verbose, just look for the Number lines.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] random housenumbers
Hi Steve,
thanks, don't know what I have missed before that I went so wrong :-O
Two open questions:
1) Why do we need the new class NumberCoord?
I'd say we just have to use one of the spare bits in the Coord.flags field.
Major problem is to find all places where we create copies of existing
Coord instances and make sure that the info is copied properly?
2) Is a CoordNode always also a number node? Or is it possible
to combine the numbers for multiple arcs? I guess that would allow
to save some bytes.
Gerd
Date: Thu, 8 Jan 2015 23:26:04 +
From: st...@parabola.me.uk
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] random housenumbers
Hi Gerd
I guess we have to
1) add a flag to RouteNode which says whether or not the node is used
for routing. A RouteNode for housenumbers will have arcs
like a normal one, but they are only used to allow placing the
housenumber infos.
I don't think the change will involve RouteNode.
Currently we have road lines made up of Coord
and CoordNode. There should be something between those two.
Lets call it NumberCoord here for want of a better name.
Add a method to Coord that returns false.
class Coord {
public boolean isNumberNode() { return false; }
}
// Then NumberCoord extends that and overrides it to return true.
class NumberCoord extends Coord {
... isNumberNode() { return true; }
}
Then CoordNode extends NumberCoord.
Then in LinePreparer around line 380 where it says:
* Current thought is that the node indicator is set when
* the point is a node. There's a separate first extra bit
* that always appears to be false. The last points' extra bit
* is set if the point is a node and this is not the last
* polyline making up the road.
* Todo: special case the last bit
The comment needs the 'current thought' changing ;)
Then use co.isNumberNode() instead of co.getId()
2) change RoadDef.writeNod2()
to create the bitstream using this flag.
3) What happens with the complex
routing routines in RouteNode, e.g.
addArcsToMajorRoads() ?
I don't think you would have to change any of that so
long as there are no invalid assumptions in there.
Do we have to add arcs to the housenumber nodes ?
No. Well you could but then they would be routing nodes ;)
4) In StyledConverter I see a call
road.setStartsWithNode(nodeIndices.get(0) == 0);
which seems to always set the bit to true.
The code in RoadHelper may be work different.
Do you have an example that explains this?
I believe that code is intended to deal with the case
where the first node is a dead end.
Attached patch shows how I intend to implement the random
housenumbers, it doesn't do anything useful yet.
Maybe you can tell me if I am on the right way?
I think that is probably not the place to start as explained above.
Sorry I may have been misleading as there are so many things called
Node. We need some new terms!
The NetCheck program was written after this was understood so
it will correctly display housenumbers in this case. The output
is a bit verbose, just look for the Number lines.
..Steve
___
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 Miike, sounds great! Reg. mp-processing: Not sure what you plan to do here. Maybe that is not so easy, keep in mind that we have the area_size() style function, so you probably have to calculate at least the outer shape before you can check if the style is creating a map object. Gerd From: m...@tvage.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Date: Fri, 9 Jan 2015 00:20:56 + Subject: Re: [mkgmap-dev] small issue with Way.getCofG() Hi Gerd/WanMil, I now have a mechanism working that has no performance overhead. I have derived a new class from Node and have moved the evaluation of the location to when getLocation is first called in the new class. I have also improved the algorithm by progressively using bigger bitmaps if a small one doesn’t produce a suitable result. I’m now looking at doing the same for multi-polygons before putting together a patch. I should have something for you to try shortly. Regards,Mike From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 08 January 2015 20:23 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] small issue with Way.getCofG() Hi WanMil, yes, I had something like this in mind. StyledConverter could call the POIGenerator for each polygon. The POIGenerator creates a dummy node, opies the tags, adds the mkgmap:area2poi=true tag and checks if the style produces a map element. If yes, it calculates the coords and returns the node which is than passed to addNode. Anyhow, this change is only useful when performance is a problem. I once had a similar idea for mp-processing. Gerd Date: Thu, 8 Jan 2015 20:55:46 +0100 From: wmgc...@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] small issue with Way.getCofG() Hi Gerd, I think there are many drawbacks to move the POI generation into the style code. At least it will complicate the style code. Maybe it is better to implement your idea directly in the POIGeneratorHook. If it has access to the point style it could check itself if the polygon will (probably) create a POI. Maybe it could first test if there is any overlap of the polygon tags with the tags used in the points file. Then it could pass an artifical POI through the points style and check if a POI is created (finally rules might be disabled to speed up the processing). The hook might also decide how to proceed dependent on the complexity of the polygon. By the way: Did you think of having different methods depending on the use case? So one getCofG() for POI placement, one getHouseNumberPoint() for housenumber processing etc. It sounds like it is hard to find one algorithm that fits all. WanMil Hi Mike, reg. POI for polygons like rivers etc: The current algo calculates a POI for each polygon before any style rule is applied. If the calculation of the Coord takes a lot of time, and many of the POI are later dropped in the points rules, maybe it is possible to create a dummy object first, pass it through the style rules, check if it produces a map object, and calculate the exact position only for those. I think we would have to change/remove the POIGeneratorHook and call it on the fly, but I don't see any big problem with that. Gerd From: m...@tvage.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 7 Jan 2015 09:29:51 + Subject: 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
Re: [mkgmap-dev] How to display U. S. highway shields with numbers only
Hi Mark 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?) In the style manual I can only find the URL http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html which is still valid and correct. Have I missed one elsewhere? Its a reference work however and you would probably do better to read a short introduction elsewhere as you would only need a few of the constructs for use in style files. Best wishes ..Steve ___ 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 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: Anyone can create their own branches in subversion by following these steps: 1. Sign up on the web site. These will be your svn username and password too. 2. Go to http://www.mkgmap.org.uk/svn/repo/mkgmap (or the appropriate page for splitter etc). 3. Click the 'Create' button for 'Enable my own branch'. This does two things. First it creates a new branch, but it also enables your username for use. 4. The page should now show details of how to access the branch that was just created. In particular note that the URL differs from the read-only URLs by using https rather than http and there is an extra '/svn/' before mkgmap. It should look something like: https://svn.mkgmap.org.uk/svn/mkgmap/u/mike.b/main 5. Check out that URL and you should be good to go. I don't know exactly how TortoiseSVN works, I expect you would be prompted for username details on first commit. Checkout still doesn't require a password if I remember correctly. There is nothing special about that main branch, once you are set up you can create other branches under your user area. Of course since nobody has used this feature for a while and so it may not work. Let me know if there are any problems. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Issues with --housenumbers
gerd unshure why , but some messages from the list , are hitting my SPAM box , even though i say this list is ok any ideas stephen On Thu, Jan 8, 2015 at 9:09 PM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: 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 ___ 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] Issues with --housenumbers
Hi Stephen, maybe I am writing too many posts ;-) I think you have to ask the mail provider. I use two methods to post to this list: Directly from Outlook.com or via GIS. Used GIS for this one. Gerd steve sgalowski wrote gerd unshure why , but some messages from the list , are hitting my SPAM box , even though i say this list is ok any ideas -- View this message in context: http://gis.19327.n5.nabble.com/Issues-with-housenumbers-tp5829402p5829425.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] License of OsmosisRuntimeException.java copy in splitter source is outdated
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/java/org/openstreetmap/osmosis/core/OsmosisRuntimeException.java 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 Index: src/org/openstreetmap/osmosis/core/OsmosisRuntimeException.java === --- src/org/openstreetmap/osmosis/core/OsmosisRuntimeException.java (revision 417) +++ src/org/openstreetmap/osmosis/core/OsmosisRuntimeException.java (working copy) @@ -1,4 +1,4 @@ -// License: GPL. Copyright 2007-2008 by Brett Henderson and other contributors. +// This software is released into the Public Domain. See copying.txt for details. package org.openstreetmap.osmosis.core; ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] prob in africa map 3
Hi Stephen, info said bb box is to big I don't see anything wrong in the splitter log, I guess you are talking about mkgmap again? You changed the max-nodes from 8 to 60. If you did not change your style files heavily this will not work. As the new message in splitter says: Consider to use a higher resolution. So, maybe try --resolution=14 --max-nodes=20 for splitter if you want to stick to your style. Gerd Date: Thu, 8 Jan 2015 14:22:35 +1000 From: steve.sgalow...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: [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 ___ 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, reg. POI for polygons like rivers etc: The current algo calculates a POI for each polygon before any style rule is applied. If the calculation of the Coord takes a lot of time, and many of the POI are later dropped in the points rules, maybe it is possible to create a dummy object first, pass it through the style rules, check if it produces a map object, and calculate the exact position only for those. I think we would have to change/remove the POIGeneratorHook and call it on the fly, but I don't see any big problem with that. Gerd From: m...@tvage.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 7 Jan 2015 09:29:51 + Subject: 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 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
Re: [mkgmap-dev] prob in africa map 3
i will try it again gerd , even with asia , that has never worked for me in a while ok no i am not changing my poi files yet , just wish to slowly change it over and make shure it works with just a small one first . the africa bombed out , when i had nodes at 8 nodes , so i changed it to 60 nodes , i will see what asia does for me especiall when it has so many poi and nodes ok stephen On Thu, Jan 8, 2015 at 7:20 PM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Stephen, info said bb box is to big I don't see anything wrong in the splitter log, I guess you are talking about mkgmap again? You changed the max-nodes from 8 to 60. If you did not change your style files heavily this will not work. As the new message in splitter says: Consider to use a higher resolution. So, maybe try --resolution=14 --max-nodes=20 for splitter if you want to stick to your style. Gerd -- Date: Thu, 8 Jan 2015 14:22:35 +1000 From: steve.sgalow...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: [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 ___ 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
[mkgmap-dev] Issues with --housenumbers
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] random housenumbers
Hi Steve, maybe you can help me with that? I seem to have no img file with an example. I guess we have to 1) add a flag to RouteNode which says whether or not the node is used for routing. A RouteNode for housenumbers will have arcs like a normal one, but they are only used to allow placing the housenumber infos. 2) change RoadDef.writeNod2() to create the bitstream using this flag. 3) What happens with the complex routing routines in RouteNode, e.g. addArcsToMajorRoads() ? Do we have to add arcs to the housenumber nodes ? 4) In StyledConverter I see a call road.setStartsWithNode(nodeIndices.get(0) == 0); which seems to always set the bit to true. The code in RoadHelper may be work different. Do you have an example that explains this? Attached patch shows how I intend to implement the random housenumbers, it doesn't do anything useful yet. Maybe you can tell me if I am on the right way? Gerd Date: Mon, 22 Dec 2014 10:17:27 + From: st...@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] random housenumbers Hi Gerd how can I make sure that Garmin programs do not try to interpolate housenumbers for places where this is not wanted? Is it possible that there is another attribute besides ODD,EVEN,BOTH ? No, you just have a range consisting of the one number to that same number. eg E,42,42. If there are several random numbers on a segment of road then you would have to introduce new flagged nodes at appropriate places along the road. By flagged node I mean that it has what we call the extra-bit set. See LinePreparer. Currently I believe that we only set this bit on road junction nodes, but it can be set on any point in the road. Unfortunately there may be assumptions in the routing code about usage of the extra bit, since we didn't know that until house numbers. The house number code should be OK in that respect though. Also when adding extra nodes along the road you would have to be careful that they are not removed by any of the simplifying filters. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev route-nodes-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] minxed-index branch ready for trunk?
Hi Steve, my impression was that everybody was happy with the results. What do you think? Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] minxed-index branch ready for trunk?
Hi, I have never tested gmapsupp.img created by mkgmap. I have used MapInstall to create gmapsupp from map installed on PC and it worked well enough for me. -- 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] minxed-index branch ready for trunk?
I have tested a gmapsupp.img created by mkgmap on my Oregon. It can't find any street when skipping the place name, so it seems you need to specify the place name, otherwise it wont work. This does not happen with the trunk version, it can also find streets if no place name is entered. With a gmapsupp.img created by Mapsource the mixed index branch works ok when skipping the place name. ___ 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 WanMil, yes, I had something like this in mind. StyledConverter could call the POIGenerator for each polygon. The POIGenerator creates a dummy node, opies the tags, adds the mkgmap:area2poi=true tag and checks if the style produces a map element. If yes, it calculates the coords and returns the node which is than passed to addNode. Anyhow, this change is only useful when performance is a problem. I once had a similar idea for mp-processing. Gerd Date: Thu, 8 Jan 2015 20:55:46 +0100 From: wmgc...@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] small issue with Way.getCofG() Hi Gerd, I think there are many drawbacks to move the POI generation into the style code. At least it will complicate the style code. Maybe it is better to implement your idea directly in the POIGeneratorHook. If it has access to the point style it could check itself if the polygon will (probably) create a POI. Maybe it could first test if there is any overlap of the polygon tags with the tags used in the points file. Then it could pass an artifical POI through the points style and check if a POI is created (finally rules might be disabled to speed up the processing). The hook might also decide how to proceed dependent on the complexity of the polygon. By the way: Did you think of having different methods depending on the use case? So one getCofG() for POI placement, one getHouseNumberPoint() for housenumber processing etc. It sounds like it is hard to find one algorithm that fits all. WanMil Hi Mike, reg. POI for polygons like rivers etc: The current algo calculates a POI for each polygon before any style rule is applied. If the calculation of the Coord takes a lot of time, and many of the POI are later dropped in the points rules, maybe it is possible to create a dummy object first, pass it through the style rules, check if it produces a map object, and calculate the exact position only for those. I think we would have to change/remove the POIGeneratorHook and call it on the fly, but I don't see any big problem with that. Gerd From: m...@tvage.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 7 Jan 2015 09:29:51 + Subject: 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.
Re: [mkgmap-dev] Issues with --housenumbers
Hi WanMil, First of all: In most cases the existing code works quite well, but in many special cases it fails. I remember when I started to implement the house number support for OSM data I thought oh just give it a short try if a very simple algorithm can convert some of the house numbers to the mkgmap format. I am surprised how good it works :-) Anyhow rather no specials are supported and OSM sometimes is also an abbreviation for Open Specials Map... Well, when you coded it I found only a few housenumbers in my area, so I did not even care about the result. Nowadays the data is much better, but there are also many more errors. 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. Are single house numbers supported by the mkgmap format or do we always have to attach an address interpolation to a street segment? If single house numbers are not supported it is possible only to ignore them or to cut the street into little segments. If I got it right, we could add nodes and assign one number to each. I've started the new branch housenumbers2 to experiment with this. 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 . Maybe this should be changed so that mkgmap tries to detect if the house numbers are in/decreasing, even/odd/mixed and then use min/max(housenumber) instead of first/last(housenumber)? Yes, tried that in the branch, seems to improve many cases where the code in trunk is wrong. 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. I think this can be fixed only by associated street relations. It would also be possible to calculate a candidate list of street segments for each house number and then try to assing the house number so that it fits best. But this sounds quite complex. I'd like to repair the cases where we have addr:interpolation info. The rest is more complex, but seldomly needed. d) In some cases we might be able to detect wrong OSM data as such and print a corresponding message. Can you give some examples beside the easy ones (no street found for house number 999 or house number without street name tag)? I found a few wrong numbers in my area because they did not match the odd/even rule which is used almost everywhere. Also, a sequence like 2,4,6,8,10,1,14 looks like the 1 should be a 12. Later I noticed this link: http://gulp21.bplaced.net/osm/housenumbervalidator/ 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. Yep. Can you estimate how many percents of house number are not handled well by the current algorithm? I think in my hometown I found more errors caused by wrong OSM data. The branch is already a little bit better. In areas that use addr:place mkgmap doesn't work at all until we support random numbers. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Issues with --housenumbers
Hi Gerd, Hi all, during the last weeks I tried to improve the --housenumber option. Great! First of all: In most cases the existing code works quite well, but in many special cases it fails. I remember when I started to implement the house number support for OSM data I thought oh just give it a short try if a very simple algorithm can convert some of the house numbers to the mkgmap format. I am surprised how good it works :-) Anyhow rather no specials are supported and OSM sometimes is also an abbreviation for Open Specials Map... 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. Are single house numbers supported by the mkgmap format or do we always have to attach an address interpolation to a street segment? If single house numbers are not supported it is possible only to ignore them or to cut the street into little segments. 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 . Maybe this should be changed so that mkgmap tries to detect if the house numbers are in/decreasing, even/odd/mixed and then use min/max(housenumber) instead of first/last(housenumber)? 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. I think this can be fixed only by associated street relations. It would also be possible to calculate a candidate list of street segments for each house number and then try to assing the house number so that it fits best. But this sounds quite complex. d) In some cases we might be able to detect wrong OSM data as such and print a corresponding message. Can you give some examples beside the easy ones (no street found for house number 999 or house number without street name tag)? 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. Yep. Can you estimate how many percents of house number are not handled well by the current algorithm? WanMil 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] small issue with Way.getCofG()
Hi Gerd, I think there are many drawbacks to move the POI generation into the style code. At least it will complicate the style code. Maybe it is better to implement your idea directly in the POIGeneratorHook. If it has access to the point style it could check itself if the polygon will (probably) create a POI. Maybe it could first test if there is any overlap of the polygon tags with the tags used in the points file. Then it could pass an artifical POI through the points style and check if a POI is created (finally rules might be disabled to speed up the processing). The hook might also decide how to proceed dependent on the complexity of the polygon. By the way: Did you think of having different methods depending on the use case? So one getCofG() for POI placement, one getHouseNumberPoint() for housenumber processing etc. It sounds like it is hard to find one algorithm that fits all. WanMil Hi Mike, reg. POI for polygons like rivers etc: The current algo calculates a POI for each polygon before any style rule is applied. If the calculation of the Coord takes a lot of time, and many of the POI are later dropped in the points rules, maybe it is possible to create a dummy object first, pass it through the style rules, check if it produces a map object, and calculate the exact position only for those. I think we would have to change/remove the POIGeneratorHook and call it on the fly, but I don't see any big problem with that. Gerd From: m...@tvage.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 7 Jan 2015 09:29:51 + Subject: 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 withWay.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
